Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Different results of template parser for arrays on different operating systems #449
I had issues with shorthand viewhelpers. The arguments I passed as an array where handled as a string at the end. I dug deeper into the issue and found the root cause in the regex
My viewhelper code:
which leads to the exeption:
I could reproduce this error just on a FreeBSD server and could find related bug reports.
The regex pattern fetches there for any reason
These values should be empty:
I'm not sure how to solve this issue in Fluid, but maybe the regex could become more strict or optimized to behave equal on all systems.
Oh boy, regular expressions come back to bite us again. Thanks for the very detailed reports and testing, @dlubitz - that's extremely appreciated!
We had a similar issue a while back with older PHP versions and now-outdated versions of linked preg libraries. If I recall (it's been many years) it was also a problem with the named patterns and recursion.
And more recently we discovered that preg has an internal limitation on the size of matches when doing recursive matches - which we cannot change. This one prevents you from declaring large arrays - at some point, Fluid starts seeing the array as a string due to the limit.
I believe the only good way to move forward is to abandon the use of regular expressions, at least for this complex recursive matching, in favor of some more naive (tokenisation-like) procedures that recursively split and tokenise Fluid templates then creates the syntax tree from those.
There is progress being made in this department but unfortunately it's very far from easy to do this right, without causing significant performance impacts. I'm at my 4th attempt using a mix of naive string searches and splits without requiring multiple stacks during parsing, plus making nodes in the syntax tree more interchangeable so they don't necessarily need to "know" what type of node they are until all tokens have been collected.
If you have some experience with similar things and would like to involve yourself you would be more than welcome!
I have two more failing environments.
The current ddev environment (that might make it easy to reproduce and work on this issue)
Debian GNU/Linux 9 (stretch)
One of our production environments
I could not reproduce the issue, but maybe my test setup was to simple. I used composer to get a TYPO3 installation and used the testcode posted by dlubitz above in the root of the webpage (after inserting
$classLoader = require DIR . '/../vendor/autoload.php';in front of it) to run the test from the command line on FreeBSD 11.2, php 7.3.8, pcre2 10.32_1. As output I get the "expected result". Could someone who has the problem try to reproduce it with this setup?
Well, after switching back to a slightly older environment, I CAN reproduce the problem with this small setup. Both environments have Freebsd 11.2-RELEASE-p9, but the failing environment has php 7.3.6 instead of 7.3.8 and pcre2 10.32 instead of 10.32_1. The difference between pcre2 10.32 and 10.32_1 appears to be that the former is linked against readline 7.0.5 while the latter is linked against readline 8.0.0. Maybe we can get the info about the used readline version for the other working and failing environments?
Can you check which version of readline your installation is using? Currently I suspect readline 7 to be the culprit, as the problem disappeared on FreeBSD after the pcre2 package switched to using readline 8.
Well, I have different versions installed but I guess that while I installed PHP via brew, it uses the version of readline that is installed via brew as well: