Documentation

500 Internal Server Errors

Last updated November 15, 2018

Sometimes when running a migration you’ll encounter a server error. These can show up as a “500 Internal Server Error”, “Internal Server Error”, “502 bad gateway” a 404 or 400 message or a combination of error message wording.

Oftentimes you will also get a similar response from WP Migrate DB Pro:

Our AJAX request was expecting JSON but we received something else.

Whatever these errors are named and however they occur, there is one commonality — they’re caused by something going wrong on your server.

What Causes Them

There are many reasons these errors occur, some of the common reasons we’ve seen shared by customers are:

  • Firewalls
    • One of the most common cases of server errors we see are errors caused by security measures. This can be a plugin like Wordfence, an Apache module like ModSecurity, or another firewall software.
  • PHP memory exhaustion
    • The PHP process requires more memory than is available on your server memory and crashes.
  • Serialized data
    • Similar to memory exhaustion, sometimes your wp_options table will have a large chunk of serialized data in one of the records. While running the find & replace on this record the PHP and/or MySQL process may crash.
  • MySQL server errors
    • Sometimes your MySQL server may crash due to errors in the database (duplicate unique keys, corrupt data).
  • Syntax error
    • Sometimes plugins and/or themes can contain PHP syntax errors or use incorrect coding practices. These can lead to PHP warnings and notices to be generated.
  • Outdated PHP version
    • Similar to syntax errors, an outdated PHP version (especially < PHP 5.4) can cause errors in plugins and/or themes that don’t support outdated PHP versions.

Fixing Errors: Where to Look For Clues

In every scenario above, the best place to look for clues on what went wrong is your server’s error logs. If you’re using a managed WordPress host like WP Engine, Flywheel or Kinsta, there should be an area in your host’s admin panel where you can find error logs.

If your web host provides a control panel like Plesk or cPanel to manage your server, there will also be section to download or view your error logs.

If you can’t find your error logs or they are empty, follow up with your host to see if they can help you track them down.

Without specific information about the error that occurred it’s extremely difficult to solve migration issues.

We’ll ask for these logs in support when we see that you’re encountering a server error, so please send them with your initial request to speed things along 🚤!

PHP Specific Errors

In your local development environment enabling error reporting and logging can help you catch any errors before they’re pushed to production.

To enable error reporting locally, in your php.ini file add (or uncomment) the following:

error_reporting = E_ALL
display_errors = On

If you’re using something like MAMP or Local By Flywheel locally these should already be set.

On your production server you’ll want to keep display_errors = Off but enable log_errors.

log_errors = On
error_log = ‘/path/to/logfile’

WP_DEBUG_LOG

For WordPress-specific errors you can enable WP_DEBUG and WP_DEBUG_LOG as well. This will report PHP errors that occur during WordPress’ execution.

In your wp-config.php file add the following to enable logging:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

When WP_DEBUG_LOG is enabled, a file located at <webroot>/wp-content/debug.log will be created and PHP errors will be logged when they occur.

To ensure error aren’t also rendered on the page you can also add the following to the wp-config.php file:

define('WP_DEBUG_DISPLAY', false);

It should be noted that because the debug.log file is located in the wp-content this file will be publicly accessible. Caution should be used when enabling this setting in production environments.

It is highly encouraged to enable WP_DEBUG in your development environment so that PHP errors can be caught early.