Load the full Panelizer default object

I'm facing the exact same issue, after the patch from comment #54 in that issue I can select individual fields from a 'Profile 2' section in the add panels content window, but only when editing the panel for users (i.e. user_view at /user/%user).

Panelizer, or any other custom panel pages doesn't work.

FWIW, here is my setup: I have two display modes for the user entity, one of them is panelized and the default user display uses normal Panels. Viewing the user profile (panels, but non-panelized) works as expected after adding & configuring the relationship. To view the panelized display mode, I have created a View that renders users entities using that display mode. Although I have configured the relationship in the panelizer panel for this secondary display mode, the fields do not render despite being present in the admin interface.

After debugging the code for a bit I found that panelized entities do not seem to pass relationships in the ctools context, which explains why the data does not render.

I've traced the call stack back and found differences in the following two files:

• page_manager_user_view_page() in file ctools/page_manager/plugins/tasks/user_view.inc (works)
• page_manager_user_view_page() in ctools/page_manager/plugins/tasks/page.inc (doesn't work)

Both perform calls to ctools_context_handler_render() using the $context array they generate, but in for panelized entities (which seem to get passed through page.inc in my case) the generated $context is empty. This had me a little confused though as it doesn't really point to panelizer, so I think I may have been too far down the stack trace.

I also noticed that ctools_context_load_contexts() is called by get_contexts() in PanelizerEntityDefault.class.php as well while rendering a non-panelized page. The non-panelized page supplies an $object parameter that defines the relationship, while the panelized display does not - I think this is more likely the culprit.

hook_entity_load()<code> has the job of loading the panelizer for an entity, and it seems to working correctly as the relationships columns of the <code>{panelizer_entity} table is empty. Therefore, perhaps the root cause of this issue is the incorrect saving of relationships to panelizer?

I apologize for the repeated posts, I am updating the issue as I troubleshoot and discover more information.

This appears to be a mishandling of the defaults; I noticed that changes (i.e. relationships) to panelizer were being saved to the {panelizer_defaults} table. {panelizer_entity} had entries for the entities I was trying to view with an empty array stored in the relationships column.

Despite never overriding the panelizer defaults for those entities, it seems to have created an entry and did not inherit the stored default panelizer relationship. Issuing a DELETE FROM panelizer_entity and clearing my cache resulted in the entities displaying correctly.

Editing a user profile results in the creation of an entry in the panelizer_entities table, and from that point on changes to the default relationships are ignored.

I also ran into this - for me entitycache was causing the problem. See #2178069: Various issues with outdated panelizer defaults when using entitycache

hm, turns out this problem persits - so probably it isn't related to entitycache then?

Same Problem here, I don't have EntityCache enabled, so this cannot be the issue.

What I figured out with some testing:

It never happens for changes in the Panelizer Content Tab, only for changes in the Settings, Context and Layout tab.

So testcase is this:
Creating a Panelizer default for a contenttype and viewmode teaser, creating some entites from this contenttype and do not overwrite the panelizer for this entity. Now adding a relationship for this contenttype and viewmode in panelizer defaults. The already created entities will not have the relationship in their panelizer. New created entities will have the relationship.

The issue is that even when the panelizer is not overwritten for an entity, there is an entry in the panelizer_entity table. And here in the column "relationships" it contains: "a:0:{}". Now this does not tell panelizer if this means "not overwritten" or "no relationship", so when the entity is loaded it assumes it means "no relationship" and does not load any relationship (it also does not check the default, because there is an entry in panelizer_entity and if this is the case, it probably does not check the defaults).

With changes in the content tab it works slightly different. When there is an entry in the panelizer_entity table for an entity, and it is not overwritten, the column "did" is 0. Which means: No Display for this Entity. If now panelizer loads an entity, it loads the default display (from the panelizer defaults).
If the entity display is overwritten, the "did" column contains a reference to panels_display table, so panelizer knows if it is overwritten.

So Panelizer cannot find out if the settings for an entity in the panelizer_entity are just copied from the defaults or if they are actually saved.
I think we should change the behavior of panelizer_entity to save "NULL" in all the columns on panelizer_entity, when it is not overwritten, so when loading an entity, panelizer knows that it is not overwritten and can load the defaults.

Of course the question is, why panelizer even creates entries in panelizer_entity for an entity when it is not overwritten, but during playing around I saw that even you edit only one panelizer viewmode for an entity it creates entries for all viewmodes in panelizer_entity.

Also found a workaround/quickfix:
You can safely delete the entries in panelizer_entity and the panelizer settings will fall back to the defaults. Just be sure to not delete entries in panelizer_entity for actual overwritten entities. I used a query "did != 0" to check this, as all our overwritten entities have changes in the panelizer displays.

If somebody knows the code of panelizer better, feel free to write some code for it :)

Ouch, the methods hook_entity_insert() / hook_entity_update() don't check whether an entity has dedicated panelizer settings or not and just always saves the panelizer object found for it. Which can be the defaults of course.
The attached patch looks worse than it actually is. It basically introduces the property entity_custom_panelizer which indicates if a panelizer setting is dedicated to the entity or not.
And the hooks hook_entity_insert() / hook_entity_update() only save the settings into the panelizer_entity if the flag is set.
I really hope I didn't miss something but first smoke-tests look promising.

I'm working on an alternative solution to this in #2012270: Allow default Panelizer to be selected that will record the fact the entity is using the default display, but it may be based upon incorrect assumptions. Have you tested your solution with any sort of revisions system?

FYI this would require an update script, threes some code in https://drupal.org/files/issues/panelizer-n2012270-22b.patch that could be built upon.

Correction, https://drupal.org/files/issues/panelizer-n2012270-25.patch is the file that includes an update script.

This adds an update script.

@DamienMcKenna Thanks for the feedback and the updated patch!

• No, I didn't test this with revisions, however I think that should work just fine as the detection if an entity has a dedicated panelizer setup is done before the entity_custom_panelizer flag is set and this detection is revision save.
• While flagging an record in panelizer_entity sounds like a viable way too, I think it's odd to store a whole config per entity if an entity doesn't even have a choice. If the entity has a choice however we miss the ability to switch back to the default setup.
  Thus an option to fallback to the default on such entities is definitely something missing too. But in case of a fallback we simply could remove / not save the entity specific panelizer settings. That should be revision save too, because PanelizerEntityDefault::hook_entity_load() is aware of revisions.

Btw. while analyzing further I found this code:

      // Ignore view modes that don't have a choice or already have their
      // own custom panel set up.
      if (!$this->has_panel_choice($view_bundle) || !empty($entity->panelizer[$view_mode]->did)) {

Does someone know if !empty($entity->panelizer[$view_mode]->did) would be a reliable way to do detect if the panelizer belongs to an entity or the default is used? If so we could remove the flag and use this approach instead. I'm not quite sure how reliable this is atm.

Updated patch, removed some tabs in favor of spaces.

@das-peter: Thanks for the updated patch, I just reinstalled TextMate and it's evidently misbehaving.

Yes, saving the default selection is the wrong approach, it's something I was considering for the other issue but mistakingly went with a 'default' placeholder instead; thank you for helping me see the correct way :)

In my testing I saw that as soon as something was customized on an entity's Panelizer display it clones the original and the {panelizer_entity} table is updated to track a 'did' value, with a blank 'name' value. That said, because Panelizer allows for multiple defaults, we have to compare against the generated default name, as shown in the update script I provided.

Thanks, das-peter and DamienMcKenna. I tested the patch in #12 and it works great for entities using the default without any panel choice. However, once panel choices are in use the problem persists.

Once panel choices are in use we need to save a respective entry in panelizer_entity to record the choice. To make it inherit any changes to the template I think it would be easiest to fix the loading logic in PanelizerEntityDefault::hook_entity_load() to add in the template-default if the entry is at default state.

But, if we'd do that fix to make it work with panel choices I'd assume it fixes the problem for the default without panel choices case as well. So maybe, we should just do that? Those "default" panel config entries are useless, yep - but do no harm either. It's ugly, that panel configs in default state are re-saved when they are used per entity though, so we might want to improve it to keep just empty columns for not used values in panelizer_entity?

Alternatively, I could see us adding another table simply saving the used template only, but that would require another, separate query. Therefor, I think the slightly de-normalized approach with a single query is better and does its job just well.

Simplified the title.

Making this a release blocker for v3.2.

(typoo in the title)

I've built a patch in #1841262: Load configured settings (renderer selection, CSS ID, CSS code) when a display is used that should help with the entity loading problem.

This version works off the existing values, skips the need for a new variable.

I think my issue is somehow connected to this, but I am not exactly sure.

I have a content type ("section") and its default view mode is panelized (only with the "Provide default panel" option).

Later I added a view context to this panelized view mode and was surpised to see that this context did not appear for all my nodes of this content type.

Digging around I saw that panelizer had made an entry for every node that did not get the context in the table "panelizer_entry". Just for information, there is no real order for the entries that got save in the table, e.g. from the 8 section items I have on the site at the moment the nodes with ID's 108, 111, 113 and 114 were saved and 107, 109, 110 and 112 didn't get saved.

Now if I delete these 4 nodes in "panelizer_entry" everything seems to work ok from now on. It seems to work, because future nodes don't go into this table.

Using the patch from #19 doesn't solve the issue for me, because the "name" column in "panelizer_entry" in my case is "node:section:default:default" for all 4 nodes. The variable $default_name in the function panelizer_update_7111() in the patch only resolves to "node:section:default" and the db_delete condition is not met.

Hope this helps and thanks for any input.

@drupov: Try this one: #1841262: Load configured settings (renderer selection, CSS ID, CSS code) when a display is used

Yes, the patch from #1841262 worked in my case. Thank you!!!

Is the current issue possibly also somehow connected to my case? Should I apply that patch too?

@drupov: The patch in this issue is related, but not strictly necessary. That said, if you could spare a few minutes to try it out I'd be very grateful.

Closed a duplicate: #2074271: Entity update writes panelizer_entity entry even if default is not overridden

As explained in #14 I don't think writing the default values is so problematic. As we do have do that anyway when panel choice are in use, I think it's fine to keep writing defaults in order to avoid creating yet another different code path / behavior.

Instead, I think it's fine to make sure to load the latest default panel in hook_entity_load() - regardless of whether it's the entity type default or just a referenced panel choice.

Attached patch updates the loading logic to always add in the defaults. Moreover, it adds in *all* defaults, not just the display - so it should fix the noticed issues with relationships and #1841262: Load configured settings (renderer selection, CSS ID, CSS code) when a display is used also.

Closed a duplicate: #2064663: Provide a way to revert to the default Context/Relationship configuration

Closed a duplicate: #2103941: when changing panelizer defaut for a node type, changes are not commit to the already created nodes

I'm planning on moving in the direction of #2012270: Allow default Panelizer to be selected, so I'm resetting this back to the goal of not saving default values.

I've merged in fago's changes as they seem reasonable.

As pointed out in #14 not saving default values will not solve the issue for panel choices, which face exactly the same problem. We could avoid saving default values regardless of this issue though :)

Updated to fix a missing 'clone' when the display is copied.

Rerolled. And yes, this replaces the changes from #1841262: Load configured settings (renderer selection, CSS ID, CSS code) when a display is used.

Committed! Thanks everyone for their help!

Sorry to reopen this, but I think this commit has broken something. I have some panelized nodes that have overridden the default settings, and now if I try to change the panelizer settings, to turn on IPE or set a CSS class for example, the code falls through the 3 scenarios in hook_entity_update, because $panelizer->display_is_modified is not set.

Is it possible the db update deleted the relevant records?

@Peacog: Can you please check the panelizer_entity table to see if you still have records for that node?

Yes, there is a record for all of my panelized nodes. What's happening is that as soon as I override the default panelizer state of any node, either by adding content or by changing a setting those changes are applied, but I can't go back and change the settings. The changes are ignored.
When I revert to 7.x-3.1 everything works again, so it's not a database issue.

@Peacog: Can you please test if the patch in #2206155: Path 'admin/structure/types/manage/%/panelizer' is inaccessible resolves the problem for you, or wait for a new dev build? I've been testing it locally and it's working fine for me, even with EntityCache enabled.

No, I'm afraid that doesn't fix it. I'm using Entity Translation and Entity View modes (view modes for taxonomy, not for the nodes that have this problem). Could either of those have something to do with it?

Please don't scream at me (too much), but I just discovered the VBO integration and am wondering if I made a mistake :-|

After spending all day thinking about this, I've realized I made a mistake in removing the records - providing a separate UX to let the content editors bulk update the displays will be a much better editorial workflow and will let me tie into creating new revisions, as necessary. Besides, while digging around I found that there were other parts of the module that kinda depended upon the record existing, and would take even more work.

So I've reverted the change and will review fago's patch #25 again.

This is fago's patch from #25 with the missing 'clone'.

After some testing I've committed this. Thanks fago.

Oh, forgot that I now need to add a placeholder update 7111.

Committed.

And now, where were we? Ah yes, #2012270: Allow default Panelizer to be selected.

Is this issue still solves the Entity update writes panelizer_entity entry even if default is not overridden bug?
Which patch should I use to solve this particular problem?

@nghai: Please see #2404999: Don't save records for default values.

@DamienMcKenna thanks! I had a look and will post there regarding the same.

I landed up on this issue from here: https://www.drupal.org/node/2242487, but I am not sure which patch to apply out of the patches above.

Thanks,
Ashish.