2

The documentation on the creation of custom modules says,

# Note: do not add the 'version' or 'project' properties yourself.
# They will be added automatically by the packager on drupal.org.

so I never put a version number in my module. But then I add difficulties writing database update scripts, I never managed to get an N in hook_update_N() that the update would recognize.

Also, my module really doesn't have any utility outside of my organization, since it has very specific domain requirements; therefore it is not, and never will, be released as a contributed module.

So, can I use a version number in my info file, and use it to generate the name of the update function? And if I insert it in an update of my module, will it be correctly managed?

1
  • 2
    hook_update_N is unrelated to any version string in the info file - if you’re having trouble with those hooks, concentrate on that issue; adding a version, while yes of course you can do, and it won’t break anything, won’t affect update hooks. What it may do, is give you a red/yellow item in the available updates list, as I think the updater will check d.org for versions of the module if version is set
    – Clive
    Commented May 18, 2021 at 15:11

1 Answer 1

4

If you host your module outside of drupal.org, including a private Git repository, or a local computer from which the module is copied on the site, you can set the version key in the .info.yml file for the module.

If the module updates are handled differently, the module could also implement hook_update_projects_alter() to tell the Update Manager not to check for that module updates, for example implementing the code shown in the documentation.

function mymodule_update_projects_alter(&$projects) {
  // Hide a site-specific module from the list.
  unset($projects['site_specific_module']);
}

As for the number N used in hook_update_N(), that number isn't related to the module version. It's just a progressive number, used from Drupal to verify which hook_update_N() implementation has been already run. hook_update_N() explains the convention for the four digits used for N.

  • 1 or 2 digits for Drupal core compatibility (for example, 8 for compatibility with Drupal 8, 10 for compatibility with Drupal 10)
  • 1 digit for your module's major release version (for example 1 for the 8.x-1.3 release)
  • 2 digits for a counting number, starting from 01

To use an existing project as example, the pathauto.install file for the release 8.x-1.11 defines, as last update hook pathauto_update_8106(); the same file for the release 8.x-1.5 has pathauto_update_8107() as last update hook, which is the latest update hook also for the release 8.x-1.8.

Note that the digit for the major version release isn't sufficient to describe the version release (which would include also the minor version), but it's not sufficient also for a major version that is higher than 9.
Note also that Drupal core won't report any error whether (for example) a 8.x-2.3 release contains mymodule_update_8133() as update hook. What described is a convention for which only the Drupal compatibility digit is required.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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