Still on Drupal 7? Security support for Drupal 7 ended on 5 January 2025. Please visit our Drupal 7 End of Life resources page to review all of your options.Overview
For the 29. Layout patterns (i.e. sections) product requirement, we need a new config entity that:
- stores a component tree, with no dynamic prop sources, only static prop sources (because dynamic ones require a particular context, static ones don't)
- has a human-readable label
- can be validated thoroughly (including the above point)
- depends on the
Componentconfig entities it uses - has thorough test coverage: a subclass of core's
ConfigEntityValidationTestBase
Out-of-scope, follow-up issue needed:
- can be listed/read by the UI using a HTTP API: #3479982: HTTP API to read+write PageTemplate and Pattern config entities
- can be created by the UI using a HTTP API: #3479982: HTTP API to read+write PageTemplate and Pattern config entities
Together, that will allow un-hardcoding #3463300: Implement the concept of sections within the client 😄🤞
Proposed resolution
Create a new Pattern config entity type using the following config schema:
experience_builder.pattern.*:
type: config_entity
constraints:
FullyValidatable: ~
mapping:
label:
type: required_label
label: 'Label'
# A single component tree.
component_tree:
constraints:
ComponentTreeMeetRequirements:
# Only StaticPropSources may be used, because a Pattern cannot rely on an entity of a particular type
# and bundle to be present everywhere it is inserted/used.
props:
absence:
- dynamic
- adapter
presence: ~
tree:
absence:
# @see \Drupal\Core\Block\MainContentBlockPluginInterface
- block+system+system_main_block
# @see \Drupal\Core\Block\TitleBlockPluginInterface
- block+system+page_title_block
# @see \Drupal\Core\Block\MessagesBlockPluginInterface
- block+system_messages_block
presence: ~
type: experience_builder.component_tree
label: 'The component tree a reusable pattern'
💡FYI: type: experience_builder.component_tree already has thorough validation! That means 90% of the work is done. What remains is crafting a new config entity type with test coverage, and write the one additional validation constraint. 👍
User interface changes
None.
Issue fork experience_builder-3479643
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
wim leersComment #3
wim leersComment #4
wim leersComment #5
wim leersComment #6
wim leersComment #7
wim leersDiscussed with @longwave, we agreed that this would make sense for him to tackle after #3478537: Introduce an XB `PageTemplate` config entity lands, because it adds the validation constraint that will make this trivial to implement.
Comment #8
wim leers#3478537: Introduce an XB `PageTemplate` config entity is in.
#3479982: HTTP API to read+write PageTemplate and Pattern config entities is also already green, and is written in a sufficiently generic way that this should also just work!
This is actionable now. There's plenty of examples/blueprints to follow from #3478537.
Unassigning @longwave, who is on vacation right now :)
Comment #9
wim leers#3479982: HTTP API to read+write PageTemplate and Pattern config entities is in!
This should also expand the test coverage that #3479982 introduced for: this MR should add a
testPattern()method as a sibling toXbConfigEntityHttpApiTest::testPageTemplate().Comment #10
be-a-helperI know this isn't MVP, but will it be possible to validate above the component tree level?
I've repeatedly seen content management tools fail to recognize that both content and context validation are real needs, and if you're validating the meta relationships between components it makes sense to be able to query the component models as well.
Some example criteria a marketing approver might use:
1. A page can display more than one location component, but not if they have the same entity reference.
2. A page may have a carousel or a left column, but not both
3. A page must reference the title at least 4 times for SEO
4. All metadata keywords must be present in page content
Comment #11
lauriii@be-a-helper This seems outside the scope of this issue. Could you file a new issue for that question?
Few interesting edge cases that came up in the design process:
I'm wondering if this has implications on the data model?
Comment #12
wim leers#10:
Yes. See #3481720: Tighten validation: only allow StaticPropSource in XB fields + PageTemplate, DynamicPropSource in ContentTypeTemplate for an example of the precision of validation that is already present :)
It'd be trivial to add more validation constraints — either for the XB module itself or for contrib/custom modules.
The 4 examples you cite would all be possible to implement. But the real challenge will be in which level to apply such validation constraints to: individual content entities (so at the XB field type level:
\Drupal\experience_builder\Plugin\Field\FieldType\ComponentTreeItem) or at the content entity type bundle level (not yet implemented, stretch goal for0.2.0— see #3455753: Milestone 0.2.0: Early preview, requirement 9, which is a stretch goal.Agreed with @lauriii in #11 that #10 is out of scope for this issue. A new issue for your described use cases would be very much appreciated, but should be postponed on #3455629: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model.
Comment #15
wim leersNice to see this getting started, @f.mazeikis — did a very high-level initial review pass 🤓
Comment #16
wim leers🏓 Reviewed again.
This time in slightly more detail.
Now that #3475584: Add support for Blocks as Components is in, we can properly push this forward 👍
Comment #17
wim leersFYI, the validation pieces I mentioned above are blocked on #3485917: `ComponentTreeMeetRequirements` constraint validator must be updated now that Blocks-as-Components are supported + make PageTemplate render main content!. 😅
Comment #18
wim leers#3485917: `ComponentTreeMeetRequirements` constraint validator must be updated now that Blocks-as-Components are supported + make PageTemplate render main content! is in! This is now properly unblocked 👍
Comment #19
wim leersDown to 2 non-commit blocking nits that would be nice to see resolved prior to merging, but I've already approved the MR — thanks @f.mazeikis! 😊
Comment #20
wim leersComment #21
wim leersWow, in order to achieve the thoroughness of test coverage, to gain the necessary confidence that XB's config entities do indeed meet the
14. Configuration Managementproduct requirement, I had to add a bit of infrastructure that Drupal core seems to be wholly missing 🤯 https://git.drupalcode.org/project/experience_builder/-/merge_requests/3...This was pointed out 8.5 years ago and still has not been resolved: #2724835: Improve ConfigDependencyManager::getDependentEntities() documentation.
Comment #23
wim leersSee you in #3486203: Integrate saving sections with the backend: (de)normalize Pattern config entities using the client-side data model next, where the client will be updated to actually use this! 😊
Comment #25
wim leersWe forgot to update
docs/config-management.mdin the already merged MR 🙈Docs MR ready to be reviewed by @f.mazeikis.
Comment #27
wim leersFeel free to merge yourself next time! 😄