"Master Entries", "Entry Instances" and "Template entries"

[thupsi]

While contemplating 16199, I was thinking that there must be a better way to handle global blocks (and global content in general), a topic that has been broadly discussed in Discord, with no globaly (pun intented) accepted solution.

Before Craft 5, a decent approach was Justin Holts' "Using Entries and Relationships as a content builder system".

Currently, my personally preffered solution is to use a "global blocks" section and use an entries field inside a matrix entry to fetch global blocks (entries) as described in my comment. Essentially this is a mix of the new nested Matrix and Justin's method of global entries.

While this works and is flexible, it still has problems:

1. You can't easily search content linked via an entries field.
2. You can't edit the entry inline in an entries field.
3. If you were able to edit the entry inline the author would probably be confused when the content was changed globaly.
4. If you want to use a "global" entry as a source for fallbacks/defaults in a "local" entry, you need additional logic and fields in your "local" entries.
5. If the content in an entry is mostly linked global entries, as described by humandevs in 16199, the "ownership" of that content feels a bit muddled. Is it global only or does it also belong to the entry? Or both?

After some thinking I have a proposal to add the ability for matrix fields to have - in addition to blocks (nested entries) - entry instances:

• The entry instance would be a duplicate of an existing entry that is created on the spot, as a matrix entry, and would store its "relation" with the master entry.
• Master entries should not live inside a matrix (since they are meant to be of global scope), but should be able to be cloned on the spot from a matrix entry if needed and placed in a section, and then the matrix entry should become an entry instance.
• The entry instance would be editable but would also be able to push or pull changes from/to the master entry.
• The master entry would be able to push changes to all its instaces (effectivelly reverting all local changes in them).
• Pushing and pulling would replace all content, to keep things simple, but maybe merging of changes could be added in a future iteration if this feature gets implemented.
• Master entries and entry instances would idealy be marked as such in the UI with links to "master/instance" relations.

Benefits:

• All entry instances will be owned by their local owner entry: they would be essentially Matrix entries with some added powers.
• Since they belong to the local owner, they will be easily searchable.
• Since they can use the matrix editing UI, they can be editable inline.
• Pushing/synching would be manual, so no accidental changes to global content or vice versa.
• Local content deviations could be easily made and easily reverted.

One last thing: There's no reason entry instances should only be used inside Matrix, that's just a made-up limitation. For example "Master entries" could be used as "Template entries" for any new entry, in any section, and have the same pushing/pulling capabilities.

Thanks for reading this, hope it makes sense!

[humandevs]

This would definitely work for our use cases, and would be more flexible than being able to insert matrix entries into other entries (which causes confusion over who/where the 'parent' is and should be). It also allows content authors to not know that they will be re-using content when they initially create it, but allow them to pull it out for re-use later.

FYI the link to Justin Holt's page didn't work for me, but I was able to find his presentation video here: https://craftcms.com/events/dot-all-2022/sessions/using-entries-and-relationships-as-a-content-builder-system

It's possible it could get problematic once a lot of entry instances are created. For example, we build knowledge bases and user manuals, and the number of instances of the "warning" callout is quite a lot, at least a couple in every manual. It doesn't get updated very often, but there are cases where the name of a product changes, etc, and it would have to updates all of those instances across the entire database.

Embedded vs linked entries is, thus, perhaps, a philosophical question.