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 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 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? -- ---------------------------------- 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).
This makes sense, and I encourage you and others to proceed. There is no good reason it has not been done so far. On Mon, Mar 2, 2009 at 10:24 AM, Nabil Alsharif <nabil@gobrighttree.com> 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 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 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?
-- ---------------------------------- 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).
Great. This is going to be my first contribution to drupal and I don't know what the process for submitting such changes is. Do I open an issue and attach patches? Or do I have to sign up for a cvs account and commit via cvs? Would it be better to submit (patches or commit) partial but working changes, or should I wait until it's all done and then submit one big change? On Mon, 2009-03-02 at 10:22 -0500, Moshe Weitzman wrote:
This makes sense, and I encourage you and others to proceed. There is no good reason it has not been done so far.
On Mon, Mar 2, 2009 at 10:24 AM, Nabil Alsharif <nabil@gobrighttree.com> 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 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 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?
-- ---------------------------------- 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).
update.php uses the batch api I believe. It would be brilliant if the whole batch api could be run in CLI mode rather than just update.php. Good luck. Stew 2009/3/2 Nabil Alsharif <nabil@gobrighttree.com>
Great. This is going to be my first contribution to drupal and I don't know what the process for submitting such changes is. Do I open an issue and attach patches? Or do I have to sign up for a cvs account and commit via cvs?
Would it be better to submit (patches or commit) partial but working changes, or should I wait until it's all done and then submit one big change?
On Mon, 2009-03-02 at 10:22 -0500, Moshe Weitzman wrote:
This makes sense, and I encourage you and others to proceed. There is no good reason it has not been done so far.
On Mon, Mar 2, 2009 at 10:24 AM, Nabil Alsharif <nabil@gobrighttree.com> 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 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 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?
-- ---------------------------------- 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).
Nabil Alsharif wrote:
Great. This is going to be my first contribution to drupal and I don't know what the process for submitting such changes is. Do I open an issue and attach patches? Or do I have to sign up for a cvs account and commit via cvs? With this you generally open a new issue (or multiple issues) and with each issue have a patch at the ready. It's up to you to decide how fine grained you want it to be. But generally smaller patches are better (they are easier to review).
Would it be better to submit (patches or commit) partial but working changes, or should I wait until it's all done and then submit one big change? If you can I would suggest trying to make the changes incremental and submitting them over a period of time, with newer patches building on the older ones. Open them in separate issues, you can reference the older issue number in the new issue (e.g. Building on #123456 this patch...). It depends on the code in question (sometimes this just isn't possible), but generally smaller is better.
Best, Kyle Cunningham
If we refactor this properly to be UI independent it will open the door to things like using Debian's APT for updates! That would be awesome. On Mon, Mar 2, 2009 at 11:16 AM, Nabil Alsharif <nabil@gobrighttree.com>wrote:
Great. This is going to be my first contribution to drupal and I don't know what the process for submitting such changes is. Do I open an issue and attach patches? Or do I have to sign up for a cvs account and commit via cvs?
For core, it is always via patches and issues.
Would it be better to submit (patches or commit) partial but working changes, or should I wait until it's all done and then submit one big change?
Depends on if you want to get feedback early or feel you have a solid approach that is working. I would say since this is your first attempt at core contributions, submit partial stuff to get feedback. The process can be slow and may dishearten the newbies at first. But if you persist, things will get done. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
On Mon, Mar 2, 2009 at 7:24 AM, Nabil Alsharif <nabil@gobrighttree.com> wrote:
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?
The Drush patch in your first link http://drupal.org/node/194107 works like a charm. If your goal is being able to invoke update.php from the command line, take a closer looks at it. I've been using it for a while. -D
I didn't know that that patch worked! When I tried it I got a bunch of errors but that's beside the point. The issue is that it is still pretty much a re-write of update.php and as soon as something changes in update.php the two are out of sync. I'm glad that it's working though because I was a little worried that a scriptable update system wouldn't be around in time for my own personal reasons. On Mon, 2009-03-02 at 09:29 -0800, Domenic Santangelo wrote:
On Mon, Mar 2, 2009 at 7:24 AM, Nabil Alsharif <nabil@gobrighttree.com> wrote:
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?
The Drush patch in your first link http://drupal.org/node/194107 works like a charm. If your goal is being able to invoke update.php from the command line, take a closer looks at it. I've been using it for a while.
-D
I tried it on a D6 multi-site setup when it didn't work. On Mon, 2009-03-02 at 10:11 -0800, Domenic Santangelo wrote:
On Mon, Mar 2, 2009 at 10:13 AM, Nabil Alsharif <nabil@gobrighttree.com> wrote:
I didn't know that that patch worked!
Whoops, I should specify: I can only confirm firsthand that it works in D5!
-D -- ---------------------------------- 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).
Nabil Alsharif wrote:
I tried it on a D6 multi-site setup when it didn't work.
Here's the script I use for CLI updates on a D6 multi-site installation http://ninjitsuweb.com/files/drupal-update.sh.txt I think I got it from an Acquia blog post? Can't remember how much I tweaked it, if at all. To update all the sites at once, I call it from inside another script that basically looks like this: for f in `ls drupal-root/sites/` do echo "Updating: $f" php -d memory_limit=96M -f drupal-update.sh -- -s $f -r drupal-root/ -m -u & wait done To do a dry-run to check if updates are needed, replace `-m -u` with `-l -d`. Best, Matt
w00t w00t! thanks a ton. On Mon, 2009-03-02 at 14:23 -0500, Matt Chapman wrote:
Nabil Alsharif wrote:
I tried it on a D6 multi-site setup when it didn't work.
Here's the script I use for CLI updates on a D6 multi-site installation
http://ninjitsuweb.com/files/drupal-update.sh.txt
I think I got it from an Acquia blog post? Can't remember how much I tweaked it, if at all. To update all the sites at once, I call it from inside another script that basically looks like this:
for f in `ls drupal-root/sites/` do echo "Updating: $f" php -d memory_limit=96M -f drupal-update.sh -- -s $f -r drupal-root/ -m -u & wait done
To do a dry-run to check if updates are needed, replace `-m -u` with `-l -d`.
Best,
Matt
-----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-----
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.
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.
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, 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 fi 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. Gordon. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmtwYQACgkQngavurZvkrz2WwCfVfJTvPSY6JcAWLE8gnIfjUqZ NVkAn1ovcpmsRxDeGxu7GicDNLyAWixH =E6cG -----END PGP SIGNATURE-----
On Wed, 2009-03-04 at 10:47 +1100, Gordon Heydon wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi, And since I created that issue I have had working code for Drupal 5 and above. umm... ok? It's cool that you got working for all three. Soon enough there are going to be 4.
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. Just because a problem happens only once in a while doesn't mean that it isn't a problem
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.
Yes I agree with you that the goal and I hope that we can maybe work together on this. The current problems that I see are three: 1. Major upgrades, i.e from drupal 5 to 6 to 7 (to 8?). 2. Even though your script works, a lot of energy is required to re-create or change it. 3. Duplicate code between the two update scripts (web and cli) but an update.inc could resolve this.
Gordon.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkmtwYQACgkQngavurZvkrz2WwCfVfJTvPSY6JcAWLE8gnIfjUqZ NVkAn1ovcpmsRxDeGxu7GicDNLyAWixH =E6cG -----END PGP SIGNATURE-----
participants (8)
-
Domenic Santangelo -
Gordon Heydon -
Khalid Baheyeldin -
Kyle Cunningham -
Matt Chapman -
Moshe Weitzman -
Nabil Alsharif -
Stewart Robinson