Parser issue with nested elements

[christianseel]

Summary

There seems to be a bug in the MODX parser with a special nested MODX tag structure. Issue exists if you have nested chunk calls where the chunk name contains another placeholder like [[$chunk-[[*context_key]]]].

Step to reproduce

• create a chunk called chunk-1 and paste the following content:

<div class="wrapper">
    <span>Level: [[+level:default=`not set`]]</span>
    [[+nestedcontent]]
</div>

• edit the resource with the ID 1 (can be any other resource but then update the name of the chunk with the resource ID)
• fill the following code into the content field:

[[$chunk-[[*id]]?
        &level=`1`
        &nestedcontent=`
            [[$chunk-[[*id]]?
                &level=`2`
                &nestedcontent=`
                    [[$chunk-[[*id]]?
                        &level=`3`
                        &nestedcontent=`
                            this is level 3. and here it breaks!
                        `
                    ]]
                `
            ]]
        `
    ]]

Observed behavior

MODX parser breaks at the 3rd level and returns wired output with broken placeholder/tags like

<div class="wrapper">
<span>Level: 1</span>
`
            [[$chunk-1?
                &level=`2`
                &nestedcontent=`
                    [[$chunk-1
</div>

</div>

If you remove the most inner chunk call (3rd level) and just leave the other 2 levels it works as expected.

Also if you replace the [[*id]] placeholder in the chunk name with 1 it works as expected.

Expected behavior

Correct output with 3 <div class="wrapper"> and a text this is level 3. and here it breaks! in the inner div.

Environment

Tested with MODX 2.5.0-pl and 2.4.2-pl. Also PHP 5.6 and 7.0. Both Apache. No special templates, no ContentBlocks…

[OptimusCrime]

Do you have pdoTools installed?

[christianseel]

Hey, nope. But I might be close to the issue in the source codes. Looks like it's related to $depth for processElementTags(). Seems like it's using the default value 0 for chunks instead of the system setting or default value of 10 which is used at most other function calls.

This line seems guilty: https://github.com/modxcms/revolution/blob/2.5.x/core/model/modx/modparser.class.php#L431

…investigating :)

[christianseel]

Changing https://github.com/modxcms/revolution/blob/2.5.x/core/model/modx/modparser.class.php#L431 to something like

$maxIterations= intval($this->modx->getOption('parser_max_iterations',null,10));
$this->processElementTags($outerTag, $innerTag, $processUncacheable, $this->modx->parser->isRemovingUnprocessed(), "[[", "]]", array (), $maxIterations);

fixes my issues. Any reason why this is currently called with a $depth/ $maxIterations value of 0

[OptimusCrime]

No idea. Do you want to submit a pull request for this? It will make testing easier for the MODX team.

[christianseel]

Yeah sure, was hoping to get feedback on slack but seems like nobody got time right now :D I'll prepare a PR in a second…

[OptimusCrime]

Sweet. I was going to offer trying to do it the next couple of days if I had the time, but if you can do it that is much better.

[OptimusCrime]

@modxbot open

I think we'll keep this open until the issue has been resolved, @christianseel :)

[christianseel]

Well, for me it's resolved. So I'll move the discussion into the PR for the proposed solution… But if you care leave it open 👍

[opengeek]

This is merged into 2.5.x for inclusion in the 2.5.6 release.

[pixelchutes]

Re-opening since merged PR was reverted.

[sdrenth]

About the PR: https://github.com/modxcms/revolution/pull/13044

Is the PR above being added into 2.6.0 since this issue has been marked for this milestone or is it going to be added for 3.0 for reasons mentioned in the PR?

[OptimusCrime]

I think it can be merged into 2.x as this is a bugfix?

Edit: See the last two comments made on the PR.

[Ibochkarev]

The problem is urgent

MODX Revolution 3.0.0-alpha3 (git), PHP Version 7.4.12

https://user-images.githubusercontent.com/2138260/110427415-ea28e180-80d1-11eb-91f9-8246282ad0a3.mov