Blog Sections Open

Fixing getResourcesTag Output After an Update

How to restore tag-based getResourcesTag listings when an update changes placeholder handling or tag output stops rendering.

One of the easiest ways to break a working tag page in MODX or Evolution-style builds is to update one part of the stack and forget how the listing is assembled. In the original case, a project used tagLister to print the tag cloud and getResourcesTag to collect matching resources, but after an update the results stopped appearing even though the templates themselves still looked correct.

The usual problem is not the tag logic itself. It is the rendering order. getResourcesTag often writes its output into a placeholder, and the page then expects that placeholder to be rendered later. If the snippet call becomes cached, if the placeholder is printed before the snippet runs, or if the package versions are out of sync, the page looks empty even though the query is technically fine.

Start with the known-good structure

For tag-based listings, keep the tag menu and the listing separate. A structure like this is predictable and easy to debug:

[[tagLister?
&parent=`0`
&sortBy=`tag`
&target=`[[*id]]`
]]

[[!getResourcesTag?
&elementClass=`modSnippet`
&toPlaceholder=`results`
&showHidden=`1`
&tpl=`novost`
&parents=`[[*id]]`
&limit=`6`
&includeTVs=`1`
&includeTVList=`image,opisanie,metaDescription`
]]

[[!+results]]
[[!+page.nav]]

The important detail is the uncached call to getResourcesTag and the uncached placeholder output. If one side is cached and the other is not, or if the placeholder is printed in the wrong place, the page will behave inconsistently after upgrades and cache clears.

What to check first

  • Clear the full site cache after updating snippets or parser-related code.
  • Confirm that getResourcesTag is still called uncached with .
  • Make sure the placeholder is printed after the snippet call, not before it.
  • Recheck package versions if the project mixes older snippets with newer parser behavior.
  • Test the generated tag URL directly so you know whether the problem is the query or only the final rendering step.

If the page still comes back empty, temporarily remove the placeholder and output the snippet directly. That tells you very quickly whether the issue is in the query, in the placeholder pipeline, or in the template used for the final rows.

The general rule is simple: tag pages survive updates much better when the query step, the placeholder step, and the final template step are kept explicit and uncached where needed.

Newer post

Fixing Quip Threaded Comment Errors and Prerender Notices

What to check when threaded comments suddenly start throwing parser notices, undefined indexes, or invalid makeUrl errors.

Older post

Why Newly Created Resources Can Return 404 Until the Environment Catches Up

How to troubleshoot new Evolution CMS resources that seem to save correctly but still return 404 errors on the frontend for a while.