[4.0.0-beta.1] Ability to embed existing entry

[Mosnar]

Description

More of a questions than a bug: will we be able to select an existing entry to embed?

I was able to hack-around not being able to select existing entries to some degree by copy and pasting the embedded entry I created (which seems to work very well, by the way!)

Video demo:

CleanShot.2024-02-07.at.14.18.28.mp4

[brandonkelly]

That’s not currently planned, but maybe worth considering.

[wmdhosting]

+1 for this..

[gregorterrill]

Agreed. As another example, it feels weird that I can have a Testimonials section with a Testimonial entry type, and I can see and edit those in the Entries section. But then if I let CKEditor add entries of the Testimonial entry type, they look the same in terms of fields so the user adding them feels like they're doing the same thing, but they don't appear in the Testimonials section (and similarly, I can't reuse ones I've already created via the Testimonials section) because they're owned by the entry the CKEditor field is on and not first-class entries themselves (I think?).

[davidhellmann]

I can understand booth sides. CKE should not be a matrix field. When you need a lot of "external" content then maybe a matrix field is they way to go. For me the approach is a bit more to enhance the CKE and having a bit more control how I can add a button or a headline block or an image etc. When you add the possibility to select entries then you need more settings what the user can select. Just the entryType didn't work because it can be on different sections. And Matrix fields work the same way? When you need a dedicated entry selector (a relation field) on the entryType? All entries created on a matrix field belong also just to the entry and it's also not possible to select an existing one? When I need an entry from a section a have to create a relation field.

But Interesting discussion.

[AugustMiller]

Worth noting that when you output a CKEditor field in the front-end, Craft attempts to get a string representation of each nested element.

Without an intermediate "owned" entry (and entry type) to connect existing content, you would be left to handle rendering those elements with their own partial (i.e. _partials/entries/post.twig) for both CKEditor fields and wherever else they get used.

Instead, discrete entry types for "Asset Block" or "Related Entry Block" allow you to customize exactly how the external content appears in that context (with a partial like _partials/entries/embeddedAsset.twig)!

(I suppose you could sort of reverse out of the partial in the first scenario by looking at whether the element is "owned," but you may or may not have information about what field context it's being rendered in, etc…)

Ransom's revelation about this feature being a means of embedding structured content is spot-on; I'll make sure to stress this as I get to CKEditor docs! 💞

[brandonkelly]

It feels a little odd not to support it - I'm curious why not?

We set out to build a better way to manage longform content. The nested entries are part of that content, so it makes sense that they are owned/fully managed by the field.

You can still have relationships with that setup; they would just need to exist within the nested entries. (We have an example of this in the Craft 5 update of our Europa demo.)

There is no technical reason we can’t just allow both though, so that’s why it’s worth considering. However we’ll need to take care to make sure there’s a clear visual distinction between nested entries and related elements.

As another example, it feels weird that I can have a Testimonials section with a Testimonial entry type, and I can see and edit those in the Entries section. But then if I let CKEditor add entries of the Testimonial entry type, they look the same in terms of fields so the user adding them feels like they're doing the same thing, but they don't appear in the Testimonials section (and similarly, I can't reuse ones I've already created via the Testimonials section) because they're owned by the entry the CKEditor field is on and not first-class entries themselves (I think?).

Right—the entries are fully managed by the CKEditor field itself, just like Matrix fields (particularly when set to the card view).

[gregorydavidjenkins]

I just got done with my first full content model and build out using Craft 5 and I've been thinking a lot about this new paradigm. I'm not totally sure where I've landed either, so these are more just musings. First, I think the new changes are incredible – sort of what I've always wanted Craft to be able to do.

I think everything being Entries is a really good abstraction from an architectural standpoint, but I've stumbled over the control panel terminology more than once in my mental model. I think that might be what's happening in this thread as well.

If (inside of a ckeditor) I'm creating an "Entry", then ... where is that entry? My past experience with entries tells me it's somewhere I should be able to locate and reuse. But that's just because the word entry appears in the "Create a new entry" dropdown. If it said create a a new "block" I don't think I would make any of those same assumptions. (or maybe I get to choose what it says as part of the ckeditor configuration). Honestly it might be better for it to not say anything, but be a sort of Icon that implies adding a modular piece of content.

I had to back out and tell myself: I never used to be able to expect to "find" a matrix block (in the control panel, for example), and was totally comfortable with it completely living inside of the field in that one parent entry. Same with something like a vizy block.

It makes sense logically now that I've played around for a while, but it took me a while to understand how/why an entry might appear in the "Entries" section of Craft and why it wouldn't. I think the situation where you have an entry type that is available in a section and also available in a matrix/ckeditor is a bit confusing. When I query that section those matrix/ckeditor powered blocks won't be included, but (I assume) if I query the entry type they would. That's just a new concept, not bad, just unexpected.

Thinking out loud, I think the cost of removing some of the built-in structure and flattening everything into an entry (which I think is a good move, again) is some clarity in the Control Panel and I imagine as feedback continues to roll in, there might be some low-hanging UI changes that might fill in some of the gaps.

I think some folders or a simple taxonomy for entry types (lightweight, just a control panel aid in the same way field groups used to be somewhat disposable) would be great. After content modeling for just a couple days I immediately began prefixing entry types with "[Block]" – now I've seen a few conversations/screenshots of others doing a similar thing.

Perhaps it's just the learning curve, but I imagine that entry types list is going to be dramatically longer in Craft 5 (if I converted the last Craft 4 site I made into this scheme there would be at least 80 entry types, probably more). It's somewhat disorienting to see "Two Column Text" (something sort of modular like a block), next to "Homepage" in the list. Again, I get that architecturally making them one thing is the best move, I'm just trying to picture some Control Panel UI that might help.

[brandonkelly]

But that's just because the word entry appears in the "Create a new entry" dropdown. If it said create a a new "block" I don't think I would make any of those same assumptions.

I feel like “entry” and “block” are both pretty generic words¹, and we should be focusing on ridding the authoring UI of both of them. In the next Craft release, for example, it will be possible to customize Matrix fields’ “New entry” buttons with something like “New ingredient”.

¹ I could agree that “block” is slightly more specific – it is only ever used to refer to a piece of content that is a nested component of another piece of content. But calling nested content within CKEditor fields “blocks” feels one step forward; two steps back to me, because “blocks” only makes sense in contexts where the blocks make up the entirely of the parent content, whereas CKEditor fields are mostly made up of rich text, with some nested content sprinkled throughout.

[gregorydavidjenkins]

I feel like “entry” and “block” are both pretty generic words1, and we should be focusing on ridding the authoring UI of both of them

Yes, agreed!

I think being able to customize some of that language in the CP is absolutely the best path forward.

My comment about the word block has more to do with my own context (using Craft for a decade or whatever) and less to do with the ideal future state you are pointing to.

Any plans to make that same "New Ingredient" magic happen for the ckeditor nested entries UI?

[brandonkelly]

Just added a “New” Button Label field setting for the next release 🎉 (546c67d)

[brandonkelly]

Just tagged version 4.0.0 with that new field setting.

[gregorydavidjenkins]

Thank you!

[theAdhocracy]

+1 on this! Our use case is for content that both lives within a specific article and outside of it, and we're looking to migrate our existing Matrix/SuperTable setup to CK Editor, but right now this is giving us pause.

Specifically, we have travel articles that often contain asides or callouts to other pieces of content, for example a restaurant or tourist location. These callouts are placed between relevant paragraphs of text – so if a person is writing about a meal they had, we'd often call out with a restaurant card – but editorial may want to move them to a different location within the article. They're also likely to be created new for a given article (it's not often that we'd review a location more than once). In both instances, CK Editor gives our authors much better flexibility.

However, sometimes an author will create locations or other callouts whilst they're in situ. This allows us to have a stream of regular content. When they write up the article, they'd still want to insert that callout, so being able to embed existing content would be great. It frees up different authors to work in different ways.

[theAdhocracy]

Just to add: after some experimentation, it appears you can take the copy/paste hack from @Mosnar one step further if you have the Source button enabled. However, there's a major caveat (see below).

You can copy/paste an existing embedded piece of content, and then alter the data-entry-id to any valid, embeddable content entry. For example:

<craft-entry data-entry-id="12345">&nbsp;</craft-entry>

Within the editor this appears to work. It initially throws an error, but once you save the entry and refresh, it starts displaying the card as it would elsewhere.

However I don't see content embedded with this technique returned in GraphQL queries. I'm still trying to understand how GQL is meant to work with nested content in CK Editor fields (as it doesn't seem to do what I'd expect), but it appears to always be absent. I'm not sure, though, whether it would render correctly with a partial, as the paragraph element and content title are returned in the same way as regularly embedded entries, so it could be worth a shot for someone with a Craft-powered front end 😉

[MangoMarcus]

+1 for this, although it might also be worth considering adding something like this to Matrix fields too. Ie. allow selecting an existing entry for a certain entry type in a matrix. I was imaging the existing entry would behave like an entries field where they're not editable inline, although I suppose that's also something to consider.

I appreciate you'd normally use an "entries" field for this but it'd be useful to edit some block types inline in the matrix, and other block types just select existing entries. There's no way to do this atm without defining and intermediate block type for the matrix.

[natecartwright]

+1 for the ability to specify existing entries for ckeditor and matrix fields. With the new ability to easily copy out matrix block entries and to return raw content of ckeditor fields, we have the ability to re-use entries first created in matrix blocks/ckeditor fields, but for full content re-use we need the ability to then select those independent (now re-usable) entries. This turns Craft into a fully Composable Content Management System!