Plugin troubleshooting: what to try first

Try this first

1. 01

   Clear caches

   Page cache, object cache, CDN cache and your browser. A surprising share of "broken" settings are cached pages.

2. 02

   Update

   WordPress core, the plugin, the theme and PHP compatibility. Read the plugin's changelog for known issues.

3. 03

   Reproduce

   Write down the exact steps and the page where it happens, logged in and logged out.

4. 04

   Test for conflicts

   On staging, deactivate all other plugins and switch to a default theme. If the problem goes, re-enable one at a time.

5. 05

   Log errors

   Enable WP_DEBUG and WP_DEBUG_LOG and read wp-content/debug.log.

The old knowledge base on this domain had an article titled "try this first before troubleshooting" and a troubleshooting category that attracted links from support threads. The order above is the same advice, current for 2026.

A WordPress plugin troubleshooting sequence, worked through

In our worked example the complaint is that share counts show zero on every post after a plugin update, on a site with 900 posts, a page cache plugin and a CDN. The numbers are invented; the sequence is the point. Each step takes a few minutes and rules out one cause before the next step starts.

1. 01

   Purge, then look again

   Purged the page cache and the CDN, opened a post in a private window. Counts still zero on the three posts checked. Caching ruled out in under five minutes.

2. 02

   Read the changelog

   The update notes said the plugin now requires an access token for Facebook counts. The token field in settings was empty. Filled it in from how to create a Facebook access token; Facebook counts returned, X and LinkedIn still zero.

3. 03

   Check what the networks return

   Read how share counts work: X and LinkedIn removed public counts years ago, so zero from them is correct. Only the total was wrong, and only because it had once included cached numbers.

4. 04

   Check the schedule

   wp cron event list showed the refresh hook's next run 26 hours in the past. WP-Cron had been disabled by the host without a replacement job. Added a server cron every ten minutes.

5. 05

   Confirm on staging

   Repeated on a staging copy with all other plugins off and a default theme, to be sure no conflict was hiding behind the fix. Same result, so the fix was complete.

# the commands used in the worked example (WP-CLI, on staging)
wp cache flush
wp plugin list --update=available
wp cron event list --fields=hook,next_run_relative
wp plugin deactivate --all --exclude=example-share-plugin
wp theme activate twentytwentyfive
tail -n 50 wp-content/debug.log

Total time was about forty minutes, and three of the five steps found nothing, which is normal. The temptation at step two is to reinstall the plugin, restore a backup or switch plugins; each of those would have hidden the real causes, an empty token and a dead schedule, and the same zeros would have come back within a day.

When the admin is a blank page

A white screen or "There has been a critical error" message after activating or deactivating a plugin usually means a PHP fatal error. Since WordPress 5.2, the site emails the admin a recovery mode link that lets you log in with the faulty plugin paused. If the email does not arrive, disable the plugin by renaming its folder in wp-content/plugins over SFTP or your host's file manager; WordPress deactivates a plugin whose folder it cannot find.

// wp-config.php: log errors without showing them to visitors
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Symptoms, causes and fixes

Pitfalls

• Testing conflicts on the live site. Deactivating plugins in production drops features for readers and can lose settings; use staging or a host's staging tool.
• Changing several things at once. If you purge, update and deactivate in one go and the problem clears, you learn nothing and it returns.
• Reading only the last line of debug.log. Fatal errors usually follow a run of warnings that name the file; read the fifty lines before it.
• Leaving WP_DEBUG_DISPLAY on after the fix. Notices on public pages reveal file paths and can break redirects.
• Deleting a plugin instead of deactivating it during a test. Some plugins remove their settings on delete, and you may want them back.
• Trusting a single profiler run. Measure a page three times with and without the plugin; the first run after a purge is always slower.

Reset a plugin's settings

Many plugins offer a way to load default settings. If yours does not, its settings live in the options table; export them before deleting so you can restore them. Resetting is a last resort after conflicts and caches are ruled out.

Performance complaints

If a plugin is blamed for slowness, measure with and without it rather than trusting a single profiler. A query monitoring plugin shows slow queries and remote requests per page, which is usually where the time goes.

Share plugins are a frequent suspect because they make remote requests for counts; whether that cost lands on the visitor or on a scheduled task depends on the plugin's caching method, which the share button speed guide explains. A plugin that has stopped receiving updates, such as the one this domain once sold, should be replaced rather than debugged; the steps are in removing MashShare cleanly, and the wider set of notes lives in the WordPress troubleshooting notes.

Sources

• WordPress Advanced Administration Handbook: debugging in WordPress
• Health Check and Troubleshooting plugin, WordPress.org directory
• Make WordPress Core: fatal error recovery mode in WordPress 5.2
• WordPress Advanced Administration Handbook: editing wp-config.php

Questions

Related reading

1. 01Fixing the get_currentuserinfo() is deprecated noticeWhat the get_currentuserinfo() is deprecated notice means, how to find the plugin or theme calling it, and the one-line fix using wp_get_current_user().6 min read
2. 02External cron jobs for WordPress, the right wayReplace WP-Cron's visit-triggered schedule with a real server cron job: disable WP-Cron, call wp-cron.php or WP-CLI on a schedule, and check tasks run.6 min read
3. 03Removing MashShare cleanly from a WordPress siteRemove MashShare from WordPress without breaking posts: find leftover shortcodes and theme calls, decide what to do with stored counts, and clean options.7 min read