The Structured Content Initiative is working on a concept to simplify the registration process for Content Blocks (Content Elements) where Content Blocks are delivered as composer packages. Currently we defined that one composer package equals one Content Block, but we’ve been asked how we would enable to create bundles. There are two options:
Having multiple Content Blocks in one composer package.
Creating a distribution of Content Block packages (e.g. like TYPO3 minimal distribution) or within a bundling extension.
What to you think? Which would be a better solution?
This is actually impossible to answer right, because the suggested technologies are made for completely different purposes.
PHP composer is made for PHP code libraries. I really don’t see content blocks/elements as code libraries.
I would go as far as: Why spam packagist with hundreds of useless content block extensions?
Reality for our projects is: We rarely re-use content elements in a different project. Requirements are always different per project and we always build them according to what is needed, not more, not less.
The whole idea of sharable CEs goes into the direction of theming, where a design foundation is provided as a whole. This includes CEs then. So if you share CEs (themes) at all, put things that belong together into a single extension and simply use the mechanisms to disable those one does not need.
Having composer handling the dependencies doesn’t mean we need to spam packagist.
As you wrote some rarely re-use content elements. We as well build them for each customer, as they all have different requirements. We therefore would not even think about publishing them to packagist.
Depending on the concrete content of the packages, it still would be PHP code. Composer is not only used for libraries, but also for projects and other things. I find it okay to use composer for content elements. There is no big difference between them and TYPO3 extensions, at least not for me.
I would prefer 2, as this is how it should be. Each package should do one thing. You might end up with some content elements sharing the same source (e.g. Data Processors), that would be a reason to also opt in for 1. Still I would prefer 2. One would either need to setup dependencies between elements, or just make the processor generic and move it out of the dedicated content element packages.
Clear, this is not a technical problem. But technical systems are there to solve non-tech problems too.
So, yes, I am not sure if composer is the right distribution system for this kind of things.
Usually you would use local “path” composer repositories in your projects so there is no need to publish them. It’s just a way to modularize your project.
A package manager facilitates management and discovery (package type).
If you can reuse blocks within your organisation, that’s a bonus. And even publicly sharing is easy when blocks are packagable.
That could be done with any other package manager as well, yet in the TYPO3 universe composer is ubiquitous so let’s just use it.
Regarding bundling:
I think it would be nice and I see the desire for it. Having such numerous small packages might not be for everyone.
Yet technically it might complicate some things a bit and might remove some of the clarity which it would have if we would just not allow it.
My opinion: I think that bundling should use the package manager-mechanism: Either a meta-package or an extension requiring content blocks. Or a contentBlock requiring an extension for its e.g. DataProcessors, …
I wouldn’t like extensions to fiddle with “managing” contentBlocks at all.
Content elements don’t diverge that much from an editor’s perspective as they do regarding their display. So maybe we should strive for more semantic and less diverse data structures while making it as easy as possible to create multiple templates for the same data structures.
I don’t see that a special bundling layer for CEs is needed. CE datastructures could be registered via tagged services, matching templates should be collected from defined directories.
A headless approach could help structuring things, even when you don’t plan to create a headless page.
Will content-blocks be treated like content-elements, in the way that we can adjust the permissions of which BE user/usergroup can see/use which block? If so, than I’d prefer the bundling of blocks in one package.
The reason is, that as agency we’ve created an extension/package of custom elements/blocks anyway, which can be used in multiple projects (e.g. can be seen as a “agency base template extension with common features and CE’s where each customer extension is build on top of”). Through editor permissions the needed elements/blocks will be activated for each project.
Like the other feedback above, I don’t see a reason why each block should be available as stand-alone package: 1) common used blocks could be bundled in an own extension described above, and 2) they might be too specific to share across projects anyway.
The base TYPO3 installation could ship with a bundle of standard blocks, like with the standard elements right now.
Edit: After re-read the above, I support the point of Jonas Eberle “reuse blocks within your organisation” and the meta-package idea. Personally I just don’t want to see millions of single block-packages wasting packagist or the TER (see point related to slider extensions above).
Many thanks to all contributors on this topic. The Structured Content Initiative has evaluated your comments and closes this topic as follows:
Content Blocks can be bundled by creating a distribution of Content Block packages (e.g. like TYPO3 minimal distribution) or within a bundling extension.
