Answered Help! Error after upgrading MODX Rev. from 2.2.6-pl to 2.2.7-pl! Syntax error: Internal Server Error

I find it odd the suggestion that something to do with MODX makes it bad for a cloud based platform when MODX Cloud/SiphonLabs is also a shared cloud hosting platform. Unless they know something that isn't public and have a specific modification/workaround to alleviate such problems with MODX.

Quote from: halfnium at Apr 18, 2013, 10:25 AM

incomplete rendering of the item trees at the dashboard's left side, and (rarely) rendering the Manager page seemingly without using its style sheet.

May I ask whether you are using the compressed css/js setting in the system settings?

I have had several troubles with these enabled in the MODX system settings. My solution was to disable these within MODX but enable css/js compression within htaccess, this seems to avoid conflicts within the MODX internal cache but still give a performance boost through serving compressed files between server and client side.

I quite agree that Revo ought to be working the same way --- reliably --- regardless of hosting platform. Revo might run like blazes on one host, like molasses on another, but it ought to deliver the same results on either eventually. Of course this is barring some required feature (per http://rtfm.modx.com/display/revolution20/Server+Requirements) gone missing altogether.

Quote from: absent42 at Apr 24, 2013, 10:36 PM

Quote from: halfnium at Apr 18, 2013, 10:25 AM

incomplete rendering of the item trees at the dashboard's left side, and (rarely) rendering the Manager page seemingly without using its style sheet.

May I ask whether you are using the compressed css/js setting in the system settings?

I have had several troubles with these enabled in the MODX system settings. My solution was to disable these within MODX but enable css/js compression within htaccess, this seems to avoid conflicts within the MODX internal cache but still give a performance boost through serving compressed files between server and client side.

Do you refer to settings "Use Compressed CSS" and "Use Compressed JavaScript Libraries?" I have not changed these from their virgin installation values, which is "Yes" for both. These are good ideas. Shouldn't they work reliably, particularly as set by default at install time?

Do you refer to settings "Use Compressed CSS" and "Use Compressed JavaScript Libraries?" I have not changed these from their virgin installation values, which is "Yes" for both. These are good ideas. Shouldn't they work reliably, particularly as set by default at install time?

Those are the ones. I always turn them off. It doesn't seem to slow down the Manager and it prevents those occasional mis-renderings.

No, not every server will be configured to allow these to work properly. The compression process takes up a lot of memory and processor resources. Especially limited shared hosting can fail. It's also possible that browser settings can cause the client end to fail. Personally, I think they should be off by default, since when it doesn't work you end up with an unusable Manager.

I like a practical work-around as well as the next guy, but doesn't it seem that there is a deeper issue to dig into here?

Not really. It's a nice feature, but not essential for the Manager's functionality. It's like processing a huge image using phpThumb, if the server can't supply the memory and processor resources to handle it then you won't get a thumbnail and you'd have to prepare the image before uploading it for use.

Setting those two to "No" (and invalidating cache via deletion) reduces the frequency of the problem tremendously as I mouse around and click Manager menu items, but that does not eliminate the problem. The Manager's behavior is not suitable for exposure to a client.

Selecting Package Management seems the easiest way to generate the problem.

Via CPanel, I can see the last few server errors. All report inability to create a child process due to inability to allocate memory. Meanwhile, virtual memory transiently maxes out at two gigabytes, which is the limit my hosting service has graciously provided. Physical memory use is miniscule by comparison, less than 128MB even when I beat heavily on the Manager, and just 8 to 12MB at idle.

Too bad for this particular hosting service that they currently advertise on the MODX Web site. Too bad for me that I've signed up for three years with them.

Hm. Is there any MODx team support feature for hassling hosting services that advertise with MODx but don't fully support MODx?

Or maybe look at it the other way around: MODX LLC may lose some welcome advertising revenue if the MODX CMS's memory (and processor?) use can't be smoothed out, made less bursty. The trend is toward these low-cost, cloud-based hosting services, so this problem is going to repeat with increasing frequency. Best to engineer a response on MODX's side, seems to me.

BTW, when I asked before signing up, this particular hosting service assured me that they had several happy MODX customers. Could that have been (a) wishful-salesman thinking (since there was Revo 2.2.7-pl on their Softaculous menu), (b) based on actual experience with Evo or (c) a case of telling the prospective customer what he wanted to hear (a.k.a. lying)? I would be quite upset with them, except that their tech support has been first-rate and patient as we've puzzled over this for the last two months.