[development] Update.php re-design
Gordon Heydon
gordon at heydon.com.au
Mon Mar 2 23:13:09 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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 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
issue.
Gordon.
>
> --
> ----------------------------------
> 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).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkmsaAUACgkQngavurZvkrzS1wCgpHK1JlpgRiYzCffo1K7FaLXA
tPwAoIlcyWzctBia1UpN/x1Txa0BcUYE
=Zq1e
-----END PGP SIGNATURE-----
More information about the development
mailing list