When saving nodes to new revisions it some times results in a fatal error.

Files: 
CommentFileSizeAuthor
#16 panelizer-n1871552-16.patch5.11 KBfrakke
#9 panelizer-n1871552-9.patch2.6 KBfrakke
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch panelizer-n1871552-9.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#7 panelizer-n1871552-7.patch954 bytesfrakke
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch panelizer-n1871552-7.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#6 panelizer-n1871552-6.patch893 bytesfrakke
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch panelizer-n1871552-6.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#1 panelizer-n1871552-1.patch1.92 KBfrakke
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch panelizer-n1871552-1.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

frakke’s picture

StatusFileSize
new1.92 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch panelizer-n1871552-1.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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 :-)

merlinofchaos’s picture

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.

merlinofchaos’s picture

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.

frakke’s picture

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

  1. Panelizer -> save: no errors
  2. edit draft -> save: PDOException
  3. (reload edit draft)
  4. edit draft -> save: success
  5. Panelizer -> save: success
  6. edit draft -> save: PDOException
  7. 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...

merlinofchaos’s picture

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

frakke’s picture

StatusFileSize
new893 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch panelizer-n1871552-6.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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.

frakke’s picture

StatusFileSize
new954 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch panelizer-n1871552-7.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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

malcomio’s picture

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

frakke’s picture

Issue summary:View changes
StatusFileSize
new2.6 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch panelizer-n1871552-9.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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

Yet another issue:

  1. Create a new node and publish it.
  2. Create a new revision through the panelizer panels interface.
  3. 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).
  4. Then, when we edit the panelized display, it will edit the latest display for that node revision, which is as expected.
  5. 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.

malcomio’s picture

Status:Closed (duplicate)» Needs review

The last submitted patch, 1: panelizer-n1871552-1.patch, failed testing.

The last submitted patch, 6: panelizer-n1871552-6.patch, failed testing.

Status:Needs review» Needs work

The last submitted patch, 9: panelizer-n1871552-9.patch, failed testing.

The last submitted patch, 7: panelizer-n1871552-7.patch, failed testing.

DamienMcKenna’s picture

Status:Needs work» Closed (duplicate)

There was no reason to reopen this.

frakke’s picture

StatusFileSize
new5.11 KB

Working against c73e476d807bf99001828a95dbf6ebcc80fe7d67
Sorry for not working against head, but we can't update the module right now.

Anyway, added support for revisions when resetting panelizer display. It will keep the panelizer revisions rather than just deleting them blindly.