[wp-hackers] Simplified Upgrade Process
ringmaster at midnightcircus.com
Wed Feb 1 15:38:45 GMT 2006
In response to a post on wp-docs:
Vogel, Andrew (vogelap) wrote:
> The upgrade documentation is fine, though it would be easier to have a
> list of files that SHOULD be deleted (not just a list of those to KEEP).
> It's kinda the upgrade PROCESS that's a pain. Deleting files is scary
> for Joe User. It would be ideal if the files could just be overwritten.
I'm curious what files we're recommending be specifically deleted and
why. Granted, I'm not a typical user, but I essentially upgrade every
week or so essentially by copying the latest WordPress files directly
over the existing ones, and then runing upgrade.php.
I've never had an issue that required me to delete a file -- even when
is still there and everything runs just fine. If we're talking about
the cache, the upgrade code should be flushing the cache before it
starts, so you shouldn't have to do that, either.
I don't doubt that there are upgrades where it is necessary to delete
some files, but I need to understand the problem. What files and why?
Michael E. Hancock wrote:
> 8. Reactivate the original list of plugins
Vogel, Andrew (vogelap) wrote:
> Here's a plugin idea... a plugin that would take a snapshot of the
> activation status of the plugins on the site, and then batch
> activate/deactivate them. Read on...
This seems easy enough, but the point of deactivating plugins is so that
when the site comes back online after the upgrade it isn't affected by
incompatible plugins. If you reactivate all plugins directly after
install, you not only defeat the purpose of deactivating them in the
first place, but you then need to programmatically solve the horrible
puzzle of how to deactivate a bad plugin from WordPress code that does
An overall simpler solution might be to create a new plugin header that
specifies the WordPress versions that the plugin works with. Upon
install, if the new version of WordPress does not fall within a plugin's
working range (using the db version info?) then it would be deactivated.
This solution works nicely because:
1) It can inform the user that an upgrade may be required for their
plugin to work properly with their current WordPress version.
2) Users can re-activate plugins manually even with the warnings, in the
case that a plugin is known to work in spite of the version mismatch.
3) Plugins without this version header (all current plugins) will be
deactivated for not matching.
None of this would fix themes that use functions from deactivated
plugins. Apart from Podz's suggestion to wrap all plugin functions in
if(function_exists()) calls, the only solution I can think of there is
to tie a theme to the WP version number (like plugins) or to specify
plugin names/unique functions as requirements for the theme. In the
latter case, a theme would name the plugins that it requires in order to
run, and would automatically revert WP to use Default (just at upgrade
time?) if those plugins weren't activated.
Alternatively, this might be a good standard feature for a theme's
Any theme solution is impractical to enforce, therefore improbable to
happen. I can imagine a more complicated scenario (similar to how
Windows provides that boot screen that says, "Windows failed to boot,
choose an option:") where the install sets an option, "just_installed",
to 'new'. Just before attempting to display the theme for the first
time (when just_installed == 'new'), the option would be set to the IP
of the request. When the theme completes, the option would be set to
'ok'. If the option is the IP address of the current user and not 'ok'
, 'new', or some other IP when initially requested, then the theme has
failed to load, and the theme should be reset to Default. The option
could also be set to 'failed=themename' for further examination on the
Presentation tab. Or something.
/me returns to crack smoking.
More information about the wp-hackers