On Fri, 13 Nov 2009 Randy Fay wrote:
Thanks for your comments on this!
You're welcome. Let me apologize for being late in responding. Other duties kept me off list for quite a while.
While you're right that the original intent of hook_install() is to do a * schema* setup and the original intent of hook_update_N() it to update that when change occur down the line, they are both actually and widely used to set up the Drupal configuration in non-schema ways so that it's ready for the module. You yourself mentioned in a later message a variable_set() which is a configuration change, not a schema change.
I do understand that hook_install and hook_update_N have been misused to help a package maintain sanity. It is that misuse that needs to be addressed by providing either updated documentation for hook_install and hook_update_N to allow for the unintended use or to provide instruction for how to control the variable default values of a package during install and upgrade phases.
I *think* that the reality is that these two functions are often used in a variety of ways to make sure configuration is correct for the current version of the module, not just in terms of schema.
Yes, I agree that they have been used this way but shouldn't be. Perhaps a specialized menu callback that is created during the install or update phases that can is then executed on first use and removed from then removed from the router table is what is needed for this. Only the install or update phase would create the menu callback within the menu router table.
You mention the idea of setting up something for cron to do... but that would be a privately implemented hook_update_N, woudn't it?
No, a variable can be reset outside of the install/update phase so that it can be executed manually if desired. In D7 hook_update_N will only be allowed to be executed once.
In my case, which is a bit extreme, I'm writing a module whose only job is to do one-off configuration changes to staging*.drupal.org. There are 10 of these machines, and their configuration is slightly different from Drupal.org, but they are occasionally reinstalled with D.o's database. That means that the install needs to work to set the config correctly, and also that when a config change is introduced, hook_update_N (or a similar technique) needs to take care of it. We're trying to avoid reconfiguring everywhere.
The thing I dislike about this is you are requiring a installation of an update to your module just to make a configuration change. If instead you put the changes in a INI file type and create a hook_cron (or even a hook_init if the code doesn't take very long) to check for a new file date you can make the configuration changes without shutting down the site for update.php.
As others have mentioned, this pattern is quite common.
INI files are for configuration. It makes sense to use what is already available for configurations and PHP can read them for you to the point that it returns an associative array of values. You can even have a hierarchical tree array.
A valuable discussion. I'm interested in hearing more.
Yes, I agree and I would like to hear more as well. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
