Umbraco-cms: V8: Element type content in the content tree or not?

Created on 21 Jan 2019 · 8Comments · Source: umbraco/Umbraco-CMS

With the introduction of element content types we're faced with a choice: Do we allow element content types in the content tree or not?

A common use case is to have a folder of widget elements within the content tree for reuse across the content tree. Element content types are ideal for this use case. If we allow them in the content tree, that is.

Allowing element content types in the content tree has several backdraws though... for example:

Editor confusion. Do we really want to encourage solutions with non-routable content in the content tree?
Element content types shouldn't be selectable e.g. in the link picker. But they most certainly should be in the content picker. Or maybe that should be configurable.
Allowed tree actions, template assignments and whatnot are different for element content types.

The alternative is to deny the creation of element content types in the content tree. But even if we do, we still need to address the fact that they can exist in the content tree - e.g. if the content type was made into an element type subsequent to creating instances of it.

I have made some PoC's for both cases and they both seem manageable. Question is: Which direction do we pursue?

communitpr releas8.0.0 typbug

Source

kjac

👀1

All 8 comments

I don't think we should allow elements in the tree.

Elements are meant to represent something that does not have a corresponding record in database, etc. I get the need for "widget things" that would be non-routable items, but still full tree items. But then, I feel it's something else, and I'm afraid mixing with elements is going to be confusing.

Which means... elements should not appear in the list of candidate child types, for a content type. And should not be created at root.

Thoughts?

zpqrtbnk on 22 Jan 2019

@zpqrtbnk I'm inclined to agree with you. Although it would be convenient to have element types in the content tree, it really does feel wrong. I fear it's a quick fix that we'll regret down the road.

Also... we can always allow them later on if need be. It's harder to disallow them once people have started using them.

Maybe we should create an "element tree" where the editors could create reusable content blocks. But that's for another day.

Off the top of my head I can see we need the following changes:

It shouldn't be possible to pick element types as allowed children to other content types.
It shouldn't be possible to create element types in the content tree.
If a content type is changed into an element type, the editor must handle existing items in the tree gracefully.
If a content type is changed into an element type, the various tree pickers (content picker, link picker, multinode picker, ...) must handle any existing picked items gracefully when rendering.
The various tree pickers (content picker, link picker, multinode picker, ...) should not be allowed to pick element types (in the case where a content type is changed into an element type) (this is a nice-have).

I'll start throwing some PR's in your direction 😄

kjac on 22 Jan 2019

OK. Pull requests for items 1, 2 and 3 are now ready.

I have managed to provoke a PANIC exception by picking a content item in a content picker and then turning the picked content item type into a an element type. It's got to do with URL resolving (which shouldn't be possible for elements), so we can code around it. Funny thing is I can't reproduce it after a restart, even with the exact same DB and setup.

panic

Now I'm also starting to see errors that haven't been there before when editing existing element type items after some random save and publishing. Perhaps the cache is not liking the element types too much? This one looks like some mapping issue which should also be possible to resolve, though.