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

Moonbase · April 21, 2022, 1:43pm

Summary

My daughter runs a modified version of SepiaRiver’s Example Blog which worked fine on MODX 2.8. She now (accidentally) updated MODX to v3 and I now have to fix stuff…

After “repairing” the Namespacing issues, it still seems that generated MODX tags with an exclamation mark (for no caching) don’t work anymore—instead the tag is displayed on the web page.

Step to reproduce

Example:
̀̀

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

produces

[[!$blog_listing]]

on the web page, while $blog_article works fine. If I change !$blog_listing to $blog_listing in the above, it calls up block listing—but immediately shows the next [[!… tag in that. (reflect is just a filter snippet that returns the short class name (i.e., removes the namespace part.)

Observed behavior

It seems to me that—after the update to MODX 3—tags using [[!… don’t work anymore.
Nothing relevant is shown in MODX’ error protocol.

Expected behavior

Instead of displaying the tag, MODX 3 should parse it.

Environment

MODX Revolution 3.0.0-pl (traditional), Apache2, mysql 5.7.37-nmm1-log, misc. browsers (Firefox, Opera, Chromium, Android).

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?