Common WordPress errors and fixes: a step-by-step guide

Introduction

WordPress powers nearly 45% of the web, but that ubiquity comes with a price: you'll encounter errors. Whether you're managing a client site, building custom plugins, or scaling a WooCommerce store, knowing how to diagnose and fix common WordPress errors and fixes is essential to maintaining uptime and user trust. This guide walks you through the most frequent issues you'll face in production and how to resolve them systematically.

White Screen of Death: Enable Debug Logging

The white screen of death (WSOD) is WordPress's way of saying "something broke, but I'm not telling you what." You'll see a blank page, no error messages, nothing. This typically happens when a fatal PHP error occurs and error reporting is disabled—which is the default in production environments for security reasons.

Why it happens: A plugin, theme, or custom code triggers a fatal error. WordPress catches it but doesn't display it to prevent exposing sensitive paths or database information to visitors.

How to fix it: Enable debugging by editing wp-config.php. Add these lines before the line that says /* That's all, stop editing! */:

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

The WP_DEBUG_LOG constant writes errors to /wp-content/debug.log instead of displaying them on the front-end. The WP_DEBUG_DISPLAY set to false prevents errors from showing to visitors—critical in production.

Once enabled, trigger the error again. Check wp-content/debug.log via SFTP or your hosting file manager. You'll see the exact line and function causing the issue. Common culprits: undefined array keys, calling methods on null objects, or incompatible PHP versions in plugins.

Real-world scenario: A client's site goes white after activating a popular SEO plugin. You enable debug logging, find that the plugin references a function removed in PHP 8.1, and either update the plugin or disable it pending a patch.

Error Establishing a Database Connection: Check Credentials

This error appears when WordPress cannot reach the database. It's one of the most common issues, especially after migrations, server moves, or credential changes.

Why it happens: Incorrect database name, username, password, or host; the database server is down; the database user lacks sufficient privileges; or the hosting firewall blocks the connection.

How to fix it: Start with wp-config.php. Verify these constants:

define( 'DB_NAME', 'wordpress_production' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'your_secure_password' );
define( 'DB_HOST', 'localhost' ); // or your RDS endpoint

For each value, cross-check against your hosting control panel or database management tool (phpMyAdmin, AWS RDS console, etc.). A single character wrong breaks the connection.

If credentials look correct, test the connection independently. SSH into your server and run:

mysql -h localhost -u wp_user -p wordpress_production

Enter the password when prompted. If this fails, the database server is unreachable from your web server. Contact your hosting provider or check your database security groups (especially if using AWS RDS or similar managed services).

If you're using a remote database, verify the host address. Some hosting providers use internal hostnames for local connections and external endpoints for remote access. Also check that your database user's host setting allows connections from your web server's IP address.

Real-world scenario: You migrate a site from shared hosting to a Docker container. The database host remains localhost, but the database runs in a separate container. Change DB_HOST to the container's network alias and the error resolves.

Memory Exhausted: Raise Limits or Fix the Plugin

The error "Allowed memory size of X bytes exhausted" means a process consumed all available PHP memory. WordPress has a default of 40MB, but themes, plugins, and large dataset operations can exceed this quickly.

Why it happens: A plugin loads entire database tables into memory; a poorly written loop never exits; image processing operations (resizing, creating thumbnails) are memory-hungry; or legitimate growth in your site's complexity demands more headroom.

How to fix it: First, increase the memory limit in wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

The first constant sets the limit for normal WordPress operations. The second allows background tasks (cron, REST API) to use more memory. Start by doubling your current limit and monitor.

However, raising the limit is a band-aid, not a cure. You must identify the culprit. Enable debugging as described above and look for the line that consumes memory before the exhaustion error. Common offenders:

• Backup plugins: Creating full-site backups in-memory instead of streaming to disk.
• Report generators: Pulling all posts/orders for a date range into one array instead of pagination.
• Image processors: Batch processing uploaded images without garbage collection between iterations.

Once identified, fix the plugin code. For pagination example, instead of:

$all_posts = get_posts( array( 'numberposts' => -1 ) );
foreach ( $all_posts as $post ) { /* process */ }

Use:

$paged = 1;
while ( true ) {
  $posts = get_posts( array( 'numberposts' => 100, 'paged' => $paged ) );
  if ( empty( $posts ) ) break;
  foreach ( $posts as $post ) { /* process */ }
  $paged++;
}

Real-world scenario: A WooCommerce client's order reports plugin crashes when generating annual summaries. You find it fetches 50,000 orders at once. Implementing chunked processing with 500-order batches and proper garbage collection allows the report to complete in 256MB.

Too Many Redirects: Check URLs and HTTPS Settings

Your browser shows "too many redirects" or hangs indefinitely. WordPress is caught in a redirect loop, where page A redirects to page B, which redirects back to A (or a chain of similar redirects).

Why it happens: Mismatched WP_HOME and WP_SITEURL constants; HTTPS/HTTP mismatch where non-SSL traffic redirects to SSL indefinitely; a plugin or rewrite rule creates circular logic; or multisite configuration conflicts.

How to fix it: Check your wp-config.php for these constants:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Both should match exactly, including the protocol. If they differ, WordPress redirects between them endlessly. Additionally, they should match what's stored in the database (Settings → General in the admin panel). If you hardcode them in wp-config.php but the database has different values, you may see unexpected behavior.

For HTTPS issues: if your server redirects HTTP to HTTPS (good practice), but WordPress is still configured for HTTP, the initial page load redirects to HTTPS, WordPress then redirects again due to its configuration. Ensure both your server and WordPress use the same protocol.

Check your `.htaccess` file for problematic rewrite rules. A rule that matches everything and redirects creates instant loops:

RewriteCond %{REQUEST_URI} ^/old-path/(.*)
RewriteRule ^(.*)$ https://example.com/new-path/$1 [R=301,L]
RewriteCond %{REQUEST_URI} ^/new-path/(.*)
RewriteRule ^(.*)$ https://example.com/old-path/$1 [R=301,L]

Obvious in this example, but in real code with many rewrite rules, such conflicts hide easily. Review the order of rules and ensure no rule matches its own output.

Real-world scenario: You migrate a site to a CDN. The CDN strips HTTPS before sending traffic to origin, but your origin server redirects all HTTP to HTTPS. Add a header check: only redirect if the request doesn't come from the CDN (which sets a custom header to indicate the original protocol).

Common Mistakes

• Leaving WP_DEBUG enabled in production: Exposes file paths and sensitive data. Always set WP_DEBUG_DISPLAY to false and log to file instead.
• Assuming the error message is always correct: A "database connection" error sometimes means a plugin can't run a query, not that the connection failed. Check the debug log, not just the user-facing message.
• Raising memory limits without investigation: If you keep increasing the limit indefinitely, you're masking a broken plugin. Profile memory usage with tools like Blackfire or Query Monitor to find the real issue.
• Forgetting to clear caches after fixes: You fix a redirect loop, but your browser cache or a caching plugin still serves the old redirect. Hard-refresh your browser and flush WordPress cache (if using a cache plugin).
• Changing only one of WP_HOME/WP_SITEURL: Both must match. Partial updates create redirects.

Key Takeaways

• Enable WP_DEBUG_LOG immediately when troubleshooting; the debug.log file is your primary diagnostic tool.
• Database connection errors are usually credential or firewall issues; verify both before assuming server problems.
• Memory exhaustion is a symptom, not a disease; find the plugin or code causing it, then optimize rather than blindly raising limits.
• Redirect loops stem from URL mismatches or circular rewrite rules; ensure WP_HOME and WP_SITEURL align and review .htaccess carefully.
• In production, disable debug output to users and log to file; security and user experience depend on it.