Tags: janhelke/Fluid
Tags
[BUGFIX] Ensure correct `ViewHelperNode` in `ViewHelper` Fluid have been designed without DependencyInjection and therefore shared classes, for example ViewHelper, in mind. Using systems can implement custom ViewHelperResolvers to determine how ViewHelper are resolved and created, using custom configuration. For example, the TYPO3 CMS implements such a custom ViewHelperResolver providing the ability to instanciate them throug Symfony DI. This allows shared ViewHelper instances now and may become more likely, especial for custom ViewHelper using the `CompileWithRenderStatic` trait. ViewHelper and ViewHelperNodes are connected through cycling references. This has not been a problem until the execution code for `convert()` have been moved from ViewHelperNode to the AbstractViewHelper (TYPO3#787) to avoid creating unnessesary children codes, which may be duplicated and not needed. However, that enforced the code to work with the `ViewHelperNode` set in the `ViewHelper`. Using DI and shared `ViewHelper` now leads to the state, that the wrong `ViewHelperNode` instance is referenced in the shared `ViewHelper`. That compiled template code retrieving the wrong argument in some circumstances, for example in a for-loop when the viewhelper are additionaly used after the for-loop. Moving the `convert()` code from the node to the ViewHelper is valid, but `shared ViewHelper instances` are valid too. This change now updates the ViewHelperNode reference in the ViewHelper before dispatching to the ViewHelper. We do not have any evidence yet, but the same thing is done in the `ViewHelperNode->evaluate()` method. This is baked by a regression test. A cross check is added, but skipped for now as it makes the test green even without the fix. That points to another issue, test setup related or other, and have to be tackled in a dedicated change. The skipped test is added to the phpstan baseline. Used command(s): ```shell composer phpstan:generate-baseline ``` Resolves TYPO3#804 Related: TYPO3#787 TYPO3@1f1dc5a
[TASK] Support Neos/Flow class compiler With 2.7.3, we extracted all logic from bin/fluid to src/Tools/ConsoleRunner.php and src/Tools/console.php, where ConsoleRunner contains the worker class and console.php the autoload and instantiation logic as global code. This works, but one could argue it's ugly having code within a source directory that is supposed to contain classes only. More importantly, it turns out Neos/Flow can not deal with global code that just "runs" in a folder that expects to contain all code being encapsulated in classes only. The proxy mechanism of Neos/Flow stumbles: Undefined variable $argv in Packages/Libraries/typo3fluid/fluid/src/Tools/console.php line 22 The patch moves the global scope code back into bin/fluid. Additionally, the Heredoc in ConsoleRunner gets a minor update because the Neos/Flow class compiler interpretes 'name' of the phrase 'class name' as a class name which leads to another exception: The name of the class "name" is not the same as the filename which is "ConsoleRunner.php". Resolves: TYPO3#691
[TASK] Avoid utf8_decode() (TYPO3#621) utf8_decode() has been deprecated in PHP 8.2. It's used in one unit test which can easily switch to mb_convert_encoding() instead. This makes mbstring a require-dev dependency, which is added with this patch. > composer req --dev ext-mbstring
PreviousNext