Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem
info hooks have one major design gap: if provided info changes, how to invalidate cached dependent data?
(in dataflow speak: we have only a pull and no push mechanism.)
examples:
* if hook_menu() info changes you do a menu_rebuild() (and pray that no other modules caches hook_menu() info)
* commerce_custom_line_items.module implements hook_commerce_line_items() and hardcodes a cache clear mechanism on behalf of commerce_line_items.module
Clarification
some hooks like hook_menu() are not explicitly named hook_foo_info(), but for this issue we call them info hooks too. this might change with #1751240: Fix naming pattern of info hooks.
Proposed solution
Invoking hook_foo_info_change() notifies all modules that
* hook_foo_info() data changed
* all caches need to be cleared
* and maybe other actions taken
in contrast to today's solution to e.g. calling menu_rebuild() any module can listen to this ntification.
Example
if dynamic_foo_provider.module implementing hook_foo_info() changes their info
then it calls
// invoke hook_foo_info_change() and clear dependent caches
module_invoke_all('foo_info_change', 'dynamic_foo_provider');
and any foo_info_consumer.module can invalidate its cache like this
/**
* Implements hook_foo_info_change()
*
* clears the cache when provided info changes
* @see:http://drupal.org/node/1446808
*
* TODO: for now we clear our whole cache if some module announces an info change
* we might use $module and make this more granular later
*/
function foo_info_consumer_foo_info_change($module) {
foo_info_consumer_clear_foo_cache();
}
About $module
The $module parameter can help to partially clear cache.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 0001-1446808-hook_foo_info_push-example.patch | 791 bytes | geek-merlin |
Comments
Comment #1
Damien Tournoud CreditAttribution: Damien Tournoud commentedWe have a bigger problem with the pull mechanism, which is that we cannot manage dependencies between objects defined by two info hooks, as described in #1416558: hook_entity_info(), hook_schema(), and the field system are strongly bound to each other.
We should just move completely to a push mechanism, with an event that just says "please have fun pushing new objects now".
Comment #1.0
geek-merlinadded backref
Comment #1.1
geek-merlinworkaround for d.o filter
Comment #2
geek-merlinthanks for sharing damien. i'll keep going for this one, keeping an eye on the issue you mentioned!
Comment #2.0
geek-merlinbetter doc
Comment #2.1
geek-merlinimproved
Comment #3
geek-merlinAtteched an example, think we need (guessed) about 50 implementations like this.
And the api docs.
Kindly asking for architectural review.
EDIT: note that push() became change() in #6 which this patch does not yet reflect.
Comment #4
geek-merlinComment #5
geek-merlinComment #5.0
geek-merlinimproved
Comment #6
geek-merlinChanged terminology from "push" to "change" - far more intuitive.
Comment #7
donquixote CreditAttribution: donquixote commentedI want to kindly mention that with our poor hook naming scheme, every hook can make name clashes (or for D8, we should rather say, it increases the chance for unintended hook invocations in future contrib).
We generally ignore this problem, but we should be careful introducing a ton of hooks all at once.
Should we not rather introduce just one hook? Or would that have performance implications?
Comment #8
geek-merlinAnswered this on GDO to keep this issue focused.
Comment #9
donquixote CreditAttribution: donquixote commentedMore thoughts over there, http://groups.drupal.org/node/267163#comment-850378
Esp, a suggested alternative system with a "dependency matrix"
Comment #9.0
donquixote CreditAttribution: donquixote commentedpush => change
Comment #10
xjmSo, at this point, this issue is no longer relevant for Drupal 8, since most info hooks are done away with and replaced by plugin managers, which have their own mechanisms for updating plugin definitions. There's a possibility of rescoping this issue to be about having some sort of generic mechanism for this for plugins, I guess? I retitled along those lines. That or it's wontfix.
In any case setting to active, since the previous approach in the issue is no longer applicable, and bumping to 8.1.x since we're unlikely to get below thresholds to add features in 8.0.x. We can move it back later if we do get under thresholds.
Comment #11
dawehnerAfter talking with chx this morning he wanted to open up a follow up for block, given that with derivatives you
cannot have a huge number of custom blocks. On a more abstract level the menu links introduces a system where you
can add new plugins and actually store them: #2312383: Provide a plugin manager interface which allows to add new definitions/update some/remove some
On top of that there is #2031859: Invoke an event[s] when a plugin ID disappears which ensures that things are actually announced.
Comment #12
geek-merlin@xjm #10: i totally agree.