Fluid does not detect all xmlns namespaces
<div xmlns:f="..." xmlns:x="..."> <div xmlns:r="..">asdf</div> </div>
In the example above only the f and x namespaces are recognized, but r is missing.
The reason is the usage of a wrong variable in \TYPO3\CMS\Fluid\Core\Parser\PreProcessor\XmlnsNamespaceTemplatePreProcessor such that only the first found tag with a namespace definition is searched.
This HTML used to work in CMS 7 and I'm not aware of an according breaking change documentation.
Updated by Claus Due about 5 years ago
I wish this was quick to explain, but it isn't. There are plenty reasons why now, we only support a single "place" to register namespaces for each template file.
Where to begin...
Let me compare previous logic to current one:
- Before, namespaces were held in the parser and every method to manipulate them was fluid-core-only. That's very different now; namespaces are decoupled from the parser and are now managed by the ViewHelperResolver.
- Before, namespaces could be added and removed by the parser at will, since only a single namespace with any identifier was supported. That's also very different now: when you register a namespace twice you don't replace the old one - you extend that namespace to look in additional class namespaces.
- Namespace extraction from xmlns is now done as a pre-processing step, no longer part of the parser as such. It would not be possible to extract our namespaces this way and still be able to tell the parser when to apply our extracted namespaces (which node? When to remove it again and how?)
Combine those and it gives us a situation where, if the templateparser was to perform such manipulations, we would have to remove said namespace again afterwards because it would have to expire once the enclosing xmlns-carrying tag is closed. That puts quite a bit of complex requirements on the way namespaces are stored - adding a namespace that's already registered and then removing that again would have bad side effects so we would have to somehow track much more about the namespace add/remove process.
We're further challenged by the extraction now sitting in the pre-processing step that's fired only once. Our extractions would have to require new, currently non-existing logic in the templateparser to support modifying namespaces at certain points based on nodes... I really would not go in that direction as the parsing step is already quite complex.
The best compromise that does not cause confusion is the one I chose, I believe. It is the one that works with almost all current implementations and doesn't pollute namespaces unexpectedly by combining all extracted namespaces regardless where they sit in the template's node tree. But it is a compromise.
And that's why there's a unit test for it (coming back to the actual subject). It is an intentional behavior and as such, it has a test to ensure that behavior happens.
You are also right there's no breaking change described in the change log... that's my fault - I forgot about it while writing the breaking changes, and I know why: I was very focused on the ViewHelper API and not so much on use cases that had no implementations in the TYPO3 core. Sorry about that, if there's a way to update that so long after the fact, let me know!
But in regards to restoring the old behavior I would personally vote not to attempt that. Anything we do in that regard would inevitably require that fluid itself gets changed significantly, making the parsing and coupling with pre-processors/renderingcontext even more complex, and it honestly feels like far too much. The right answer is imho that this edge case is no longer supported - our pragma now is we encourage globally registered namespaces (via view/viewhelperresolver) and extending namespaces once per physical template file or source chunk that gets parsed.
Updated by Markus Klein about 5 years ago
- Complexity deleted (
- Is Regression changed from Yes to No
Thanks a lot for the detailed explanation.
I absolutely have no problem with the breaking change. We just have to document it. Better now than never.
Most people will read the breaking docs only after the final CMS 8 release anyway.
Can you please create a patch, which adds this information?
I propose to add it to the existing RST. Please set Mattes and me as reviewers, so we make sure that the wiki (etc.) is updated then as well.