Skip to content

Section 06 of 06

WordPress plugin troubleshooting notes

A row of interlocking paper cogs in graphite, grey and pale grey sitting on a finely ruled baseline

Share plugins sit on top of WordPress features that fail quietly: scheduled tasks that never run, deprecated functions that start throwing notices after an update, and conflicts that only appear with one theme. When share counts stop updating or the admin goes blank after an update, the cause is usually here rather than in the share plugin itself.

These notes cover the troubleshooting order that resolves most problems, the replacement for a function many older plugins still called, and how to run scheduled tasks reliably on quiet or heavily cached sites.

Every other section is listed guide by guide in the complete list of guides.

The guides in this section

  1. Fixing 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. External 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. Plugin troubleshooting: what to try firstTroubleshoot a WordPress plugin problem in a safe order: caches, conflicts, debug logging, recovery mode, and disabling a plugin when the admin is down.6 min read
Plugin troubleshooting order01Clear every cachefirst02Update everythingsecond03Conflict test on stagingthird04Read the debug logfourth
Most plugin problems end at the first or second step.

Before you change anything

Work on a staging copy where you can, keep a current backup, and change one thing at a time. The most expensive troubleshooting mistakes come from fixing three things at once and not knowing which one mattered.

Why these notes sit beside the sharing guides

The old knowledge base and blog on this domain mixed share plugin help with general WordPress fixes, because the two kept overlapping: a deprecated function in a newsletter plugin broke admin screens, a cron problem froze share counts, a caching layer hid settings changes. Those posts still receive links, and the questions behind them are still asked, so they are answered here in their current form.

Where to start, by situation

The admin is a blank page, or a plugin broke after an update. Go straight to plugin troubleshooting: what to try first; the recovery mode email and the rename-the-folder method get you back in within minutes. A notice about a deprecated function has appeared. fixing the get_currentuserinfo() is deprecated notice covers the most common one, and the method of finding the caller applies to any deprecation notice. Scheduled things happen late or never: posts miss their time, backups run at odd hours, share counts freeze. The cause is almost always WP-Cron waiting for a visitor; external cron jobs for WordPress, the right way replaces it with a server job in two lines.

How this section connects to provenance

Migration keeps author and image metadata intact, and the mechanics of that live in WordPress rather than in any plugin. Author data sits in the users table and reaches shared links through the theme's byline and the tags an SEO plugin writes, so changing a share plugin, fixing a deprecated call or moving cron to the server leaves it unchanged; byline schema shows how to check the output. Image metadata is different. WordPress copies the original upload untouched but, by default, strips embedded metadata from the resized versions it generates, through a filter named image_strip_meta, and the resized version is usually what a share preview uses. A migration that regenerates thumbnails therefore produces images without their provenance record. where image metadata gets stripped: WordPress, CDNs and uploads lists each point where that happens and what to keep; the provenance section covers what to do with the original.

Tools these notes assume

Each note uses the same small kit, and it helps to have it ready before something breaks. WP-CLI, run over SSH, lists plugins, cron events and options faster than the dashboard and works when the dashboard does not; every command in these notes is shown in full. SFTP or a host's file manager is the fallback for disabling a plugin by renaming its folder. A staging copy, from the host or from a backup, is where conflict tests happen, because deactivating plugins in production drops features for readers. The debug log, enabled with three constants in wp-config.php, is where PHP notices and fatal errors are written once display is turned off; the constants are given in the troubleshooting sequence. A recent database backup makes every step reversible, and the removal walkthrough for the old plugin shows what a cleanup looks like when all of these are used together.

Questions

Why do share counts depend on cron?

Most plugins refresh counts in scheduled tasks. If WP-Cron does not run, counts never update.

What should I try first when a plugin breaks?

Clear every cache and update everything, then test for conflicts on staging.

Is it safe to edit wp-config.php?

Yes, with a backup and care. Add constants above the line that says to stop editing.

Do these notes apply to sites without share buttons?

Yes. The troubleshooting order, the deprecation fix and the cron setup are general WordPress maintenance; share plugins are simply where this domain's readers first met them.

Hannah Voss, Editor. Checks every guide against a working WordPress install and the networks' current documentation. Last reviewed September 2026.