[drupal-devel] Install system work

[neil at civicspacelabs.org]

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