Bug #1848
closedHaving Issues with Saving Menu Changes on the Commons Codex
Added by scott voth over 12 years ago. Updated over 12 years ago.
0%
Description
Hi - I've tried numerous times to save menu changes on the Codex, but when I do the save request fails. In Firefox, I just get a blank screen. In Chrome I get a message popup "Server Error" (HTTP 500). This all started when I was adding some items to the menu using drag and drop, and somehow lost the last 5 items. Then I put them back, but the last correction I wanted to make never seems to save. I was wondering if someone could take a look - maybe at the log - to see what's keeping it from updating. Thanks. I have attached a screenshot of the error I get in Chrome, below. I am using the builtin WordPress Menu function, and have a lot of items (maybe around 80).
Codex - http://codex.commons.gc.cuny.edu
Files
serverError.JPG (31.3 KB) serverError.JPG | scott voth, 2012-04-22 12:59 PM |
Updated by Matt Gold over 12 years ago
- Status changed from New to Assigned
- Assignee set to Boone Gorges
- Target version set to 1.3.13
Updated by Boone Gorges over 12 years ago
Scott, this appears to be a memory problem - when I put in some debug traces, I found that about 65 of your 76ish menu items were being saved.
I tried to nudge up the WP_MEMORY_LIMIT variable, to see whether it would make a difference, but it didn't seem to have any effect. André, I've added you as a watcher so that I could ask two questions: (1) Is there something in our php.ini that would be disallowing WP to override it? The value appears to be fixed at 64M. If so, would you mind removing the restriction (or even upping the memory limit temporarily, maybe to 96M, just for testing)? (2) What do you think of increasing the memory limit globally and permanently? If we have the resources, we should use them - RAM is the bottleneck for WP sites, and we could probably improve page load time with a higher memory limit.
Updated by local admin over 12 years ago
The purpose of that directive is, as per http://www.php.net/manual/en/ini.core.php#ini.memory-limit, to:
"prevent poorly written scripts for [sic] eating up all available memory on a server."
Fortunately (since we don't have to worry about that ;) the setting can be disabled by setting the value to -1.
I changed it now so please give it a shot and let me know if it helped?
If we notice any adverse effects of this change I can always change it back to something else.
Updated by Boone Gorges over 12 years ago
Hi André. Thanks for your help. I tried again but ran into the same 500 error. Did you restart Apache so that the new settings would take effect?
Related, I'm flying a bit blind. Does the commons user have access to the PHP error log? Maybe PHP errors are not being logged at all? Would you mind setting the PHP error reporting level to E_ALL http://www.php.net/manual/en/errorfunc.constants.php, and putting error messages into a log file that the commons user can tail?
Updated by local admin over 12 years ago
Boone Gorges wrote:
Did you restart Apache so that the new settings would take effect?
Yes, I did.
Related, I'm flying a bit blind. Does the commons user have access to the PHP error log? Maybe PHP errors are not being logged at all? Would you mind setting the PHP error reporting level to E_ALL http://www.php.net/manual/en/errorfunc.constants.php, and putting error messages into a log file that the commons user can tail?
I thought this stuff was always logged to /var/log/httpd/error_log, no?
Updated by Boone Gorges over 12 years ago
I don't appear to have access:
[commons@commons log]$ ls -la /var/log | grep httpd drwx------. 2 root root 4096 Apr 22 03:40 httpd
Updated by local admin over 12 years ago
Boone Gorges wrote:
I don't appear to have access:
[...]
That's on the folder, but the file itself is world-readable. But hey, I took a look at it and it seems like it still not respecting the php.ini
setting:
[Mon Apr 23 11:09:11 2012] [error] [client 157.55.16.230] PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 122880 bytes) in /var/www/html/wiki/includes/parser/Parser.php on line 2387
Let's test it one more time... meanwhile I'll see what I can do to get the setting to work.
Updated by Boone Gorges over 12 years ago
the file itself is world-readable
Here's what I get:
[commons@commons www]$ tail -f /var/log/httpd/error_log tail: cannot open `/var/log/httpd/error_log' for reading: Permission denied
Updated by local admin over 12 years ago
Boone Gorges wrote:
the file itself is world-readable
Here's what I get:
[...]
That's odd. I'm not sure why... meanwhile I reset the permission over the whole /var/log
directory for you:
[root@commons ~]# setfacl -R -m u:commons:rx /var/log/
..and now it looks ok:
[root@commons ~]# su - commons [commons@commons ~]$ tail /var/log/httpd/error_log [Mon Apr 23 12:09:19 2012] [error] [client 88.0.43.178] PHP Warning: Parameter 1 to Language::getMagic() expected to be a reference, value given in /var/www/html/wiki/includes/StubObject.php on line 58, referer: http://es.search.yahoo.com/search?p=%282002%29+Using+portfolios+to+assess+the+writing+of+ESL+students%3A+a+powerful+alternative%3F+Journal+of+Second+Language+Writing%2C+Volume+11%2C+Issue+1%2C+February%2C+49-72&ei=UTF-8&fr=moz35 [...]
Updated by Boone Gorges over 12 years ago
Cool, I can tail it now - thanks André :)
Strangely, though, when I test original problem, the process was killed, but I didn't get anything in the error_log at all - no Fatal Error of any kind. Back to the drawing board...
Updated by local admin over 12 years ago
I would love to help troubleshoot this. It may still be another server setting and I would not want to delay you unnecessarily.
We could connect via phone or IM to do it live. I have some time today.
Updated by Boone Gorges over 12 years ago
Thanks very much for the concern, André. I'm going to take a little more time to see if I can narrow it down the issue any further - I want to rule out one or two WP-level issues. If I can't make progress, I'll let you know.
Updated by Boone Gorges over 12 years ago
I did a bit more debug, and it definitely looks like this is a memory_limit issue. I ran a trace using PHP's memory_get_usage(), and confirmed that execution is getting killed around 256M.
FWIW, it's due to a crappy implementation in WP. See https://core.trac.wordpress.org/ticket/14134
I did try increasing WP's memory limit to 512M for testing. I tried two techniques, neither of which seemed to have any effect:
define( 'WP_MEMORY_LIMIT', '512M' );
and
ini_set( 'memory_limit', '512M' );
In both cases, the timeout still happened at 256M, and ini_get( 'memory_limit' ) returned '256M'. André, I guess that means that your php.ini change didn't stick. Would you mind changing it manually to a higher number (instead of -1) just for the time being?
Updated by local admin over 12 years ago
Ok, let's try 1024M. Just restarted now...
Updated by Boone Gorges over 12 years ago
Hey André. Still no dice - ini_get( 'memory_limit' ) is still returning '256M', both before WP launches and after it's initialized. Somehow the ini change isn't sticking.
Updated by local admin over 12 years ago
That's odd because php_info()
is reporting the correct memory:
[root@commons ~]# php /var/www/status/php.php | grep memory memory_limit => 1024M => 1024M
I wonder if the script is constrained by some other memory...
Updated by Boone Gorges over 12 years ago
André, can you try to su to the commons or Apache user? PHP supports .user.ini files that may be sneaking in there somewhere. (This is a total guess :) )
Updated by local admin over 12 years ago
Boone Gorges wrote:
André, can you try to su to the commons or Apache user? PHP supports .user.ini files that may be sneaking in there somewhere. (This is a total guess :) )
Same thing:
[commons@commons ~]$ php /var/www/status/php.php | grep memory memory_limit => 1024M => 1024M
I wonder what other setting could be constraining this... Is there a test script I can run to see if further changes help? How do I best test this?
Updated by Boone Gorges over 12 years ago
- Status changed from Assigned to Reporter Feedback
Heh.
So, I had another look. Turns out that (1) WP was being annoying/tricky/buggy, and (2) I spoke too soon when I said that the 'memory_limit' setting wasn't sticking.
When I was debugging, I tested against WP_MEMORY_LIMIT and ini_set(). But I didn't know about this: https://core.trac.wordpress.org/browser/trunk/wp-admin/admin.php?annotate=blame&rev=19097#L108 In other words - when you're viewing the Dashboard (any page inside of wp-admin), any memory limit you've set at runtime is overridden. This is not well documented. In fact, given that it was originally introduced to allow for higher memory use on the Dashboard https://core.trac.wordpress.org/changeset/14491, I think it's a bug - before overriding the more general WP_MEMORY_LIMIT with 256M, it should make sure that WP_MEMORY_LIMIT is not already greater than 256M.
Anyway, I set the 'WP_MEMORY_LIMIT' to 512M in our production environment file, and the menus are now saving correctly. Scott, can I ask you to verify before closing the ticket?
André - many thanks for your help. If it's OK with you, let's keep the memory_limit as-is, and monitor memory use (I'm a bit worried that a couple dozen simultaneous connections could cause problems, but I'm sure you run Munin or something to keep an eye on it).
Updated by local admin over 12 years ago
Boone Gorges wrote:
André - many thanks for your help. If it's OK with you, let's keep the memory_limit as-is, and monitor memory use (I'm a bit worried that a couple dozen simultaneous connections could cause problems, but I'm sure you run Munin or something to keep an eye on it).
You're welcome. Yes, that approach sounds fine.
Updated by scott voth over 12 years ago
Awesome! You guys are the best. Just confirmed that it is saving properly. Thanks!
Updated by Boone Gorges over 12 years ago
- Status changed from Reporter Feedback to Resolved
I think we all learned a little something :) Thanks for the confirmation, Scott.