Parser issue with nested elements

christianseel commented 8 years ago

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 commented 8 years ago

Do you have pdoTools installed?

christianseel commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

christianseel commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@modxbot open

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

christianseel commented 8 years ago

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 commented 7 years ago

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

pixelchutes commented 7 years ago

Re-opening since merged PR was reverted.

sdrenth commented 7 years ago

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 commented 7 years ago

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 commented 3 years ago

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

modxcms / revolution