Imagine my surprise when I went to write an example.taxonomy.inc file for my module and it had no effect.

This is because core doesn't register API functions with hook_hook_info() consistently.

Cleanup issue to fix that. Affected modules:

Note that this issue (and its potential children) is only about implementing hook_hook_info() in these modules. Moving specific hook implementations to new files is a separate, follow-up task.

Comments

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Closed (duplicate)

Moving to #1107528: Stop using magic functions and force modules to declare the hooks they want to implement.

Meta webmaster issue: we don't do partial search string matching? hook_info search doesn't match hook_hook_info?!?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Title: Core does not use hook_hook_info() » [meta] Core does not use hook_hook_info()
Status: Closed (duplicate) » Active

Moving back. The above issue is not related.

Notes from @sun on the other issue:

Lastly, please note that hook_hook_info() is a very poor construct currently, and before advancing on it, we need to solve a range of major issues:

IMO, we should take the low-hanging tasks first: actually use the hook. Then solve the other problems.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

My hope for advancing further on hook_hook_info() is essentially blocked on #977052: Implement hook_hook_info() for Field API hooks -- unless that lands, I don't see a point in adding hook_hook_info() elsewhere.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I see a couple of reasons for it:

  1. Internal API consistency
  2. Benefit to contributed modules (allowing cleaner organization of code)
  3. Better testing of our own code by forcing us to eat our own dogfood.

I would not hold up advancements -- like moving aggregator functions, which are rarely used -- just because of the most difficult edge case. That approach is the enemy of progress.

Note that I just want to register the hook right now, not actually start moving functions around in core.

ralf.strobel’s picture

ralf.strobel commented

I can only see a few (but large) groups of hooks in the core modules that would make ideal candidates for lazy loading. I would go as far as saying that if they were dealt with, the rest almost seems negligible...

  1. Any cached declarations: hook_menu, hook_theme, hook_block_info...
  2. Backend-exclusive forms: hook_block_configure, hook_field_settings_form...
  3. Insert/Update/Delete actions: hook_node_update, hook_user_cancel, hook_cron

For (1) one could think about canonizing the module.info.inc files that Entity API has introduced, through an "info" group in hook_hook_info().

For (2) a file module.admin.inc seems logical, the way that some modules already introduce it. It might even make sense to load it not hook-based but whenever a page request path begins with "/admin", so that developers can effectively move all non-fontend code out of their main files.

Group (3) makes sense as read operations far outweigh the write operations on most sites, while write operations are usually responsible for more of the code.

If these three groups of hooks were eliminated, my main module files would shrink a lot, leaving mostly stuff that really is required by almost all page requests.

pounard’s picture

pounard
Primary language French
commented

I'll all for this issue, especially for the field module.

pounard’s picture

pounard
Primary language French
commented

I'm OK with the 1) group.

The "info" group sounds about right, but only for those who cache results. For exemple, hook_element_info() (or hook_elements() I don't remember) should stay in the .module files because it's not cached (and there is probably no need to cache it anyway).

pounard’s picture

pounard
Primary language French
commented
Issue summary: View changes

Updates progress.

Anonymous’s picture

Anonymous (not verified) commented
Issue summary: View changes

Added RDF module issue.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Issue summary: View changes

Linked to child issue for user.module.

mikeytown2’s picture

mikeytown2 commented

an update to this is views in core does this as well.
http://api.drupal.org/api/drupal/core!modules!views!views.module/functio...

Any reason why we don't have cron group?

mikeytown2’s picture

mikeytown2 commented
Issue summary: View changes

Linked to child issue for node.module.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Component: base system » extension system
Issue summary: View changes

I think hook_hook_info() is obsolete for D8, so I've created

#2233261: Deprecate hook_hook_info groups, mark hook_hook_info() for deletion

I was tempted to directly proceed and close this meta + all the child issues, but postponing that until there's community agreement on that stance.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Version: 8.6.x-dev » 8.8.x-dev

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Status: Active » Closed (duplicate)

Closing in favour of #2233261: Deprecate hook_hook_info groups, mark hook_hook_info() for deletion