[wp-hackers] Simplified Upgrade Process

[Vogel, Andrew (vogelap)]

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.

-andrew vogel
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 
> 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
> 
> 
> 
> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>