The WordPress plugin update system isn’t verbose enough and needs to learn how to communicate with end users.
When updating plugins only the barest amount of information is passed on to the end user and in many cases hitting the “view version details” link and looking at the changelog before committing to the update provides you with only the scantest of information, if any at all.
We’re all used to backing up our databases before updating in case a plugin goes haywire, but a lot of the time we have no control over or warning about intentional changes being made by plugin authors.
Today I upgraded the Digg Digg plugin from version 4.2.2 to the latest version 4.5. A lot has changed between those two releases but you would not think it, by looking at the information I was presented with from the WordPress upgrade panel.
Even after the upgrade was completed, checking the details of the upgrade yields no useful information about what actually occurred or what was changed during the upgrade.
The upgrade to 4.5 was a disaster. The new version retained none of the settings of the previous version and also stopped working on WP 3.01 multisite which was something 4.2.2 was capable of. Even on a stand alone WP 3.01 (not multisite enabled) it lost all of it’s settings.
This is something which the average user isn’t prepared for. They’re left flailing around wondering what broke? Was it something they did? Did they screw up the upgrade? All questions, which could be easily answered if the upgrade had simply output some useful information such as:
This upgrade will perform the following tasks:
Overwrite files X-Z. Delete DB table entries A-F. Creating new tables for G-H.
This will result in a loss of your current settings.
Do you want to proceed (Y/N)
Simple, easy and everybody understands exactly what is happening before they commit to those upgrades.
I understand that this will mean a bit more work for plugin developers as they would have to pass information to WordPress in order to let it know what will take place, but is that really too much to ask?
It might get plugin developers to think about the upgrade process in a bit more depth and actually start deleting the unused information that they left lying around in the DB.
Not wanting to pick out any one plugin as an example here, but the Digg Digg plugin failed on exactly this point today.
Once the upgrade was complete it had lost the settings. When I performed a downgrade to 4.2.2 all the settings were magically restored. Well it wasn’t magic really. What actually happened was that the plugin author had decided to use a new table for the latest version of his plugin and simply neglected to remove and/or port the settings to the new one.
This my friends is why your DB’s bloat and need to be manually checked for defunct tables from time to time. Just like that lazy housemate of yours that never cleans up after himself, plugin authors often forget or neglect to clean up the dirty footprints of their plugins after upgrades and removals.
Maybe instead of relying on the good intentions of developers, if information about file deletions and database changes were a requirement of the upgrade process then maybe we’d see devlopers adopting better practices instead of hoping that we’ll magically start implementing them without incentive.
Not to mention that this information could help lower the blood pressure of many WordPress newbies.