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.
_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers
