I’m experiencing problem on several sites after updating to MODX 3. There are codes visible on pages like:
[[If? &subject=`0` &operator=`!empty` &then=`
[[!getResources? &parents=`9` &tpl=`sidebarTpl`
[[!mgGetImages:notempty=`
Strange thing is, on other pages with the same template and codes there are no problems. Anyone seen this before?
Is this MODX 3.0.3?
If so, apply these pull requests and check if that helps.
modxcms:3.x
← Mark-H:issue-16263
opened 01:02AM - 02 Dec 22 UTC
### What does it do?
Improves the regex pattern used in modParser::collectEle… mentTags() to avoid hitting a backtrack limit under some environments (PHP 7.2, 7.3). Also adds a log message in case an error is detected.
Credit to @JoshuaLuckers for providing the patch.
### Why is it needed?
Make sure long tags can be parsed correctly and make debugging easier if something does fail. Please see #16263 for more details.
### How to test
Please see #16263 for more details. It's worth noting I've so far seen 3 people refer to the fix in the issue as fixing the issue they had. As with all parser tweaks, trying it out on different real sites would be preferred to ensure this doesn't introduce any new issues.
[Here's a CI run of the unit test prior to applying the fix](https://github.com/Mark-H/revolution/actions/runs/3597851277/jobs/6060109440), to show the unit test and fix work.
Locally I've also been able to reproduce it by running the test on 7.2 before:
```
➜ 3.x git:(issue-16263) ✗ php core/vendor/bin/phpunit _build/test/Tests/Model/modParserTest.php
PHPUnit 8.5.31 by Sebastian Bergmann and contributors.
..........................................................[1] 78526 segmentation fault /Applications/MAMP/bin/php/php7.2.34/bin/php -c core/vendor/bin/phpunit
```
and after applying the fix:
```
➜ 3.x git:(issue-16263) ✗ php core/vendor/bin/phpunit _build/test/Tests/Model/modParserTest.php
PHPUnit 8.5.31 by Sebastian Bergmann and contributors.
........................................................... 59 / 59 (100%)
Time: 181 ms, Memory: 14.00 MB
OK (59 tests, 70 assertions)
```
(I'm doing `php core/vendor/bin/phpunit` because otherwise php can't get to mysql on my local machine.)
### Related issue(s)/PR(s)
Fixes #16263
modxcms:3.x
← Mark-H:302-fix-brackets
opened 01:51PM - 17 Nov 22 UTC
### What does it do?
Fix where literal brackets (not intended as an opening/clo… sing tag) go in the parsed command modifiers.
### Why is it needed?
John MacDonald reported the parser breaking in the following scenario:
```
[[++google_analytics:notempty=`
<script async src="https://www.googletagmanager.com/gtag/js?id=[[++google_analytics]]"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', '[[++google_analytics]]');
</script>
`]]
```
Rather than outputting the script, it returned just the value of `[[++google_analytics]]`.
That test case was simplified to ```[[+tag:notempty=`[]`]]``` as the literal brackets appeared to be the problem.
Internally, the command ended up as `notempty[]` with an empty modifier. The `notempty[]` command doesn't exist so the original value is returned in its place.
By using the `$inModifier` flag (which gets set in the switch case for ``` ` ``` when depth is 0) the brackets are parsed into the modifiers as they should.
### How to test
See tests for examples. Feel free to come up with more complex cases.
### Related issue(s)/PR(s)
Reported via Slack.
Introduced with #16288 in 3.0.2.
I think it’s been there a few versions. I’m not familiar with Github: what is the solution?
In the pull requests I linked above, go to the tab “Files changed”. Ignore the file with the tests (modParserTest.php), but download the other file and replace the existing file on your server with this new file. Make sure you do this in MODX 3.0.3.
Okay, I tried to edit the PHP files in MODX, it gives me an error:
file extension ‘PHP’ not allowed
You have to add php
to the list of “Uploadable File Types” in the system setting upload_files
if you want to be able to edit PHP files in the manager.
But don’t do this. Use FTP to upload the new files.
(And save the old files, in case something goes wrong. So that you can restore the previous state.)
Done, and the codes are gone from the pages now. Yes, I made backups .
Btw, why are these files not included in 3.0.3 update?
These pull requests were only merged, when 3.0.3 was already released.
But they should be included in the next version.
Ah, I see. At my sites these problems were around since late 2022.
It took us some time to find solutions for these issues. We also made sure to add various use cases to our testing suite to prevent it from breaking in the future.