Simplified Upgrade Process

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Simplified Upgrade Process

Michael E. Hancock
After hearing complaints that both the upgrade and the upgrade instructions
are too complicated, I wonder can the upgrade be made this simple:
1.  Upload the upgrade file
2.  Change permissions on the appropriate files/folders (wish I could just
say folder)
3.  In the Admin panel, click on the Update WordPress button and follow the
instructions
4.  Change permissions back to correct state

Of course, step 3 is where all the heavy lifting would occur.
1.  Make a backup of the database and any 'customized' files
2.  Notify the user of the nature of the 'customized' file conflict and
allow option to halt the upgrade process
3.  Notify user of any incorrect permission settings and allow option to
halt the upgrade process
4.  Delete any files or folders such as wp-content/cache
5.  Deactivate the plugins and remember what was deactivated
6.  Extract any new/upgrade script file and delete any old unused script
files
7.  Update the database as necessary
8.  Reactivate the original list of plugins
9.  Warn user of any 'customized' files/scripts that need to be addressed
10. Advice user to chmod files/folders back to appropriate state
11. Place user back at Admin panel


Michael E. Hancock

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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




_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Scott Merrill
Owen Winkler wrote:
> 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?

There have been scores of posts to the support forums about people
experiencing problems after upgrades.  Many of the people experiencing
these problems copied the new files overtop the old.  When asked to
delete the files, then copy the new files into place, the problems
disappeared.

Maybe it's snake oil, but it seems to work.

--
[hidden email] | http://skippy.net/

gpg --keyserver pgp.mit.edu --recv-keys 9CFA4B35
506C F8BB 17AE 8A05 0B49  3544 476A 7DEC 9CFA 4B35
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Scott johnson-5
In reply to this post by Michael E. Hancock
Um... I had similar thoughts and then I stepped back and thought
again.  Yes you want that but bear in mind that the simpler you make
things the more extensive the testing and development has to be.  The
classic example is if you want a 10X improvement in ease of use then
you spend 10X more "money" (ok for WP time).  So if Apple spent $50
million to make the Mac in 84 then to do "Mac Next Gen" you have to
spend $500 million.

Now that's a metaphor and not 100% true but there's some real truth
there.  So if you want to make things easy its a lot of hard work.
And it'll never work in all circumstances no matter what you do.

But if you want to swing for the fences, go for it.  I'd love for it
to be easier myself I just know how hard that is.

Scott

On 2/1/06, Michael E. Hancock <[hidden email]> wrote:

> After hearing complaints that both the upgrade and the upgrade instructions
> are too complicated, I wonder can the upgrade be made this simple:
> 1.  Upload the upgrade file
> 2.  Change permissions on the appropriate files/folders (wish I could just
> say folder)
> 3.  In the Admin panel, click on the Update WordPress button and follow the
> instructions
> 4.  Change permissions back to correct state
>
> Of course, step 3 is where all the heavy lifting would occur.
> 1.  Make a backup of the database and any 'customized' files
> 2.  Notify the user of the nature of the 'customized' file conflict and
> allow option to halt the upgrade process
> 3.  Notify user of any incorrect permission settings and allow option to
> halt the upgrade process
> 4.  Delete any files or folders such as wp-content/cache
> 5.  Deactivate the plugins and remember what was deactivated
> 6.  Extract any new/upgrade script file and delete any old unused script
> files
> 7.  Update the database as necessary
> 8.  Reactivate the original list of plugins
> 9.  Warn user of any 'customized' files/scripts that need to be addressed
> 10. Advice user to chmod files/folders back to appropriate state
> 11. Place user back at Admin panel
>
>
> Michael E. Hancock
>
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>


--
-------------------------------------------------------
J. Scott Johnson
Ookles launches 2/28/06 - have you signed up yet?
new startup: http://ookles.com/
blog: http://fuzzyblog.com/
podcast: http://techwarstories.com/
[hidden email]
aim: fuzzygroup
cell: 857 222 6459
-------------------------------------------------------
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Simplified Upgrade Process

Vogel, Andrew (vogelap)
In reply to this post by Michael E. Hancock
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: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Owen Winkler
> Sent: Wednesday, February 01, 2006 10:39 AM
> To: [hidden email]
> 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
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Owen Winkler
Vogel, Andrew (vogelap) wrote:
> The page on the codex recommended deleting (specifically not
> overwriting) all WP files with a few exceptions (wp-config.php, etc).

Does it give a reason why?  Which page is it?

Owen


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Podz
Owen Winkler wrote:
> Vogel, Andrew (vogelap) wrote:
>> The page on the codex recommended deleting (specifically not
>> overwriting) all WP files with a few exceptions (wp-config.php, etc).
>

If you after a one-size-fits-all upgrade process it just isn't going to
happen.
If the few steps in the readme work for you, great.
But remember that the upgrade instructions have to work for every single
user in as many environments as possible. Remember too that with each
upgrade someone is doing it for the first time - they see all their
posts as being at risk maybe and understandably they need slow
step-by-step instructions that they can follow with confidence.
Unless every theme author and every plugin author works within some sort
of strict framework (which just isn't going to happen) then explicit
steps are needed that cater for all users.

P.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Owen Winkler
Podz wrote:
> Owen Winkler wrote:
>> Vogel, Andrew (vogelap) wrote:
>>> The page on the codex recommended deleting (specifically not
>>> overwriting) all WP files with a few exceptions (wp-config.php, etc).
>
> If you after a one-size-fits-all upgrade process it just isn't going to
> happen.


I would rather see a simple set of instructions that works most of the
time with a "Having trouble?" link that points to a page of symptoms and
potential remedies than a convoluted 3-page installation manual.

That's just me.  :)

Owen

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Chris Lott
Having experienced the "I don't know why it works, but deleting all
files first seems to fix it" problem myself, I completely understand
why the help docs are so thorough.

+1 on making a simplified and then an "if you have problems" set of documents.

If deleting is going to be the norm, perhaps there needs to be some
jiggering of filenames and locations to make it easier to nuke an
existing installation while leaving the four or five folders and files
necessary alone. Change the prefix of the keeper folders and files
from wp- to wpk- or something? Then one could just nuke wp-*
recursively and be done with it.

c
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Scott Merrill
Chris Lott wrote:
> If deleting is going to be the norm, perhaps there needs to be some
> jiggering of filenames and locations to make it easier to nuke an
> existing installation while leaving the four or five folders and files
> necessary alone. Change the prefix of the keeper folders and files
> from wp- to wpk- or something? Then one could just nuke wp-*
> recursively and be done with it.

Move _everything_ out of the WordPress root except wp-config.php
perhaps?  Then, just delete all sub-directories _except_ /wp-content/

--
[hidden email] | http://skippy.net/

gpg --keyserver pgp.mit.edu --recv-keys 9CFA4B35
506C F8BB 17AE 8A05 0B49  3544 476A 7DEC 9CFA 4B35
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Scott johnson-5
Whoa!  like that scares me and will, almost certainly, by definition
break incoming links.  I use wordpress to power my blog site but I
have other files I ftp up like my resume which I can't format well in
WP (my fault not WP's).

I don't know the history of this list well so if this has been covered
before, smack me with a wet noodle but major system upgrades are
basically fairly rare.  This one is painful because WP 2.0 is only a
month ago.  One thing that I've seen is that installing plugins /
themes is non trivial for non geeks.  If installation is really your
interest isn't installing plugins and themes easier a better focus?

*girds self for wet noodle slappage*

Scott

On 2/1/06, Scott Merrill <[hidden email]> wrote:

> Chris Lott wrote:
> > If deleting is going to be the norm, perhaps there needs to be some
> > jiggering of filenames and locations to make it easier to nuke an
> > existing installation while leaving the four or five folders and files
> > necessary alone. Change the prefix of the keeper folders and files
> > from wp- to wpk- or something? Then one could just nuke wp-*
> > recursively and be done with it.
>
> Move _everything_ out of the WordPress root except wp-config.php
> perhaps?  Then, just delete all sub-directories _except_ /wp-content/
>
> --
> [hidden email] | http://skippy.net/
>
> gpg --keyserver pgp.mit.edu --recv-keys 9CFA4B35
> 506C F8BB 17AE 8A05 0B49  3544 476A 7DEC 9CFA 4B35
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Mark Jaquith
On Feb 1, 2006, at 1:53 PM, Scott johnson wrote:

> Whoa!  like that scares me and will, almost certainly, by definition
> break incoming links.  I use wordpress to power my blog site but I
> have other files I ftp up like my resume which I can't format well in
> WP (my fault not WP's).

Do you have these stored in /wp-admin/ or /wp-includes/ or in the WP  
root?  You should probably move them to /wp-content/ .... anything in  
WP root or /wp-admin/ or /wp-includes/ is considered fair game for  
deletion when upgrading WordPress.

As for my method of upgrade... I have WordPress in /wordpress/ I load  
up the new version of WordPress in /wordpress-upgrade/, then I just  
open up a text editor and write a bunch of "rm" and "mv" commands,  
excluding /index.php, /wp-config.php, and /wp-content/, and then  
execute it.

That leaves a lot less downtime than you would get if you deleted  
then FTP'd the stuff up there.

--
Mark Jaquith
http://txfx.net/


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Chris Lott
In reply to this post by Scott johnson-5
On 2/1/06, Scott johnson <[hidden email]> wrote:
> Whoa!  like that scares me and will, almost certainly, by definition
> break incoming links.  I use wordpress to power my blog site but I
> have other files I ftp up like my resume which I can't format well in
> WP (my fault not WP's).

As do I, but those things should be stored in wp-content or an aliased
directory outside the wp tree? That's how I try to do it anyway.

c
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Simplified Upgrade Process

Vogel, Andrew (vogelap)
In reply to this post by Michael E. Hancock
I got it from http://codex.wordpress.org/Upgrading_WordPress, though
http://codex.wordpress.org/User:Carthik/Five_Step_Upgrade tells me just
to overwrite.

I'm comfortable doing it either way, however, I think that instructing
Joe User to delete and upload (instead of overwriting) is cumbersome,
inelegant, and prone to mistakes.

-andrew vogel
Manager of Professional Programs
University of Cincinnati
College of Pharmacy
 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Owen Winkler
> Sent: Wednesday, February 01, 2006 12:41 PM
> To: [hidden email]
> Subject: Re: [wp-hackers] Simplified Upgrade Process
>
> Vogel, Andrew (vogelap) wrote:
> > The page on the codex recommended deleting (specifically not
> > overwriting) all WP files with a few exceptions
> (wp-config.php, etc).
>
> Does it give a reason why?  Which page is it?
>
> Owen
>
>
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Sebastian Herp
In reply to this post by Mark Jaquith
Mark Jaquith wrote:
> As for my method of upgrade... I have WordPress in /wordpress/ I load
> up the new version of WordPress in /wordpress-upgrade/, then I just
> open up a text editor and write a bunch of "rm" and "mv" commands,
> excluding /index.php, /wp-config.php, and /wp-content/, and then
> execute it.
>
> That leaves a lot less downtime than you would get if you deleted then
> FTP'd the stuff up there.
>
Hmm ... I am using Wordpress since version 1.0 and never had a problem
with just untargzipping the new release/nightly directly over my current
installation. Maybe we should just find the circumstances this will fail
and just fix that or detect it in upgrade.php. Don't make the process
more painful for the rest of us.
Setting permissions right, and letting an upgrade-script do the
downloading, unzipping, etc would be nice, but then I am out of the loop
and have no control over the upgrade (maybe the upgrade thing is broken
an wildly deletes files on my server ... I don't want that to happen).
The current way is easy enough. ssh user@host, wget new-archive.tar.gz,
tar -xzvf new-archive.tar.gz, open browser and call upgrade.php ... easy
enough :-)
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Carthik Sharma
In reply to this post by Vogel, Andrew (vogelap)
On 2/1/06, Vogel, Andrew (vogelap) <[hidden email]> wrote:
> I got it from http://codex.wordpress.org/Upgrading_WordPress, though
> http://codex.wordpress.org/User:Carthik/Five_Step_Upgrade tells me just
> to overwrite.
>
> I'm comfortable doing it either way, however, I think that instructing
> Joe User to delete and upload (instead of overwriting) is cumbersome,
> inelegant, and prone to mistakes.

Having thought about upgrade woes, at least for some Unix/Linux users,
the path of least resistance seems to be a tool (admin page?)  which:

1) Asks the user to upload the wp.tar.gz file containing the source
for the next version.
2) Compares the core files with the right tag in SVN to identify files
that have changed
3) Offers the files that differ from the unaltered core for download,
either individually, or as a gzipped archive.
4) Untars the new .tar.gz over the existing
5) Asks user to check and restore any of the user-modified files

For this to work, of course, the "upgrade page" should be up even if
the rest of the world is broken, which will take some imaginitive
smithing.

Advantages:
The user need only visit the upgrade page and follow through with the
steps required

Cons:
Not all hosts might have diff/tar installed (maybe bundle the
essential functions with wp then?)

Forgive me if I sound like I am speaking when I am drunk :)

Carthik.

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Ryan Boren
Carthik Sharma wrote:

> On 2/1/06, Vogel, Andrew (vogelap) <[hidden email]> wrote:
>
>>I got it from http://codex.wordpress.org/Upgrading_WordPress, though
>>http://codex.wordpress.org/User:Carthik/Five_Step_Upgrade tells me just
>>to overwrite.
>>
>>I'm comfortable doing it either way, however, I think that instructing
>>Joe User to delete and upload (instead of overwriting) is cumbersome,
>>inelegant, and prone to mistakes.
>
>
> Having thought about upgrade woes, at least for some Unix/Linux users,
> the path of least resistance seems to be a tool (admin page?)  which:
>
> 1) Asks the user to upload the wp.tar.gz file containing the source
> for the next version.
> 2) Compares the core files with the right tag in SVN to identify files
> that have changed
> 3) Offers the files that differ from the unaltered core for download,
> either individually, or as a gzipped archive.
> 4) Untars the new .tar.gz over the existing
> 5) Asks user to check and restore any of the user-modified files
>
> For this to work, of course, the "upgrade page" should be up even if
> the rest of the world is broken, which will take some imaginitive
> smithing.
>
> Advantages:
> The user need only visit the upgrade page and follow through with the
> steps required
>
> Cons:
> Not all hosts might have diff/tar installed (maybe bundle the
> essential functions with wp then?)
>
> Forgive me if I sound like I am speaking when I am drunk :)

That would be nice if file management on most hosts weren't such pain.
You have to worry with permissions, safe_mode crack, security concerns,
and so on.  See what happened when we tried to get the disk cache and
uploads going.

Ryan

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simplified Upgrade Process

Michael E. Hancock
In reply to this post by Owen Winkler
From: "Owen Winkler" <[hidden email]>
> ... 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.

Not according to this customer's comment:
http://wordpress.org/support/topic/59307?replies=8#post-318811

Michael E. Hancock
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Loading...