Right …
Deja Vu
This is exactly what went wrong at CycleClubMembers too. Which was the project that Options4All merged into during October 2015. And it was 1 of these problems (and a couple of others mentioned here), that made me decide to pull the plug on it. And focus on income producting activities instead. But I’m back … and things were going okay, until this error popped up (again):
https://www.facebook.com/teamconnectgiveshare/photos/a.519648364870154.1073741828.505733982928259/519648348203489/?type=3&theater
What is a “500 Internal Server Error” ?
One of the most vague errors out there. As it can be literally EVERYTHING!
The probable cause
72 hours ago, for some odd reason when I tried to upload some php scripts; I suddenly was staring at file tree on FTP of a month ago. Darn probably a server crash and the hoster forgot to notify me about it. Or … my own poor mistake of working 16-18 hours per day. Not a biggy! Had a backup! But only of the plugins folder only Database was still intact, managed to upload some files, and that’s when the problems really started; both frontend and admin backend giving the error. Darn! How to fix it? Without starting from scratch … again?!
Problem Elimination / Troubleshooting
So what have I tried thus far?
Disabling a couple of plugins?
Running a slim downed configuration again of ‘only’ 57 active plugins and currently 40 inactive plugins Not that strange is it? That things don’t really work as planned. :) And yes I need all those plugins; determined to make it work! But what’s so odd about it, how things worked great before getting some sleep.
But yes … the only way I could gain access 48 hours ago was to disable all WordPress plugins from within mysql again. To see which ones you got running:
SELECT * FROM wp_options WHERE option_name = 'active_plugins';
And to disable all of them (if you got WordPress version higher than 2.9 and you probably do as we are currently as WordPress 4.4). Then the code snippet you need for that is:
UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';
Where “wp_” WordPress Table Prefix, might be something you have to replace by your own predefined when you run all kinds of anti-hack modifications. Was able to login again and reactivate most of my plugins … for the problem to come back again. So it’s a plugin conflict? Myeah … feels like something else.
Note: As just before I disabled all the plugins I found out I could login into my wordpress admin backend just fine from my iphone and tablet. Never had that happen before! But looking back I should have considered that an important clue! More about that later …
Edit wp-config.php for debugging
Added in a couple of lines based on the info at http://codex.wordpress.org/Common_WordPress_Errors
define('WP_MEMORY_LIMIT', '256M'); //hack define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); //logging content to /wp-content/debug.log define('WP_DEBUG_DISPLAY', false); @ini_set( 'display_errors', 0); @ini_set( 'upload_max_size' , '64M' ); @ini_set( 'post_max_size', '64M'); @ini_set( 'max_execution_time', '400' );
These values were incremented slowly btw, as 256MB is WAY too high. By default it’s around 32MB; and suffices for most WordPress environments. 40-64MB is normal for woocommerce sites. 128MB is exceptional. Anything higher? Usually isn’t even possible at shared hosting, hence my surprise it was for me. Tip: Helpful plugin btw (which is the equivalent of coding a phpinfo() yourself when you know a little about php): https://wordpress.org/plugins/wordpress-php-info/
And concerning I do have to run forced https connections with woocommerce and running — at the moment — flexible SSL on cloudflare, I read at https://docs.woothemes.com/document/ssl-and-https/ it would be smart to already setup:
if (isset($_SERVER) && $_SERVER == 'https') $_SERVER='on';
And while at it …. picked up a few new tricks at http://codex.wordpress.org/Editing_wp-config.php
#define( 'EMPTY_TRASH_DAYS', 7); # Disable all automatic updates: #define( 'AUTOMATIC_UPDATER_DISABLED', true ); # Disable all core updates:
Which I will enable later. But … did that solve my problem “500 Internal Server Error”-problem? Nope. :( And nothing spectacular going on in the logfile either.
Edit .htaccess file
A ton of stuff was in there due to iThemes Better WP Security configuration changes and … “WP Fastest Cache”. The latter being a hidden gem as a WordPress caching plugin. Beats WP Super Cache and Zencache. Which is confirmed by a 100% 5-star rating at https://wordpress.org/plugins/wp-fastest-cache/
But …
Caching issue then?
- Played around with CloudFlare settings till I dropped, but not much of a change. So it must have something to do with some kind of caching plugin then for sure?
- Then removed the aging parameters in .htaccess (which are so important for increasing your GTmetrix Score; a SEO thing ). Things improved. But still getting random 500 Internal server errors.
- Then I went over the WP Fastest Cache settings and during … and my eye caught something:
That explains my earlier findings earlier. So that means it’s definitely a caching issue! Also further down:
So disabled that too. And just to be on safe side? Disabled all caching all together … for now. A working website is better during development stages than a faster site.
And that seemed to have solved most of the frontend issues!
Couple of other ‘fixes’ I still have to checkout …
As the 500 errors have now moved to the backend it seems, which is not a great thing, considering members can already register during prela
Cpanel PHP settings?
Interesting read is this article: http://www.inmotionhosting.com/support/edu/wordpress/wp-fixing-500-internal-server-error
Can’t alter the PHP version. But did see MIME types with compression turned on by default. That could explain conflicts with htaccess? Hmz
Reupload the WordPress core files
Based on what was mentioned in this article: http://www.wpbeginner.com/wp-tutorials/how-to-fix-the-internal-server-error-in-wordpress/
Further study the Apache logfiles in Cpanel
Could still be a file or folder access problem.
OR … something else?
Conclusion: Is it worth all the ‘hoopla’?
Yes, in my case it is. As I have some pretty big plans with my current self-hosted WordPress platform. As it’s so many things, as you can also read at the current frontpage. But will do an article on managed wordpress hosting next month that you might find interesting to read, when you like to make money blogging (read: share content that’s might entice people to engage with you).
For now? I’m happy again to be able to share great content with the planet.
Update 22Jan16: fixed! turned out the shared hosting platform had a limit of 128MB after all (no matter what the php overrides said). Migrated to a #beastmode VPS again. Which solved a whole bunch of nuisances. Might blog on that later.
P.S. like to hire me to fix your WordPress issues? Keep an eye out on the https://blog.computernerdinside.com/shop/
- My Dutch / NL WordPress Translation contributions: October 2022 - October 9, 2022
- My Dutch / NL WordPress Translation contributions: August 2022 - August 23, 2022
- [NL] Ultra Light digital nomad Europe travel with Ryanair / Wizz Air - August 20, 2022
- My Dutch / NL WordPress Translation contributions: July 2022 - July 27, 2022
- My Dutch / NL WordPress Translation contributions: April 2022 - April 2, 2022
- My Dutch / NL WordPress Translation contributions: March 2022 - March 10, 2022
- What is the best global travel community for 2022 ? - February 20, 2022
- My Dutch / NL WordPress Translation contributions: February 2022 - February 3, 2022
- My Dutch / NL WordPress Translation contributions: January 2022 - January 4, 2022
- My Dutch / NL WordPress Translation contributions: October 2021 - October 7, 2021