Changes to Matrix Blocks and CKEditor Blocks should be part of a draft

[maxstrebel]

If I edit a page with matrix blocks or blocks in CK Editor I would assume all changes to be local/temporary before I saved. No matter if I open an edit dialog or not. Unlike Entry Relations, which are relations.

What actually happens is: The change in the slideout menu is on the live site right away – not part of my draft.

craft.5.matrix.drafts.mov

From an authors point of view I would assume that all changes to this page are part of my draft. If I want to propose a revision of that page to my team, I want to be able to show it with changes to my blocks, too (without them being on the live site). It also adds a lot of risk, as in the past clients would let their work students do these kinds of jobs (without the need of technical schooling) – which could now accidentally edit the live page.

The current assumption (#14286) is, that the card view is an entry relation due to its definition. I would like to challenge this implementation. I agree that entries should always behave in the same and reliable way. An entry relation should open in the slideout and the change be applied to it. As a possible (theoretical) solution one could propose a differentiation between blocks (used in Matrix and CK Editor) and Entry Relations.

Thus I'd be very happy if changes to blocks are part of the provisional drafts and drafts.

[MattWilcox]

Just to add in here so it's in one place:

• My view is the flow in the video feels like a bug, not an intentional choice
• I think this behaviour will cause a lot of support requests from clients confused why content is being effected outside of a draft
• IMO, a Draft should create a new context, and changes made inside one should never leak out
• "Relational" stuff should be through Fields, and not through Entry Types. i.e., yes, if this was an Entry field's content being edited then the changes reflecting through make sense. But not for an Entry Type Instance. I do not exoect Entry Type Instances to behave like this.

[thupsi]

Some of these concerns have been expressed in this discussion, where I did not comment, because I thought it would be too much of an ask to negotiate changes of this nature so close to the Craft 5 launch.

Nevertheless, I agree with all of the above and don't have much to add myself. I share the belief that the current behaviour can easily lead to unintended changes going live, and I don't expect authors to think of nested cards as related entries, especially in "content builder" scenarios.

The only case where I would expect changes in nested entries to go live immediatelly would be in the "element index" mode, and even then, it could depend on the kind of relations, entries etc.

Would it be possible to have an option, per matrix field, to either "save changes immediately" or "participate in owner drafts"?

[MoritzLost]

@brandonkelly Can you comment on if/when those changes will be made to the behaviour for element cards in CKEditor and especially Matrix Blocks? We wanted to use the element cards display mode for our page builder Matrix field, but this issue makes this mode completely unusable for this use-case. Your comment #14286 (comment) sounds rather like this is the intended behaviour and there are no plans to change it?

[thupsi]

Hello @MoritzLost!

Brandon is of course the one to give a definite answer, but in the meantime I wanted to give you an update from another discussion: #14727 (comment). TL;DR it seems we will get an improved behaviour, in line with what your editors would expect from a page builder. Just keep in mind that the roadmap item mentioned in my comment wasn't ready in time for 5.1 and is now slated for 5.x.

[MoritzLost]

@thupsi Thanks! I say your comment there since it's linked on the roadmap, but that was back in March before 5.1, and 5.x is scary to me 👀 I've seen some feature requests end up on the backburner for a long time, so I'm hoping for an update from Brandon if we can expect changes in the near future.

[maxstrebel]

Here's the end of the discusssion on discord: https://discord.com/channels/456442477667418113/456442477667418115/1218258609360601158. I am also waiting for this and will not upgrade to 5 before it is done ;)

[brandonkelly]

@maxstrebel Nothing changes if you keep using the inline-editable blocks view mode.

[maxstrebel]

Sure. I assumed that this change would come 5.X and really like CK Blocks and Cards 😉

[brandonkelly]

I’ve been toying with this, but… it’s complicated. There are a couple aspects of how things work that I don’t want to veer away from:

• We want to retain the ability to save nested content directly. Half of the reason we added the card view was so you can go in and make edits directly to nested content, without needing to save the entire top-level entry. That’s a major performance/AX win, especially on projects with more complex content models and/or a large number of sites.
• We don’t want the slideout to drastically differ from the full-page edit form; otherwise the entire concept of element editor slideouts starts to get a little muddy. They are UI-optimized versions of their full-page counterparts; nothing more or less.

That said, purely from a workflow perspective, I can see the benefit of being able to make edits across multiple nested entries, and having them all published at once.

The original plan discussed in Discord was:

1. Optimize the slideouts for closing without fully saving when done editing (“Done” as the primary action instead of “Save”).
2. Show provisional changes in the Matrix/CKEditor field’s cards, as an indication of nested pending changes.
3. Publish provisional changes when the parent entry is saved.

However:

• Changing the primary action within the slideout chips away at the element slideout concept, and would differ from the full-page edit form for nested entries.
• Button inconsistency aside, we think Command/Ctrl + S should definitely continue to directly save the nested content, but it would be very awkward if there was a discrepancy between that shortcut and the primary button.
• Automatically applying provisional drafts when saving the parent entry will likely have unintended consequences when authors didn’t expect their provisional drafts to go live yet.
• It would almost certainly not be expected behavior for nested content more than one level deep, whose content wouldn’t have any representation on the top-level page. So we should not do that. But now we’re back at square one for those entries.

So what do we do?

As a starting point, it feels like showing provisional changes within element cards/chips—across the entire control panel—is an obvious improvement. So that part is already done (pending a11y review): #14975.

For all slideouts capable of autosaving, we are also considering changing the “Close” button to “Done”. Coupled with the chips/cards showing provisional content, we think that will help communicate that it’s perfectly safe to close the slideout without losing your changes.

That leaves the problem of not having an easy way to see and publish all your nested changes at once, which we’re still thinking about.

[thupsi]

As a sidenote, I would like to highlight the fact that the drafts problem applies almost exclusively when cards are used for page builders or the like. A popular use case for sure.

There are though cases where matrix fields are meant to contain autonomous entries and this is a powerfull new feature in Craft 5. We need to aknowledge this, to prevent fixing one thing and breaking another.

Consider this:

I have a single page called "Our Team". In this page I want to present 20 team members. Each team member must also have a dedicated page with meta, some text etc.

Prior to Craft 5, I would implement this by having a single for the "Our Team" page, and a structure for the team members. This would present the problem of having content with parent and child relationship in two different places and making my entry index more complicated. If instead I chose to have the team members in a matrix inside the "Our Team" page, it could get unwieldy, I would have to manually add routes for the member pages, I wouldn't be able to edit each member in it's own draft, and accessing them from other templates would be somewhat cumbersome.

In Craft 5, I can have the team members in a matrix field and have all the benefits of separate entries without having to jump through hoops, plus also having the bonus of collocation and easy overview within the "Our Team" page, reflecting the actual mental model of the editors.

In short, the newfound ability of Matrix blocks to function as nested sections solves part of what the Unified Content View was/will try to solve. This complicates things, because we can't say anymore that Matrix blocks should always belong to the owner entry and be attached to its drafts. Rather, it depends.

[thupsi]

Another sidenote. I'm curious if the upcoming "Content Releases" feature could be leveraged to solve this conundrum.

[MoritzLost]

@brandonkelly Thinking through the challenges you outlined, I think the behaviour for nested entries should be an option on Matrix fields. I definitely agree that there shouldn't be two primary actions for pop-outs, this is too confusing.

I see two distinct use-cases, with different expectations for nested entries:

1. The nested entries primarily belong to the entry. For example, a page builder.
2. The nested entries are independent entities. @thupsi gave a good example with the team index page and individual team members.

For the first use-case, I expect the nested entries to have a shared lifecycle with the parent entry. That is, changes stay provisional until I'm saving the parent entry, at which point all the provisional changes to the nested entries are saved as well. For the second use-case, I expect the nested entries to have their own independent lifecycle. This would be the current behaviour, where saving an entry from a pop-out will immediately update the canonical version.

Then there are some cases where this is not clear-cut, where nested entries kind of belong to the parent, but may also have their own frontend route or be used in other contexts.

I don't think there's a single solution that will work for all use-cases. In my opinion, those two modes of operation should be an option on matrix fields, so I as a developer can decide which mode of operation I want for every matrix field. I imagine a configuration on matrix fields with two options:

• Nested entries share their owner's life-cycle. Changes in a pop-out are saved as provisional drafts, and applied when the parent entry is saved.
• Nested entries have their own life-cycle. Changes to nested entries are applied immediately upon saving.

Wording can be improved, but you get the idea. This would also solve the issue with multiple levels of nested entries, because I can set the behaviour I want for every Matrix field at every level.

[thupsi]

I was thinking something along those lines also, see my comment above

Would it be possible to have an option, per matrix field, to either "save changes immediately" or "participate in owner drafts"?

Now that I think of it some more, and expanding on @MoritzLost 's thinking, maybe in the case where the Matrix field is set to behave as a classic matrix block, you could remove the "Save" button completely in slideouts and just leave an "OK" button that will create a draft to be published along with the parent entry's save.

That leaves the problem of full screen editing of those "block" entries, where it would be weird to have an OK button. I can think of two options:

1. Disable full screen editing for "block" entries.
2. Have a sort of notification on save (like the one for provisional drafts) that goes something like "This is nested content, your changes will apply when you save the top level parent".

Edit: Actually if you want to keep the save button in slideouts, you could have such a notification as described above.

[MoritzLost]

@brandonkelly What do you think about adding an option as I suggested in my comment above?

I understand this may not be a priority, though for some use-cases this is a vital issue. Could you let us know if this is still on the roadmap and if/when we could expect this issue to be addressed in some way? We're planning our Craft 5 updates, and we would love to be able to utilize the new element cards, but this lifecycle issues makes this impossible for most use-cases.

[MattWilcox]

I think the problem is the assumed context. It feels like Brandon and team P&T are thinking as though the most nested element is always the contextual reference - whereas when I'm editing a page the page is the important context and everything else is subject to that. i.e., if the page is a draft everything in it is also a draft. I think in terms of the page because I am in the CMS's page editing context.

The implementation of Cards really muddies that if the content of the card isn't isolated to the same context.

Tough one.

In my head, the behaviour Brandon describes is something I'd expect in a relational field like an Entry field. But not as part of an Entry Type. Which is not a field. It's its own thing.

[thupsi]

An entry though is not always a page. It could be a taxonomy group for example. It could be a global settings group. It could be lots of things where it's not the most important context. I'm playing the devil's advocate here, but really I'm trying to poke at this from all angles.

[MattWilcox]

That's my point though about "the context". In my head, you set the context of what you are doing from whichever section you're editing in - and the fact that Entries (the New Thing and not The Old Entry Concept) don't behave differently because they don't take into account the context within which they're used is "the issue".

I'm sort-of saying that the idea that Entries (The New Thing not The Old Thing) are applicable in many places as the same instance instead of their own instance is a fundamental problem.

[thupsi]

I think, ultimately, the correct "context", can only be known by the developer, so, the nested entry/block's behaviour should be configurable.

[maxstrebel]

Yes, I completely agree. I like the entrification and that they all share the same behavior. And that this makes them pretty exchangeable.

I still have the gut feeling that making them all entries under the hood but distinguish between an entry (as in page or entry) and a block (as a block in CK or in a Matrix) would be a better choice – instead of making it configurable, what might make projects even more complex to set up and to get into. This would give it an option to move stuff between sections, but would solve a lot of the UX/AX/DX overhead because the slideout could show the info if it is a relation or a block. You can rely that a related entry can (and should) easily be saved right away and that a changed block will be part of the entry/draft/release. I know this poses challenges in performance / database / versioning.

[maxstrebel]

Hey Brandon, this ticket had quite some comments on the philosophy of how things should work. I took some time to test Craft 5 with some smaller clients.

So besides all technological topics, Craft CMS is a content management system. In the current state, I have to add a warning text to the CK Editor fields, that authors cannot make any changes to it when they do a draft because (button, image, quote, ...) changes will be live right away. Same is for Cards (although I can just not use it).

Documentation at my clients now is as follows: Ideally they should use drafts for new versions of the content (event page for next year, new education offers, etc.), because they keep the revision history, slug (and more). But if there's changes to a CK Editor field (with blocks), they need to either duplicate the block, or save a new entry and switch them.

It keeps getting harder to tell the benefits, because it is really confusing and feels wrong. My bigger clients want their interns to edit the content. And they understandably start to ask if we can get back to something easier.

Will changes to CK be part of a draft at some point? Or is this something that will stay this way for a longer time?

[thupsi]

It's a little hidden (you have to open them in a new tab to see the complete UI), but you can still use drafts in nested entries. In my example, when I make a change to an individual apartment I don't want that to be tied to the apartments index drafts or versions, that would feel wrong and unexpected.

The problem for some (most?) cases is that you would want the drafts of the owner to be in sync with the ones of nested entries.

[thupsi]

Yeah, makes sense. Though this is a very specific use case. Still also in this case, I'd assume as the information is shown on this specific page, why would you NOT want it to be part of the draft?

The information is displayed in many places, not only in the apartments index.

[thupsi]

It's a little hidden (you have to open them in a new tab to see the complete UI), but you can still use drafts in nested entries.

[maxstrebel]

So I'm NOT talking about nested entries :) they're completely fine as they are. I'm ONLY talking about Matrix Blocks and CK Editor blocks.

So apart from the obvious case of CK Editor, in 99% of the cases my clients use drafts to either review content before it goes live or the prepare a new revision of a page. Examples are:

• Event is over and the event page should show impressions from the event (completely new blocks)
• A page is a preview page but at day X a product becomes available. You want to prepare the page for day X and just apply the draft on day X
• You task an intern to do changes but a senior person has to proof before it goes live

All these are use cases that every of my clients above a certain budget makes sure are present. And I have to make sure these workflows still work. In Craft 5 this means I can only use Inline Matrix Blocks and no CK Editor Blocks.

That said, CK Editor Versioning/Drafts is the main problem for me. As I cannot reasonably explain why changes are not part of the draft.

[thupsi]

As I said before, I agree with you. This may not be clear (my fault) because we got a little sidetracked with my particular example. In many cases (don't want to say most cases, because people can do all sorts of things with such a flexible system) what you're asking should be the default.

My "sidenotes" are fineprint:

• Nested entries and matrix blocks should continue to be able to be used interchangeably, it should be up to the dev to decide. You say that you don't want to lose existing abilities, but if we separate blocks from nested entries we shall lose new abilities.
• You can still use your old way of doing things if you keep matrix fields in inline mode and don't use nested entries in CKEditor (keep using the old way of matrix fields and CKEditor as an inline block in them). I realise and agree this is not ideal, we want the best of both worlds.