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

Opcode cache - probably not, but many hosts enable Suhosin by default. To check, create a PHP file containing the following:

Post the output here so we can have a look.

To check the MODX settings, go into PHPMyAdmin or MySQL console in bash, select your MODX database and run the following query:

Quote from: wingnutty at Apr 12, 2013, 06:02 AM

Opcode cache - probably not, but many hosts enable Suhosin by default. To check, create a PHP file containing the following:

<!--?php
phpinfo();
?-->

Post the output here so we can have a look.

To check the MODX settings, go into PHPMyAdmin or MySQL console in bash, select your MODX database and run the following query:

SELECT * FROM `modx_system_settings` WHERE `key` IN("compress_css","compress_js","concat_js");

Thanks!

All the settings for compress and concat were '1'. I changed them to '0' but the problem remained the same.

Phpinfo returns quite a big output of configuration details, but no mention of suhosin anywhere. Do you need a specific bit of info from the command? I can cut the section and paste it here, but the whole output wouldn't be advisable.

I also reported the memory error to my local support to see if they can check for processes consuming excesive memory or if I indeed need more of it.

Did you clear the MODX cache after updating the database values?

Yes, see what your host replies with. You may very well be hitting a memory cap assigned by your host, and increasing that may solve your issue. Let us know how that turns out!

Quote from: wingnutty at Apr 12, 2013, 07:10 AM

Did you clear the MODX cache after updating the database values?

Since I can't run the Clear Cache command from inside the manager (the process just crashes with the same Syntax Error window) I deleted the whole core/cache directory, but it still didn't work.

I guess I'll wait to see it Tech Support comes with a solution from their side. I'll let you know how it went. Thank you very much for all the help!

I offer an explanation for the bizarre MODX Revo Manager behaviors that many of us are seeing. These include the randomly appearing "Syntax Error: Internal Server Error" message, incomplete rendering of the item trees at the dashboard's left side, and (rarely) rendering the Manager page seemingly without using its style sheet.

I moved a 2.2.5 installation with about 1800 resources from hosting service A, where I did not encounter these problems, to hosting service B, where I saw them every few minutes. (The hosting service names are disguised to protect the innocent). Note well the fundamental difference between the services. Service A is a cPanel conventional shared machine. Service B is a cPanel shared cloud server.

Of course Service B tech support considered my trouble report to be merely the confused ravings of a nonsensical mind. So I backed up my site and ported it to my XAMPP local development machine (where the site exhibited none of the above-described problems). Then I installed MODX 2.2.7-pl using B's Softaculous service, so that B would agree that I was not breaking anything. Mirabile dictu! That brand-new, virgin (no resources or add-ons) Revo installation exhibited the same problems.

A diligent tech support guy who had struggled over this with me noted something in the server's log: The memory limiter was kicking in. The Revo Manager's rendering caused allocation of a gigabyte of VM, whereupon the server denied further allocation and so caused threads to fail. The allocation was transient, less than a second long, but that was enough to cause trouble. The ugly workaround is clearing the "Syntax error" and/or reloading the page.

So my tech support friend boosted my account's physical memory limit to 512MB and virtual memory to a whopping two GB! The problems became infrequent but did not entirely disappear. The limited cPanel log available to me showed VM pegging at the full two GB occasionally.

This is OK for my current use case, which is a non-commercial, non-critical Web site for a non-profit organization. It's not so attractive in general, however.

What's going on here? I suspect that a Revo "feature" is in play: Everything that can run asynchronously and in parallel is doing so. The result is a responsive UI, but only if ones server can handle the high transient memory demand. Maybe there is a good, old-fashioned sparse allocation problem in the mix, too.

Since the MODX Manager is an example of the programming style that the underlying framework encourages (i.e., as much parallel, asynchronous processing as possible thrown at an interpreted, object-oriented language), the problem will continue to pop up. Cloud-based hosting, which is on the ascent for good economic reason, seems to have trouble with high transient memory allocation. Looks like a collision course.

Some of the memory problems reported in this forum were found to be looping memory leaks and resolved accordingly. That is not the case with the above described problem.

Service B advertises MODX suitability and expertise on http://modx.com/partners/hosting-saas/ . That's how I found them and why I pre-paid for three years of hosting with them. I sure hope it works out alright.

So, is this a bug report or a feature report?
===============
Update: The problem reported above seemed to have disappeared. (But it really had not. Keep reading.) I was unsure whether the hosting service had made some change or if recent version 2.2.7 -> 2.2.8 site upgrade had made a difference. For whatever the reason, the resource log showed that the Manager was no longer pegging virtual memory at my hosting service's two GB limit, and I was not encountering the bizarre Revo Manager behaviors.

Fantastic! So I went a step farther and turned on "Use Compressed CSS" and "Use Compressed JavaScript Libraries" once again. Sorry to report that the above-described behaviors re-appeared, and the resource log once again showed VM pegging at the two GB limit. Once again, the easiest way to induce the problem was to click on Package Management.

I found that enabling either of the compressions would induce the problems. Enabling both made problems more likely to happen. Disabling both, the problems disappeared. I found this entirely repeatable through several trials.

I'm glad for the improvement. Both Manager and site performance are quite snappy with the compressions disabled. I feel that I can now expose the site's content editing person to the Manager, which has not been practical since I changed hosting services in January 2013. In turn, I'm encouraged to move another of my sites to this hosting service.

I'll continue to encourage my hosting service and the MODX team to collaborate on this. If & when the compression options no longer cause problems, I will report that along with the identity of my hosting service, who is a MODX advertiser. I want this to get better, better, better, not make waves that cause anyone problems. [ed. note: halfnium last edited this post 10 years, 10 months ago.]

Thanks for sharing, Halfnium!

Your case describes very closely what happened to me. In my case, by expanding my physical memory limit to 256M and with a VM capacity of 1 GB I haven't experienced the problem again. But my site is still relatively small, since I haven't added many of the contents yet (and only a couple of test users are around at the moment), so I'm worried that the problem returns when my site starts using more resources after what you said.

(I also paid 3 years of hosting in advance, so let's all hope this gets solved soon.)

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

Cloud-based hosting, which is on the ascent for good economic reason, seems to have trouble with high transient memory allocation. Looks like a collision course.

That's quite an interesting statement. I have recently moved two sites to a cloud hosting platform https://www.tsohost.com/ and so far haven't experienced any such issues (touch wood). I don't know exactly how much cPanel is bound to other server configurations but I do know from reading the company blogs etc that when they developed their cloud platform they made a decision to ditch cPanel apparently due to some supposed limitations that the system imposed on the flexibility of the cloud platform.

I'm wondering if this is an inherent weakness of cloud platforms in general, or due to forcing an older server configuration system into a newer platform style.

I would GLADLY sacrifice some of the streamlined nature of the modx manager and have something more evolution like if it meant a slicker more stable product in the cloud. Just saying.