We are using Fieldable Panels Panes, Panelizer and Workbench Moderation in tandem to build a site with a moderation workflow in which a draft of the entire page is created and then reviewed before being published.

It works well, except when a fieldable panels pane is edited on the draft version of the page, the edits automatically appear on the published version of the page too. This is because the panelized page references the entity ID of the fieldable panels pane and therefore always uses the most recent revision.

I propose allowing the panelized page to refer to the revision ID of the fieldable panels pane instead. That way the draft revision of the node and the published version of the node will refer to different revisions of the FPP when the FPP is edited, and everything magically works.

Comments

Status:Active» Needs work
StatusFileSize
new1.07 KB

So, the Fieldable Panels Panes module almost supports this already. Here's a patch demonstrating a small tweak that makes it actually support it.

This patch is fine for our use case, but would need to be developed further in order to be committed to the module. Instead of forcing the revision ID to be stored in all cases like I'm (hack-ily) doing in the attached patch, it would presumably need to be some kind of option.

Another issue (credit goes to grndlvl for thinking of this) is that this model kind of breaks down for reusable FPPs... There, the goal (even for our use case) actually sort of is that if you edit the FPP in one place, your edits take effect everywhere at once.

You have just discovered the use-case for ERS, which works on fieldable panel panes where workbench moderation does not.

It's...vaguely sort of kind of possible that you could use ERS only for fieldable panel panes while still utilizing workbench moderation for your nodes, though I suspect it will be extremely clunky.

StatusFileSize
new2.08 KB

I am not sure how this follows ERS's use-case, while, ERS handles the publishing of revisions at specific times it still separates the pane from the Panelized entity.

We have Panelizer working with workbench with the hack/patch from http://drupal.org/node/1402860#comment-7344842 and we def. found out the hard way that these modules do not play together nicely, however, I think this particular use-case could still be valid because it is not dependent on workbench, but rather revisionable entities in general. Especially when you wish to tie an FPP to a specific revision so that when a user edits the FPP on a draft Panelized node via the IPE then the live FPP should not be changed, but yet lives as a separate revision that is specific for the current revision of the Panelized node.

To open up additional dialog I have attached a patch that accomplish this, albeit pretty hackishly.

I also wonder if another approach to this would be to extend the entity field panels content type to allow on the fly editing that respects the revision of the node.

Thanks,

Jonathan

Right, my understanding is that ERS would be for a situation where you want each pane to have its own independent publishing workflow. But in our case the panes are closely related so the goal is to have them reviewed and published all at once.

In other words, if the page starts off with 4 panes:

A - B - C - D

The idea is that an editor can add, delete, rearrange, and edit them while working on a draft of the page, such that they wind up (for example) like this:

B - A - D (edited) - E

And then that whole set of changes is pushed live at once.

It does work very nicely with this patch as well as the other one Jonathan mentioned, although both are still a bit hackish.

Since all the changes in the patch here are in a single submit handler, it's possible the right way to do this doesn't involve patching the FPP module at all; another module could swap out the submit handler instead and just deal with it that way. We do require a couple other UI changes for this to behave sensibly (for example, hiding the FPP revision checkbox and forcing it to always be checked) and a separate module could take care of that all at once.

There is a similar patch that allows use of vuuid here:
https://drupal.org/comment/8428099#comment-8428099

It may be worth looking at it and possibly combining the two patches here.

Issue summary:View changes

I agree that the logic in #4 is sound. The real challenge here is a UX one. I'd suggest that one way to communicate the difference between reusable and non-reusable panes would be to prohibit the editing of reusable panes in the Panels interface and instead force the user to go to the Fieldable Panels Panes UI to edit those panes.

I'm also thinking we shouldn't allow panes to move between being reusable and non-reusable panes. Once created they should remain as either reusable or non-reusable. If it's necessary to switch from one to the other then the pane should be duplicated. Otherwise you could get into some really confusing UX situations.

Also: I'd love to hear more from merlin about how he sees ERS as addressing this problem. I've given ERS a try and cannot see how it addresses this problem but I may just be dense or there may be another way of approaching this problem that I'm blind to.