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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

merlinofchaos’s picture

To 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.

recidive’s picture

Assigned: Unassigned » recidive
Status: Active » Needs review
FileSize
1.1 KB

Here's a patch that makes panelizer create node revisions when saving a display if default node revision setting is enabled.

DamienMcKenna’s picture

Assigned: recidive » merlinofchaos
Issue summary: View changes

@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?

DamienMcKenna’s picture

DamienMcKenna’s picture

Component: Code » Revisions
DamienMcKenna’s picture

After 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

DamienMcKenna’s picture

Thinking 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?

DamienMcKenna’s picture

Status: Needs review » Closed (works as designed)

I've committed #2223479: Option to create node revision should always be present so I this isn't relevant anymore.