When you assign a CSS ID, custom CSS code or select a custom display renderer (e.g. IPE) to an entity bundle's default display settings, those values are not used for the display of the individual entity object nor are they copied over when that entity object's Panelizer settings are edited.
Update:
There are a few parts to this:
- When a Panelized entity is loaded it doesn't use the latest entity/bundle configuration, it uses the settings last saved in the {panelizer_entity} table.
- #1965148: Load the full Panelizer default object
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | panelizer-n1841262-10.patch | 1.86 KB | damienmckenna |
Comments
Comment #1
tchopshop commentedI guess this refers to the fact that I could not apply a css class or ID to a panelized teaser display. I really need this though. I need to apply a class to each one of my list of default layouts, so that I can further style them.
Comment #2
mediaformat commentedI was able to apply custom classes to the layouts, regions, etc in panels. admin/structure/panels/layouts
Comment #3
Laurent Ren commentedI got the same problem.
With existing entity, when I modified some options (CSS ID, link to entity, etc...) of the default display (by "default" I mean displays configurable in /admin/config/content/panelizer), these options were not used/copied to the display of the existing entity.
When creating new entity or reset displays of existing entity, these options were copied/used.
In order to resolve this problem, I added this, in PanelizerEntityDefault.class.php, in the hook_entity_load and at line ~841 :
after :
Then in my custom module :
Comment #4
damienmckennaThere's also a generic problem that the CSS is never reloaded.
Comment #5
damienmckennaComment #6
damienmckennaJust ran into this. Argh.
Comment #7
damienmckennaWorking on this tonight.
Comment #8
damienmckennaOk. This is definitely weird.
It seems that this is being caused by the fact that when the entity is saved, the full Panelizer record is saved, including the then current values for these settings; this can be confirmed by checking the {panelizer_entity} table. If the default is updated these settings are not reloaded, Panelizer just uses whatever values had been saved in the {panelizer_entity} table. However, when the entity is updated it then also updates all the Panelizer settings to the latest versions.
Because we're already dealing with not saving the defaults in #1965148: Load the full Panelizer default object, lets focus this issue on making sure Panelizer properly loads all of the settings from the named display configuration, not the {panelizer_entity} table.
Comment #9
damienmckennaComment #10
damienmckennaThe problem was rooted in PanelizerEntityDefault->hook_entity_load(). The way it worked, it checked different scenarios to see what display to use, in the end it would assign the bare $display variable from the configured default for any display that had one, but didn't load the other settings. I've updated it to load $contexts, $css, $css_class, $css_id, $display, $extra, $link_to_entity, $no_blocks, $pipeline, $relationships, $title_element.
This appears to resolve the problem in my (albeit limited) testing. It adds a little more processing during hook_load_entity, but I think it's minimal.
Comment #12
damienmckennaI never noticed this was on the 7.x-2.x branch. Gah.
Comment #13
damienmckennaComment #14
damienmckenna10: panelizer-n1841262-10.patch queued for re-testing.
Comment #15
joel_osc commentedPatch seems to be working well for me, thanks!!!
Comment #16
drupov commentedRefering from https://drupal.org/comment/8478787#comment-8478787
Panelizer was using the saved values from table "panelizer_entity" and did not respect views contexts that were loaded for that view mode. Patch from #10 solved that for me.
Thanks @DamienMcKenna for pointing me to the right issue!
Comment #17
fagoI've implemented a fix at #1965148-25: Load the full Panelizer default object which should cover this problem as well - please have a look and test.
Comment #18
scottalan commented@fago
Should the reference to your fix be at #1965148-25: Load the full Panelizer default object?
edt: sorry, just realized how the short-link works. I see you were referencing: https://drupal.org/comment/8492051#comment-8492051. I misunderstood and thought that was a reference to a node (8492051).
Comment #19
fagoyes, I updated the link to avoid further confusion ;)
Comment #20
drupov commentedWith both patches - #10 from here and https://drupal.org/comment/8492051#comment-8492051 - I cannot apply the value I enter in the "CSS ID" field on the Settings page to the panelized entity. It simply is not part of the html.
What I enter in "CSS class" field gets rendered though.
Comment #21
damienmckennaAfter some more testing this is good for now. Committed.
Comment #22
damienmckennaScrap that.
Yes, #1965148: Load the full Panelizer default object will replace this.