Module installation hook

[a null comment so i get subscribed to the issue]

This feature is very similar to http://drupal.org/node/45831 (activate/deactivate hooks). The main difference seems to be that hook_install() is invoked only the first time that a module is enabled, whereas hook_activate() is invoked whenever a module is enabled (regardless of whether or not it's previously been enabled).

I don't think that we need install / uninstall AND activate / deactivate hooks. Only one pair is needed. Personally, I vote in favour of implementing activate / deactivate hooks, and of marking the hook_install() feature a duplicate. Perhaps the hook_activate() feature can be written in such a way that modules implementing it can check if the module is being installed for the first time. E.g.:

function foo_activate($first_install = FALSE) {
  if ($first_install) {
    // do stuff that only needs to be done when the module is enabled for the first time ever.
  }
  
  // stuff that must be done any time the module is enabled.
}

I would have to say I rather see _(activate||deactivate) and _(install||deinstall) rather than putting all the logic inside 1 _hook (function)..

It makes the code a little cleaner IMO, and easier to track/understand/change/find.

I'm going to throw a big -1 on the idea of a _deinstall hook. The last thing I want when I disable a module to test for a conflict is the tables to be deleted (which is the only thing I can think of doing with a deinstall hook).

Committed to HEAD. Thanks.

hmm... does it worth also an uninstall hook? ...almost for the same price... ???

markus_petrux, what's the usage case for an uninstall hook? symmetry is nice but if it's not ever going to be used there's not much point.

i think an uninstall hook is not bad - think about modules like administration, simple access or taxonomy access

well, besides the problem that there's not an obvious time for an uninstall hook to be called (after i delete the module?), i think the previously discussed activate/deactivate hooks are the best way for things like access modules, to do what they need to do. those hooks can be called when ever a module is activated or deactivated not the one time it's installed and then when it's uninstalled (when ever that would be). that and i think the names are a more accurate reflection of what they do.

i've written up some basic docs for hook_install

There's at least one thing that could be done on an uninstall hook. Modules could the uninstall hook to remove variables from the variables table.

Removing variables on a disable hook may not be a good place to clean up, since one could disable a module temporarily. For instance, I use the devel module, but it is only enabled when I need to check something. The rest of the time is disabled, so it doesn't impact any where else.

I would love that modules could clean up their own variables, but I would hate that that was done when I temporarily disable the module.

Well, having an uninstall hook and what use of it a contrib module makes are different things...

markus_petrux, when would this hook be called? how would you tell drupal that you wanted to uninstall a module?

Adding a new checkbox in admin/modules visible only for installed modules that support the uninstall hook that reads 'uninstall'? In this case, both hooks would be invoked if implemented, first disable_hook and then uninstall_hook.

hmm.... or nothing, heh. The difference between disable and uninstall might not be clear or easy to understand.

I'd suggest "purge" for the destructive operation. That has a much more "warning, be careful, you can screw up big time with this" feel to it than "uninstall". :-)

+1 for a hook for uninstal/disable module.

I am developer of Taxonomy Access Controll.
From time to time i get request for this from users.
(Since they forget to disable TAC on settings page, afterwards they have much trouble w/ accessing/editing nodes, because of the remaining values in table 'node_access')

So do I understand this correctly, that an install / activate / deactivate / uninstall system like in Gallery 2 is planned?

keve, as drumm pointed out, activate / deactivate is a separate issue, you should go review that patch.

scroogie, i've got no idea what gallery2's install/uninstall system looks like (maybe you could drop a link to the docs?) but i don't think there's anything "planned" here, just discussions. we really ought to move the uninstall talk to a new issue, seeing as this one's already "fixed".

Now that hook_install() exists in core, a very important issue exists that must be resolved for all 4.7 module developers. Should we now make our 4.7-compatible modules utilise this new hook to its full potential? In particular, I'm thinking of the most common installation procedure that has to take place for any contributed module: database setup.

Will 4.7 contributed modules have no need for database.mysql and database.pgsql files? Will their SQL CREATE TABLE queries instead be executed by hook_install? And if so, should the SQL be hard-coded into hook_install() implementations, or should hook_install() read in the appropriate schema file and pass it to the database? Personally, I favour the latter option, as it makes prefixing easier (particularly for non-PHP-fluent site admins), and as it doesn't mean that hundreds of database.xxsql files will be deleted (which would confuse many users, who are no doubt used to looking for them by now).

Or, alternatively, do we just recommend that module developers not implement their database setup scripts into hook_install() for 4.7? I think both options have merit, but I'd like to see a standard agreed upon for 4.7, otherwise every module developer will just do whatever he/she wants, and we really don't want that happening.

Personally, I favour the latter option, as it makes prefixing easier

I think prefixing is not that problem anymore, because you have to setup your prefix at the settings.php and the table name is in {} so that it gets converted automatically

Ahh.. good point Tobias, prefixing will indeed be automatic!! Definitely a big reason for using hook_install() for database setup. Nevertheless, I think my other reason for keeping the database.xxsql files is still valid.

jaza, if you're going to use the hook_install you should remove the .mysql and .pgsql files from your 4.7 branch. Leaving them will just confuse users who'll think that they need to install the files when the module will do it for them. That and, as mentioned, the .mysql and .pgsql files won't have the table prefixing done automagically.

As a user of Mambo/Joomla too which has installers for modules/components/mambots it's very natural to have an uninstaller function too.

The difference between activate-deactivate and install-uninstall is very clear for me.

Uninstall deletes module dependend tables or tablefields, removes module dependend variables in the system and finally removes its own directories while function "deactivate" just tells the cms not to use this module from now on.

Just use the Joomla system (xml-configuration files) for drupal?

Would make migration of modules to (and from) drupal easier too.:-)

Please post an uninstall feature as a separate request, if there isn't one already. Check the above mentioned activate / deactivate thread first.