How to implement pages inheriting templates configurations with Puck

[LengYXin]

How to implement with Puck: the pages module inherits configurations from the templates module, the pages cannot modify the inherited configurations from the templates, and when the templates configurations are updated, the pages can automatically sync the updates? Seeking best practices.

[FedericoBonel]

Hey @LengYXin!

Puck is unopinionated on this, and I haven’t done it myself yet. Implementation would depend a lot on your requirements, but here are a couple of ideas:

• You could set the template data on your Puck data object whenever you load it into the editor, and mark the corresponding fields as readOnly if they’re defined in the template.
• Another option could be to use a root field that lets you select a template, then use resolveData to update the values on each component accordingly and set them as read only.

Another API that might be useful is the Permissions API. With it, you can control what users are allowed to edit, create, or delete. That could help handle some of the editing restrictions that come from the template.

These are just a few approaches, I’d be curious to hear how you end up implementing this!

[LengYXin]

I am currently exploring the use of the Permissions API to perform such operations. But it seems there is a problem. I'm initiating the control of Slot. For example, prohibiting any modifications.

[FedericoBonel]

Hmm, have you checked out the drag and edit permission?

[LengYXin]

Hmm, have you checked out the drag and edit permission?

Have tried it ，I also submitted this. #1330 (comment)
It seems that "insert" cannot control the behavior of "Slot".

[LengYXin]

Hi @FedericoBonel

I implemented this using a workaround. I set the pointer-events: none style for the render of each component in editMode, where _template is a marker injected into props via walkTree when saving the edit template. I took this approach because I had tried numerous methods to disable the drag-and-drop action for Slots.

This is the outer wrapper component.

This is the result. While the goal was achieved, the solution is somewhat inelegant.
Would you happen to have any better suggestions?

[FedericoBonel]

Ah, I see, very interesting approach!

Off the top of my head, I’m not entirely sure, but there could be some side effects with this. The main thing I’d recommend is checking whether you need to add the pointer events on both the component wrapper and the data-puck-dropzone children (I think you're trying to target the data-puck-component with that).

Another tip would be to look into the componentOverlay override for rendering the overlay of a “locked” component. Also, double-check whether you actually need an overlay portal here I’m not sure it’s 100% necessary, since it seems like the pointer events styling might be what’s blocking the dragging.