500 errors that redirect to requested page (appear to be for logged-in users)

Internal server errors (error 500) are often caused by plugin or theme function conflicts, so if you have access to your Dashboard, try deactivating all plugins. If you don’t have access to your Dashboard, try manually resetting your plugins (no Dashboard access required). If that resolves the issue, reactivate each one individually until you find the cause.

If that does not resolve the issue, try switching to the Twenty Nineteen theme to rule-out a theme-specific issue. If you don’t have access to your Dashboard, access your server via SFTP or FTP, or a file manager in your hosting account’s control panel (consult your hosting provider’s documentation for specifics on these), navigate to /wp-content/themes/ and rename the directory of your currently active theme. This will force the default theme to activate and hopefully rule-out a theme-specific issue.

If that does not resolve the issue, it’s possible that a .htaccess rule could be the source of the problem. To check for this, access your server via SFTP or FTP, or a file manager in your hosting account’s control panel, and rename the .htaccess file. If you can’t find a .htaccess file, make sure that you have set your SFTP or FTP client to view invisible files.

If you weren’t able to resolve the issue by either resetting your plugins and theme or renaming your .htaccess file, we may be able to help, but we’ll need a more detailed error message. Internal server errors are usually described in more detail in the server error log. If you have access to your server error log, generate the error again, note the date and time, then immediately check your server error log for any errors that occurred during that specific time period. If you don’t have access to your server error log, ask your hosting provider to look for you.

Thanks – my specific question was about how to get the 500 errors to show up in a log.

Right now, I am not seeing them in:

• the regular PHP error log (which I have enabled)
• the WordPress debug.log under wp-content (also enabled)
• the email notifications of fatal errors that are new to WordPress 5.2
• the Apache error log

I have access to all those and I have seen other fatal errors in them when they occurred.

Is there anything else I could do to try to get the error into a log?

If it’s not being saved to the server error log, then it’s not actually a 500 error. It could just be false “error” that’s being displayed.

All 500 errors hit the server error log _before_ being displayed.

The browser says something about “this page could not be displayed” before redirecting – typically that is a 500 error.

What other circumstances could cause that, do you think?

Ah no, a 500 error will say in big bold black letters “Internal Server Error (500)” usually with some extra text like “An internal server error has occurred.” Details: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_errors

“this page could not be displayed” generally means that PHP failed to render the page.

This may be a plugin or theme conflict. Please attempt to disable all plugins, and switch to the default Twenty Nineteen theme. If the problem goes away, enable them one by one to identify the source of the problem.

If you can install plugins, install Health Check. On the troubleshooting tab, you can click the button to disable all plugins and change the theme for you, while you’re still logged in, without affecting normal visitors to your site.

So are you saying the PHP “white screen of death” is not technically considered a 500 error?

In either case, my point is that the PHP errors, if that is what it is, are not being logged anywhere. Normally, when there are memory exhaustion issues with a PHP script, I can enable something to get that logged, but I don’t seem to be able to do that with WordPress.

Is there something with WordPress 5.2’s error handling that makes it harder to get the regular PHP fatal errors like “memory limit reached” into the logs?

So are you saying the PHP “white screen of death” is not technically considered a 500 error?

Correct, a 500 error is reported at the server-level as a 500 error. A white screen of death simply means that PHP crashed while attempting to render the page.

All server-level errors are logged in the server error log. If it’s not in the server error log, it’s not a server-level error. Specifically in this case, if a 500 error is not logged in the server error log, it’s not a 500 error.

Normally, when there are memory exhaustion issues with a PHP script, I can enable something to get that logged, but I don’t seem to be able to do that with WordPress.

You are correct, but depending at which point PHP crashed, it may not have been able to log anything. That’s one of the big differences between a PHP-level and a server-level error.

Is there something with WordPress 5.2’s error handling that makes it harder to get the regular PHP fatal errors like “memory limit reached” into the logs?

Nope, what you’re experiencing is a normal good old-fashioned PHP crash.

So again, this may be a plugin or theme conflict. Please attempt to disable all plugins, and switch to the default Twenty Nineteen theme. If the problem goes away, enable them one by one to identify the source of the problem.

If you can install plugins, install Health Check. On the troubleshooting tab, you can click the button to disable all plugins and change the theme for you, while you’re still logged in, without affecting normal visitors to your site.

Thanks – I haven’t been able to cause the error to happen again today. It seems extremely unpredictable – there’s not particular pages that I can visit that will reliably trigger it.

Did it start after making the site live, or after setting up WP Rocket?

I enabled WP Rocket within an hour or so of making the site live, to deal with the traffic, but I don’t recall seeing it before I enabled WP Rocket.

I have a ticket open with them, but since I can’t get more specific logging details they weren’t able to give me much guidance.

Unfortunately, I can’t really disable WP Rocket on live because some of the pages are too slow for a production environment without page caching, since they have so many queries / extensive use of a page builder (Elementor).

Have you considered testing with a different caching plugin instead? That would at least rule them out.

I’m thinking about switching to WP Supercache, since I actually had tried that before in development briefly, but we were recommended WP Rocket, and so we switched.

However, with some other caching plugins in addition to it, it seems WP Supercache might actually have been faster and more reliable, so it might be worth switching back.

The only reason I’ve stuck with WP Rocket so far is that we paid for it.