It is important to note that you do not need to activate and deactivate plugins when upgrading the WordPress core from version to version. Here is an explanation from Ryan Boren about why . However, depending on the plugin, some of them may have an update process built into their update, i.e. updating the plugin rather than WordPress. However, I will consider your three questions and answer them as best as possible.
1. I am worried that the production and middle-tier servers have the latest code, but there are no database updates needed for the latest code?
Yes, when upgrading, if there is a change to the database schema, WordPress will not function properly if the new schema does not exist. When trying to access the admin side of WordPress, if the db version is lower than your version of WordPress expects, it will redirect you to the database update page.
WordPress sets the global name $wp_db_version in the $wp_db_version file and supports each of the migration scripts to gradually upgrade the database from each previous version to the next, until the version number is updated, see here . The following is a simpler list in the FAQ that shows how revision numbers correspond to WordPress versions. .
2. If so, does anyone have any thoughts on how I can change the Capistrano deployment code to deactivate / activate plugins?
As I said above, you usually do not need to activate / deactivate plugins after updating the kernel, unless I assume that the plugin specifically requires you to do this. If a plugin breaks when you change the layout in WordPress, plugin developers will need to release a new version. When updating this plugin, it will be disabled and restarted, and responsibility for all these developers will force everything that should happen to do so.
However, you may need to deactivate / activate separately in deployed environments such as yours, as the actual upgrade process is on a different machine and therefore probably different from the other database from which it will ultimately be used.
Perhaps the best thing you can do is to make your script deployment a remote plugin URI in WordPress, the plugin you want to post that will deactivate / activate plugins or existing one.
Perhaps some outgoing plugins can handle parts of what you are looking for, but I take the key component of your question into automation and avoid the need to go into each environment and update the plugins for each of them, so developing one you do exactly what you need, this is the way. Plugin development is possible if you use tools that WordPress already provides.
Browse the entire /wp-admin/includes/plugin.php file to find out what you might find useful. In addition, the verification code that actually handles the plugins on the admin side in /wp-admin/plugins.php is just to see how this is done. You might want to stop the deactivate_plugin hooks from clearing the plugin configuration using plugins that clear themselves, so consider passing $silent as true when you deactivate the plugin.
To make this really smooth, you probably want to grab get_option('active_plugins') to see which plugins are already activated, and just run your script on them (make sure the plugin excludes itself from the process)
3. What about changes to WordPress, for example, from 3.2 to 3.3?
Changes from 3.2 to 3.3 should be considered as no different from any other set of changes, so everything said here is applicable.
4. If Capistrano is not a tool for this - and I need to do it "manually" by going to the admin - is there a service mode tool / plugin that automates the deactivation / activation of the plugins somewhat so that any updates are activated upon activation?
I don’t think that Capistrano will do any heavy climb here, but of course it is also not so. You just need to be able to just hit the URI in the plugin, and that should make things move in the application. The important thing is that it is obvious that all these functions should be available, so you can just run it, as in an independent script.