ElementEditor Drafts & External Content

[markhuot]

Hello, I'm bumping up some confusion over how drafts are managed in Garnish/JS. Specifically I'm not sure when my custom code should be triggering a draft save. Here's the basic idea of a page builder custom field that stores related components against my custom field.

1. user loads an existing, published, entry. There are no drafts and no changes to any of the fields.
2. user interacts with my custom field. The custom field uses new Craft.CpScreenSlideout() to edit the field contents in a slide out.
3. The user submits the slide out form…

Because a video is worth a thousand rambley words here's that flow:

Screen.Recording.2023-10-07.at.5.44.04.AM.mov

Notice in that flow how saving the component triggers my own custom action/route to save the data. That doesn't touch the parent entry and doesn't create any drafts. However, once the slide out closes and I click anywhere on the screen I get an automatic save-draft event, presumably because the slideout updated some hidden inputs in the custom field's input HTML.

So, what's the correct flow here? Should I be managing drafts when I save the component? Should I avoid that and let Craft's native save-draft run? But if so where do I store my temporary state of the component change in the interim?

Not directly related, but I did read #11349 too and it somewhat helped me understand how the checkForm and changes are monitored. Why this is different/trickier is because I need to know the draft ID when saving my component but it doesn't appear that I have the draft ID until after the slide out closes.

[brandonkelly]

Notice in that flow how saving the component triggers my own custom action/route to save the data.

But if so where do I store my temporary state of the component change in the interim?

Little confused. Is the change saved, or is its updated state being hard-coded into a form input?

[markhuot]

Little confused.

Only a little? You're doing well!

Sorry, this is breaking my brain and I'm not sure why. The goal is to have a custom field that hooks in to Craft's save-draft event so that we can modify field data and when that data is modified save the modifications to a provisional draft, much the same way adding a relationship to an Entries field works. The rub here is that the data to be persisted isn't just a related ID. It's a full element that needs to be saved against the draft.

Take the following example,

• I have a Section named "Pages"
• The section has a custom field called "Page Components"
• Inside the "Page Components" field there is UI to edit the content of a "hero" component in a slideout
• The hero are stored in its own DB table, and is not serialized back to the page content
• For example, Page ID:1 could be tied to Hero ID:1
• If I were to add a second hero ID:2 to the page, it should store that new relationship against the provisional draft, not against the published entry.

So, I've figured out that I can call new Craft.CpScreenSlideout('keystone/components/edit', {params}) to open a slide out. But, instead of the slide out action doing any database persistence I just return raw form data back to JS which I then place in to the primary form's fields[pageComponents][] triggering a save-draft. Now when my field is saved I see that I have non-persisted data in the field (coming from the slide out) and can wait for the draft to be saved and then persist/save that data to the draft.

This is all working quite well! I can now persist data to drafts via slide outs and discarding a draft discards all that provisional data.

Screen.Recording.2023-10-11.at.12.21.03.AM.mov

The only issue I've run in to with this approach is that save-draft does not offer any customization hooks which means it's impossible for me to hook in to the event to return updated HTML to be rendered. E.g., when a component is added I need to add additional HTML for the new component. I could do this in JS but I'm already rendering the original field UI in Twig so I'd like to render XHR responses in Twig too.

What I've come up with for now is to use a Response::EVENT_AFTER_PREPARE and manually update the save-draft JSON to include missingElements with my updated markup. This works surprisingly well.

So three questions based on all of that,

1. Am I crazy? Is there an easier way to do this sort of delayed saving until after a draft is created? Is there a JS hook that I can call to save my own draft and have the element editor automatically update with the draft info/you have unsaved changes bar? It seemed like all that was tightly tied to the internal save-draft event so it felt easier to hook in to what's already there.
2. The missingElements doesn't seem to work in live preview. Is that a known bug? Ignoring all of this: even a conditional field (using a light switch to toggle a field) doesn't update/display in live preview's CP side. The front-end template live updates but the field is not shown in the Craft UI.

[brandonkelly]

It seems like ideally, your components should be created normally right away, and assigned to the (provisional) draft, and then reassigned to the canonical entry when the draft is applied. That way you don’t need to worry about serializing the component and storing it in a hidden input.

To do that, you would first need to ensure that the user is actually editing a (provisional) draft. You can do that by calling ElementEditor::ensureIsDraftOrRevision(). (So long as your JS code is only getting executed when $static is false from your field’s inputHtml() method, you don’t need to worry about it being a revision.)

async function createComponent() {
  const myField = document.getElementById('my-field-id');
  const editor = $.data(myField.closest('form'), 'elementEditor');

  await editor.ensureIsDraftOrRevision();

  new Craft.CpScreenSlideout('keystone/components/edit', {
    elementId: editor.settings.elementId,
    // ...
  });
}

createComponent();

editor.settings.elementId is a new thing I just added for the next release (4a87e4b) so your plugin will need to require craftcms/cms ^4.5.7. Without that change it wouldn’t be as easy to know what the new draft’s underlying element ID is.

[markhuot]

Yes! ensureIsDraftOrRevision() is exactly what I needed. This will simplify so much.

[markhuot]

Follow on to this: is the a corollary method in PHP? When moving and creating components I can initiate the draft in JS on click because the result of the click will lead to modification of the element and a draft should be created.

However, when editing an existing component it is possible the user could click "cancel" from the slide out and in that situation a draft should not be created. So I think I'd like to wait to create the draft until after the slide out is submitted. But that doesn't seem possible.

What'd be really great is if there was a hook in the CpScreenSlideout during submit where you could do this sort of thing. Something like this half baked idea, https://github.com/craftcms/cms/pull/13821/files.

In the meantime I'm just going to live with opening the editor creating a new draft and you'll have to discard the draft if you're OCD like me.

Thank you!!

(video of your changes working! So great!)

Screen.Recording.2023-10-12.at.11.52.00.PM.mov

[brandonkelly]

I can see how that would be a little nicer, but there’s no easy way to make that possible right now. FWIW you’re now following a similar behavior to how Matrix fields work in Craft 5 when configured to use the element index view. In that case, the new nested entries are created right away, before the slideout is opened, so it’s crucial that the parent draft be created first.

[brandonkelly]

Craft 4.5.7 is out now with that new elementId ElementEditor setting.

[markhuot]

Woo! Thank you.