Could not find action file: but with a twist

By the way, I hadn't known about ctrl shift i debugger in firefox, what a great tool! Thanks.

There's the source of the 'a' in 'aresource' I would say, clearly.

That's the first thing in the list of headers.

I'm guessing: ?a=?a=resource/ becomes ?a="?a=resource" then the ? and = are stripped out, and it becomes: ?a=aresource

Right clicking on an Element and selecting edit gives this:



No extra ?a= so the path works.

Right clicking on a Resource and selecting edit gives this:



Which gives the Error: Resource not found since the ?a=? is there I assume



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

See if this helps --

When there is an .htaccess file in the MODX root (with the friendly URL's part active - as it is by default), The friendly_urls System Setting should be set to Yes.

When there is no .htaccess file (note: the ht.access file doesn't count -- it's ignored), the friendly_urls System Setting should be set to No.

Something else to try is renaming the ht.access file in the Manager folder to .htaccess.

I use Apache configs on the local system, not .htaccess, that's the only difference though.

The live .htaccess and the dev config are the same, except the dev one is simpler, just what I posted above, that's the entirety of it.

The manager has the ht.access, which I should remove, and there are no further rewrites in manager.

Also worth noting is that everything was working, then it just stopped, during I think one upgrade/synch a few months back.

As you can see from the rule, apache exits rewrites if the directory starts with assets or manager, so the redirect QSA for friendly urls never kicks in.



So the issue is the doubling of the ?a=?, but the question is, how is that getting generated?

The site uses friendly urls, which work fine on dev and live.



I hadn't even noticed the actual nav bar url was wrong, so when I change it and remove the extra ?a= it all works fine, as expected. So the issue can be narrowed down to something deciding to add a ?a= to the query string for click on left nav bar resource/element item, and for right click + edit option for left bar resource item. [ed. note: lizardx last edited this post 10 years, 9 months ago.]

I'm afraid I still can't think of any likely cause for the doubled parameter.

Do you have any URL-related plugins? It's grasping at straws, but you might consider disabling all your plugins, then deleting all files in the core/cache directory. If it works, you can bring back the plugins one at a time until the problem recurs.

I don't see a 'disable' option, there's uninstall, reinstall, and remove. And check for updates.

There's no url plugin that I'm aware of, I always try to keep the plugins very very basic since plugins are most likely to not be properly updated for modx updates in general, wayfinder, quip, articles (not used), archivist (I think not used), breadcrumbs, taglister (not used I think), tinymce, getPage (not used), getResources (not used).

Right-click on each individual plugin in the tree and select "Deactivate Plugin." Delete the core/cache files when you're done.

Another thing to try is Susan's suggestion:

1. Install UpgradeMODX
2. Change the settings_version System Setting to any older version (it doesn't even have to exist).
3. Visit the dashboard, and in the UpgradeMODX widget, "upgrade" MODX to the version you are currently using.

That will overwrite all the MODX core files with fresh ones in case you have a corrupted file somewhere.

Tried both things, disabling all plugins, and upgrading after changing version number, issue persists. Haven't tried upgrading from 2.4.1 to 2.4.2 though it's doubtful that would do anything I suspect. I keep my local version and live version the same.

By the way, if that upgrademodx plugin is reliable and works you just solved my single biggest issue with modx, what a pain it is to update, and how long it takes me to do it safely. I use the pl advanced install.

I'm running out of things to suggest. I'm afraid this is going to be something really obvious that I should have thought of.

Is there anything helpful in the MODX error log?

Assuming that the error log is no help, here's what I'd probably try next.

First, export the DB to an SQL file (with DROP TABLE selected) in PhpMyAdmin. Then, create a fresh install of MODX on your server, and import the SQL file to its database. You'll have to use the original site's credentials to log in to the Manager. If you still have the problem, that tells you the problem is in the DB. If you don't, it's in the files. In the latter case, you can bring the files over in batches, testing as you go, to see when the problem recurs.

If it's in the DB, since you don't have the problem with the local install, you could export both DBs in PhpMyAdmin to SQL files and do a compare with something like WinMerge to look at the differences.

You could do something similar with the files, but it would be pretty tedious since there are thousands of them.

My move of last resort is to set up remote debugging on the site in PhpStorm, launch index.php in the debugger and step through the code, switching back and forth between the debugger and the Manager, and wait for that URL to be processed. Both setting up the debugger and stepping through the code are a royal pain, and if you're not comfortable reading PHP code, probably not very helpful for you.

Sorry to not respond sooner.

1. Modx error logs show the error, that's all. There's no actual error occurring except for the url getting the extra ?a= so there's no surprise that the only error is the path not found error.

2. It's in my opinion highly likely that the error is in the js that builds these urls, though I have no idea where that code comes from really beyond some basics. With that in mind, it's tempting to just overwrite the various js directories and see if that fixes it.

Unfortunately searching for a= gives a ton of results and doesn't limit stuff much.

I my mysql stuff as much as possible on the command line, but the import/export stuff is already tested at least in part because I've already rebuilt the modx local db a few times from the live db data.

I don't believe this is a PHP error though I can't be sure.

I think the most logical thing is to try to overwrite the js files which are the ones generating the admin control panel urls I assume. The actual generated error is just modx doing normal error catching, a non existent url was requested which triggers the logged error, so that's all working as expected.

Technically if one were to be picky one could note that there's actually a bug in the query string parser in modx, since ?a=?a=resource shouldn't become aresource but it's hard to catch stuff like this when it's almost certainly a corruption that wouldn't be expected. I'm actually curious to see what some of my php form processing code would do that with that.

To test proper query string handling I did this:



After checking the js files, I found that the local version in manager were older than the live version, which means part of an upgrade failed to install all the files. This has by the way always been my worry because the procedure to update modx involves so many chmod to various directories that it's very easy to make a mistake, and it looks like one was made at some point.

In theory the installer should be checking all the directories it needs to write to, not just the top level ones. That looks like the issue as far as I can tell. I'm copying over my manager files to my local site and I'll see if that works, though it's likely that it will just get corrupted and I'll have to blow up the entire install, which worries me in terms of something failing due to complexity of updates.

Just a quick update:

I gave up, and tried reinstalling the 2.4.1 pl advanced, which all worked fine, except now my resource tree is empty.

I don't want to upgrade until I can actually fix this because I don't want to risk this happening on the live site, and I need the versions to match.

I've tried the:

compress_css - 0 (off)
compress_js - 0 (off)

suggestion but it makes no difference.

The Elements tree now works fine, as does the Files tree, and the Resources is just completely empty.

You can see the arrow to expand the list appear very briefly when the page loads, then it vanishes.

The resources are all present, and visible in for example resource search, but the resource nav tree is empty.

The site itself loads and runs fine, so it's purely a manager problem.

Given how common this problem is ( https://frogabog.com/news/2015/modx-manager-empty,-blank,-resource-tree-missing,-menu-non-functional-%28menu-doesnt-work%29/ but note there the fallback: if this doesn't work, reinstall), it might be worth taking a much closer look at it I think, for example, if this happened on the live site, that would be a killer, unless there's a fix that's not too hard.

I'm now at the point where I'm going around in circles, that is:

Updating the db with the live db data, clearing cache, logging out, clearing browser cache, etc, and I can also of course reinstall again, but technically, there's a point where I have to stop because it takes too much time from paying client work.

It seems to me like there's a major weak spot in the design if data in the database, which is readily accessible in the manager via other routes, like search for id, or title, etc, and visible in the resource list in search, isn't just there in the tree. It's like something in the programming is thinking too much rather than just looking for what is actually there and printing it out.

The only real difference between live and local systems is php versions and mysql versions (PHP live: 5.3.39, local: 5.6.15; mysql local: 5.6.27; live: 5.6.23)