[wp-hackers] Simplified Upgrade Process
Vogel, Andrew (vogelap)
VOGELAP at UCMAIL.UC.EDU
Wed Feb 1 17:35:21 GMT 2006
The page on the codex recommended deleting (specifically not
overwriting) all WP files with a few exceptions (wp-config.php, etc).
It's a pain to have to do so.
At the VERY least, the codex page should provide an alphabetized list of
the files to delete, not those to keep.
Manager of Professional Programs
University of Cincinnati
College of Pharmacy
> -----Original Message-----
> From: wp-hackers-bounces at lists.automattic.com
> [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of
> Owen Winkler
> Sent: Wednesday, February 01, 2006 10:39 AM
> To: wp-hackers at lists.automattic.com
> Subject: Re: [wp-hackers] Simplified Upgrade Process
> 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
> 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 --
> 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...
> 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.
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers