Manager white-out on setting friendly_urls to Yes

Some hosts need time to process te .htaccess. Did you make recent changes to it? Also, check if the server supports mod_rewrite. You can check it with phpinfo();.

Looking now at the network tab in the browser, and what I see is that immediately after clicking Yes for friendly_urls, the browser is trying to load the files for the front end home page and not finding any of them (404 errors). Seems odd it would want to load the home page rather than stay in the Settings area.

Thanks for that reply. About .htaccess: The only changes were made after the first wipe-out when I started to simplify the situation to remove factors that might be causing the problem.

About the server: I have another 20 or so MODX Revo sites on the same server, all happily with friendly_urls set to Yes. And quite a few of those are MODX 2.8.1. Suddenly, with this new installation, wipe-out.

Ah that’s weird. Did you try re-install?

So in desperation I go to PHPMyAdmin and find the friendly_url setting and set it to 1. Then clear the cache in the file manager. The back end works. And the front end works if I use the unfriendly URL. But when I am in the manager on a resource page and click to View, the new tab in the browser loads but the browser doesn’t even manage to load the URL.

Can you clarify if there is nothing at all being shown, or if you still see some parts of the manager (navigation and/or tree) but the main area is empty?

  • In the first case (nothing at all shown), an error is likely server-side and would need to get logged to a PHP or server error log. If you cannot find any such error log, please consult your host or server admin on where to find or how to enable those logging.
  • In the second case (some manager parts still visible), an error is likely client-side and there should be information about the error available in the browsers’ developer tools console. Also, in this case, is it a persistent issue where the manager remains in a “white-out” after refreshing the browser, or does it only “crash” as you describe when attempting to change the friendly_urls system setting?

Thanks, Mark. When I originally posted the problem, the screen had gone all white except for the lone tab marked: Help (which was sort of consoling, although clicking Help brought no…help).

Now I am in desperation mode and clicking various things, such as the XHTML_url setting, which I have switched off, thinking that switching stuff off reduces the chances of an error occuring (!). I can now select the Yes option in the manager area for the friendly_url setting, but it doesn’t save.

Interestingly, when I had friendly_url set to 1 using PHPMyAdmin, the site loaded with the unfriendly URLs, but the menu tabs were not recognised at all, either by friendly or unfriendly tabs. Clicking anything took you back to the default start page.

I have just tried re-running setup. The setup process whizzes through without a hitch. The site works with unfriendly urls. I can select Yes for friendly_urls in the Settings area of the MODX manager, but the selection is not saved.

Back to square one. So will try Bob’s life saver: SiteCheck. If only to pass the time and create a sense of possibly doing something.

1 Like

Ran Bob’s SiteCheck, and the only things in red are two table errors for these tables: modx_actions_fields, and modx_fc_sets, for which the error message is:

Charset mismatch in column: action
Collation mismatch in column: action
DB Charset: utf8mb4
Field Charset: utf8_general_ci


All the other tests get green.

So that sounds like the error is client-side. Can you please check the browser developer console for errors?

Clicking various things isn’t useful. Look for details: error messages are the number one thing you can work on that will actually help get you somewhere. :wink:

Open developer tools before changing the setting value. Change it. Check the console tab for javascript errors, and the network tab for the response to the connector.php requests trying to save the setting value which clearly fails.

Charset/collation errors do not typically have any impact on saving a setting.

If the error is client-side, his other sites would not be working right? Could it be the css/js compression?

No, that’s not been an issue since 2.5 when the dynamic compression was removed. Since then compress_js/css only affects if you’re using a development or production version of the core assets. It can be useful to disable compress_js for debugging or if you’re working on the core, but other than that it should always be enabled.

Mark, Thank you for your patience. Okay, looking at the errors in the browser console when I click outside away from the Yes (because I can select Yes, but the usual action of clicking outside the value to save it is not working - only for that one setting), and the first error is a 404 for this URL

The file exists at that location.

Then the following:

Uncaught TypeError: this.mask.addClass is not a function
ExtJS 3
ExtJS 3
setInterval handler*n
request ExtJS
ExtJS 16
ExtJS 26

Want to add that this is only the third site I am trying to set up with utf8mb4. Found the 2 columns Bob’s script said were mistaken in the 2 tables, and have changed them to utf8mb4.

From the early days with MODX, I switched off CSS and JS compression for every site. And they are off for this one as well.

In the Network section of the browser developer tools, for other settings changes I see a green 200 log for a JSON type something using the connectors/index.php URL, but then when I select Yes for friendly_urls and click outside the Yes box to save the change, I see a nasty purple 404 beside a HTML type event for the same URL.

That URL seems to cause an error here (perhaps you’re accessing the site pre-launch through /etc/hosts or it requires a specific VPN to access?) but as it does work for every other setting this sounds a lot like a firewall/WAF interfering based on the provided parameters.

Perhaps mod_security is flagging on the “friendly_urls” key or you have something like CloudFlare proxying the server that’s doing so.

So there might be something on the server stopping me making the change to the friendly_url setting in the browser. But when I use PHPMyAdmin to make the change directly in the database, the site then becomes unnavigable and none of the URLs work any longer. Are there therefore two problems here?

Yeah that definitely sounds like 2 different problems to me and I’d recommend tackling one before moving on to the next. :slight_smile:

If friendly urls, once enabled, don’t work in the front-end my first guess would be to look at the .htaccess and making sure the relevant portions of the rewrites are enabled…

Thanks a million, Mark. You were right. I was forgetting about the dreaded mod-sec that has been such a pain in the neck in the past. Completely forgot. You mentioned. I remembered. So disabled mod-sec and - wham! - setting saved. Friendly URLs work. Fantastic! And I can then re-enable mod-sec in the CPanel for the hosting account without breaking the site.

Thanks again.

1 Like

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”.