In order to make Panelizer and entity revisions to be more consistent and well integrated with systems that rely heavily on revisions, such as content staging and workflow, it would make sense creating revisions for panelized content when the display is modified. That way the changes in the display can be reverted by reverting the revision, or previewed in a workflow/content stating environment.
I'd like to know what you think about this, and if this could be developed as a patch for panelizer, maybe as a optional feature.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | panelizer-node-revision-saving-display-2055275-2.patch | 1.1 KB | recidive |
Comments
Comment #1
merlinofchaos commentedTo start with: Is Panelizer honoring the default revision flag? It's entirely possible that the problem is that it's not, and simply by checking the default setting for revision and setting that flag on the entity (which only really applies to node at this time but could also apply to fieldable panel panes) it could (by default) create a new revision or not when the display is saved.
After that, it is probably only necessary for the UI to actually ask if a new revision should be made in a tiny number of cases; for that, I would prefer to support such a feature by creating appropriate hooks and allowing a sub-module to enable that feature so that it doesn't create an impediment for users with less complicated workflows.
Comment #2
recidive commentedHere's a patch that makes panelizer create node revisions when saving a display if default node revision setting is enabled.
Comment #3
damienmckenna@merlinofchaos: What do you think of the patch? It obviously doesn't cover all use cases, but would it be a reasonable starting point in the interest of making the workflow more intuitive, as far as revision handling goes?
Comment #4
damienmckennaComment #5
damienmckennaComment #6
damienmckennaAfter some debugging I discovered that Panelizer was not correctly matching core's handling of revisions: #2223479: Option to create node revision should always be present
Comment #7
damienmckennaThinking on it further, I'm not actually sure this should happen, I think #2223479: Option to create node revision should always be present is the correct approach. Thoughts?
Comment #8
damienmckennaI've committed #2223479: Option to create node revision should always be present so I this isn't relevant anymore.