FREQ: Inline editing display for Entries fields and remember last parent selected for an entry created in an Entries field

[humandevs]

We've moved to Entries fields from Matrix-In-Matrix to allow Entries to be re-used in multiple places, but the editing experience is not as great - requiring clicking into the Entry to edit it, and then requiring choosing "Select Entry" once the nested Entry is created. The turtles-on-turtles-on-turtles can get a little confusing. I think it would make sense in this case to by default assign the parent of an "inline editing" created Entry to the parent of the nested Entry added to the Entries field.

An alternative to Inline editing of Entries fields would be inline editing of fields added to a card. However, although the cards view is good for a quick summary, it's not quite as nice as inline editing a Matrix block where we can see all the formatting of the text and image fields in the block.

Another option we could do is use Matrix blocks or CKEditor blocks instead, but we'd need a way to be able to re-use those nested Entry blocks, and be able move an Entry out of one matrix block into another easily, like we can with changing an Entry's parent. Thus, inline editing view of Entries fields would make more sense, I think.

Also, another issue is organizing Entries in an Entries field. Currently, if an Entry is added to an Entries field, you have to select which parent you want for that Entry, for each entry you add, and the Entries selection dialog also doesn't remember what Structure/parent you last picked an Entry from. When using Entries fields like re-composable Matrix fields as we are, often many entries will be added in sequence, and it would be nice to have an option to remember the last parent used, and default to that, or a button to "Create Entry and Create Another Entry Like This" that keeps the metadata of the created Entry, leaving you in the Create Entry screen so you can create multiple at once without having to click back and forth a bunch.

Or, of course, allowing "digging into" a Matrix/CKEditor block Entry from the Entries selection dialog box for Entries fields and Matrix fields, to enable content re-use in Matrix blocks and CKEditor fields by selecting only a single block to insert into another Matrix or CK Editor field or Entries field, like how the Entries field works. In this case the nested Entry would need to be 'owned' by just one Matrix block or CK Editor field, but usable in multiple, which I think is more confusing than sticking with inline editing Entries fields when componentized & reusable Entries are needed. This allows us to use all of the existing features of Entries filters to find relevant 'block' Entries (Structures, Categories & Tags).

[thupsi]

If an entry is edited inline wouldn't the author expect that edit to be local though? Global/reusabe entries are IMO benefited from appearing as separate entities from the entry they are being related to.

That being said, I fully support the idea of nested matrix entries being portable and selectable from various contexts. Additionaly, it would be awesome if a "global" entry could be used as a template for newly created matrix nested entries (basicaly we would need a way of cloning an existing entry from a given section when creating a new nested entry).

The way I would go, with existing functionality, about reusable entries:

• Global blocks section with entry types A,B,C etc
• Global block entry type with an entry field accepting entries from Global blocks section.
• Blocks matrix field accepting Global block AND entry types A,B,C

As a bonus, the Global block entry type could have fields to partialy overide the selected global block OR each entry type A,B,C could be optionaly related to a global block of the same type to pull fallback content from it.

[humandevs]

That is a very good point that in many cases simply using a Blocks matrix field that can insert an Entry Type with multiple "global" Entries or one-time Blocks solves many re-use scenarios and is better organized to differentiate 'insertable' Entries from 'owned by' Blocks.

Also, we keep a Structure for each level of nesting, and only allow Entries from that Structure to be inserted into the corresponding Entries field, otherwise this becomes a mess real quick.

Argument for needing Entries fields now instead of hybrid Entries/Matrix blocks

Our sites structures are generally Product > Chapters > Articles > Blocks, but both Articles and Blocks need to be re-usable, and content authors won't necessarily know they will need to or even are able to re-use Entries but not Blocks when adding them, because the new product revision will be 90% the same except that 10% that needs to be replaced/added/removed as it does not apply to the new Product when the new Product comes out. Thus, Entry fields are I believe the only way to currently ensure re-use is possible in the future.

A simple feature to "eject" a copy of a Matrix block to its own independent Entry would solve that problem, by allowing us to default to using Matrix blocks until we need to re-use the block, and "ejecting" it to its own global Entry.

Using Conditions to reduce need for Entries fields

We do have clients with a lot of similar Products where 80% of the chapters are the same, but not too many where those are more than a handful of Products. However, conceivably, other companies may have a ton of products with minor version revs. We're handling this with Entry Conditions that hide Articles or Blocks based on the Product Features (Categories) of the Product currently selected. This cuts down on the number of re-usable Entries needed, as one Chapter with conditional Articles or one Article with conditional blocks can be re-used for multiple Product revisions or similar Products.

Issues with portable/selectable Matrix blocks

Adding the ability for Matrix Block Entries to be portable/selectable for re-use instead of using Entries fields has the problem that, if a block is re-usable, it by definition probably shouldn't be owned and nested by one Entry. This is why we also currently have a "Folder" Entry Type, because by-definition a re-usable "block" doesn't nest neatly into a tree hierarchy of Matrix block containing Entries (it goes into at least two!), so adding them as a child of a single Matrix Block/Entry doesn't make sense. Instead, having an Entry Type ("Folder") in the Structure that is exclusively used for organization and not content allows a logical grouping of "re-usable" Entry blocks using a flatter organization structure than using a Matrix field as the organizing hierarchy.

Organizing Entries created from an Entry field's Create Entry interface

However, by default nesting Entries under their Parent makes the most sense, as not all blocks will be re-usable, and the first time you create a re-usable Entry, it's only tied to one parent, at least at first. Only the Entries that actually are re-used elsewhere should be pulled out into organization Folders/Groups, or tagged with a category to relate them all together.

All of this is why I think conceptually for re-usable content, enabling inline editing of Entries fields is more organized than enabling re-usable Matrix fields. Plus it makes it easier to have the interfaces for each differ:

Avoiding UX confusion of inline editing Entries

To avoid the confusion of content creators thinking their edits are only local, we could:

1. Show the Entry Type icon, entry name, breadcrumb, and perhaps the Structure above the inline editable entry
2. Require an extra click to get to edit mode
3. Add a note indicating you are editing an independent Entry which will change the content any place that Entry is displayed
4. Link to docs explaining diff between "insertable" Entries fields and "owned by" Matrix/CKEditor fields
5. Have a link to Show RelatedTo and Parent and Children of the Entry to help elucidate where else the Entry is used.

Similarly, re-usable Matrix/CKEditor Entries come with the same UX dilemma as inline editable Entries fields, but in reverse, and I'm not sure how you then indicate a Matrix block has been re-used elsewhere. So, leaving Matrix/CKEditor nested entries as permanently owned by their parents, and enabling inline editing of Entries fields I think is easier to grok.

Real World Example

To help better contextualize this, it might be helpful for an example:

For our sites, we generally use Product > Chapter > Article > Block organization. Products have a list of structure children Chapters, and Chapters have an Entries field of re-usable Articles, and Articles can be of two types:

1. Step Articles have an Entries field called Steps that contain multiple Longform Articles
2. Longform Articles have an Entries field called Blocks that contain Composable Blocks of various component blocks Entry Types.

Thus, three Structures:

Products: Contains Products and children Chapters entry types
Articles: Contains Step Articles and Longform Articles entry types
Composable Blocks: Contains various block entry types like text, text + image, video, 2 column text, etc.

And the "Folder" Entry type can be added into these Structures to "group" related Articles or Blocks that might be used in multiple places, instead of having a really deep tree of Matrix blocks.

Current downsides of Entries fields, in summary

This means though anytime you want to add a new Step Article, you're delving 3 levels deep of creating entries, adding their parent, clicking Choose Entry, etc, whereas with a Matrix-in-matrix inline editing this all happens on one page; but then none of the Entries are re-usable.

How to improve confusing multiple relations

Finally, and not totally related (pun intended), to reduce confusion we have added a Relations tab to all Entry Types, which has a Twig Template that grabs all the Parent, Children, and RelatedTo (w/ Fields!) entries and displays them with a link to the related Entry, so content creators can see where Entries are used, and jump up and down the trees between Entries easily. We also display related Categories in the Relations tab, which lets us organize across Sections:

And, for reading all of that, here is a picture of some kittens in a computer: