-----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-----