[wp-hackers] Pre-upgrade and post upgrade hooks
wordpress at santosj.name
Tue Jan 8 14:16:40 GMT 2008
Well, as to why I'm working on the ticket. It is because I can and I
find the problem both slightly complicated and interesting. Besides the
pre-activation hook, I would love to have this in the core, because of
the possible ideas and solutions I could create if it was in core.
Well, that is one of the problems, is that only a fraction of the
WordPress library is included. I would have to say, that it would be fun
to build an auto-upgrader into the plugin using the hooks. I could first
check to see if there is an upgrade available in the pre-upgrade and
then in the post upgrade I could download (if possible) and upgrade
myself. Forget WordPress or the user doing it.
It appears that the more difficult solution is the acceptable approach
to the ticket's resolution. I'll try to work out a patch that replicates
the sandbox, by most likely using the existing sandbox code.
I'm unsure that displaying feedback is needed. I would like to offer it
if something failed, but if everything is working fine, then people are
used to a screen that gives them almost no relevant information. I would
like to keep it that way when there are no problems.
Sessions are just files on the server and are updated whenever you start
the session and update the contents. I've die() after updating session
data and everything was fine.
> On Tue, 08 Jan 2008 19:26:37 +1100, Ryan McCue <ryanmccue at cubegames.net> wrote:
>> DD32 wrote:
>>> I DO think that after an upgrade is run, plugins should be sandboxed, and sequentially activated, and de-activating those which cause an error to be thrown -- at least this would prevent the entire admin going down, And doesnt require plugin authors to do anything extra to allow this process to happen.
>> I think the main issue is working out how to sandbox them. I'd
>> personally be in favour of having an external PHP file, which loads the
>> specified plugin and nothing else. We then run `file_get_contents` to
>> get each one and check if the output is empty. If not, we deactivate it
>> and add a notice to the page.
> I was thinking similar to the current admin activation method.
> * Set redirection or flag in session(I'm unsure if the session data gets saved if a fatal error occurs?) for failed load
> * Include plugin
> * Change redirection or flag to show plugin loaded correctly.
> * Repeat with next plugin
> Checking plugins (1/12)
> Notice: There is an updated version of "Plugin Name"(abc.php) available, [link]Download 1.8 here[/link]
> Checking plugins (2/12)
> Checking plugins (3/12)
> Error: "My Plugin"(xyz.php) has failed to load cleanly, Plugin has been deactivated.
> Checking plugins (4/12)
> Error: "My 2nd Plugin"(z.php) has failed to load cleanly, Plugin has been deactivated. [bold]An updated version is available, [link]Download 1.8 now[/link][/bold]"
> (Of course, it would be nicer for the number to change and the errors/notices to be listed underneath)
> Main problem i see with that method would be that idealy you need to load all of WP's files to ensure that it does load correctly(I'm not sure if the admin console currently includes all WP files atm(such as those for templating and whatnot) either), and on slower hosts it could cause slower upgrades.
> Theres also the issue of those who do not use a browser to do the upgrade and instead use wget to automatically do it after the svnup
>> I personally see no flaw :)
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
http://www.santosj.name - blog
Also known as darkdragon and santosj on WP trac.
More information about the wp-hackers