I’m realising how differently plugin development goes when my plugins are hosted with WordPress Extend. Having the SVN repository has really simplified some things and made maintenance a lot less time consuming but I’m finding a big downside. My plugins seem to be perpetually in beta! I guess before I could upload a new feature or a bug fix and, if there was a problem with it, I could sort it out before more than a handful of users had been inconvenienced. Now, however, every new version gets wide distribution and every error has a wide public.
Yesterday, for example, I was puzzling over one person’s problem installing Similar Posts. It seemed the plugin activation code wasn’t working. I couldn’t see why until I noticed he was using WordPress 2.0. I installed the same version locally and quickly discovered the problem was with the function ‘plugin_basename’. Apparently it didn’t work correctly on Windows servers until WordPress 2.2. So I thought ‘Easy! I’ll create my own version that does work’.
It seemed obvious to me at the time that, since it was being used by each of the four post plugins, the new function ppl_plugin_basename should go into the Post-Plugin Library where the shared code lives. And so the nightmare began…
I had managed to create a circular dependency between the installation of the plugins. If I tried updating the Library the other plugins blew up. If I tried first to update one of the plugins the Library exploded.
The solution was to manually delete the plugins from the server and upload new versions with the dependency removed. Easy enough but I’m waiting for the deluge of disgruntled users who downloaded version 2.5.0.7 during its brief lifetime and can’t use the automatic updater.
The WordPress Extend repository gives developers a wider audience: great … but that’s all the more people to mess up in front of!
How do all you other plugin developers use the repository to the best advantage?
happy father’s day 😉