WordPress Plugin Not Working? The Complete Troubleshooting Guide

Few things derail a productive day faster than discovering that a WordPress plugin has stopped working. Maybe your contact form is no longer sending emails. Perhaps your SEO plugin has vanished from the admin menu. Or worse, your entire site has been replaced by a blank white screen. Whatever the symptom, a malfunctioning plugin can bring your site to its knees, and the frustration is compounded by the fact that you often have no idea what changed.

WordPress powers over 40% of all websites on the internet, and much of that dominance comes from its plugin ecosystem. There are more than 60,000 free plugins in the official directory alone, with thousands more sold through third-party marketplaces. This vast ecosystem is both WordPress's greatest strength and its most persistent source of headaches. Every plugin is written by a different developer, with different coding standards, different update cycles, and different assumptions about the environment it will run in. When two or more of those assumptions collide, things break.

This guide is designed to be the troubleshooting reference you come back to every time a plugin misbehaves. We will walk through each major category of plugin failure, explain what causes it at a technical level, and give you precise, step-by-step instructions for diagnosing and resolving the issue. Whether you are a site owner with limited technical experience or a developer debugging a client's installation, you will find actionable solutions here.

The White Screen of Death (WSOD)

The White Screen of Death is the most alarming plugin failure because it gives you almost nothing to work with. Your site loads as a completely blank page, sometimes with no error message at all. Behind the scenes, a fatal PHP error has occurred, but WordPress's default error handling suppresses the output to prevent exposing sensitive information to visitors.

What Causes the WSOD

The WSOD is nearly always caused by a PHP fatal error. Common triggers include a plugin update that introduces code incompatible with your PHP version, a plugin that exhausts the available memory, or a conflict between two plugins that try to modify the same WordPress hook. When PHP encounters a fatal error, it halts execution entirely, and because WordPress has not yet had a chance to render any HTML, the browser receives an empty response.

Step-by-Step Recovery

Step 1: Enable WordPress debug mode. Connect to your site via FTP or your hosting file manager. Open the wp-config.php file in your WordPress root directory. Find the line that reads define('WP_DEBUG', false); and change it to:

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

This configuration writes all errors to a file at wp-content/debug.log without displaying them to visitors. Reload your site, then check the debug log file. The last few entries will typically name the exact file and line number where the fatal error occurred, which tells you immediately which plugin is responsible.

Step 2: Disable the offending plugin via FTP. If you cannot access the WordPress admin dashboard, navigate to the wp-content/plugins/ directory via FTP. Rename the folder of the plugin identified in the debug log. For example, rename contact-form-7 to contact-form-7-disabled. WordPress will automatically deactivate any plugin whose folder name no longer matches. Reload your site to confirm it recovers.

Step 3: If you cannot identify the specific plugin, rename the entire plugins folder to plugins-disabled. This deactivates every plugin at once. If your site loads, create a new empty folder called plugins, then move plugin folders back from plugins-disabled one at a time, reloading your site after each move. The plugin that causes the white screen when moved back is your culprit.

Plugin Conflicts: Identifying the Culprit

Plugin conflicts are the single most common reason a WordPress plugin stops working. Unlike the WSOD, conflict-related failures are often subtle. A feature might partially work, a page might load slowly, or a setting might fail to save. The root cause is almost always two plugins trying to do the same thing, or two plugins loading JavaScript or CSS files that interfere with each other.

The Systematic Deactivation Method

The most reliable way to identify a plugin conflict is to deactivate all plugins and reactivate them one at a time. Go to Plugins > Installed Plugins in your WordPress dashboard. Select all plugins using the checkbox at the top, choose "Deactivate" from the Bulk Actions dropdown, and click Apply. Now reactivate the plugin that is experiencing problems first, and confirm that it works correctly in isolation. Then reactivate each remaining plugin one by one, testing after each activation. When the problem reappears, the last plugin you activated is conflicting.

Using the Health Check and Troubleshooting Plugin

If you cannot afford to deactivate all plugins on a live site, install the Health Check and Troubleshooting plugin (made by the WordPress.org team). This plugin creates a private troubleshooting session visible only to you, using a default theme with all other plugins disabled, while your visitors continue to see the normal site. You can then enable plugins one at a time within your troubleshooting session to identify the conflict without any disruption to your live visitors.

Common Conflict Patterns

PHP Version Compatibility Issues

WordPress itself requires PHP 7.4 or higher, but many modern plugins now require PHP 8.0 or later. If your hosting environment runs an older PHP version, newly updated plugins may fail with syntax errors or deprecation warnings that escalate into fatal errors. Conversely, some older plugins that were written for PHP 7.x may break when your host upgrades to PHP 8.x because of stricter type handling and removed functions.

How to Check Your PHP Version

In your WordPress dashboard, go to Tools > Site Health > Info and expand the "Server" section. Your PHP version is listed there. Alternatively, you can create a file called phpinfo.php in your WordPress root directory with the following content:

<?php phpinfo(); ?>

Visit that file in your browser to see detailed PHP configuration. Delete this file immediately after checking, as it exposes sensitive server information.

Common PHP Errors and What They Mean

• "Parse error: syntax error, unexpected '...'" -- The plugin uses PHP syntax not supported by your version. This usually means you need a newer PHP version.
• "Fatal error: Uncaught TypeError" -- PHP 8.0 introduced stricter type checking. A plugin passing a null value where a string is expected will throw this error in PHP 8.x but would have worked silently in PHP 7.x.
• "Deprecated: Function ... is deprecated" -- The plugin uses a PHP function that has been marked for removal. This is a warning, not a fatal error, but it indicates the plugin needs updating.
• "Fatal error: Call to undefined function" -- The plugin calls a PHP function that does not exist in your PHP version. This can happen with functions that were removed in PHP 8.0, such as create_function() or each().

Upgrading PHP Safely

Most hosting providers offer a PHP version selector in the control panel (cPanel, Plesk, or a custom dashboard). Before changing the version, run the PHP Compatibility Checker plugin, which scans all your plugins and themes for code that may not work under the new PHP version. Change the version only after confirming compatibility, and always keep a backup ready to revert if something breaks.

Memory Limit Exhaustion

Every WordPress page load executes PHP code that consumes server memory. When a plugin tries to process a large dataset, generate a complex report, or handle a file upload, it may exceed the memory allocated to PHP. The result is a fatal error that reads: Fatal error: Allowed memory size of X bytes exhausted.

Symptoms and Diagnosis

Memory exhaustion often manifests inconsistently. Your site might work fine most of the time but crash when a specific page is loaded, when a particular admin task is run, or when traffic spikes. The error message in your debug log will include the exact memory limit and the file that exceeded it. Common culprits include page builder plugins rendering complex layouts, image optimization plugins processing large batches, and backup plugins trying to compress your entire site in memory.

How to Increase the WordPress Memory Limit

There are three methods, and you should try them in this order:

Method 1: wp-config.php -- Add this line to your wp-config.php file, just before the line that says "That's all, stop editing!":

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

The first value controls the memory available to the front-end, and the second controls the admin dashboard. For most sites, 256M is sufficient.

Method 2: .htaccess -- If your server uses Apache, add this line to the .htaccess file in your WordPress root:

php_value memory_limit 256M

Method 3: php.ini or .user.ini -- Create or edit a php.ini (or .user.ini) file in your WordPress root directory and add:

memory_limit = 256M

If none of these methods work, your hosting provider may enforce a hard memory cap at the server level. Contact their support to request an increase, or consider upgrading your hosting plan.

File Permission Problems

WordPress needs specific file and folder permissions to function correctly. If permissions are too restrictive, plugins cannot write to their own configuration files, create cache directories, or save uploaded media. If permissions are too permissive, your hosting provider's security scanner may disable files, and you expose your site to potential attacks.

Correct Permission Settings

The standard recommended permissions for WordPress are:

• Folders: 755 (owner can read/write/execute, group and others can read/execute)
• Files: 644 (owner can read/write, group and others can read only)
• wp-config.php: 440 or 400 (owner can read, no one else can read or write)

How to Fix Permissions via FTP or SSH

If you have SSH access, you can reset all permissions at once with two commands run from your WordPress root directory:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

If you only have FTP access, most FTP clients (FileZilla, Cyberduck, WinSCP) allow you to right-click a folder or file and set permissions. For large sites, applying permissions recursively through FTP can be slow, so SSH is strongly preferred. Some hosting providers also offer a file permission repair tool in their control panel.

Database Connection and Corruption Issues

WordPress stores all plugin settings, post content, user data, and site options in a MySQL (or MariaDB) database. When the database becomes unreachable or its tables become corrupted, plugins that read or write to the database will fail. The most visible symptom is the message "Error establishing a database connection," but subtler symptoms include plugin settings that revert to defaults, content that disappears, or admin pages that load partially.

Checking wp-config.php Settings

Open your wp-config.php file and verify the four database connection constants:

define('DB_NAME', 'your_database_name');
define('DB_USER', 'your_database_username');
define('DB_PASSWORD', 'your_database_password');
define('DB_HOST', 'localhost');

The DB_HOST value varies by hosting provider. Some use localhost, others use an IP address or a hostname like mysql.yourdomain.com. Check your hosting documentation or control panel if you are unsure. A common cause of database connection failures is a recent password change that was not reflected in wp-config.php.

Repairing the WordPress Database

WordPress includes a built-in database repair tool. To enable it, add this line to your wp-config.php:

define('WP_ALLOW_REPAIR', true);

Then visit https://yoursite.com/wp-admin/maint/repair.php in your browser. You will see options to repair and optimize your database tables. Click "Repair and Optimize Database" to fix corrupted table indexes and reclaim wasted space. Remove the WP_ALLOW_REPAIR line from your config file after you are done, as this page is accessible without authentication.

For more severe corruption, you may need to log into phpMyAdmin (available through most hosting control panels), select the affected database, check all tables, and use the "Repair table" option from the dropdown menu.

Caching Issues After Plugin Updates

Caching is one of the most common reasons a plugin appears not to work after an update. The plugin's code has changed, but your server, your caching plugin, or your CDN is still serving the old version of the page. The result is that the update appears to have had no effect, or worse, causes visual glitches because old cached CSS and JavaScript files are loaded alongside new HTML markup.

The Three Layers of Caching

When troubleshooting a plugin that "isn't working" after an update, always clear all three cache layers in order: server cache first, then plugin cache, then CDN cache. Also clear your browser cache or test in a private/incognito window to rule out local caching. Many hours have been wasted debugging a problem that was simply a stale cache.

Plugin Update Failures

WordPress auto-updates plugins by downloading the new version, extracting it, and replacing the old plugin folder. If any step in this process is interrupted -- by a server timeout, a permissions issue, or a hosting provider's resource limit -- the plugin can end up in a broken state where the old files are partially replaced by new ones.

Symptoms of a Failed Update

• The plugin shows as "active" but its version number has not changed
• A "maintenance mode" notice appears and does not go away (WordPress creates a .maintenance file during updates)
• The plugin's admin page shows a blank screen or a PHP error about a missing file
• WordPress displays "An automated WordPress update has failed to complete"

Manual Update via FTP

If the automatic update has left a plugin in a broken state, the cleanest fix is a manual update:

1. Download the latest version of the plugin from its official source (WordPress.org plugin page or the vendor's website)
2. Connect to your site via FTP and navigate to wp-content/plugins/
3. Rename the existing plugin folder (for example, plugin-name to plugin-name-old)
4. Upload the extracted new version folder to wp-content/plugins/
5. Log into your WordPress dashboard and verify the plugin is active with the correct version number
6. Delete the old renamed folder once you have confirmed everything works

Rollback Strategies

If a new plugin version introduces a bug, you may need to roll back to the previous version. The WP Rollback plugin lets you select any previous version of a plugin from the WordPress.org repository and install it with one click. For premium plugins not hosted on WordPress.org, check if the vendor provides access to previous versions in your account downloads. As a last resort, you can often find the previous version in your backup files.

JavaScript and jQuery Conflicts

WordPress bundles jQuery and loads it by default, but many plugins include their own versions of jQuery or other JavaScript libraries. When two different versions of the same library are loaded on the same page, one will overwrite the other, causing functions that depend on the overwritten version to fail. This is one of the most common and most difficult-to-diagnose plugin issues.

Identifying Console Errors

Open your browser's developer tools (press F12 or right-click and choose "Inspect"), then click the Console tab. Reload the page and look for red error messages. Common JavaScript errors caused by plugin conflicts include:

• "$ is not a function" -- jQuery is either not loaded, loaded in a different order than expected, or overwritten by a non-jQuery library that uses the $ symbol
• "Cannot read properties of null" -- A script is trying to manipulate a DOM element that has not been rendered yet, usually because the script loaded before the HTML it depends on
• "Unexpected token" -- A minification plugin has broken the JavaScript syntax, often by incorrectly concatenating files or removing necessary semicolons
• "X is not a constructor" -- Two plugins are loading different versions of the same library, and the older version does not support the constructor syntax the newer plugin expects

wp_enqueue_script Best Practices

Well-written WordPress plugins load their JavaScript files using the wp_enqueue_script() function, which tells WordPress about each script's dependencies and prevents duplicate loading. Problems arise when plugins bypass this system and inject scripts directly into the page using hardcoded <script> tags. If you are a developer, always specify jQuery as a dependency when enqueueing scripts that use it, and always use the jQuery variable name instead of $ in WordPress context, or wrap your code in a closure:

(function($) {
    // Your jQuery code here using $ safely
    $(document).ready(function() {
        // Plugin initialization
    });
})(jQuery);

Identifying Conflicting Scripts

In the browser's developer tools, go to the Network tab, reload the page, and filter by "JS" to see every JavaScript file being loaded. Look for multiple versions of the same library (you might see jquery.min.js loaded twice from different paths). Also check for scripts that load from the <head> section without the defer or async attribute, as these block page rendering and can cause timing-dependent failures.

Theme Incompatibility

WordPress themes control much more than the visual appearance of your site. They define which WordPress hooks are available, how the page markup is structured, which JavaScript libraries are loaded, and what CSS styles are applied globally. A plugin that works perfectly with one theme may fail entirely with another because the expected HTML structure is different, a required hook is missing, or a theme stylesheet overrides the plugin's CSS.

Switching to a Default Theme for Testing

The fastest way to determine whether a theme is causing your plugin issue is to temporarily switch to one of WordPress's default themes (Twenty Twenty-Four, Twenty Twenty-Three, etc.). Go to Appearance > Themes, activate a default theme, and test the plugin. If the plugin works correctly with the default theme, the issue is a theme incompatibility. You can then investigate whether the conflict is in the theme's functions.php, its template files, or its CSS.

Child Theme Considerations

If you are using a child theme, test with both the parent theme alone and the child theme to isolate whether your customizations are causing the conflict. Common child theme issues include overriding WordPress action hooks that plugins rely on, loading custom JavaScript that conflicts with plugin scripts, and CSS rules with high specificity that hide plugin UI elements. Check your child theme's functions.php for any remove_action() or remove_filter() calls that might be unhooking something a plugin needs.

Why Some Plugins Avoid These Problems Entirely

After reading through all of the issues above, a pattern becomes clear. The vast majority of WordPress plugin failures trace back to a handful of architectural realities: PHP conflicts, database table corruption, theme hook dependencies, JavaScript collision with other scripts, memory exhaustion from server-side processing, and caching layer interference. These are not bugs in any single plugin. They are inherent consequences of how traditional WordPress plugins are built -- as PHP code that runs inside the WordPress execution environment, sharing the same memory space, the same database, the same hook system, and the same JavaScript global scope as every other plugin.

But not every tool that integrates with WordPress needs to follow this architecture. A growing category of services take a fundamentally different approach: instead of installing PHP code that runs on your server, they provide a single JavaScript snippet that loads from an external CDN. The script runs in the visitor's browser, completely independent of your WordPress installation. It does not touch your PHP environment, does not write to your database, does not depend on any theme hooks, and does not share the JavaScript global scope with other plugins.

Asyntai: An Example of the Script-Tag Approach

Asyntai is an AI-powered chat tool that follows exactly this architecture. Instead of a traditional WordPress plugin that installs PHP files, creates database tables, and hooks into WordPress's execution cycle, Asyntai works by adding a single <script> tag to your site. The AI chat widget loads from Asyntai's CDN, runs in its own isolated scope in the browser, and communicates directly with Asyntai's servers for AI processing.

Asyntai automatically crawls up to 5,000 pages of your site to understand your content, then answers visitor questions using your own content, in 36 languages with automatic language detection. The AI processing happens on Asyntai's servers, not yours, so it adds no load to your WordPress hosting. There is a free plan that includes 100 messages per month for one site, making it easy to test without commitment.

While Asyntai also offers an official WordPress plugin for convenient installation, the plugin itself is lightweight -- it simply injects the same script tag into your pages. It does not run complex PHP logic, create database tables, or hook into WordPress's cron system. This means even the plugin version avoids the entire category of failures described in this guide.

When to Contact Plugin Support vs. Hire a Developer

Knowing when to seek outside help can save you hours of frustration. Here is a practical framework for deciding between contacting the plugin's support team and hiring a WordPress developer.

Contact Plugin Support When:

• The issue started immediately after a plugin update (this is likely a bug the developer needs to know about)
• The plugin works on a fresh WordPress installation but not on yours (this helps the support team understand it is an environment-specific issue)
• You have identified a specific conflict with another named plugin (the developer may already have a known fix or workaround)
• The error message references a specific file within the plugin's own directory
• You are using the free version and the feature you need is actually a premium-only feature (this happens more often than you might think)

Hire a Developer When:

• Your site has multiple interacting issues that compound each other (permission problems plus database corruption plus outdated PHP)
• You need a custom integration between two plugins that do not natively work together
• The plugin author has abandoned the project and you need a replacement or a fork
• Your hosting environment has unusual constraints (shared hosting with low resource limits, security restrictions that block standard plugin behavior)
• You have modified core WordPress files or are running an extremely old WordPress version that cannot be updated

When contacting plugin support, always include your WordPress version, PHP version, a list of all active plugins and their versions, the exact error message (from the debug log, not paraphrased), and the steps to reproduce the issue. This information saves multiple rounds of back-and-forth and dramatically increases the chance of a quick resolution.

Preventive Maintenance: Stopping Problems Before They Start

The best way to deal with plugin failures is to prevent them. A small amount of regular maintenance eliminates the vast majority of emergency debugging sessions.

Use a Staging Environment

Never update plugins directly on your live site. Most managed WordPress hosts provide a one-click staging environment where you can clone your site, apply updates, test thoroughly, and then push the changes to production only after confirming everything works. If your host does not offer staging, you can create one manually using a subdomain and a database clone, or use a local development tool like LocalWP. Testing updates in staging first catches conflicts before they affect your visitors.

Maintain a Regular Backup Schedule

Automated daily backups are non-negotiable. Use your hosting provider's backup system or a dedicated backup plugin to create daily snapshots of both your files and database. Store backups in a location separate from your hosting account (a cloud storage service, for example). Test your backups periodically by restoring one to a staging site to verify they actually work. A backup you have never tested is a backup you cannot trust.

Establish an Update Schedule

Rather than updating plugins whenever WordPress nags you, set a specific day each week or month for plugin maintenance. On that day, review available updates, check each plugin's changelog for breaking changes or compatibility notes, apply updates on your staging site first, test, then push to production. This disciplined approach prevents the "I updated 12 plugins at once and now something is broken and I do not know which update caused it" scenario.

Minimize Your Plugin Count

Every plugin you add increases the surface area for potential conflicts, security vulnerabilities, and performance degradation. Before installing a new plugin, ask whether WordPress's built-in functionality or a simple code snippet can accomplish the same goal. If you have two plugins that overlap in features, consider consolidating to one. As a general principle, fewer plugins means fewer problems. A well-maintained site with 15 carefully chosen plugins will always be more reliable than a site with 40 plugins doing overlapping jobs.

Conclusion

WordPress plugin issues are a fact of life for anyone managing a WordPress site. The plugin ecosystem's openness and diversity are what make WordPress so powerful, but they also mean that conflicts, compatibility gaps, and configuration failures are inevitable. The good news is that nearly every plugin failure falls into one of the categories covered in this guide, and nearly every one has a systematic fix.

Start with the basics: enable debug mode, check the error log, isolate the problem by deactivating plugins one at a time. Verify your PHP version, check your memory limits, confirm your file permissions. Clear every layer of caching. When in doubt, test against a default theme with all other plugins disabled. Most issues will reveal themselves through this process within minutes.

For ongoing reliability, invest in prevention. Use a staging environment for updates, maintain daily backups, audit your plugin list regularly, and keep your PHP version current. Consider the architecture of the tools you add to your site -- tools that run as standalone scripts in the browser, rather than as deeply integrated PHP code, will always be more resilient to the conflicts and compatibility issues that plague traditional WordPress plugins.

The time you spend understanding how WordPress plugins work -- and how they fail -- pays dividends every time you avoid a panicked debugging session at midnight. Bookmark this guide, and the next time a plugin breaks, you will know exactly where to start.