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.

#11 1986334-interdiff.txt1.44 KBEclipseGc
#10 1986334-10.patch3.31 KBEclipseGc
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]
#9 1986334-9.patch2.41 KBEclipseGc
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]
#4 fpp-revisions-1986334-4.patch2.08 KBgrndlvl
#1 fpp-revisions-1986334-1.patch1.07 KBDavid_Rothstein


David_Rothstein’s picture

Status:Active» Needs work
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.

David_Rothstein’s picture

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.

merlinofchaos’s picture

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.

grndlvl’s picture

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.



David_Rothstein’s picture

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.

MiroslavBanov’s picture

There is a similar patch that allows use of vuuid here:

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

azinck’s picture

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.

azinck’s picture

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.

EclipseGc’s picture

Status:Needs work» Needs review
new2.41 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

Rerolled against head.


EclipseGc’s picture

new3.31 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

I'm actively using this on a site right now and it's performing pretty well, however it has a couple of issues.

1.) Edit->Save a reusable FPP will result in it being removed from the interface.
2.) Cached view of the FPP after save in IPE.

Logic to fix 1.) resulted in a cached FPP because passing the revision id is what causes entity class load() method to bypass cache, so I had to introduce a new type of subtype to support this which is "current:$fpid". There is corresponding logic in _fieldable_panels_panes_load_entity() that selects the max vid of the FPP and passes that along with the load to get the FPP that was just saved. This is definitely still NR but I think we're getting closer to something that's got a fair bit of testing on it and which actually works!


EclipseGc’s picture

new1.44 KB

Interdiff for those interested

azinck’s picture

I should add that we've been using #4 in production on a very large site for about 10 months now with no problems. We didn't run into the problems described in #10 because we're not using the IPE and we've done a number of alterations to prevent editing reusable FPPs in the Page Manager interface. So for our self-limited use-case it's been working extremely well.

EclipseGc’s picture

In the spirit of full disclosure, I suggested a similar set of limitations in the system I'm working in, but ultimately the changes required to support the actual feature were pretty minimal. I'm very pleased with the basic approach of this patch.

Ramasubbu Drupal’s picture

Hi to everyone,

If we use the "Workbench" module then the node must enable with "Revision". But if we use the "Workflow" module then no need to use the "Revision" option. So the panelized fieldable panel pane will display with any changes and workflow changes on the node.

No need any patches. I have done this flow in my project. Its working fine with workflow and panelizing.

The workflow module is available for Drupal 7 also. Click here to download the workflow module.

ruloweb’s picture

This patch breaks fieldable_panels_panes export using features, because entity_id is containing vid instead of uuid when revision is enabled.


MiroslavBanov’s picture

If anyone is interested, I have a patch here that fixes pane load by vuuid: