TYPO3 Neos Technical Discussion September 3rd & 17th

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: <link https: gist.github.com mneuhaus>gist.github.com/mneuhaus/6389661Possible 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

Conclusion: 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. Conclusion: 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 <link http: forge.typo3.org issues>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. Conclusion:

• 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 <link http: forge.typo3.org issues link for>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?

Conclusion: Having the version in the composer manifest is <link http: getcomposer.org doc>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?

Conclusion: 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? Conclusion: We should switch that setting to use keys (instead of numeric ones) so you have a chance to override single items.