I have dozens of previously working static resources (PDFs) all now returning 404s. These all worked, for years. I had not recently made any changes.
MODX Cloud site, has been at version 2.6.something when the static resources stopped working sometime in the past week. In an attempt to fix this issue I updated to 2.7.3 today, but that didn’t solve it.
I have double-checked the paths and settings, and as I said these all have been previously working for years. I tried adding a new static resource and it 404s as well.
Has something changed with MODX Cloud environment?
Should I continue to update to 2.8.3?
I’ve upgraded sites with SRs through the versions you mention without problems. That’s not on MODX Cloud right enough.
If you open one of the SRs by hitting the View button in the manager, does this also result in a 404? [I’m assuming you’re generally browsing links in the front-end].
I’m sure you’ve checked the Content Type extension / binary setting - I’ve had issues there before but only during development - not randomly just happening.
Thanks, yes, opening in View button from the resource and/or front end links are 404s.
Checked the Content Type extension and binary is checked – I believe that’s correct?
Nothing in error log except this:
[2022-03-02 15:08:54] (ERROR in modMenu::getSubMenus @ /www/core/model/modx/modmenu.class.php : 148) modAction support is deprecated since version 2.3.0. Support for modAction has been replaced with routing based on a namespace and action name. Please update the extra with the namespace core to the routing based system.
Definitely worth upgrading to 2.8.3. Also check the path to your PDFs is within the path configured in resource_static_path, if the static file is elsewhere it will throw a 404 since 2.8.2 for security reasons.
Thanks Mark. I won’t have a resource_static_path setting until I upgrade, correct?
If the static files are here: assets/files/foo/bar.pdf, can I put assets/files/ in the setting and foo/bar.pdf in the Static Resource content field? Or do I still put the full path in the content?
For a multi context site should resource_static_path be set at the context level as well, or doesn’t matter as long as it’s the same for every context?
Oh, sorry. I thought you were already on 2.8.2 but misread. There may be something else afoot in that case…
You can keep a relative or absolute path in the static resource content, as long as the resolved path is within the path configured in resource_static_path. E.g. if you set that to {assets_path}files/, you can have either assets/files/foo/bar.pdf or foo/bar.pdf or /full/path/to/assets/files/foo/bar.pdf in the static resource content.
Yeah, this issue appeared while the site was at 2.6.*, so that’s why I’m sure it isn’t the 2.8.2 bug. Gonna contact Cloud support and see if they have any ideas.
Thanks Bob I was wondering the same. But it turns out it was a caching issue. And a memory issue (mine).
I recently added a browser caching rule as recommended here:
Apparently if you have PDF as a file type in that rule it breaks static resources with PDF content type. The smart folks at Cloud Support figured it out very quickly. Hopefully they will add a warning to the docs.
(Solution was to remove PDF from the file types in the browser cache rule.)
This topic was automatically closed 2 days after discussion ended and a solution was marked. New replies are no longer allowed. You can open a new topic by clicking the link icon below the original post or solution and selecting “+ New Topic”.
