After looking at this module a bit I think it could gain a huge amount of support if more people realized that it allows creation of fieldable things that can be stored in Panelizer displays and that the data is completely revision-safe with respect to the node the Panelizer display is attached to, unlike Fieldable Panels Panes. Maybe you could mention this on the project page? :)

Comments

DamienMcKenna created an issue. See original summary.

Sneakyvv’s picture

Sneakyvv commented
Status: Active » Fixed

Hi Damien,

Glad you liked the module!

I'm not familiar with Panelizer myself. I've looked at it before, but never had a use-case where it fitted my needs. So actually I'm not 100% sure I completely understand the benefits you describe, but I'll assume you know what you're talking about :-)
I've updated the project page to mention what you said. Please inform me if the copy could be clearer or should have more information.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

Heh, I didn't think you'd take it as literally ;-)

Something like this might be better:

Paragraph Panes makes a great option for building custom, fieldable panes for use in Panelizer. Because the pane's data, i.e. the field values, are stored in the Panelizer display directly, they can be managed using revisions and content workflow modules e.g. Workbench Moderation, Revisioning, Workflow, etc. This also makes them a better option than Fieldable Panels Panels when a content workflow is required.

Sneakyvv’s picture

Sneakyvv commented

Thanks!

It made me, I think, understand better what you meant. Because the paragraphs are stored/serialized in the pane configuration they can be revisioned, moderated/workbenched, etc., right?

Just out of curiosity: can you tell me how this is different from FPP's approach?
Is it that FPP creates actual entities instead, which have their own revisions (not linked to the referencing node's revisions)?

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

Right, FPP creates its own entity objects, which then means there needs to be a way of connecting the node revisions to the FPP revisions, which gets messy.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.