Dropped connection after log in

ModX seems exactly like what I've wished a CMS would deliver, take care of the undercarriage but out of the way of the site development and styling.

Alas, I cannot consistently access Manager after submitting password, sometimes don't even get the log on screen.

This time, right after a supposedly successful install, I log in and Safari throws a "Failed to open page" error. The explanation given states that "the server unexpectedly dropped its connection. This sometimes occurs when the server is busy…" On other attempts to install ModX I've started out with a successful Manager log-on, got some work done, then found myself unable to log back on later. One time I got the "connection dropped" screen, but found myself in the Manager when I navigated back a page, but this was fluke behavior.

Troubleshooting efforts: Double checked PHP values and settings to assure compatibility with ModX's expressed requirements. Replaced MySQL with MariaDB. Upgraded my system to overwrite Apache config files and then rewrote the pertinent conf and virtual host files. Get the same result even after assigning all files and folders 777 privileges.

Tested out the index.php file in the Manager folder. Goes kablooey on the if clause at lines 57 through 59. Did a var_dump on the modx object and the settings it lists looks right.

Expected Outcome: Expected to see the Manager page.

• MODX Version: 2.5.8
• PHP Version: 7.1.0
• Database (MySQL, SQL Server, etc) Version: MariaDB 10.2.8
• Addit ional Server Info: Apache 2.4.27
• Installed MODX Add-ons: None.
• Error Log Contents:
Thu Oct 05 20:25:31.413700 2017] [autoindex:error] [pid 239] [client 127.0.0.1:49289] AH01276: Cannot serve directory /Library/WebServer/Documents/mysite.local/: No matching DirectoryIndex (index.html,index.html,index.php,index.html,index.php) found, and server-generated directory index forbidden by Options directive (attach as file if it’s too large)

Hmmm-mm. This sounds like I might need to edit htppd.conf again. Suggestions?

The most common cause of stuff like this is a loss of the session. One way that happens is switching from a www page to a non-www page or vice versa. You would see that in the URL if that's the case. The solution is to uncomment the part of .htaccess that forces one or the other (but not both).

Another possibility is your 777 permission setting. If the server is running suExec, or suPhP, or something similar, it wants 775 for directories and 644 for files.

Be sure the RewiteBase in .htaccess ends in a slash.

Much appreciate the tip, BobRay. After I allowed for overrides, activated the .htaccess files in the site root and edited the site's main .htaccess file as suggested.

At first I got a very slow log on-- close to an hour, maybe longer. So long I thought nothing was working until I came back to it after leaving the machine to do a chore, surprised to find the manager page there in Safari after I woke it up. I logged out to see if I could log in again. Another very long log on.

I didn't wait for the page to resolve, for it occurred to me that I hadn't activated .htaccess in the manager directory. I did that and not only restarted Apache but rebooted the laptop (after it hung up while switching users)/

Now it all seems up and running. Two log outs and log ins on Safari and also Firefox.

I've gone into detail in case someone else runs into this problem on a Mac or other UNIX-like localhost set up.

Thanks.

I'm glad you got it sorted. Thanks for reporting back in detail.

Ups! A couple days later, the connect reset messages come up again while trying to log on to the Manager. The error log for the site shows no error dated today. Maybe ModX thinks everything's running just fine but the browsers all think it's taking too long. Who knows?

Possibly relevant, possibly irrelevant background: in between the socket connection to MariaDB went missing. Didn't enjoy much success in troubleshooting this mystery, either. Got onto the machine this morning, thinking I'd continue to work some more on that, only to discover I could access the database server no problem, first on the command line and then through phpMyAdmin. Some kind of system reset may took after the third or fourth reboot.

It surprises me than nobody else seems to have run into this problem. I don't think my system set up is all that idiosyncratic, a Mac OSX localhost, setting ModX up in one of three virtual hosts, making use of a Homebrew installed MariaDB, served by Apache2 and running on PHP 7.

I think I've read other reports of DB anomalies with MODX and MariaDB (although MariaDB is recommended on the MODX cloud pabe). I don't know if MariaDB was the true issue though.

Is your character set utf8mb4? I've read that MODX has issues with that, though I don't know if it's still true.

While there could be a problem with the database, I switched over to MariaDB from Oracle MySQL as part of the "connection reset" troubleshooting effort. The problem started when I had a vanilla MySQL set up. When I call upon MariaDB with a PHP app that I've written, the connection works fine, the interaction with the database works fine, so it doesn't look like a global MariaDB issue.

This all would make more sense if ModX never worked at all. The way it sometimes does, most of the time doesn't is pretty puzzling.

I dispose of the cache and still get "connection reset," so it's not as though something's getting written over there that interferes with later sessions.

It turns out that the server character set is utf8mb4_unicode_ci. Specific tables are collated utf8_general_ci. Maybe the sourse of the stress lies here.

It's ironic, but I wrote a long reply and the Forum logged me out before saving it.

I've tried to reconstruct the key points.

There's a discussion of this on GitHub. Using utf8mb4 limits unique indexes to 191 characters, but MODX allows 255. https://github.com/modxcms/revolution/issues/12445. Apparently, an update to MODX occurred on this within the past week, but it will only affect new installations.

This is just speculation on my part, but maybe you're running into trouble when you save a MODX object with an indexed field longer than 191 characters.

I believe this issue affects both MySQL (or at least MySQL + InnoDB), and MariaDB equally.

https://stackoverflow.com/questions/43483129/does-mariadb-allow-255-character-unique-indexes

I've changed the collation to utf8_general_ci for the server and this database in particular.

My Ubuntu machine has sat idle for a while. Maybe it'll see what happens with an install ModX on a different OS, reverting back to Oracle MySQL.

No need to deploy right away the site that I prefer to develop with ModX, so if I make no further progress, I may as well wait for a couple updates and try a fresh install. Perhaps fixes to other issues will inadvertently address this mystery.

I very much appreciate, Bob, all the effort you've put into getting a handle on this.