This brief aims to outline an idea I had for TYPO3: an API for registering various content types that can then be used by editors. Currently we have a multitude of different ways such content types can be achieved, even with sub-types for plugins and sub-sub-types in the form of Extbase-based plugins.
It would make sense to have a common API for all this.
We should declare a convention for a new file, Configuration/ContentTypes.php
which can be placed in extensions and will
return an array (or collection object?) of content types provided by said extension.
Example:
<?php
defined('TYPO3_MODE') or die('Access denied');
return [
new StandardContentType('mytype', ...),
new ExtbasePlugin('myplugin', ...),
];
The idea being that we create (by default immutable) objects that define all the settings a certain type of content requires
to drive it - e.g. ExtbasePlugin
would require additional "allowed actions" and "uncached actions" parameters in addition
to those required by any content type.
The returned objects can then be iterated and persisted. As a first-level compatible solution this iteration and registration could be done simply by extracting the required parameters and calling whichever API we currently have, to make the actual registration of title, icon, fields to show, allowed actions and whatnot.
I would then personally also add a capability for content types that will not be written to caches in any way, e.g. by
a second configuration file UncachedContentTypes.php
- for "content types from runtime-configured extensions", but in a
way that also standard extensions can utilise it.
If we switch to this API that returns a set of objects with a strict interface, it becomes possible to make abstractions on
top of this to read content types from basically any type of source. Using Flux as an example, Flux would simply create one
or more new types of ContentTypeDefinition
interface implementations that extract the required metadata from sources like
it does currently.
It also means that we can fully validate things like Extbase plugin registrations even before they are registered and as a full unit before any part of the configuration is written to caches.
At the time of writing this, we might have:
StandardContentType
which receives the attributes you normally have to register as select option forCType
etc. and allows you some way to define TCA'sshowitem
. This would be the preferred thing to use by third parties.StandardPlugin
which is a basiclist_type
implementation that registers through our legacy plugin API.ExtbasePlugin
which extends the standard plugin and adds the controller action, vendor identity etc.
Then in addition we may want to provide new types:
FluidTemplateContent
which is likeStandardContentType
but results in aFLUIDTEMPLATE
TS object and has options for things like template file reference and default variables. Possibly later extended with a PHP-based API to register but not execute DataProcessors (in the longer term solidifying the current DataProcessor's API with proper declarations of all accepted options.
This strategy can equally well be applied to things like:
- Extension configuration currently stored in
ext_conf_template.txt
can be given a true PHP API and loaded from such a configuration file. - Equally,
ext_typoscript_setup.txt
could be handled via such a configuration file and instead of returning a TS string, might instead return an array which is then possible to modify based on things like extension settings. - Extension updates. It would be almost a no-brainer to drop the
ext_update.php
pattern in favor of letting extensions return collections of proper PHP object instances each reflecting a certain update (and then let's extend that API to make it more useful than the very manual ext update procedures we have now). - Page types (
doktype
) as PHP API for creatingPAGE
-level TS setup, with integration fortypeNum
so it becomes much easier to define things like JSON-exchanging endpoints. Perhaps even load such separately as anEndpoints.php
file? - Services. Instead of registering authentication etc. services in our
ext_localconf.php
files, we could return proper PHP instances from aServices.php
file. - If/when we some lucky day finally get a strict API for all configuration in TYPO3 - extensions to such configuration.
- In the end, basically anything we currently have to do in
ext_localconf.php
files.
For your consideration.
Small addition: thinking more about the Fluid integration aspects, which also makes sense if we apply it to pages, we could instead create a solution that:
FluidRenderingDefinitionInterface
which can return things like template file reference, default paths, default extensioncontext, special namespaces, etc. so we encapsulate all Fluid-specific instructions there.
FluidRenderedInterface
which can be adopted byContentTypeDefinitionInterface
implements.getRenderingDefinition(): FluidRenderingDefinitionInterface
End result being that any arbitrary type definition can signal that it is rendered by Fluid and can return the metadata that would be
used to render that Fluid (be that as TS
FLUIDTEMPLATE
object or in custom ways, thinking again of Flux). This would make it veryeasy to configure new types of content that render basic Fluid templates without ever having to deal with the TS or TCA aspects.
Lastly: there's also the consideration that having a strict PHP API means we can automatically document every type and every option ;)