Currently, Panopoly Magic will generate a new revision for a Fieldable Panel Pane each time it is previewed. It makes sure to not update the "current revision" pointer for existing widgets (which is great!) but afterwards it leaves all those old revisions around which makes the "Revision" list for FPPs much less useful.

For most users this isn't a problem - not that many people look at the "Revision" list for FPPs. But there's lots of cool things that could be done with Panopoly and moderated editorial workflows, and then it becomes important to look at revisions.

I see two possible solutions:

  1. Find a way to preview without saving revisions. Obviously, this would be good! However, I can understand why it was implemented this way in the first place. To generically generate a preview you can only use "generic" information about the Pane like type, subtype and configuration array. With FPP, the subtype is actually the revision id and the proper entity is loaded from the database during render. :-/ So, saving the revision allows the same render pipeline to work for both FPP and more normal widgets. To avoid saving the revision, we'd need a seperate render pipeline just for FPPs.
  2. Delete these extra revisions after displaying the preview. Once the preview generated, I see no reason that we couldn't just delete it. This seems like the simpler option.

More thinking and experimenting is necessary...

CommentFileSizeAuthor
#1 panopoly_magic-fpp-revision-cleanup-2312723-1.patch2.38 KBdsnopek

Comments

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented
Status: Active » Needs work
StatusFileSize
new panopoly_magic-fpp-revision-cleanup-2312723-1.patch2.38 KB

I've been experimenting with implementing the second approach. Attached is a patch that sort of works in some situations.

The first thing I attempted was removing the temporary revisions right after the preview was rendered in panopoly_magic_form_post_render_preview(). This works great for editing FPPs that already existed!

However, for FPPs that were new, it would always leave the first revision it created in the place (so, 2 revisions for any new FPP). I think this is because it won't delete a revision if it's the ONLY revision on an FPP and that is always the case for the first revision.

So, I also added a submit handler that will remove all the temporary revisions that have accumulated during this edit session (that's _panopoly_magic_cleanup_fpp_revisions()). That got the number of revisions for a new FPP down to just 1!

Unfortunately, this still isn't perfect (and still requires the first fix), because if you never submit the form (ie. close the dialog because you decided not to add the widget), it will still create the revisions. So, for new widgets that don't get saved, we're actually generating a whole bunch of unused FPPs.

I think the ideal implementation of this approach would something like this:

  1. We create a table to store information about the temporary FPP revisions we create
  2. Once the "Add/edit widget" form is actually submitted, we clean out all the temporary revisions for this FPP
  3. Periodically, (maybe daily?) we go through and clean out any left over temporary revisions, and if no revisions remain we delete the whole FPP

This is the only way I can think of to handle cleaning up new widgets that don't actually get saved.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented
Status: Needs work » Closed (duplicate)

Closing as a duplicate of #2398347: Panopoly Magic abuses FPP revisions. The approach there is superior in that it avoids generating any FPP revisions in the first place.