[5.0] Lifecycle of nested entries and their owner

[wsydney76]

Although I'm no longer involved in active Craft (or any other...) work, I was asked to sum up changes in Craft 5 and how to adopt to them.

All fine so far, but there is one thing I can't wrap my head around: the 'lifecycle/workflow' of nested entries in different view modes.

Not sure what is intended, buggy or just not finished in Alpha, but didn't want to wait until a beta is available.

The view mode 'As inline-editable blocks' seems to work as before, however, when switching to 'as cards' the behavior changes.

According to the wording 'View Mode - Choose how nested entries should be presented to authors', I would have expected that there is only a different UI, but in fact the behavior of drafts/publishing changes.

So starting with an entry with a couple of blocks of a typical content builder (heading, text, image etc):

• Editing and 'Save' an existing nested entry does not create a provisional draft, but publishes it immediately (= the frontend shows the change).
• Creating and 'Save' a new nested entry creates a provisional draft. This change is not visible on the frontend (as expected)
• This means the frontend shows an unwanted, inconsistent state.
• Creating two different 'regular' drafts of an entry: When a nested entry is updated in one of the drafts, it is a) visible on the frontend, b) also updated in the second draft. So both drafts seem to share the same instance of the nested entry.

So all of this seems unwanted for just another 'View Mode'. (Didn't try the 'element index' thing.) I would expect all modes to work the same way: Nested entries are not immediatly saved, but just 'applied' to their owner entry, and published alongside with the owner.

That said, I can think of other use cases for nested entries that might benefit from a different behavior: While 'Content builder' things are an integral part of their 'owner' and only make sense as a whole, there could also be information models that implement nested entities as part of a hierarchy, independent from each other and their owner.

For example categories contain articles, films contain screenings with date/time/location, tv shows contain episodes, cities contain locations etc.

In this cases it makes perfect sense that nested entries 'lead your own life' without effecting the owner entry (even adding/removing then would not create a provisional draft of the owner). That would also be the perfect use case for the 'entries index view mode' with all that extra UI.

Looking forward to some clarification, thanks.

[brandonkelly]

Your assertions are correct. Matrix fields in card/index views (both identical as far as workflow is concerned) are meant to mimic relational fields.

• Both allow you to edit nested/related elements independently of the parent.
• Changes to which elements are nested/related, or their sort order, will cause a provisional draft to be created, and the change won’t actually affect the front-end until the draft is applied.

So while the interaction model is certainly different than working with inline blocks, it should feel very familiar to relational fields (which cards view is meant to resemble visually, as well).

So all of this seems unwanted for just another 'View Mode'.

Agree it’s a larger behavior change than you (the developer) might expect. The original plan was to introduce an entirely new “Inception” field type, primarily because the interaction model changes felt too big for a “view mode” setting.

We ultimately decided it was OK because it’s a developer-facing setting, so it’s something we can document, and developers can train authors on the change, if they decide to switch view modes. To an author who doesn’t have access to the settings, there would be no difference between it being a view mode or an entirely different field type. Plus, as a field setting it’s much easier to switch between view modes than it would have been to switch between field types.

[wsydney76]

@brandonkelly Ah, ok, I see. I have to admit though that I would never have come up with the idea it would work like this, given the wording on the field settings page, and seeing ideas like @thupsi suggested in #14202. Having a card with just text on it inside of a field labeled 'Content' does not really feel like just managing a related entry with its own lifecycle.

I would like to suggest making that clearer not only somewhere in the docs, but on the settings page itself, that you are not just changing the UI, but also the workflow behind it.

So for my little 'How to use changes in Craft 5' guide, I would not recommend using the card view for 'content builder style' things.

As this is probably my last Craft/Web/IT work, changing focus to 'real world only', I would like to say thanks again for all your work and support!

[brandonkelly]

Made some improvements to working with nested entries (and addresses) for Craft 5.5: #16002 🎉

[brandonkelly]

Craft 5.5.0 is out with those changes 🎉