Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Remove the forms out of provision that handle admin/settings/provision.
Instead use a configuration file stored in sites/default (see http://drupal.org/node/321940)
This will remove a lot of nasty form integration code in hosting too, and make provision simpler to port
to future releases.
Comments
Comment #1
adrian CreditAttribution: adrian commentedThis really needs to get done, because otherwise there's no ways for the hosting front end to control the settings of the platforms.
Comment #2
anarcat CreditAttribution: anarcat commentedso I started looking into this and it's not exactly trivial (for me at least).
the first thing I tried to do was to generate the config file (before tearing apart the configuration mechanisms...)
i have found that there is a _provision_synch() function, callable through drush, that generates the site.php for sites. that function could be used to generate the provision config file, but it's problematic since that would imply that provision is already configured!
so my current guess is that the way to generate the file would be through the hosting module itself, as an extra task. but the tasks created from the hosting module all call provision on site X, so we're back to the chicken and egg problem.
i am a bit confused about this matter now and will not work further on it until at least monday, so if anyone wants to look at it, they are welcome to do so.
Comment #3
adrian CreditAttribution: adrian commentedI'm mostly done with this.
Bit i'm working on now is the synch command to regenerate the config files.
Changing the front end to let you do a synch on a platform or a site (the url becomes an optional parameter).
The tricky bit i'm working on is communicating the custom settings to the synch command, but only for that command, and not for all the others.
Comment #4
adrian CreditAttribution: adrian commenteddone
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.