TYPO3 Neos Technical Discussion September 3rd & 17th

September 17, 2013

Category: CommunityDevelopment
Author: Bastian Waidelich, Berit Hlubek

In September two technical discussion meetings took place to talk about possible solutions for different Neos development related topics.

What is TYPO3 Neos and what are those meetings about?

TYPO3 Neos is the next-generation open source content management system of the TYPO3 community. Neos is based on the PHP framework TYPO3 Flow and its editing interface lets you focus on your task for a revolutionary editing experience.

The development is currently focused on creating the 1.0 release for which the goal is to create a stable basis which won't introduce breaking changes in the next releases after version 1.0. Therefor regular technical discussion meetings were established to find good and stable solutions for upcoming problems and questions.

Make large Exception Messages more readable

Initiator: Marc Neuhaus

Currently it's difficult to read some Exceptions, because they don't allow any HTML markup or new lines. They sometimes seem like multiple lines of gibberish.

Possible discussions:

  • should we use nl2br to allow newlines in exception messages
  • should we allow (HTML) markup in exception messages


We won't render HTML for security reasons. Support for a custom markup (such as Markdown or reStructuredText) would be an alternative (and useful for example to output the affected Fluid code). For now we will tweak the exception rendering by using nl2br() to allow line breaks and  change to non-bold rendering for the message for a better readable text. Bastian will push a changeset for this topic.

Current TYPO3 Neos Exceptions
Optimized TYPO3 Neos Exceptions
Current TYPO3 Neos Exceptions
Current TYPO3 Neos Exceptions
Optimized TYPO3 Neos Exceptions
Optimized TYPO3 Neos Exceptions

Numerical Views.yaml produce broken merged ViewsConfiguration

Initiator: Marc Neuhaus

When you use non-named ViewConfigurations with multiple packages you can end up with broken configurations because the view configurations get merged by numerical index. Example: https://gist.github.com/mneuhaus/6389661

Possible discussions:

  • should we update the documentation to advice the user to only use named view configurations
  • or should we update/change the ViewConfigurationManager to append instead of override the toplevel index


The nice solution would be a refactoring of the current ConfigurationManager, so that it only knows two processing types: One that merges all configurations recursively (e.g. for Settings.yaml) and one that appends all configurations (e.g. for Routes.yaml). Then the special handling that is currently done in the ConfigurationManager should be extracted to some configurable ConfigurationPostProcessor.

As this would mean quite some work we will add a new CONFIGURATION_PROCESSING_TYPE_* constant for now that does not merge the configuration recursively but appends everything in the correct order (according to package dependencies).

The *Views* configuration type will then be registered with that new processing type in Flow\Package.php:

$configurationManager->registerConfigurationType('Views', ConfigurationManager::CONFIGURATION_PROCESSING_TYPE_<to_be_named>);

Marc will push a changeset.

Accessing plugin arguments outside plugins

Initiator: Aske Ertmann

One of the topics being mentioned in the mailing list / irc channel repeatedly is using the properties from a plugin to change the page title e.g. Currently this is not very easily achieved since all the logic about the plugin arguments resides in the PluginImplementation and for changing things outside the plugin this routing logic needs to be available elsewhere, e.g. for accessing a plugin argument's title.


We discussed how to solve this and unfortunately no one had a good solution to this problem, which means it is something we will need to look further into to solve properly. Marc Neuhaus offered to try to look into this as part of his work package where he still has some time left.

So unfortunately we do not have a good solution to this problem currently, but it is definitely something we will need for Neos 1.0 to ensure it is possible to create good plugin solutions for Neos. We will report back when we have come up with a good solution.

Default node types

Initiator: Robert Lemke

There has been some confusion among implementors if a certain type came from TYPO3.Neos or TYPO3.Neos.NodeTypes.


  • TYPO3.Neos should work without TYPO3.Neos.NodeTypes
  • All node types which TYPO3.Neos depends on (i.e. which are hardcoded in the source code somewhere) should be in TYPO3.Neos, all others in TYPO3.Neos.NodeTypes.
  • All node types in TYPO3.Neos should be either abstract (meant to be extended) or final (not allowed to be extended). This means the average user does not have to deal with these node types.

As a result, this means the following node-type-changes:

  • Page is migrated from TYPO3.Neos to TYPO3.Neos.NodeTypes
  • Plugin is marked abstract, but stays in Neos
  • Shortcut is moved to Neos.NodeTypes
  • ContentCollection is marked final

Re-add versions to packages

Initiator: Bastian Waidelich

We recently removed the version tag from the composer manifests of all packages in order to avoid complications with packagist. Therefore Package::getPackageMetaData()::getVersion() returns NULL even though it is used multiple times in the code.

Possible discussions:

  • Is it important to be able to retrieve the version of a package (even though it might not be part of a (git) repository)?
  • What are the issues with packagist? Can we circumvent these (it seems to work with the doctrine packages)?
  • What other possibilities do we have to store the version of a package?
  • If we agree to re-add the version, can we automate this process in order not to end up with wrong versions?


Having the version in the composer manifest is discouraged by composer. Also it makes the build process more complex unless the version is created automatically (e.g. with a post-commit-hook). Karsten will contact the “doctrine guys” to find out how they used version meta data & composer and why they apparently removed it recently. Julle will find out if/how it is possible to use composer (w/o CLI requests) to fetch the version of a package.

Page template/layout selection

Initiator: Aske Ertmann

Following a brief discussion about template/layout selection during the node structure meeting, it would be good to decide how we want to tackle this issue in Neos.

Possible discussions:

  • Should we provide default functionality in TYPO3.Neos or have a proof-of-concept in the demo package?
  • Should we use configuration in Settings.yaml, node type configuration or meta data from the file system for configuration of templates/layouts?
  • Should we provide a custom editor for the selection of image enriched values?
  • How much of this is necessary for Neos 1.0?


We concluded to continue with the current direction and implement a proof-of-concept. The implementation should go into TYPO3.Neos, but it should be possible to exclude this feature if not needed. The definition of available layouts should be defined by setting them in the TYPO3.Neos:Page node type configuration. The actual rendering should then use TypoScript to change the template or use a specific TypoScript object, this would be up to the implementor. We will need a slide operator to be able to get the nearest set parent value. The enriched editor is not necessary for the first part and should be a more generic selector editor with image thumbnails. A basic implementation should go into Neos 1.0.

Node Type Groups

Initiator: Robert Lemke

Currently “Node Type Groups” for the UI are defined in Settings.yaml but that way there is no way to add groups via a package. Any other solution?


We should switch that setting to use keys (instead of numeric ones) so you have a chance to override single items.


The next technical discussion meeting is scheduled for October 1st, 3pm CET at bit.ly/FlowHangout


Add comment

Please log in or sign up to comment.