New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
There is a possibility that there was an issue with a wordpress plugin that could have been fixed by an automatic update of the system.
No- wanted to do that if the site did go offline again. And today the site is working perfectly. (of course). Have had a really busy day today, so did not have the time for reading logs.
But if the site gets the 500 HTTP error again, I will try the renaming of plugin folders and read the logs.
Dude..., you have yet to check the error log? People have been telling you to check the logs first from the first post...
No, You are using CSF? (If yes then you use process "kill" option in configuration?)
I know, but did not have the time today. And the site is working fine just now.
Yes, we are using CSF.
The end must be nigh...
Am I the first here to realize that error logs are stored for some time and that OP can easily look through the error logs to see what happened the last time the server panicked?
Check your logs.
[email protected]
Open a ssh terminal and type reboot
[email protected]
when did LET turn into fortuneteller forum? We're trying to guess what the error is and hope it's right? without checking the logs?
This, but also worth noting 500 errors can occur at application level and then Apache will have logged nothing relevant. It logs something relevant if it's the server or config, but does not if it's the application. Increased PHP logging can handle the other, usually.
Sometimes, still, the app just crashes the PHP process that it spawned and nothing useful is logged. Then you have to strace. That's more rare though.
OP doesn't want to check the logs. ("I am too busy to check.")
So, we, LET Wizards, must use magic to solve his issues.
Today the site was down again.
I think you deserve my reward since you was the first to mention this. It was not the plugins, but it was the theme. They used a custom theme somebody have made for them (or it's from a template site or something).
I used the same approach on the theme folders after I had done it on all plugins.
Renaming each theme folder one at the time.
And then the site got online - at least I could log in to wp-admin.
I did try renaming all plugins to their original name, and used a standard theme, and then everything is working. If I rename the theme folder to it's original name, the site gets the 500 HTTP error right away.
Then I really know whats going on - and can charge the customer for my time I have used on this issue - and can tell the customer that they need a new theme, or a fix on their old theme. But the creator of the theme is not updating it anymore - not for years.
@Coffee - pm your paypal account and I will transfer the money.
[email protected], thx
interesting. you narrowed it down, but you still didn't identify the real issue.
I understand that might be enough for your case, but I'd say you spent more time probing around the real issue than what properly analyzing the log files would have been.
did the 500 error occur because something got updated automatically/manually which then breaks things or because there is an unpatched security hole which gets exploited again and again?
while one might agree that error isn't an issue on your end, you still should be interested to not have hacked wp sites on your shared hosting environment, at least to protect other customers.
so if it's a security problem I think it still touches your responsibility. just saying...
let's agree that this was the biggest BS statement in this thread anyway.
My guess at this moment, after more information was provided, is that @Falzo has a good point.
If the site has been working with an old template, which hasn’t been updated and all of a sudden goes 500. I would check if some server updates has been done.
Change of php version as one example...
But if this was the case - why do the site work perfectly after we restore the backup? Sometimes for days - before we get the 500 HTTP error.
If it had been a server update and a issue with the theme, it should not work at all. We are not restoring a server backup - just an account backup. (cpanel)
And it's impossible to upgrade the theme - the last update was released in January 2016 it's seems, and now you can't even download the theme.
But when you restore is it restoring a theme or plugin to old version then automatically updating a few days later he certainly the cycle
Check logs carefully, don't restore the backups, You are evading the problems for few days. It should contains some information than source of error. Also, you mentioned that when you rename the problematic theme folder and changes the active theme, it works but when you change theme folder's name back, it doesn't.
Do you also activate the same theme? Because it shouldn't cause any error even if it is not compatible if it is not active until it's being reference somewhere specifically!
So, again, check logs (carefully). But since you've told the client the source and it isn't managed support, you can leave it upto them.
If it is a function in the theme that breaks the site it could happen after you visit a specific type of page/post/custom post type.
If you can select a php version for that specific customer on your hosting server, try an older version.
If the site works, check whats different between those php versions. What functions have changed, etc.....
Depends on how much time you want to put on the customer. Easiest way out of this is to tell te customer to change/update their site.
If they move to another server and it works there, you will look like a fool in the eyes of the customer.
But it's impossible to get new updates to that theme. The last update was January 2016. You can't even download the theme anymore - they have removed it from WordPress themes - and the site to the developer is gone.
When the site gets the 500 HTTP error, you can't even access wp-admin. When I then rename the theme folders, I can access the wp-admin page, so I can change the theme to another.
But if I just press preview on the old theme (with the renamed folder, but it's still available in the theme section in WordPress) - I get the 500 HTTP error.
But so long as I don't activate the old theme, the site is not getting thee 500 HTTP error.
If I restore the backup - the site has no issues using the old theme, for a day, sometimes some days - before you get the 500 HTTP issue again.
Just for fun (can't charge the customer for it) I will do just a file restore, and not a complete account restore, of the old theme, just to see if it then also will work for some days.
Maybe some of theme's dependency such as a plugin is getting updated?
Also, why not to run a comparison between files/db from backup and account?
Also, why not to run a comparison between files/db from backup and account?
I did now restore just the theme folders. Did not touch any of the plugins or any other file on the site. And then the old theme is working perfectly again - both using preview of the theme and also activating the old theme.
I did not use cpanel backup restore, we have a .zip file from 2016 with the whole site on it, and I just uploaded the theme folders via File Manager on the account.
So if it had been a issue with any of the plugins, that's all updated to the newest version - it should not had been working just restoring the theme files?
So it's clearly something that happen with the theme folders/files when it's activated on the site after a few days
^True
@mhyken With the website owner permission, copy the entire website files & db into different hosting. You can install it on any random subdomain and manually set the site address on wp-config.php. Don't forget to block SE bot in robot.txt.
This is the laziest step I did before digging into webserver configuration.
I really can't understand why you don't want to take a look at the logs, where you can find the details of the real problem, instead of experimenting and guessing...
Exactly!
this is quite weird, because the admin-area shouldn't rely on the foreign theme folders at all. I'd suspect a permission issue or some weird caching crap, esp. if the admin-area gets (partially) cached too. is there something like redis/memcached involved? wp total cache?
have you tried just pruning the cache (if any) via console?
I agree to the suspicion that it's most likely not an server issue here.
very good to have backups from which you can help and restore the client - he probably does not even know how lucky he is.
this, if accessible via shell you could run a simple find -mtime to see which files might have changed right before the 500 happens and then check what exactly changed with them.
also the error.log could have further hints, or you could check/active extended php-logging etc. but that's already been stressed enough ;-)
It does sometimes in WordPress from what I've seen. Coding or compatibility issue with theme might result in white admin area.
have you tried just pruning the cache (if any) via console?
No cache plugins or settings on the site is enabled. And when I get the 500 HTTP error, I try to load the site in multiple browsers, on different computers, with privacy mode.
And as soon as I replace the 1 MB of data in the old theme folder, the 500 HTTP error goes right away with first reload of the site.
I can now also trigger the issue - just replace the old theme folders with the data from after the site got the 500 HTTP error today - then the site gets the 500 HTTP error if it using the old theme.
If I'm using other themes, then replace the old theme folders with the data from after the 500 HTTP issue - it has no affect on the site.
But if I then enable the old theme or try preview - the site gets the 500 HTTP issue.
If I then replace the old theme folders with the .zip file from 2016, then everything works fine, both activating the old theme or just preview it.
keep figthing with word my man. without log this will going nowhere