Well the long awaited sequel to the 2.3 branch of WordPress is almost out the door. Release Candidate 1 of WordPress 2.5 is now available for those brave souls who want to do some testing before the final release. WordPress 2.5 has been covered pretty well on the blogosphere so I’m not going to go into all the details here but I did want to write a post about one new feature that could cause some problems with users upgrading.
WordPress 2.5 comes with the ability for blog owners to upgrade their plugins automatically via the Plugins Page. “Automatic Upgrade” means that instead of having to download the plugin and then ftp it to your server, you can simply click the “upgrade automatically” link and WordPress will take care of everything for you. (click the picture below to see what it looks like)
It’s a great idea and definitely one that will work okay with most basic plugins but here’s the problem(s):
- The automatic upgrade does not deactivate your plugin first and then reactivate it after upgrading. If the plugin requires activation to run any checks for WordPress version, or do any db fixes, or “activate” any new features then it won’t do this and the plugin won’t work as expected. In most cases this can be simply remedied by remembering to deactivate and then reactivate the plugin after the upgrade is complete.
- There’s no way for plugin authors to give you special upgrade instructions ahead of your upgrade. Sometimes these instructions might be important for keeping existing data or getting things to work properly. I know of at least one plugin that uses a file to store data rather than the database (bad design imho but still – a reality).
- If the plugin is in the plugins root directory instead of it’s own directory then the automatic upgrade will change it’s location. For example say you have a plugin named myfunplugin.php and it’s located at
../wp-content/plugins/myfunplugin.php– after automatic upgrade does it stuff the plugin will now be located at../wp-content/plugins/myfunplugin/myfunplugin.php. This could be a breaker for any plugin that has functions referencing the original location of the plugin. - There are other scenarios I haven’t tested yet like, what happens when a plugin changes directory structure from one version to the next?
This is a potentially a serious problem for both plugin authors and users of WordPress 2.5 and I’m posting this because I think people should be aware of it. I have posted a ticket in the WordPress Trac and I’m confident the devs are looking into it but in the meantime I recommend that blog owners use the automatic upgrade feature only if they are confident in fixing things if something goes wrong AND have checked the plugin author’s page first to see if there are any upgrade instructions.
Other than that, I’m really excited about the impending WordPress 2.5 release!
UPDATE: DD32, who is one of the contributors to the automatic upgrade feature going into WordPress 2.5 has been working on the ticket I’ve filed and a patch he created has been applied to the trunk files. Changes brought with the patch include plugin deactivation before uploading the plugin upgrade and then attempting a reactivation after the upload. This goes along way to addressing the issues I’ve raised in this post. Great work DD32!
Darren, awesome article! I wish more people took the time and did such thoughtful articles getting detailed and dirty, instead of (mindlessly) echoing what others have written — although I do appreciate people’s excitement.
And thank you for being pro-active and reporting the bug at http://trac.wordpress.org/
Well met, you have an awesome site here!
Hey, great to see you here Lloyd – keep up the good work on 2.5! Better delayed then chunky 🙂
This equally applies to anyone who manually upgrades a plugin without deactivating first. Plugin authors should not be tying upgrade routines to activation hooks. Plugins should hot-swap upgrade without problems. Same for special upgrade instructions… authors should handle that within the plugin.
Moving locations is something I’ll look into. I’m thinking it might be better to keep each plugin in its own directory. Thanks for the article!
Thanks for the clarification Mark, it makes sense that plugin authors assume responsibility for hot swappable upgrade routines… my only question then is what’s the purpose of the activation hooks for plugins?
And if this is the standards going forward then the plugin documentation on the WordPress Codex needs a major overhaul.
Especially when the codex has this as a correct way to use the ‘register_activation_hook’.
Thanks for sharing your experience Darren 😉
I see another issue and is that you miss the direct contact with the plugin’s developer and the opportunity to thank him/her his work and, by the way, he loose a lot of visits to his blog.
Ok now what hostname and password etc do u use for that feature?
@ Johnny:
The same as what you use to ftp files to your server.