Panelizer does not work well with workbench and entity revisions. [#1871552]

Comment	File	Size	Author
#16	panelizer-n1871552-16.patch	5.11 KB	frakke

#9	panelizer-n1871552-9.patch	2.6 KB	frakke

#7	panelizer-n1871552-7.patch	954 bytes	frakke

#6	panelizer-n1871552-6.patch	893 bytes	frakke

#1	panelizer-n1871552-1.patch	1.92 KB	frakke

Comment #1

frakke CreditAttribution: frakke commented 20 December 2012 at 19:19

File	Size
panelizer-n1871552-1.patch	1.92 KB

This patch does the trick for us. The issue seems to be, that the "old" panelizer object is not re-used. It then doesn't know which panelizer object to use and feeds the patched function with a default-panelizer display name.

When not using this patch, the current version of panelizer actually destroys data, ruining the panelizer/display :-)

Log in or register to post comments

Comment #2

merlinofchaos CreditAttribution: merlinofchaos commented 20 December 2012 at 19:35

This patch seems to be misusing the display_is_modified flag, which exists to ensure we don't make copies of unmodified displays. However, this patch will unconditionally create a new display every time a revision is updated, which is wrong.

Panelizer can have the same display on multiple revisions, as long as that display hasn't been modified. This is to combat the effect that panels can be quite data intensive, and having exact clones is wasteful.

Log in or register to post comments

Comment #3

merlinofchaos CreditAttribution: merlinofchaos commented 20 December 2012 at 19:36

When not using this patch, the current version of panelizer actually destroys data, ruining the panelizer/display :-)

I haven't seen this happen, so clearly there is an extraordinary circumstance. Please provide reproduction instructions.

Log in or register to post comments

Comment #4

frakke CreditAttribution: frakke commented 20 December 2012 at 21:09

In our setup, it happens when we for an existing node attempts to:

Panelizer -> save: no errors
edit draft -> save: PDOException
(reload edit draft)
edit draft -> save: success
Panelizer -> save: success
edit draft -> save: PDOException
Panelizer -> save: warning Undefined property: stdClass::$entity_type i workbench_moderation_form_alter()

Fail equals the following:

Warning: Attempt to assign property of non-object i PanelizerEntityDefault->hook_entity_update() (line 844 of /Users/X/Sites/X/sites/all/modules/contrib/panelizer/plugins/entity/PanelizerEntityDefault.class.php).
    Warning: Attempt to assign property of non-object i PanelizerEntityDefault->hook_entity_update() (line 845 of /Users/X/Sites/X/sites/all/modules/contrib/panelizer/plugins/entity/PanelizerEntityDefault.class.php).
    Warning: Attempt to assign property of non-object i PanelizerEntityDefault->hook_entity_update() (line 848 of /Users/X/Sites/X/sites/all/modules/contrib/panelizer/plugins/entity/PanelizerEntityDefault.class.php).
    PDOException: SQLSTATE[HY000]: General error: 1364 Field 'entity_type' doesn't have a default value: INSERT INTO {panelizer_entity} (name) VALUES (:db_insert_placeholder_0); Array ( [:db_insert_placeholder_0] => node:article:default ) i drupal_write_record() (linje 7113 af/Users/X/Sites/X/includes/common.inc).

$entity->panelizer is 'node:article:default' in the cases where it fails.

Yes, it might be overkill with new revisions of unchanged displays. I need to look into that...

Log in or register to post comments

Comment #5

merlinofchaos CreditAttribution: merlinofchaos commented 20 December 2012 at 21:37

So this only happens with workbench moderation? Maybe something is wrong with the loading process then?

Panelizer works well with ERS, and when I examined workbench moderation, I found its system to be somewhat brittle. Search the workbench queue for panelizer, I *believe* I recall seeing something about some work there to improve compatibility

Log in or register to post comments

Comment #6

frakke CreditAttribution: frakke commented 20 December 2012 at 23:21

File	Size
panelizer-n1871552-6.patch	893 bytes

Yes, the current loading of nodes is a bit fishy in workbench_moderation.

I have added another less intrusive patch which does not blindly create new displays when they are not needed, just to finish off here. The data stored in the database is as expected now.

Perhaps a more general fix could be in an implementation of entity_presave, but I guess that discussion belongs over at http://drupal.org/node/1402860

Thanx anyway.

Log in or register to post comments

Comment #7

frakke CreditAttribution: frakke commented 21 December 2012 at 09:43

File	Size
panelizer-n1871552-7.patch	954 bytes

Missed a few checks on the panelizer attribute on the entiry object.

Log in or register to post comments

Comment #8

malcomio CreditAttribution: malcomio commented 30 August 2013 at 17:06

Version:	7.x-2.x-dev	» 7.x-3.1
Status:	Needs review	» Closed (duplicate)

Running panelizer 7.x-3.1 I get similar behaviour, but no errors or warnings.

Sounds like a duplicate of #2039025: Workbench Moderation creates a new revision, which immediately makes the panelizer layout outdated

Log in or register to post comments

Comment #9

frakke CreditAttribution: frakke commented 22 January 2014 at 12:46

Issue summary:

View changes

File	Size
panelizer-n1871552-9.patch	2.6 KB

So I'm back on the project we found the issue on.

Yet another issue:

Create a new node and publish it.
Create a new revision through the panelizer panels interface.
Now we have a published revision with the default paneliser display (did=0) and a new revision of the node with a custom display (did=X).
Then, when we edit the panelized display, it will edit the latest display for that node revision, which is as expected.
When we edit any properties on a pane, though, it will grap the dislay attached to the published node revision. so it will fail.

This patch ensures, that when we are accessing the pane properties, the display we are working on will be forced to the latest display, giving us the correct pane properties to adjust.