Gary Gale

WordPress shortcodes. A great idea. Small snippets of text with a special meaning, enclosed in left and right angle brackets. Put one of these in a WordPress post or page and WordPress automagically expands the shortcode and replaces it with the thing that the shortcode does.

WordPress has a built-in set of shortcodes and many plugins add to this repertoire, adding one or more of their own shortcodes. But here's the problem. Shortcodes are meant to be expanded and in 99.999% of cases, that's just what you want to do. But what happens if you're one of those 0.001%; you've written a plugin that adds a shortcode and you want to document it. You can't just write the shortcode in a post as WordPress will go ahead and expand it for you.

You could take the time and effort to replace the [ and ] characters which surround a shortcode, writing something like [shortcode], which is exactly what I've been doing since I released the first version of WP Biographia. But this is a long and laborious process. Frankly, it's boring and a pain in the backside.

It's a regular Thursday evening and some things are timeless; the TV transmitter at Crystal Palace is pumping out the mindless fare that is prime time television to London. It's been doing this for as long as I can remember. Of course, the number of channels have changed a bit; television used to be just three channels ... BBC1, BB2 and ITV ... when I was growing up. A quick glance at the TV set in the living room shows that the channels now start at 100 and end at 999, though there's some gaps in that range (and there's still nothing on that I want to watch).

But something else has changed. Switching the other TV set we have on, the one that isn't plumbed into Virgin Media's cable based digital TV service, shows ...

It's a glaringly obvious oversight but a few month's back I realised that given what I do for a living, there's something missing from my blog and that something is a map.

There's a whole slew of "where am I" style WordPress plugins out there, but after some careful research I decided that none of them did precisely what I wanted, which was to show the last check-in I made on Foursquare, on a map, in the sidebar of my blog.

Those that did come close still didn't do the key thing I wanted and that was to use the map I work on as part of my day job. Now don't get me wrong, I've got nothing against the maps that I could have used; Google, Bing, Mapquest and OpenStreetMap produce very fine maps and they all have the JavaScript API I'd need to display my last checkin. But none of them used my map and that means a Nokia Map.

It's taken a while but I just did this ...

$ rsync --recursive --verbose --exclude '.git' \* ~/Projects/svn/wp-biographia/trunk/
$ svn up
$ svn stat
$ svn ci -m 'Updating with v3.0 changes from master on github'
$ svn cp trunk tags/3.0
$ svn ci -m 'Tagging v3.0'

... and after much coding, rewriting, testing and documenting, v3.0 of WP Biographia has finally made it off of the starting blocks.

And so, as Where 2012 draws to a close and the lobby of the Marriott Marquis in San Francisco fills with a slew of geo'd-out delegates waiting to check out, it's time for the traditional post conference retrospective writeup. If you were at Where this year or in previous years you'll probably want to skip ahead to the next paragraph, right now. Where, previously called Where 2.0, is one of the annual maps, geo, location conferences. Though it's very Californian and eye wateringly expensive, it's still the place to go to talk, listen and announce anything related to the nebulous industry we call Geo.

After skipping Where 2.0 last year, this year I returned as part of the Nokia contingent and found out that some things had changed.

When you release some code you've written under one of the many open source licenses that exist today, if you're lucky then you can expect to get asked for help using that code. Note that I say if you're lucky. Some people I know view giving help and support as, frankly, a pain; it gets in the way and stops them thinking about a new feature or the next big thing. I take the opposite view though, I see being asked for help as a compliment; it means someone has found the code I've written and actually thinks it might, maybe, be useful, so they're using it and need a bit of support in getting it to do what they want it to do.

So if getting asked questions about code I've written isn't a problem for me, then why am I writing this? It's not the being asked as much as it is what is being asked. Support questions such as ...