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