TYPO3 Core

Ehm... we even have a unittest to enforce that??

'Only handle first tag with xmlns ViewHelpers found'

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.

To clarify things: Just an RST is missing documenting the breaking change!

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50245

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50245

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50245