- Issue created by @longwave
- πΊπΈUnited States tedbow Ithaca, NY, USA
It seems like this should be stable blocker decide at least if we want to do this. If we do it is probably better before stable otherwise I think we would have to write an update hook that would update all content entities to use the new structure.
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
This also relates to π± [META] 7. Content type templates β aka "default layouts" β clarify the tree+props data model Active : once content type template exists, the following scenario can occur:
- the XB content type template for "article nodes" has 3 subtrees that are unlocked, i.e. in which content creators can do whatever they want
- that means the XB field for each article node won't store a single tree anymore (under the root UUID), but 0β3 trees!
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
ContentTemplate
config entities now exist.β¨ Content templates, part 2: store a component tree in the template, and allow individual entities to fill in specific slots in that tree Active is in, and β¨ Content templates, part 3b: store exposed slot subtrees on individual entities Active is being worked on. @phenaproxima, any thoughts on this given you're actively working on #3519352? π
- πΊπΈUnited States phenaproxima Massachusetts
Well, at the moment, β¨ Content templates, part 3b: store exposed slot subtrees on individual entities Active uses the root UUID to know what components in a subtree need to be injected directly into an exposed slot, and which components are just added to the main tree.
Having said that, though, what would the tree structure look like if we made this change (how would it represent infinite nesting)? That would help me understand any knock-on effects for exposed slots.