Now that #1822458: Move dynamic parts (view modes, bundles) out of entity_info() landed in Drupal 8, I wonder if it would makes sense for us to "backport" the separate hooks for entity view modes, so that they could be re-used for features exports, and also be forward-compatible with Drupal 8.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | 1900676-hook-entity-view-mode-info.patch | 9.01 KB | dave reid |
| #13 | 1900676-hook-entity-view-mode-info.patch | 4.99 KB | dave reid |
| #12 | 1900676-hook-entity-view-mode-info.patch | 4.68 KB | dave reid |
| #6 | 1900676-hook-entity-view-mode-info-6.patch | 5.28 KB | Anonymous (not verified) |
| #5 | 1900676-hook-entity-view-mode-info-5.patch | 5.3 KB | Anonymous (not verified) |
Comments
Comment #1
dave reidComment #2
dave reidComment #3
dave reidRevised patch adding an api.php, removing unwanted code from features support, and refining comments in entity_view_mode_entity_info_alter() about precedence of view modes.
Comment #4
Anonymous (not verified) commentedThis is definitely problematic. If you have view modes for nodes defined in the new hooks and in the entity_view_modes variable, the ones defined in hooks are clobbered entirely and only the ones from the variable are included.
I was able to get better results with array_merge_recursive, but when I deliberately set up some wrong things -- a view mode defined in a hook and in the variable -- other weirdness showed up.
I can fix this. I'll post a patch shortly.
Comment #5
Anonymous (not verified) commentedHere's a patch which uses hook_entity_view_mode_info_alter() to populate the view mode array with the user-defined view modes from the system variable.
Comment #6
Anonymous (not verified) commentedHere's one without debug code.
Comment #7
dave reidDid you actually test this though? It does a merge by using the +. It works exactly like features would expect, view modes defined in the variable override and and merged into the existing view modes defined in the hooks.
Comment #8
dave reidBefore we get too far as well, it would just be good to figure out if these new hooks make sense and if they're a good idea to begin with. Note that I had to add a notice on the documentation for the hooks that these in no way can cause anything that would invoke hook_entity_info(). Maybe it would be good to add recursion protection against entity_view_mode_entity_info_alter() to prevent it from happening?
Comment #9
Anonymous (not verified) commentedI did test it, and I found that my resulting view modes were empty.
It was trying to merge a complete view mode definition array (like what the info hook would return) with this which was stored in my entity_view_modes variable.
Comment #10
dave reidOk good catch and confirmed. I'm still a little tentative about entity_view_mode implementing its own alter hook. I guess I wouldn't expect the variable view modes to be defined yet in my own module's hook_entity_view_mode_info_alter(). I guess I would liken it to CTools exportables: you have exportables which have their own hooks and alter hooks, and then you have the database 'overrides' which are separate. A module that provides CTools exportables doesn't implement hook_mymodule_default_items_alter() and pull in all the database entries.
Comment #11
dave reidI think this can be solved using drupal_array_merge_deep()...
Comment #12
dave reidLet's try this one.
Comment #13
dave reidAdding protection against entity_get_info() recursion.
Comment #14
dave reidTest with patches
Comment #15
dave reidCommitted #14 to 7.x-1.x. http://drupalcode.org/project/entity_view_mode.git/commit/4264c39