[drupal-devel] Install system work
I will be working on the install system proposed by Adrian at http://drupal.org/node/22472. I am splitting up phase 1 at that address into: * Refactor update script to - use the Drupal theme system - generally look nicer, maybe progress bar for example - handle long updates without timing out - detect if an update is needed * Let modules hook into the database update script * Provide hooks for modules to provide and destroy database schema for automatic installation. Anyone got any ideas for what the upgrade screen should look like? -Neil
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Great =). I recommend updating the first phase patch first. It shouldn't be that hard, it's essentially an extra install.inc file, and a small modification to system.module. On 18 Jul 2005, at 9:16 PM, neil@civicspacelabs.org wrote:
I will be working on the install system proposed by Adrian at http://drupal.org/node/22472.
I am splitting up phase 1 at that address into:
* Refactor update script to Which update script? Drupal.org update script?
- use the Drupal theme system Phase 1 was using the drupal theme system ? what part of phase 1 are you referring to?
- generally look nicer, maybe progress bar for example - handle long updates without timing out I think an update bar would actually do that. The problem is timeouts happen when no new data is sent to the browser. It would need to have a reasonable fallback though.
- detect if an update is needed It already does that.
* Let modules hook into the database update script How would that help you ?
* Provide hooks for modules to provide and destroy database schema for automatic installation. I think a _uninstall() hook is prudent, if not always possible. Also, consider the fact that the site might not have write access to the module, so actually removing the file is very definitely not recommended.
Also, uninstalling a node module should not affect the node data.
Anyone got any ideas for what the upgrade screen should look like?
Yeah, but it doesn't help much without the dependency system, since it would need to pick up which other modules are required by it.
-Neil
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFC3BHQgegMqdGlkasRAikmAKCbe/gRdpUCcqFfIvJtzHGtPwNvxwCgxRJO zjzID6dQiYnE6XH3ONmCsyQ= =DeHL -----END PGP SIGNATURE-----
On Mon, Jul 18, 2005 at 10:32:16PM +0200, Adrian Rossouw wrote:
I recommend updating the first phase patch first. It shouldn't be that hard, it's essentially an extra install.inc file, and a small modification to system.module.
I think updating Drupal is currently the worst part since there is no standardization among module updating. I'm not prepared to take over that patch yet.
On 18 Jul 2005, at 9:16 PM, neil@civicspacelabs.org wrote:
I will be working on the install system proposed by Adrian at http://drupal.org/node/22472.
I am splitting up phase 1 at that address into:
* Refactor update script to Which update script? Drupal.org update script?
update.php
- use the Drupal theme system Phase 1 was using the drupal theme system ? what part of phase 1 are you referring to?
I guess this isn't exactly phase 1. Anyway, this is what I think needs to be done first.
- generally look nicer, maybe progress bar for example - handle long updates without timing out I think an update bar would actually do that. The problem is timeouts happen when no new data is sent to the browser. It would need to have a reasonable fallback though.
Yeah, fallbacks++. Basically what needs to happen is something like while (time < php time limit / 2) { do another update } send something to the browser This is actually a potential job for XmlHttpRequest. The fallback would have to work like install.php in CivicSpace which does some serving of pages with meta redirects.
- detect if an update is needed It already does that.
I think it could be friendlier.
* Let modules hook into the database update script How would that help you ?
Database upgrade script in the modules. Actually in an associated file.
* Provide hooks for modules to provide and destroy database schema for automatic installation. I think a _uninstall() hook is prudent, if not always possible. Also, consider the fact that the site might not have write access to the module, so actually removing the file is very definitely not recommended.
Yep. We might have uninstall just remove the extra things in the databasse.
Also, uninstalling a node module should not affect the node data.
Or we can just leave the database as is. Uninstall becomes "manually remove the file," which is acceptable.
Anyone got any ideas for what the upgrade screen should look like? Yeah, but it doesn't help much without the dependency system, since it would need to pick up which other modules are required by it.
I'm not trying to do dependencies yet. Just some relatively small patches to improve the upgrading UI and add in modules providing their database updates to a unified upgrading thing. -Neil
neil@civicspacelabs.org wrote:
I will be working on the install system proposed by Adrian at http://drupal.org/node/22472.
I've recently started work on a project that will need a "wizard" style solution, which is mentioned in that node (Wizard API). Is there anywhere I can get a copy of the code, rather than reinvent it? Simon
Hi, On Tue, 2005-07-19 at 07:35 +0930, Simon Lindsay wrote:
neil@civicspacelabs.org wrote:
I will be working on the install system proposed by Adrian at http://drupal.org/node/22472.
I've recently started work on a project that will need a "wizard" style solution, which is mentioned in that node (Wizard API).
Is there anywhere I can get a copy of the code, rather than reinvent it?
Yes I also would like to get a copy of this code. I know of a few places where it is really needed and would make things a lot simpler. Gordon.
participants (4)
-
Adrian Rossouw -
Gordon Heydon -
neil＠civicspacelabs.org -
Simon Lindsay