![]() ![]() Here's another one that should be even easier (because it's about DB schema not actual content) but is still stuck on this sort of problem: #3030154: layout_builder_layout_section column hitting database limit I can't find the issue right now, but there's another LB issue where we got stuck with this same problem. However, this might be extremely difficult to update for existing overrides (stored in field data) because we'd have to check every entity with LB overrides enabled, every revision of that entity, for every language that entity has been translated to. I wish we'd written it this way originally!Īnd it would be very straightforward to write an update path for defaults (entity_view_display config). Sections in config would be an associative array based on a UUID instead of a numerically indexed array: third_party_settings: Update demo_umami and test profile config to include UUID's on sections in appropriate core.entity_view_display.* files.Write an update hook to add UUID's to existing section instances.Update appropriate calls to new Section() to include UUID when appropriate.Determine whether we will also need a weight property.Add a UUID property to the Section class.It's worth pointing out, there is already similar UUID behavior with Drupal\layout_builder\SectionComponent so this doesn't feel too far off from what is already happening elsewhere. In either case, there's still no clear way of knowing whether a section had been overridden or not, so presumably, all sections in existing overrides would be considered changed, but I'm personally okay with that. Alternatively, instead of an update hook, we could maybe modify the Section::getUuid() to generate one if one doesn't already exist for the respective layout section, but that does require updating layout settings on a getter method, so I'm unsure if that's actually ideal here or not. Write a post_update hook to generate a UUID for all existing layout sections (both entity type displays and entity overrides).Either replace LayoutSectionItemList::getSections() with UUIDs as keys instead of indexes (potential BC break), or create a separate LayoutSectionItemList::getSectionsByUuid() method to get the sections keyed by their uuid instead.Add Drupal\layout_builder\Section::getUuid() method that can be used to retrieve the uuid for the respective section.Generate a UUID for each layout section when it gets created (but shouldn't change when a section is updated).Since it only position-based, it's not immediately obvious whether or not "Section 9" was renamed to "Section 10" or if "Section 9" was removed and "Section 10" was added.Īdditionally, since labels are optional, it's not something that can be reliably keyed off of in the first place. LayoutSectionItemList::getSections() produces "a sequentially and numerically keyed array of section objects." ![]() Components Updated in "Section 30": (Added "s", Removed "q")īut the problem is that there doesn't seem to be a way to clearly identify which sections are which.What I'd like to be able to do is take the above, and automatically produce an output that looks something like this (not exactly this, but just to demonstrate what I'm trying to do): Label: "Section 40", Layout ID: "onecol", Components: z.Label: "Section 30", Layout ID: "twocol", Components: r, s.Label: "Section 10", Layout ID: "onecol", Components: x, y.Now assume that an individual node overrides that layout such that the layout structure looks like this: Label: "Section 30", Layout ID: "onecol", Components: q, r.Label: "Section 20", Layout ID: "twocol", Components: m, n, o.Label: "Section 9", Layout ID: "onecol", Components: x, y.So for example suppose you have a content type with the following sections defined in the entity type display settings: I'm trying to identify exactly how an entity's layout has been overridden from the default settings set at the entity type display level in the layout builder settings report module ( #3202578: Improve Override Report). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |