register the install profile in system table?
We have the ability to include _install functions in install profiles. What about updates? We're currently registering the install profile through variable_set('install_profile'). Should we instead be setting it as a row in the system table? That way we could track its schema version like we do for modules and so invoke e.g. default_update_0() when update.php is run.
On 22-Aug-06, at 4:46 PM, Nedjo Rogers wrote:
We have the ability to include _install functions in install profiles. What about updates? We're currently registering the install profile through variable_set('install_profile'). Should we instead be setting it as a row in the system table? That way we could track its schema version like we do for modules and so invoke e.g. default_update_0() when update.php is run.
+1 An excellent idea. -- Boris
Boris Mann wrote:
On 22-Aug-06, at 4:46 PM, Nedjo Rogers wrote:
We have the ability to include _install functions in install profiles. What about updates? We're currently registering the install profile through variable_set('install_profile'). Should we instead be setting it as a row in the system table? That way we could track its schema version like we do for modules and so invoke e.g. default_update_0() when update.php is run.
+1
An excellent idea.
-- Boris
yeah, makes perfect sense.
Boris Mann wrote:
On 22-Aug-06, at 4:46 PM, Nedjo Rogers wrote:
We have the ability to include _install functions in install profiles. What about updates? We're currently registering the install profile through variable_set('install_profile'). Should we instead be setting it as a row in the system table? That way we could track its schema version like we do for modules and so invoke e.g. default_update_0() when update.php is run.
+1
An excellent idea.
-- Boris
Yes! Something I've wanted for a long time. +1 ..chrisxj
Nedjo Rogers wrote:
We have the ability to include _install functions in install profiles. What about updates? We're currently registering the install profile through variable_set('install_profile'). Should we instead be setting it as a row in the system table? That way we could track its schema version like we do for modules and so invoke e.g. default_update_0() when update.php is run.
What updates would install profiles run? My understanding is that they are only for enabling modules and setting configuration on installation. -- Neil Drumm http://delocalizedham.com/
On 8/22/06, Neil Drumm <drumm@delocalizedham.com> wrote:
Nedjo Rogers wrote:
We have the ability to include _install functions in install profiles. What about updates? We're currently registering the install profile through variable_set('install_profile'). Should we instead be setting it as a row in the system table? That way we could track its schema version like we do for modules and so invoke e.g. default_update_0() when update.php is run.
What updates would install profiles run? My understanding is that they are only for enabling modules and setting configuration on installation.
Say an install profile ships with a gardened/maintained taxonomy (config). This could be updated centrally over time. Same could be said for "boilerplate" content of various kinds -- shipping with integrated help, etc. In general...it will allow for versioning. We're really just at the early stages of this...need to get a couple out in the wild. This just "feels" like the right solution... -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On Tue, 2006-08-22 at 21:52 -0700, Boris Mann wrote:
On 8/22/06, Neil Drumm <drumm@delocalizedham.com> wrote: Nedjo Rogers wrote: > We have the ability to include _install functions in install profiles. > What about updates? We're currently registering the install profile > through variable_set('install_profile'). Should we instead be setting it > as a row in the system table? That way we could track its schema version > like we do for modules and so invoke e.g. default_update_0() when > update.php is run.
What updates would install profiles run? My understanding is that they are only for enabling modules and setting configuration on installation.
Say an install profile ships with a gardened/maintained taxonomy (config). This could be updated centrally over time.
Same could be said for "boilerplate" content of various kinds -- shipping with integrated help, etc.
In general...it will allow for versioning. We're really just at the early stages of this...need to get a couple out in the wild. This just "feels" like the right solution...
But most things like this will probably be customized no? The install profiles are just a 'preset' configuration. Who ever writes updates for them would have to be careful about not thrashing user modified data. But I can also see it as being cool if you are running a modified core in your install profile, personally If I were doing that I'd rewrite the 'system_update_' .$x functions and the $module_name .'_update_'. $x functions in my profile.... .darrel.
In general...it will allow for versioning. We're really just at the early stages of this...need to get a couple out in the wild. This just "feels" like the right solution...
That's what I'm feeling. I've roughed in a patch at http://drupal.org/node/80272. The main change is generalizing the various schema-related functions. Currently they assume we're talking about modules. So we introduce a $type argument, so they can be used for whatever system item type. Anyone able to give this a review? Does this sound like the right general approach? Thanks.
participants (6)
-
Boris Mann -
Chris Johnson -
Darrel O'Pry -
Moshe Weitzman -
Nedjo Rogers -
Neil Drumm