MODX 3.0.5 is mixing up resource IDs

Support
1

I have a few sites in MODX 3.0.5 and am seeing a weird issue.

In one, the menus, after clearing the site cache, have the right page titles but are linking to the wrong pages, so [[~(resource ID)]] is wrong, even though the page titles are correct.

On a second one, I have some page scripts loading the wrong data or timing out because they’re not get the info (like TV values) that they are expecting. I put this on one of these pages:

[[*id]]-[[!*id]]

to track the cached and uncached ID numbers on display. What I found was that, right after clearing the cache, I got this result:

201-1

And then, after immediately reloading the page without clearing the cache, the values are now:

201-201

So, on the first pass the uncached ID number is “1”, which is not the resource’s ID number. Even if I put the ID tags at the very top of the page template, before any snippets or other coding has loaded, I see the same result.

The only error in the log is:

(ERROR @ /www/core/src/Revolution/Filters/modOutputFilter.php : 722) PHP warning: Undefined array key 1
(ERROR @ /www/core/vendor/xpdo/xpdo/src/xPDO/Om/xPDOObject.php : 806) Backstage\v3\Model\Change: Attempt to set NOT NULL field changeset to NULL

This particular site is a Backstage setup in MODX Cloud, and the problem is NOT happening on the live site, just on the development site with Backstage installed. When the page is reloaded after the first viewing, and the uncached ID matches the cached one, no more errors are recorded.

What could be causing this? It’s really weird. This only started happening after updating MODX, although maybe some Extra update is involved??

2

The only way I can think of to make sense of this, is if a cached snippet changes $modx->resource to resource 1 during the code execution, so that for everything that is processed afterwards, the resource has changed.

Usually the code shouldn’t change $modx->resource.
Do you use “renderResources”? That’s the only snippet I know that (temporarily) changes $modx->resource.

3

This warning is caused by an output modifier tvLabel. Probably the ‘output_properties’ are not in the expected form.

If it’s a Backstage™ problem, then only the MODX Cloud team will be able to help you. As Backstage™ seems to be proprietary code.

4

No, I don’t use that.

5

@snowcreative I honestly think it might make sense to sumbit a support ticket at MODX Cloud because if this is happening because of Backstage, we’d like to know why. We’re using Backstage widely with customers and on modx.com.

6

I’ve been seeing this same error periodically for a while now but haven’t investigated where it’s coming from yet. I’m not using Backstage tho and I haven’t been aware of having any of the other issues you describe.

7

It’s not a Backstage issue. I just discovered another site with the same problem, not hosted on MODX Cloud. MODX 3.0.4. The URLs in the site menus are correct, but when you view certain pages, the correct URL loads the wrong page content, including all the sidebars.

8

MODX uses the aliasMap in the cache file core/cache/context_settings/web/context.cache.php (for the “web” context) to determine the ID of a requested resource from the URL.

Are the values in the cache file correct?
Are the values of the column “uri” in the database table modx_site_content correct? (Maybe 2 resources have the same value for “uri”?)

9

Thanks for the tip. I’ll check that out the next time this happens.