Stomping WPGMappity Bugs

Version 0.5.6 of the plugin is out and from my testing it stomps on the two remaining bugs of the 0.5 upgrade:

[wpgmappity = 0]

This was happening because some databases didn’t like the original update code.  The table structures were therefore still in the old state. When a map was saved MySQL stomped its feet and refused to persist because the table structure didn’t match the query.

This was fixed several patches ago for new updaters, but people that upgraded immediately found their DB’s “wedged.”  The upgrade scripts weren’t running because the plugin reported that it was on the newest version, but that wasn’t true.

0.5.6 sidesteps this and updates older versions.

Edit screen is only showing 5 markers

If you had more than 5 markers on a map there was a decent chance that you weren’t seeing them all when you popped open the map in the edit screen.

This wasn’t an error in the plug-in directly, it was the Google geocoding API hitting its rate limit.  Google stops returning results and the markers couldn’t build themselves.

Both a fix and a workaround ships in 0.5.6.  The JS that builds the markers on import to the edit screen was re-written to load each marker with a non-blocking, asynchronous delay.  You will notice markers stagger themselves onto the screen when you edit a map with many markers.  Secondly, there is a workaround that “fakes” the address data if for any reason the goecode fails.  The marker will still be built, but there will be a “sorry couldn’t get the address” note in the edit screen.

In the furure I’ll just persist the marker address at creation time.  For now though – this corrects the problem.

Its also important to note that the visitors to your blog are “immune” to this problem.  The only time the Geocoding API is called in rapid succession was when editing a map in the admin pannel.

So thanks to all that have been providing feedback.  Its been very very valuable.

Google Map Builder Added

Need to build an advanced Google Map outside of WordPress? No problem:

Google Map Builder by WPGMappity

The map builder is the same interface you are used to in the WordPress plugin, but lives live in an HTML page.  Build your map, preview the results, and then generate the code you need to copy and paste into your own web page.

WP Gmappity Google Group Started

So WP GMappity is rounding the corner of 12,000 downloads and appears to have been received well.  Thousands of people are using it, and after talking with some users it seems that it is a critical component in some installations.

I have been receiving quite a bit of email about the plug-in lately and wanted to open up a better resource for discussion and help requests than just the comments section.

A Google Group and mailing list has been started:  http://groups.google.com/group/wpgmappity

The group is public and anyone is welcome to join and discuss or ask a question.

I would also LOVE it if anyone would like to test out new versions before release.  One piece of suck about WordPress plug-in distribution is that there is no way to offer alpha or beta versions of plug-ins in a central way.  As such, release of non-trivial plug-ins is a way more nerve racking than it needs to be.

If you’d like to be a tester just hop into that Google Group and let me know.  I’ll send out notifications when stable branches are ready for testing.

WP GMappity 0.5 comming soon

Development of version 0.5 of the WP GMappity plug-in is under way.

This version will migrate to version 3 of the Google Maps API.  That will enable quite a few improvements as v3 is a great leap forward across the board.

0.5 will also allow the use of custom marker images.  This has been a frequent request.  v3 of the API also offers a nice Routing API.  I plan on targeting routing for 0.5.1.

The development branch is up on GitHub: https://github.com/mschwar99/WPGmappity/tree/v3

NOTE: Master is the only stable branch in that repo.  Installing any other branch in production would be… disappointing.

WordPress Plug-in Versioning Sucks

When WordPress 3.1 rolled out, an update in the version of the jQuery UI broke the WP Gmappity plug-in.  They were 100% right to include the new version of UI, and I should have tested the release candidate.  However, in order to fix it I had to make changes to the plug-in that could throw people running on older versions of WordPress for a loop.

As far as I can see the only real solution to try and not break back compatibility is to bloat up the code with all kinds of conditionals and package old versions of dependencies “just in case.”

And that is just talking about dependency changes, what about when the wholesale change to a WordPress internal API blows up a plug-in?

While everyone absolutely should be on the most current release of WordPress, in the real world not everyone will and even the most technically competent can wind up stuck in situations where they can’t control the version that they are running on.

I attended DrupalCon last week, and one of the first things that jumped out at me was how much more sensible module versioning is.  The page of any large module includes links to the newest version and stable versions targeting older Drupal releases:

In WordPress people can crawl through the SVN repo to find older versions, but I can’t tag a plug-in version as being stable against a certain version of WordPress.  I also can’t post development versions on the WordPress.org sites to try and get some help with testing before rolling out a new version.

How about we add something like Drupal’s versioning downloads to the WordPress.org site?  By all means keep the big red link in the top corner for folks who have no idea what repositories, tags, or dependencies are, but let me tag older versions of my plug-ins as stable against given WordPress versions.

So instead of this:

We do something like this: