Getting rid of module-specific control logic

Question

I'm writing a module that can have some additional functionality if other modules such as Block or Menu are enabled, but I don't want to declare them as a dependency.

Currently I'm using if(module_exists($module)) { ... } to provide module-specific functionality within my custom module (in this case, defining a particular view if the module in question is present).

However I've heard that this is not the right way to provide module-specific features, and that instead I should use hooks and plugins. The only problem is that I don't really know what that means or how to get started converting my module to using those instead of if()s.

How do I define a custom view that depends on another module without using an if()?

One of the things I am trying to do is to expose that module's SQL tables to Views if the module exists, and then define a custom view with those tables.

Answer 1

If you want to provide Views with your module, dependent on enabled modules, you can implement

hook_views_default_views

This hook allows modules to provide their own views which can either be used as-is or as a "starter" for users to build from.

This hook should be placed in MODULENAME.views_default.inc and it will be auto-loaded. MODULENAME.views_default.inc must be in the directory specified by the 'path' key returned by MODULENAME_views_api(), or the same directory as the .module file, if 'path' is unspecified.

The $view->disabled boolean flag indicates whether the View should be enabled (FALSE) or disabled (TRUE) by default.

In that hook implementation, you can check if the relevant module is enabled with module_exists or function_exists when defining that View or component of the View and return the View definition(s) accordingly.

Answer 2

I think what you are looking for (or what other people meant when they said that you shouldn't use module_exists() so much) would be to implement hooks "on behalf of" another module.

E.g. Crumbs introduces a hook_crumbs_plugins(), and then it implements this hook on behalf of other modules: menu_crumbs_plugins(), taxonomy_crumbs_plugins(), etc. These hooks will only ever be triggered if the respective other modules are enabled.

Whether this is a good idea, depends. It is ok if you are really confident that the respective module will never ever implement this hook by itself. But you need to be aware that you are intruding in the other module's "namespace".

Module names as function prefixes in D7 are quite fragile anyway compared to real namespaces, so maybe we all don't care so much in D7 and just pray that nothing blows up.

Otherwise I don't think it is all too wrong to use module_exists() where it makes sense.

Next time someone says this is best practice, ask them to explain why! There are a lot of mythical and unquestioned DOs and DONTs floating around in the community..

Answer 3

If you're using hook_views_default_views, then using if module_exists is perfectly fine.

See the example how Entityform module implements that in entityform.views_default.inc file:

/**
 * Implements hook_views_default_views().
 */
function entityform_views_default_views() {
  $view = new view;
  $view->name = 'entityforms';
  // ...
  /* Display: Master */
  $handler = $view->new_display('default', 'Master', 'default');
  $handler->display->display_options['title'] = 'List';
  // ...
  $handler->display->display_options['relationships']['uid']['required'] = 0;

  if (module_exists('views_bulk_operations')) {
    /* Field: Bulk operations: Entityform */
    $handler->display->display_options['fields']['views_bulk_operations']['id'] = 'views_bulk_operations';
    $handler->display->display_options['fields']['views_bulk_operations']['table'] = 'entityform';
    // ...
    $handler->display->display_options['fields']['views_bulk_operations']['vbo']['force_single'] = 0;
  }

  /* Field: User: Name */
  $handler->display->display_options['fields']['name']['id'] = 'name';
  $handler->display->display_options['fields']['name']['table'] = 'users';
  // ...
  $handler->display->display_options['tab_options']['name'] = 'management';
  $views[$view->name] = $view;

  return $views;
}

Then if another module wants to alter the existing view definition, it can use hook_views_default_views_alter in similar way (see example here).