Who is the host? Have you talked to them?
Host is MediaTemple; they say ask WordPress.
Help.
What kind/cost of hosting account? Did you specifically ask them to help raise PHP memory?
Rename the plugins folder with FTP to deactivate all plugins. https://codex.wordpress.org/FAQ_Troubleshooting#How_to_deactivate_all_plugins_when_not_able_to_access_the_administrative_menus.3F
Instead of 64M, try 128M. Just to see if it’s really a memory issue, or if your system isn’t letting you raise the memory limit.
Sorry I didn’t clarify; when I say I’ve tried the cut-and-paste response Mods give to users about memory limits, I also mean I’ve tried other correlating numbers that users have used to resolve their memory limit errors i.e. I’ve tried 38, 64, 128.
To clarify, .htaccess has php_value memory_limit 128M;
/etc/php.ini can have the memory limit set or not, and this usually produce the blank/white screen;
changing wp-config.php seems to have the least (as in no) effect.
The challenge is that /wp-admin/ is inaccessible, blank, or riddled with errors, so I cannot ‘Deactivate’ plugins; I can remove/rename them via FTP but it’s my understanding this maintains their activation inside WordPress, that they’re just gone, not deactivated.
Going that route I can access /wp-admin/ but as soon as I kick the theme back on the fatal errors reappear, and bounce around, from file to file, line to line.
I’m lost.
Luckily this is a website that barely gets 10 hits/day, but no way am I upgrading other domains or clients that have 1-10k/hits day, if I can’t figure this out.
Any help is appreciated.
I have a support request into the host regarding a known issue with the theme; but my fatal errors are not reported by other users of the theme. Host says average response time is 20 hours, so standing by. (btw I’m on Grid, have been for 10 years with no problems like this)
that they’re just gone, not deactivated.
They are force-deactivated when they don’t exist, and don’t use memory.
If theme activation causes the memory errors, than it’s a good chance it’s the theme. Which theme?
But the main issue may be that some hosts don’t allow memory overrides via those methods; you’re stuck with what they give.
Again, another clarify. Right now the theme is active, and the website is live; the theme relies on 7 plugins, 6 are optional, one is required; right now everything is stable, visible, no errors.
There is however a quirk in the theme ‘upgrade’ process that requires
mbstring.func_overload = 0
This is the support request I currently have into the host, to confirm – and if necessary, to set – the setting.
Because when I initiate the theme upgrade, the fatal errors kick in; but they are all over the place, which I can’t pin down. At this point I have to remove the theme folder, rename the plugins, etc. to reset the site to some semblance of operation.
So if there’s any known correlation between
mbstring.func_overload = 0
and fatal errors, I’d love to try and troubleshoot that while waiting for the host to respond. I apparently cannot set that setting from within php.ini, contrary to some docs online.
Cheers.
I apparently cannot set that setting from within php.ini….
You can’t on shared system like Grid. Wait for MT to get back to you.
Thanks for the tip. Standing by. I’ll post my findings here when I know more.
Cheers.
Implementing this setting in php.ini has at least made the fatal errors not creep up during theme ‘upgrade’:
max_input_vars = 5000
Hope this helps someone else. I’m still waiting for further resolution before marking this topic resolved.
Thanks for your patience and assistance.
