CiviCRM Community Forums (archive)

Hi,

I have been struggling recently to add a bit of code in one of our extensions to check if the CiviGrant component is enabled/disabled, and accordingly prevent the extension from being enabled. So, this would mean that the extension could be installed irrespective of the status of the CiviGrant component, but disabled until the component is enabled.

I tried using the hook_civicrm_install() function to perform a check on the CiviGrant component, and disable the extension if the check returns false. However, when I try to disable it, I get the message that the extension does not exist. This is probably because the entry to the civicrm_extension table is done after the hook has finished its execution. My question is, what would be the best way to conduct this check to prevent enabling of the extension?

1. I don't think there's any hook where it would be defined to work as you want. You can try looking for different ways to work with hook_civicrm_install / hook_civicrm_enable to veto the activation, but if it works... then that's more a matter of luck (and you'd definitely need to re-test with future versions).

2. The first option that comes to mind -- allow the module to be installed/enabled, but sprinkle in bits of conditional logic so that it doesn't really do anything if CiviGrant is present. For example, a typical civix-based extension includes something like:

function mymodule_civicrm_xmlMenu(&$files) {
  _mymodule_civix_civicrm_xmlMenu($files);
}

which could be changed to

function mymodule_civicrm_xmlMenu(&$files) {
  $config = CRM_Core_Config::singleton();
  if (!in_array('CiviGrant', $config->enableComponents)) {
    _mymodule_civix_civicrm_xmlMenu($files);
  } else {
    CRM_Core_Session::setStatus(ts('mymodule conflicts with CiviGrant. Skipping mymodule.'));
  }
}

But you would need to (a) pick out hooks and (b) figure out how to handle transitions among edge-cases (e.g. are any DB changes required in tandem with enabling or disabling mymodule and/or CiviGrant?).

3. One could write a patch to core which allows extensions to define their own requirements-checking logic. (Something akin to Drupal's hook_requirements ?)

4. Your comment speaks about allowing the "install" to proceed but skipping the "enable" step. FWIW, this is not the model currently used by CRM_Extension_Manager. If you think of the extension-lifecycle as actions ("Install", "Disable", etc) which perform state-transitions, then the key actions and transitions are these:

  - "Install":  STATUS_UNINSTALLED => STATUS_INSTALLED
  - "Disable": STATUS_INSTALLED => STATUS_DISABLED
  - "Enable": STATUS_DISABLED => STATUS_INSTALLED
  - "Uninstall": STATUS_DISABLED => STATUS_UNINSTALLED

It's true that installation does involve calling hook_civicrm_install and then hook_civicrm_enable. One could get this effect by defining a series of smaller transitions:

  STATUS_UNINSTALLED => STATUS_DISABLED [which fires hook_civicrm_install]
  then
  STATUS_DISABLED => STATUS_INSTALLED [which fires hook_civicrm_enable]

But that's not how the current code does it. Rather, the code jumps directly from STATUS_UNINSTALLED to STATUS_INSTALLED and fires both hooks.

You can see more about the meaning of each status and how the actions are performed in CRM/Extension/Manager.php

5. The extension manager has a lot of unit-tests, so if one wanted to make changes (like introducing an additional hook_civicrm_requirements), it would be amenable to TDD.