Entity update writes panelizer_entity entry even if default is not overridden [#2074271]

I may not be seeing the big picture here, but I cannot figure out why hook_entity_update function in PanelizerEntityDefault class writes a panelizer_entity record if it is using the default display and the display is not modified (overridden).

This is the behavior that I am seeing:

1. Create a node for a panelized content type. No panelizer_entity entry is written for this node, and the panelizer overview form says this is default, which is true.
2. Edit this node, save it, a panelizer_entity entry is written, essentially cloning defaults.
3. Subsequent loads of this node use this panelizer_entity record, ignoring the defaults. The overview page indicates that it is using defaults in the status column, but this is not true; any changes you make to the default display, at least for the elements stored in panelizer_defaults table, ie, css_id, css_class, extras, will not be reflected in previously updated nodes.

Once this entry is created, it is impossible to change the panelizer_default settings and have it reflect in nodes that have a panelizer_entity entry in database. Is there another reason why it writes this record on update, but not insert? Further, if a panelized node is customized and you reset it, it deletes all panelizer_entity records for that node. This seems inconsistent. If it is supposed to have a record, why doesn't it write a new one based on the defaults, and why doesn't it write a record on insert if it is supposed to have a record?

My belief, and I have every expectation that I am not grokking this all the way, is that either a panelizer_entity record is not written on update unless the display is modified, or, if it is written, we can have the option to update all panelizer_entity records with the same view mode and display id (did) of 0 with the new default values from panelizer_defaults when we update the default panelizer entry.

Comment	File	Size	Author
#2	panelizer-1402860-2.patch	1.83 KB	wesnick
#2

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

seanr

he/him

CreditAttribution: seanr commented 26 August 2013 at 14:11

One detail missing from the original post that may be relevant is that we are creating new revisions for all nodes by default. It appears that any time a revision is saved, regardless of the original node settings, the record gets added, even though it clearly shouldn't since the panelizer settings were never overridden.

Comment #2

wesnick CreditAttribution: wesnick commented 27 August 2013 at 13:10

File	Size
panelizer-1402860-2.patch	1.83 KB

I propose a solution that will only write a panelizer_entity record if one already exists and the display is not modified. Patch attached

Comment #3

dixon_

he/him

English

France

CreditAttribution: dixon_ commented 15 October 2013 at 15:16

I'm seeing the same behavior as well. And I can't wrap my head around why this would be the intended behavior either.

I've looked around to try finding some documentation on how it's supposed to work (to be able to determine if this is a bug or not), but I've failed to find answers.

Can someone who knows provide some insight here? :)

Comment #4

seanr

he/him

CreditAttribution: seanr commented 27 November 2013 at 18:34

One piece of this puzzle is that if you don't check the box to allow users to choose the panel for a content type (i.e. you only give them the default with the ability to override that) it works as expected and doesn't create the panelizer_entity entry. As soon as you allow that option, the functionality breaks, though.

Comment #5

Crell CreditAttribution: Crell commented 25 October 2013 at 22:41

I am seeing what may be a related issue. (Or not; hard to say.)

1) Create node type, panelize it.
2) Set node type to inherit "allowed content" and "allowed layouts" from the global panels settings.
3) Create node 1 of that type.
4) Customize the page. See that the allowed content follows the specified rules. Don't save customizations.
5) Change the global panels settings to allow less content/layouts.
6) Customize node 1 again. The allowed content list is still based on what it was when the node was created, vis, step 5 has no effect.
7) Create node 2 of the same type.
8) Customize the page on node 2. The allowed content list follows the settings at that point, vis, step 5 DID have an effect.

I would expect both nodes to now have the more restrictive set of allowed content panes.

Does that seem like that same issue or do I file a new bug? :-)

Comment #6

Fidelix CreditAttribution: Fidelix commented 26 November 2013 at 22:31

Priority:	Normal	» Major
Issue summary:	View changes

This bug caused severe problems for me.
The whole content of the site was revised by our copywriter, who edited almost 100% of the nodes.

This caused a panel_entity entry to be created for each of the edited nodes, and now that I needed to change the default panel I was banging my head in the wall asking why my changes just wouldn't work. After debugging closely I found the problem and hundreds of rows on the panelizer_entity table.

Deleting the appropriate rows fixed the problem.
I'm bumping this to major because it really is a major issue.

Comment #7

DamienMcKenna

NH, USA

CreditAttribution: DamienMcKenna commented 7 December 2013 at 05:11

Issue tags:

+Check with merlinofchaos

This is one I need to discuss with merlinofchaos.

Comment #8

DamienMcKenna

NH, USA

CreditAttribution: DamienMcKenna commented 11 December 2013 at 12:37

Status:

Active

» Needs review

There's a patch, lets review it.

Comment #9

seanr

he/him

CreditAttribution: seanr commented 12 December 2013 at 20:13

I don't believe that patch will handle the case where the entity does not have an existing entry but the current changes would require one to be added. Probably needs test coverage for those cases, too.