[development] Update.php re-design
gordon at heydon.com.au
Tue Mar 3 23:47:16 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 04/03/2009, at 2:59 AM, Nabil Alsharif wrote:
> On Tue, 2009-03-03 at 10:13 +1100, Gordon Heydon wrote:
>> 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
> 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
>> 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
>>> The issue that I see is that update.php is tightly coupled with the
>>> What I would like to do is pull the functions that preform the
>> 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
>> 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
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
> 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
> 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.
if [ $? -ne 0 ]; then
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
-----END PGP SIGNATURE-----
More information about the development