Try restarting httpd; most of the time, that’s not necessary for php changes. But sometimes they are needed for httpd to reload php.ini. Or, reboot the whole linux instance.
There’s a chance I’m missing something, but on Ubuntu calling “services apache2 restart” is correct way to restart apache, correct? I did that after each change I made and it didn’t have any effect. I’ll try restarting the instance.
I rebooted the server with no change.
How can I determine exactly what configuration file this setting is being imported from? From what I understand, once a variable is set in WP it can’t be overridden by a later configuration file, hence why this setting needs to be higher in the wp-config.php file than the import. But, I’m doing that. Where else could it be coming from?
Also, what’s the likelyhood that this has something to do with how Ubuntu 14.04/Apache 2.4 works (I’m fairly certain EC2 has nothing to do with it, it’s just an Ubuntu image, so any issues involved are Ubuntu related, as if I was running Ubuntu in a VM on my own machine)
Thanks,
Dave
I’ve just found a clue – when I changed the value in the default-constants.php file, it finally updated the value.
Why would wordpress ignore the memory value set in 1) wp-config.php 2) php.ini and 3) .htaccess and rely on the default value?
Did you have the define line in wp-config.php at the top of the file? Above the other functions? Sure your php.ini file was being read and other php.ini files were enabled in the main php.ini?
See http://wordpress.stackexchange.com/questions/3305/how-to-use-more-than-256mb-of-memory-in-the-admin and https://core.trac.wordpress.org/ticket/29341
Turns out I’m asleep at the wheel!!!
Lesson learned: There’s an important difference between WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT
Thanks for helping me work through it
Good that it worked. WP_MAX_MEMORY_LIMIT is fairly new and I didn’t know about it for a long time.
