Consider refactoring page_template into page_region(s)

I think the initial idea for a single page_template was when we envisioned it as replacing page.html.twig entirely. Meaning, you wouldn't have the concept of theme-determined regions within XB, just a single canvas that you can lay out however you want. But since the UX evolved into being based around theme-determined regions, I think that's a fairly strong argument in favor of refactoring the config entity to match.

Does it worsen DX of config deployments (e.g., doing a manual code review across per-region YAML files vs within a single YAML file)?

My gut feeling is that this isn't significantly worsened at least in the case of a single page template. The impact would be more in the case of multiple page templates. It seems like a trade-off that could be accepted.

Or on the other hand, would it add useful capabilities like creating variants for some regions while leaving other regions shared across page variants?

This could actually be a benefit because for example the header and footer might remain the same on every page template but the content top might need to change for some pages.

I'm wondering if based on this there should be a page template config which can specify a parent page template and is allowed to depend on specific region configurations that would override the parent?

🤯 I didn't see this coming for sure. #2 is accurate — that's how @lauriii always described it.

I definitely agree with the cons, especially the variants one. Although @lauriii makes a strong observation in #3.

I'll think about this some more. I urgently need to review some things, leaving not enough time to think through all consequences.

AFAICT this would make 📌 [PP-2] Don't store page template model data in auto-save for an entity Postponed obsolete too, and hence we could add it to the "avoid" list?

I don't think this makes 📌 [PP-2] Don't store page template model data in auto-save for an entity Postponed irrelevant, we still store the entire model against all autosaved entities - the aim of that issue is only store the parts of the model that are relevant to each entity.

You're right, I misread & misunderstood!

Remember: the future GlobalPageTemplate config entity 👻

📌 Introduce an XB `PageTemplate` config entity Active introduced the PageTemplate config entity (config schema type: type: experience_builder.page_template.*:). It comes with this comment:

# Otherwise, an Experience Builder Page Template can be created per installed theme, and stores component trees for each
# region in a theme's `page.html.twig`.

That "otherwise" refers to the preceding config schema type: a placeholder for a future piece of functionality that is very closely related: the global page template config entity.

That looks like so:

# At most a single entity of this type is allowed to exist. If it exists, it *replaces* the theme's `page.html.twig`.
experience_builder.global_page_template.*:
  type: config_entity
  constraints:
    FullyValidatable: ~
  mapping:
    # A single component tree.
    component_tree:
      # @todo This MUST contain a single XB Component that points to the title block, main content block and messages block
      # @see \Drupal\Core\Block\MainContentBlockPluginInterface
      # @see \Drupal\Core\Block\TitleBlockPluginInterface
      # @see \Drupal\Core\Block\MessagesBlockPluginInterface
      # @todo Blocked on Blocks-as-XB-Components: https://www.drupal.org/project/experience_builder/issues/3475584
      type: experience_builder.component_tree
      label: 'The component tree that represents the default page'

How would you imagine that to work in the new world proposed by this issue? 🤔 AFAICT, that'd remain unchanged, because it completely ignores the "default/active theme"'s regions.

(Sadly, I can't find any "global page template" details: it's based on discussing this with @laurii IIRC, and is about the "global template" vs the "page template" as captured by https://docs.google.com/spreadsheets/d/1OpETAzprh6DWjpTsZG55LWgldWV_D8jNe9AM73jNaZo/edit?gid=1721130122#gid=1721130122&range=I29">requirements 18 vs 19.)

+1 if we're on the same page

If y'all agree that splitting PageTemplate into N PageRegion config entities does still leave the GlobalPageTemplate config entity unchanged … then I'm +1 to this proposal, and I do think that it'll make things simpler 😊

Bonus! 🚀

In fact, a nice consequence will be that if you try to uninstall a module that provides some SDC or Block, you'd get a more precise overview in the "oops, can't do that, because these config entities depend on it" UI: it'd tell you exactly which regions it's being used in, and in the future even which variants! 🥳

To add to #7: that'd also mean that the content region would either:

• never get a PageRegion content entity, because that region is hardcoded (in code) to contain the "main content" block
• always get it, but we'd never expose it and it'd be a de facto hardcoded config entity

Related: 🐛 Hide main page content block from XB Active

Given @lauriii specifically opened #3502372, requesting him to approve #7 + #8.

+1 to doing what the issue title says: changing 1 PageTemplate config entity per theme into N PageRegion config entities per theme.

I'm confused about what concept GlobalPageTemplate represents. If it's meant to be an override of page.html.twig, I think it should be renamed to PageTemplate (which can be a followup once this issue makes that name available). We'd need to come up with a UI (possibly after 1.0) for how to create/edit this entity. But within this UI, we could make a Region component available. Then this would be an exact replacement for page.html.twig (as well as the regions section of THEME.info.yml). I.e., someone could use this to build a new theme from scratch, including using only the XB UI to create, name, and place regions.