Output modifiers in modx 3 does not work like expected if (single) square brackets used in modifier strings.
Step to reproduce
Create a ressource named “strange” with following content:
<pre>
[[*pagetitle:is=`foo`:then=`bar[not baz]`:else=`baz[not bar]`]]
[[*pagetitle:is=`foo`:then=`baz`:else=`bar`]]
</pre>
Observed behavior (output)
strange
baz
Expected behavior (output)
baz[not bar]
bar
Environment
Apache/2.4.51 (Linux/SUSE)
PHP Version 7.4.33
mysql Ver 15.1 Distrib 10.6.10-MariaDB, for Linux (x86_64)
Issue is caused by core/src/Revolution/src/modInputFilter.php line 52 - 142. Without going deeper in code, i suspect, the new implemented charbased handling on filtered elements breaks something…
As a first workaround i changed (revert) lines to (from working modx 2.x):
if ($splitPos !== false && $splitPos > 0) {
$matches= array ();
$name= trim(substr($output, 0, $splitPos));
$modifiers= substr($output, $splitPos);
if (preg_match_all('~:([^:=]+)(?:=`(.*?)`[\r\n\s]*(?=:[^:=]+|$))?~s', $modifiers, $matches)) {
$command = $matches[1];
$commandModifiers = $matches[2];
}
}
if (!empty($command)) {
$this->_commands = $command;
$this->_modifiers = $commandModifiers;
}
Did anyone else experience this issue?
Regards, Stephan
There is an error in MODX 3.0.2 that affects single square brackets.
Apply this pull request (the file core/src/Revolution/Filters/modInputFilter.php
). It should fix the issue:
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.
1 Like
system
Closed
January 6, 2023, 2:46pm
3
This topic was automatically closed 2 days after discussion ended and a solution was marked. New replies are no longer allowed. You can open a new topic by clicking the link icon below the original post or solution and selecting “+ New Topic”.