[development] Update.php re-design

Gordon Heydon gordon at heydon.com.au
Mon Mar 2 23:13:09 UTC 2009

Hash: SHA1


Actually you have also missed the effort that I have been working on  
to create an update.sh which is included directly into core. see http://drupal.org/node/233091 
  which has a working version of update.php but runs from the shell.

I have also have some more changes pending that Dries has suggested.  
but before I can do these I have 2 other patches which are really  
needed for the update.sh to work before I can really push forward.

http://drupal.org/node/375494 which is a patch to change node_load()  
to restrict the size of the static cache and http://drupal.org/node/383196 
  which is tests for update.php so that when I break update.php to  
create a better merged update process to share as much code between  
update.php and update.sh.

On 03/03/2009, at 2:24 AM, Nabil Alsharif wrote:

> There seems to be a couple of projects that are trying to make
> update.php command line friendly, non of which seem to be going that
> well:
> http://drupal.org/node/194107
> http://acquia.com/blog/drupal-cli-utils
> The issue that I see is that update.php is tightly coupled with the  
> UI.
> What I would like to do is pull the functions that preform the updates

It is not a coupled as you think. other than the fixes, most of the  
update.php/update.sh is all done in the batchapi. before the batch api  
it was not as clean as it is now.

> out of update.php so that it would be possible to have a different UIs
> to modules (Web interface, cli). There are two main reasons I would  
> like
> to do this:
> 1. It would make the projects mentioned above much easier to  
> implement.
> 2. The projects mentioned above have there own implementation of
> update.php that is independent of that way drupal updates the modules.

I do have to question about how many ways do you need to do updates.  
This is why I have been pushing a shell version as this can be  
interfaced into anything that can run updates.
> I hope to endup with something along the lines of update.inc that  
> holds
> the function for preforming the updates (i.e get_updates, do_update,
> db_add_column.. etc) and update.php that has the current UI for
> updates.
> Is there any reason that this hasn't been done before? More  
> importantly
> does any one have any good reason to not separate preforming the  
> updates
> from the UI?

I am actually looking at moving most of the update.php stuff to  
update.inc, but other than the fixes which as used to allow the newer  
version to load on the previous versions database, there is not really  
that much that can needs to be  pulled out.

If you want to talk more, just grab me in IRC, or update the update.sh  


> -- 
> ----------------------------------
> Nabil Alsharif
> Bright Tree
> 573-499-1244
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you have
> received it in error, please notify the sender immediately and delete
> the original. Any other use of the email by you is prohibited. Please
> consider the environment before printing this email or its
> attachment(s).

Version: GnuPG v1.4.8 (Darwin)


More information about the development mailing list