Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When saving nodes to new revisions it some times results in a fatal error.
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 |
Comments
Comment #1
frakke CreditAttribution: frakke commentedThis 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 :-)
Comment #2
merlinofchaos CreditAttribution: merlinofchaos commentedThis 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.
Comment #3
merlinofchaos CreditAttribution: merlinofchaos commentedI haven't seen this happen, so clearly there is an extraordinary circumstance. Please provide reproduction instructions.
Comment #4
frakke CreditAttribution: frakke commentedIn our setup, it happens when we for an existing node attempts to:
Fail equals the following:
$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...
Comment #5
merlinofchaos CreditAttribution: merlinofchaos commentedSo 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
Comment #6
frakke CreditAttribution: frakke commentedYes, 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.
Comment #7
frakke CreditAttribution: frakke commentedMissed a few checks on the panelizer attribute on the entiry object.
Comment #8
malcomio CreditAttribution: malcomio commentedRunning 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
Comment #9
frakke CreditAttribution: frakke commentedSo I'm back on the project we found the issue on.
Yet another issue:
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.
Comment #10
malcomio CreditAttribution: malcomio commentedComment #15
DamienMcKennaThere was no reason to reopen this.
Comment #16
frakke CreditAttribution: frakke commentedWorking 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.