Breaking: #73046 - Alias AbstractNode -> ViewHelperNode for backwards compatibility¶
See Issue #73046
ViewHelperInterface::compile() in standalone Fluid now requires an actual
ViewHelperNode instead of
AbstractNode as it was before.
The reason for changing this should be fairly obvious. In order to preserve signature compatibility an alias is put in place.
The alias is created so that
TYPO3\CMS\Fluid\Core\Parser\SyntaxTree\AbstractNode becomes an alias of
This is obviously less than ideal but solves the problem immediately and prioritises not breaking the public API by breaking the non-public API.
This signature change means that ViewHelpers which implement a custom
compile() method must update their signature (does not apply to ViewHelpers implementing
only renderStatic). Two ViewHelpers in TYPO3 CMS Fluid were migrated as part of the standalone Fluid
merge - but third-party ViewHelpers would require either migration or an alias.
- Overridden TemplateParsers (before standalone Fluid merge) might not work, depending on the nature of overrides (conditions checking class names may fail)
- Custom Nodes (implemented via an overridden TemplateParser, before standalone Fluid) would break either in function or form (incompatible constructor signatures on PHP7 at least)
Any TYPO3 site using an extension which replaces or directly interacts with TemplateParser or TemplateCompiler from Fluid. Only known affected community extension is at this point EXT:builder, specifically the template validation/analysis feature.
Change any reference to classes in