Problem/Motivation

When implementing a hook following the hook_foo_BAR_ID_bar() pattern, the following formats are allowed (at least for D7):

  • * Implements hook_foo_BAR_ID_bar() for xyz_bar().
  • * Implements hook_foo_BAR_ID_bar() for xyz-bar.html.twig.
  • * Implements hook_foo_BAR_ID_bar() for xyz-bar.tpl.php.

For some hooks I think this can look misleading as in the following examples:

  • /**
     * Implements hook_ENTITY_TYPE_load() for node().
     */
    
  • /**
     * Implements hook_feeds_PLUGIN_TYPE_config_defaults() for parser().
     */
    

The enforcement on ending the item reference with parentheses, implies that the referenced item is a function, which in the above two examples it is not.

Background

While working on improving the coding standards for the D7 version of Feeds, I got warned about a coding standards violation for the following piece of code:

/**
 * Implements hook_features_pipe_COMPONENT_alter() for 'feeds_importer'.
 *
 * Automatically adds dependencies when a Feed importer is selected in Features.
 */

See https://www.drupal.org/pift-ci-job/824119

Proposed resolution

I therefore propose to also allow this format:

* Implements hook_foo_BAR_ID_bar() for 'xyz_bar'.

Its use however MUST be limited to items that are not a function nor a template.

Existing issues

I've been looking for existing issues to find out if there maybe is a specific reason for why the proposed format would not be allowed, but I couldn't find one so far. What I did find:

Format is already used in D8 core

I saw that D8 core already uses this format and also similar formats.

  • From field.module, Drupal 8.4.2:
    /**
     * Implements hook_ENTITY_TYPE_update() for 'field_storage_config'.
     *
     * Reset the field handler settings, when the storage target_type is changed on
     * an entity reference field.
     */
  • From block.module, Drupal 8.4.2:
    /**
     * Implements hook_ENTITY_TYPE_delete() for 'configurable_language'.
     *
     * Delete the potential block visibility settings of the deleted language.
     */

Other formats used in core:

  • From block.module, Drupal 8.4.2:
    /**
     * Implements hook_ENTITY_TYPE_delete() for menu entities.
     */
  • From node.module, Drupal 8.4.2:
    /**
    * Implements hook_ENTITY_TYPE_predelete() for user entities.
    */

Comments

MegaChriz created an issue.

jhodgdon’s picture

+1.

drunken monkey’s picture

+1

I personally prefer using double quotes in comments, but otherwise I agree, this should definitely be allowed!
+1 for allowing both single and double quotes around the variable part instead of call parantheses. (Since the Coder rule is apparently disabled by default currently, I didn't even know this wasn't allowed already.)

We should probably also make this clearer in the documentation. There, we don't even list the (explicitly allowed) variants for template files.

Dave Reid’s picture

Another format to consider is "Implements hook_NAME() on behalf of MODULENAME.module." This can be seen often used in contributed modules to implement their module's hooks on behalf of core modules (since core cannot implement contributed module hooks).

MegaChriz’s picture

@Dave Reid
That's is a good one. The D7 version of Feeds implements some hooks on behalf of core modules too. Now that is just documented as Implements hook_NAME(), with the core module documented in the @file docs:

/**
 * @file
 * On behalf implementation of Feeds mapping API for locale.module.
 */

/**
 * Implements hook_feeds_processor_targets_alter().
 */
function locale_feeds_processor_targets_alter(array &$targets, $entity_type, $bundle_name) {
  foreach (array_keys($targets) as $target) {
    $targets[$target]['preprocess_callbacks'][] = 'locale_feeds_preprocess_callback';
    $targets[$target]['summary_callbacks'][] = 'locale_feeds_summary_callback';
    $targets[$target]['form_callbacks'][] = 'locale_feeds_form_callback';
  }
}
Dave Reid’s picture

Hrm, I assume that wouldn't be valid since a file shouldn't have multiple @file docblocks?

From https://www.drupal.org/docs/develop/standards/api-documentation-and-comm...

The API module will only recognize one file docblock per file (the first one; there shouldn't be more than one).

jhodgdon’s picture

Yeah there can only be one @file per file. But that example might be a whole file of stuff Feeds implements for Core locale?