Manager white-out on setting friendly_urls to Yes

ilja-web · March 24, 2021, 11:00am

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();.

cottagestuff · March 24, 2021, 11:02am

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.

cottagestuff · March 24, 2021, 11:05am

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.

ilja-web · March 24, 2021, 11:24am

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

cottagestuff · March 24, 2021, 11:35am

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.

markh · March 24, 2021, 11:36am

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?

cottagestuff · March 24, 2021, 11:46am

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.

cottagestuff · March 24, 2021, 11:51am

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.

cottagestuff · March 24, 2021, 12:09pm

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

Related?

All the other tests get green.

markh · March 24, 2021, 12:11pm

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.

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.

ilja-web · March 24, 2021, 12:21pm

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

markh · March 24, 2021, 12:27pm

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.

cottagestuff · March 24, 2021, 12:34pm

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

https://www.9watling.co.uk/connectors/index.php

The file exists at that location.

Then the following:

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.

cottagestuff · March 24, 2021, 12:41pm

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.

cottagestuff · March 24, 2021, 12:54pm

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.

markh · March 24, 2021, 1:04pm

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.

cottagestuff · March 24, 2021, 1:18pm

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?

markh · March 24, 2021, 1:25pm

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

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…

cottagestuff · March 24, 2021, 1:32pm

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.

system · March 26, 2021, 1:32pm

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