Content Block as Site Set

[nhovratov]

A Content Block and a Site Set are not so different concepts. Both have a central YAML definition config.yaml with a name property and load things automatically (TypoScript for example). The only difference is, Site Sets are scoped to a Site, whereas Content Blocks loads its stuff globally.

To bring these two concepts together, a Content Block could simultanously also be a Site Set. The name is already there and follows the same pattern vendor/name. Now, Content Blocks could automatically register these paths to the SiteCollector and they would already be a valid entry for dependencies in the site configuration or other Site Sets.

What would be the benefits of this? As soon as a Content Block is attached to a Site, we can create scoped Content Elements. Meaning you can have two or more Sites with individually selected Content Blocks. This feature would be optional. So if you don't define any Content Blocks for a Site, all Content Blocks are available as usual.

Free Features: In addition to scoped Content Elements, we get free TypoScript and PageTsConfig providers! As a Content Block is now also a Site Set, you can simply place a setup.typoscript and a page.tsconfig file respectively and they will be loaded automatically for the Site.

Steps to implement:

• Extend / Configure SiteCollector to also collect Content Blocks paths
• If a Site has at least one Content Block (Set), all other CBs must be hidden (NewContentElementWizard, Record Type Selector in FormEngine, New Record View)
• Document new possibilities to autoload TypoScript / Page Ts Config when used as Site Set

More Ideas:

• Provide a virtual Site Set to include all Content Blocks within an extension (Something like extensionname/content-blocks-all
• Allow to have settings definitions to configure Content Elements (maybe later, if this is a good idea).