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


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





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.


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

It tried to reproduce the issue with


but the output is correct.

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

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

// 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">

    <div class="container">


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


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


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

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

    <footer class="container">
      <div class="row">
        <div class="col-md-12 blog-footer">
          <!-- <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>



Hmm, Askimet has hidden my post. Trying again.

I made two small chunks, to be sure:


<p>Some chunk!</p>


<p>Other chunk!</p>

and used:


What I get on the web page:



I still can’t reproduce this.

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

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:is=`Some template var!`:then=`!$some_chunk`:else=`!$other_chunk`]]]]

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

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

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

Unfortunately, I can’t reproduce this as well.

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?

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.

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…

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?

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 */
$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.

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


Eventually HTML.


Same: Displays as [[!SelectChunk]].

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

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

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

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

and see if that helps.

1 Like

Do you have the FastField extra installed?

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

@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.

1 Like

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.

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?