[wp-testers] Testers wanted: Plugin update testing

[Andrew Ozz]

DD32 wrote:
> Like my reply said, It should only delete it when its
> ready to copy the new files in, An alternative solution, Would be to
> move the old plugin into a "backup" folder, and then, if the upgrade
> fails, attempt to move the backup back into place.. But, Honestly, to
> me, That doesnt seem like its needed, because its going to fail to
> copy the files eitherway if thats the case... I'm open to ideas, If
> you, or anyone else can decide on a way that it should work, and it
> seems sensible, Then i'm right up there with making it so.

IMHO it shouldn't delete anything, at least for this release. Even sites 
with 20-30 plugins would accumulate only a 2-3MB if they are updated 
couple of times each.

After it checks that a newer version exists, it could work this way:

1. Try to rename the plugin's directory. Append or prepend a keyword + 
time() or something similar, store the new name in the db for later 
reference. If it fails at this step, either try other methods or tell 
the users that their server setup is not currently supported, and 
probably will be in future versions.

2. If rename was successful (means have write access and is in the right 
place), create the directory for the new version. Schedule a cron job to 
check the status of the updated plugin in about 1 min. and in case it 
failed, rename the old version back.

3. Download & extract the new version directly in that directory (no 
need to store in temp then move, save some time/resources). While 
extracting, skip the creation of the top plugin directory, basically 
make a copy of plugin's trunk, skipping any screenshots.

4. The plugins page in the admin would need to recognize the renamed 
directories and not list them as unactivated plugins. It would also need 
  a new subpage that would activate about once a month in the dashboard, 
listing all backup versions from recently updated plugins that are safe 
to delete.

The current method would probably fail for larger plugins with a lot of 
files, because of either memory or timing, as php is not that good 
dealing with network delays and unzipping. The only way seems to be to 
download large plugins file by file, putting a lot of strain on the 
plugin repository.

An alternative would be to zip the script files separately from the 
images. That way the file size would be more manageable. Then download 
any images the plugin has directly, can be scheduled as a 30 sec. cron 
job etc.

Perhaps a better solution is to concatenate all script (txt) files into 
one xml file. That way we can skip the zip class and do a simple 
unzipping in the php buffer, then parse the xml and split it in separate 
files. We have something similar in the Export/Import Posts, shouldn't 
be hard to adapt for script files and would me a lot more stable.

It also may be worthwhile checking other methods, like a "WordPress 
Maintenance" Firefox extension using Fireftp or similar (did somebody 
mention that already?), or possibly going the Fantastico way and dealing 
with the hosting companies directly.