[development] Update.php re-design

Gordon Heydon gordon at heydon.com.au
Tue Mar 3 23:47:16 UTC 2009

Hash: SHA1


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

> On Tue, 2009-03-03 at 10:13 +1100, Gordon Heydon wrote:
>> Hi,
>> 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 saw that issue. I even replied to it. A working version of  
> update.php
> that can be run in a script is the reason I started this whole thing.

And since I created that issue I have had working code for Drupal 5  
and above.
>> 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.
> That is true, but people still have to manage the fixes, which means
> they (you?) have to update the script every time update.php adds a new
> fix.

The only time the update.php script is changed in during the major  
Drupal updates. ie from Drupal 5 to drupal 6. All the other changes  
are in the install files.
>> 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.
> It's not about how many ways I want to do updates it about the fact  
> that
> you might want to do updates a different way then I do.
> For example I am going to have to maintain a large number of drupal
> sites. I have an upgrade process for these sites in place that  
> includes
> some non-standard (in a drupal context) processes. It would be awesome
> if I could manage drupals database updates from there too, and the
> easies way I see to do that is via a sane update API.

All the these systems that I have seen have the ability to execute  
shell scripts. So when doing the update the management process just  
needs to execute the shell script to do the update.

I management all my clients with git, and basically I just have a post- 
update script will does the following.

./scripts/update.sh -l
if [ $? -ne 0 ]; then
   ./scripts/update.sh -u

With Debian packages you can do the same thing from the post  
installation script and the update will run.

Drupal already have an update api, which is a part of the install  
files attached to every module. My goal with the issue I raised is to  
create a minimize the common code between the 2 and allow the updates  
to be done from either method.


Version: GnuPG v1.4.8 (Darwin)


More information about the development mailing list