[wp-hackers] Simplified Upgrade Process

[Owen Winkler]

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 
all of the javascript moved from wp-admin to wp-includes, the old stuff 
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...

<snip>
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 
not run.

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 
functions.php.

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.

Owen