MODX 3: Generated "[[!…" (don’t cache) tags seem not to work anymore

halftrainedharry · April 21, 2022, 2:06pm

It tried to reproduce the issue with

[[[[*class_key:is=`MODX\Revolution\modDocument`:then=`!$someChunk`:else=`$otherChunk`]]]]

but the output is correct.

Is this tag nested inside other tags?
Do you have another way to reproduce the issue?

Moonbase · April 21, 2022, 2:19pm

If it helps, here is the code for the “reflect” filter snippet I used in the above:

<?php
// MCH 2022-04-21: Return short class name (remove namespace)
$reflect = new \ReflectionClass($input);
return $reflect->getShortName();

but I’ll experiment and try to come up with a simpler example. Thanks for helping!

At present, above code is used in the Example Blog’s “Blog Template” like so:

<!doctype html>
<html lang="de">
[[$head]]

<body>
    <div class="container">
        [[$header]]
        [[$header-navigation]]

        [[$jumbotron-[[*class_key:reflect]]]]
    </div>

    <main role="main" class="container">
        <div class="row">
            <div class="col-md-8 blog-main">

                [[[[*class_key:reflect:is=`CollectionContainer`:then=`!$blog_listing`:else=`$blog_article`]]]]

            </div><!-- /.blog-main -->

            [[$aside]]

        </div><!-- /.row -->

    </main><!-- /.container -->

    <footer class="container">
      <div class="row">
        <div class="col-md-12 blog-footer">
          <hr>
          [[$license]]
          <!-- <p><a href="javascript:self.scrollTo(0,0);">Zurück nach oben</a></p> -->
          <p><a href="[[~10]]">[[getResourceField? &id=`10`]]</a> · <a href="[[~11]]">[[getResourceField? &id=`11`]]</a></p>
          <a href="#" class="btn btn-top" onclick="topFunction(); return false;" id="topBtn" title="Nach oben"><i class="fas fa-angle-up" aria-hidden="true"></i></a>
        </div>
      </div>
    </footer>

    [[$scripts]]
    [[$json-ld]]
</body>

</html>

Moonbase · April 21, 2022, 2:47pm

Hmm, Askimet has hidden my post. Trying again.

I made two small chunks, to be sure:

some_chunk

<p>Some chunk!</p>

other_chunk

<p>Other chunk!</p>

and used:

[[*class_key:reflect]]
[[[[*class_key:reflect:is=`CollectionContainer`:then=`!$some_chunk`:else=`$other_chunk`]]]]

What I get on the web page:

Auswahl_181

Auswahl_180

halftrainedharry · April 21, 2022, 3:02pm

I still can’t reproduce this.

Do you have other extras installed that may overwrite the behaviour of the default MODX parser? Maybe pdoTools?

Moonbase · April 21, 2022, 3:04pm

You can also reproduce it by creating a template var some_tv with a default text of Some template var! and using the two chunks above:

[[*some_tv]]
[[[[*some_tv:is=`Some template var!`:then=`!$some_chunk`:else=`!$other_chunk`]]]]

it will never expand the chunks but just display the text.

Moonbase · April 21, 2022, 3:10pm

It is still a rather rudimentary site. Installed extras are:

Ace 1.9.2-pl
Collections 4.0.0-beta1
examplemodxblog 0.0.2-dev1 (modified)
getPage 1.2.5-pl
getResourceField 1.0.3-pl
getResources 1.7.0-pl
GoogleSiteMap 2.1.2-pl
Markdown Editor 1.1.0-pl
pThumb 2.3.3-pl
Resizer 1.0.2-beta
Tagger 2.0.0-alpha1
translit 1.0.0-beta
UpgradeMODX 2.3.1-pl

halftrainedharry · April 21, 2022, 3:28pm

I don’t see anything in this list of extras that likely affects the MODX parser.

Unfortunately, I can’t reproduce this as well.

Moonbase · April 21, 2022, 3:30pm

Darn. What else can I do to diagnose this? My daughter is already desperate to get her site up and running again… (and I was the one to tell her “always do the updates”… sigh)

Btw, the MODX Updater suggests to update to MODX 3.0.1-DEV (shown red). Should we do that?

halftrainedharry · April 21, 2022, 7:29pm

Is it possible to make a fresh MODX3 installation on the same environment (maybe in a subfolder or a subdomain), to check if this is a general problem (on this environment) or if something is just corrupted on your current installation?

I don’t think this is an official release. So an update may not be a great idea.

Moonbase · April 23, 2022, 12:07pm

Hm. Not so easy, due to .htaccess stuff. We might try on a subdomain, but it’ll take some time, I fear.

Best testing strategy? Would you agree with…

Installing a “naked” MODX 3
Setting up a test file using a calculated [[!…
Installing one extra at a time, then testing again

Thanks, so we won’t upgrade to any “-DEV” version.

Does MODX 3 have any known problems with certain PHP versions? (We currently run it on PHP 7.4.28.)

I wonder why others haven’t been hit by this yet…

halftrainedharry · April 23, 2022, 3:45pm

Not that I know of. The download page says that 7.4 is “Recommended for Production” and 8 is “Supported”.

I haven’t seen anything similar here in the forum or on github. It doesn’t seem to be a widespread issue.

Is a simple uncached tag like [[!$some_chunk]] also not processed or only when it’s nested inside another tag?
Is there a system setting parser_max_iterations (and if “Yes”, what is the value)?
What is the “Content Type” of your resource? Under “Content” → “Content Types” is the checkbox “Binary” for this content type unchecked?

bobray · April 24, 2022, 5:56pm

Unless I’m misunderstanding your needs, you could replace that tag in your original post with a pretty simple snippet, like this:

New Tag:

[[!SelectChunk]]

Snippet:

/* SelectChunk snippet */
$chunkName = 'blog_article';

if ($modx->resource->get('class_key') == 'CollectionContainer') {
    $chunkName = 'blog_listing';
}

return $modx->getChunk($chunkName);

It will be faster and it should avoid any possible nesting, cache, or interference issues, though it doesn’t help determine whether or not you’ve discovered a bug in MODX 3.

Moonbase · July 24, 2022, 2:47pm

No, not processed. Same applies to TVs like [[!*some_tv]].

Nope.

Eventually HTML.

Yes.

Same: Displays as [[!SelectChunk]].

I really suspect either the tag parser has a bug or the 2→3 upgrade process messed something up.

halftrainedharry · July 24, 2022, 4:25pm

In the last 3 months, most problems related to MODX 3 and the parser were caused by a change in how output modifiers are parsed. So although your problem seems to be different, maybe try changing this line in the code

github.com

modxcms/revolution/blob/cb6f56a19af818ad4d1d62dc0d31b9819aaa876f/core/src/Revolution/Filters/modInputFilter.php#L56


      
          public function filter(&$element)
          {
              /* split commands and modifiers and store them as properties for the output filtering */
              $output = $element->get('name');
              $name = $output;
              $splitPos = strpos($output, ':');
              if ($splitPos !== false && $splitPos > 0) {
                  $matches = [];
                  $name = trim(substr($output, 0, $splitPos));
                  $modifiers = substr($output, $splitPos);
                  if (preg_match_all('~:([^:=]+)(?:=`((?:(?:[^:=][\s\S]*?|(?R))*?))`)?~s', $modifiers, $matches)) {
                      $this->_commands = $matches[1]; /* modifier commands */
                      $this->_modifiers = $matches[2]; /* modifier values */
                  }
              }
              $element->set('name', $name);
          }
          
          
/**
           * Indicates if the element has any input filter commands.
           *

to this (how it was in MODX 2.x)

if (preg_match_all('~:([^:=]+)(?:=`(.*?)`[\r\n\s]*(?=:[^:=]+|$))?~s', $modifiers, $matches)) {

and see if that helps.

bobray · July 24, 2022, 10:06pm

Do you have the FastField extra installed?

Moonbase · July 25, 2022, 10:25am

No, still only the ones mentioned above (plus updates of those).

Moonbase · July 25, 2022, 11:22am

@halftrainedharry: Wow, your proposed change actually worked! Thanks a bundle.

I changed /core/src/Revolution/Filters/modInputFilter.php as proposed, had to clear MODX’ cache and voilà—all back to good!

Being a change in core, we now of course fear it might be overwritten with the next update. Maybe this could also be tested by others and possible (re-)included in the release?

Thanks for all your help so far.

bobray · July 26, 2022, 4:35am

The mystery is why this isn’t happening to everyone. I have several MODX 3 installs that are parsing tags perfectly.

It may be a clue that I don’t use output modifiers at all and tend to avoid deeply nested tags.

joshualuckers · July 26, 2022, 11:44am

I introduced the changes causing this issue. See Fix the parser when using nested output filters by JoshuaLuckers · Pull Request #14458 · modxcms/revolution · GitHub

@opengeek can you take a look at my comment in the PR about reverting the change?

opengeek · July 26, 2022, 1:19pm

I saw the comment. I have not seen a PR that reverts these changes. Can you submit one so we can get this taken care of?