5

I'm using a development -> staging -> live server workflow, and all three sites run off the same Git repository. The repository contains a few modules (a custom module for Selenium testing, etc.) that I never want to run on the live site.

Is there a way (in settings.php, perhaps?) to block a module from ever being enabled? I suppose I could also remove it from the repository, but my workflow is easier if I keep everything together.

5

In the standard Drupal deployment methodology, only code is move from dev -> stage -> prod, and only the database moves from prod -> stage -> dev. Since modules' enabled state is stored in the database, if you follow this workflow, you do not need to worry about your dev modules becoming enabled in production.

Your problem then becomes the inverse: how to insure that your dev modules are automatically enabled for you when you move your database to dev. If you use Drush sql-sync to move your database, then the example file sync_enable.drush.inc shows how to enable dev modules as a post-sql sync task. You can also automatically disable production-only modules such as securepages if you wish.

  • Yes, you're right. I was confused because my site is still in development and I am currently pushing changes from the dev database to production, since production has no data yet. This will obviously change once I launch the site. – Patrick Kenny Apr 16 '12 at 1:02
  • Marking this the answer because it clarifies why I won't have the problem I thought I would have. – Patrick Kenny Apr 16 '12 at 1:10
  • I should also add that if you wish, you may, during your development phase use the same technique to enable and/or disable modules when you push your database to your not-yet-live production system. I usually just keep the dev modules on in this scenario, until I'm almost ready to publish, at which point I turn them off on prod and adopt the prod -> dev workflow. – greg_1_anderson Apr 17 '12 at 2:33
8

You can hide modules from the admin UI by using the hidden property in the module's .info file:

hidden = TRUE

This method might be useful if you want to make sure the module is never enabled via the UI.

In case you're interested in how to do the opposite (stop a module from being disabled), it's also done in the .info file by setting the required parameter:

required = TRUE

Once you've done that Drupal will see the module as a 'core' module and stop it from being disabled through the admin UI.

  • The intent was to ask for the opposite, the question is now updated to properly reflect this. – Letharion Apr 13 '12 at 9:58
  • @Letharion So it was, I've re-arranged the answer it should make more sense now – Clive Apr 13 '12 at 10:08
  • hidden = TRUE ftw – Alex Weber Apr 13 '12 at 13:06
  • Thanks! Knowing how to hide modules to prevent them from being enabled in the Core UI is very useful. However, in my case I am more worried about accidentally enabling the modules myself. – Patrick Kenny Apr 16 '12 at 1:06
3

There is a module that does almost exactly what you ask: Environment Modules. The only difference is that is does not disable modules based on the environment (dev/staging/production), but it enables them. That means that your normal site configuration should contain only the modules you need on the live site, and you configure Environment Modules to enable additional development modules only on the dev server.

If you decide to try/use this module, I'd like to hear how it works for you.

  • drupal.org/project/env may help – Mohammad Ali Akbari Apr 13 '12 at 10:06
  • That's an interesting module, but I already use features (with the Features module) and a controller module which enables all my custom features, giving me basically the same benefit. What I'm trying to do is make sure I don't accidentally enable a module on the wrong version of the site. – Patrick Kenny Apr 16 '12 at 1:06
1

I'm not aware of a supported way to "block" a module. You could attempt to force the issue by having a module with a high weight that does

db_query("DELETE FROM system WHERE name IN ('module 1', 'module 2')");

but that seems like risky business.

I would do it in some form of deployment script, that you probably have anyway to handle the dev->stage->production workflow. My team keeps a build configuration with each site that is used to deploy the site. It would then be easy to have a list of modules that should be removed after each deploy on the production server.

1

Checkout the Habitat module. It allows you to set modules that should be enable or disabled on the different environments you have. You can set this in settings.php. I use a settings.php that loads an environment specific settings.php and in these I have the habitat setting for each environment.

-2

You can check it with module_exists

if (module_exists('mymodule', 1.2) {
  if($myliveip == 'myliveip')
   drupal_uninstall_module('mymodule');
}

And call this in your modules hook_init API

  • module_exists() accepts just the name of the module as argument; the second parameter you pass it in your snippet is not used from the function. It is not clear what the purpose of if($myliveip == 'myliveip') should be. The question has been edited; the OP is asking how to be use a module is enabled on the production server. – kiamlaluno Apr 14 '12 at 18:38
  • Adding this to hook_init() is also a weak idea, it will be called on every single page load, well after the module is disabled. – Alex Weber Apr 15 '12 at 5:09
  • @kiamlaluno, @ Alex, Thanks for figuring me the risk. – niksmac Apr 16 '12 at 3:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.