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.I think that I have discovered a bug or documentation issue in the view mode caching while developing a module that allows users to configure view modes in domain access for individual domains.
Background
The module adds additional view modes per domain per existing view mode. So for the full view mode for the node entity, it creates additional modes "Full (domain a)", "Full (domain b)", etc.
Since this was generating a large number of view modes, I have given the users options to disable certain domains from generating additional domains. When saving these settings, I do a entity_info_cache_clear() and cache_clear_all().
Issue 1: Removing a view mode defined in hook_entity_info_alter() that was enabled.
The view mode correctly no longer appears in "Custom display settings".
Issues:
- The secondary tabs are still visible.
- The tab link to the non-existent view mode display settings generates an error.
Issue 2: Re-adding the removed view mode via hook_entity_info_alter().
On the display settings, the re-added view mode appears in the "Custom display settings" again.
Issues:
- The view mode is still enabled (this is probably the expected behavior)
- The secondary tabs do not show
Resolution
This is the final solution that resolved the issue; Clearing the field, entity, general cache and rebuilding the menu.
/**
* Clears the cached entity info so that the new view modes are updated.
*/
function domain_view_modes_settings_submit($form, &$form_state) {
// Update the entity view modes.
entity_info_cache_clear();
// Clear field caches.
field_cache_clear();
// Clear the caches in case the view modes change these.
cache_clear_all();
// Fix the remaining secondary tabs in case a view mode is deleted.
menu_rebuild();
}
Adding a menu_rebuild(); to entity_info_cache_clear() was going to be my first purposed solution to this issue. but I'm think that simply documenting this in entity_info_cache_clear(); would be enough. Due to the overhead of the first, I would go with the second personally, but I would prefer a core maintainer to make this decision.
Running the former through testbot to see what happens and a stab at the documentation in the other.
| Comment | File | Size | Author |
|---|---|---|---|
| drupal-entity-info-doco.patch.txt | 589 bytes | Alan D. | |
| drupal-entity-info-menu-rebuild.patch | 470 bytes | Alan D. | |
Comments
Comment #2
marcingy CreditAttribution: marcingy commentedThis is a support request as far as I can tell.
Comment #3
Alan D. CreditAttribution: Alan D. commentedComment #4
Alan D. CreditAttribution: Alan D. commenteddrupal-entity-info-menu-rebuild.patch queued for re-testing.
Comment #5
Alan D. CreditAttribution: Alan D. commentedCross-post. I've got it working, with multiple cache clearing and a menu rebuild, but it was a major developer WTF if you are dynamically altering the view modes (not that many users will be!)
Comment #6
Alan D. CreditAttribution: Alan D. commentedVerbose title, but better explains the real issue.
Real world use cases:
Module upgrade (without any updates) renames a view mode
Dynamic view modes (this particular use-case)
[Maybe] Changing bundle path URL without update script
Basically, this function is designed to reset the data collected by entity_get_info(), but the change could potentially leave broken menu links and invalid cached content (ie: cached content from a view mode doesn't exist anymore)
Comment #7
tstoecklerI don't think this is a support request. I think this is a bug, but changing to "task" for now.
Here's my two cents:
I think if someone changes entity information it makes sense for them to have to call entity_info_cache_clear(). That's just a trade-off for the caching. And it's also very easily discoverable. If debug(entity_info()) isn't returning what is in your hook_entity_info(), then there must be a layer in between. And a quick search on api.drupal.org will quickly yield entity_info_cache_clear().
But having to call a handful of cache reset and rebuilding functions in a particular order is neither intuitive nor developer time well spent.
So, if we reasonably can, we should try to make life a bit easier and try to automate some of this.
Comment #21
smustgrave CreditAttribution: smustgrave at Mobomo commentedWonder if this is still a valid task for D10?