Could not find action file: but with a twist

Modx Revolution 2.4.1, this happened on my local dev server a while back while I was synching the local db with the remote live db data. That is, updating the local to be the same as the remote.

Don't read this too fast, note that the path is wrong: /default/aresource/update.php

I've grep'ed through core and manager to see if I could find any instance of 'aresource' but of course nothing appeared.

This error makes it impossible to work with my resource data in my local version, and I can't figure out how to resolve it.

The live site is fine. I just tried updating the local db with the remote data, and the error still persists. Since that data is now in my local system, I have to assume the /aresource/ path error cannot possibly be in the live database, unless it can, somehow. And it's not in any of the files of modx itself.

Also noteworthy is that there is no update.php file at all in either local or remote manager, just: update.class.php

I've cleared the core/cache repeatedly, made sure to give it 777 permissions, but nothing makes the error go away.

I guess I could nuke everything and reinstall, but given this issue might also hit the live site, I'd like to know how to resolve the issue without resorting to desperate measures.

thanks.

Did you check the namespace 'path' field? That's where that URL comes from.

Is that the 'namespaces' table? I don't see anything in that one related to that path. Or is it somewhere else?



I also searched through the sql dump file and there's no occurrence of 'aresource' in it, just to be on the safe side. So the system looking for a path that doesn't appear to be in either the database of the physical files, which suggests a bug somewhere? [ed. note: lizardx last edited this post 10 years, 9 months ago.]

That's it, but apparently the problem is not there. Is this happening for all Manager actions, or just specific ones?

You might also check the modx_actions table.

It happens when I try to view any resource/element from the left nav option list. I can't see any other time it happens, unless I haven't poked around manager options enough.

I checked those tables, and don't see anything.

The questions I have would be: why is it adding the 'a' to /resource/ and why is it looking for a file that does not exist? update.php?

These seem like two separate issues.

<update>

I poked around a bit more, and found that I can edit Elements (chunks, snippets, templates) if I right click on the name in the left nav column and select the 'edit' option. If I try to edit a resource by right clicking the name and selecting 'edit', however, it says:

Error!

Resource not found.

But if I click on them directly, the same 'could not find action file' message always appears for both resources/elements items.

Also note I've searched the entire dumped db sql file for 'aresource' and 'update.php' and those don't appear in that file, or in any modx system file that I can find, which suggests that modx is constructing these file names out of something.
[ed. note: lizardx last edited this post 10 years, 9 months ago.]

Don't know where the "aresource" is coming from, it should be "resource". manager/controllers/default/resource/update.class.php

Is this an old installation that's been upgraded many times? I'd be inclined to use BobRay's UpgradeMODX on it setting it to "upgrade" to the current version. And make sure your browser cache has been cleared so it's not trying to use some old cached Javascript files.

Re 'age' of installation, it's a modx revolution, I can't remember when I installed it, was a few years ago. I wouldn't call that 'old' myself. I forgot to mention, this is the advanced modx revolution.

Don't know where the "aresource" is coming from, it should be "resource".

That's the question I believe, so the answer is what is missing.

Same for the 'update.php' instead of update.class.php.

The browser cache was a good thing to remind users of, and me, so I cleared cache, and, even better, logged in with a browser I'd never logged into the manager before.

Same results. So the issue can't be the browser cache since that browser had no cache of the manager, though it is a good guess.

Are there other locations in modx core or manager that might have cached files? the update.php seems like a dead giveaway that something cached or corrupted is being used when it shouldn't be. As with the /aresource/ corruption.

Again, one of things I want to figure out is how to fix this in case this ever happens on the live site, if it does, I need to have it running very quickly, and since it clearly can happen, and has happened, what I need to figure out is how to fix it.

What we know so far:

1. The core/cache/ has been cleared, both via control panel and direct rm -fr core/cache/*

2. The browser caches have been cleared, and a fresh browser has been used

3. The issue is only occurring on my local dev version

4. I've imported the live db sql several times to the local dev version, which means that the db tables are identical, except for the adjustment to the core path in the workspaces table required when moving it. Though there could be a table in there with a changed name left over in theory.

5. aresource and update.php do not occur in the actual files of core or anywhere else. Which does really suggest a caching issue, only as noted, the caches of browsers/modx have been cleared, repeatedly. Well, it does occur in the log data after the error happens, of course, but that's it.



[ed. note: lizardx last edited this post 10 years, 9 months ago.]

I don't think this will help you, but update.php is the legacy processor, which will be run if MODX can't find update.class.php (which it wouldn't because it's looking in the wrong directory).

I've been scratching my head hear for a while trying to think of where the extraneous 'a' is coming from -- without much luck, I'm afraid. You could check the paths and URLs in core/config/config.inc.php, but I don't think the problem is there.

You might watch the Network tab in FF Chrome dev. mode (Ctrl-shift-i) to see if that gives you any clues about the steps leading up to the issue.

That's helpful, so that narrows down the issue to the corrupted /aresource/ directory name alone. So there's only that one issue.

To my eyes, it looks like the aresource is a constructed corruption, though that's of courses only a guess, ie, something is appending the 'a' to 'resource'.