Troubleshooting

This page collects the most common Scalability Pro problems and their fixes, based on five years of support in our Discord server. If your issue isn’t here, see the Frequently Asked Questions or ask us on Discord.

First, update to the latest version

A large share of problems are already fixed in a newer release. Before anything else, update both WordPress and Scalability Pro (and, because they share a common settings and updater module, update all your Super Speedy plugins, not just this one). In particular, the settings page needs WordPress 6.8.0 or above – on older WordPress the tabs can render blank or all stacked on top of each other. If you can’t update WordPress, use an older Scalability Pro from your account downloads. Flushing your opcache and object cache after updating helps the new files load.

Your site is slow, or CPU is high, after deactivating and reactivating

This is the most common cause of “it was fast, now it’s slow”. Deactivating Scalability Pro deletes all of its indexes, so when you reactivate you have to recreate them. Go to the Indexes tab, click Select All, then Update Indexes, and wait for it to finish. Try to avoid deactivating the plugin on a large live site for this reason, and if you do, recreate the indexes straight afterwards.

Category or product counts are wrong, or categories look empty

If category counts show 0 or stale numbers, or archive/taxonomy blocks show “no products found” on the front end while the products are clearly assigned in the back end, this is the Defer term counting option. Deferred counts are brought up to date overnight, so after a big import they can lag. To fix it now, any of these work:

• Click the “Recount now” button on the Imports tab, or use WooCommerce > Status > Tools > Recount Terms.
• Quick-edit and save any one product, which triggers a recount.
• Switch Defer term counting off and use Cache Post Counts instead.
• Run the WP-CLI recount (see below).

The standard WP-CLI recount is:

wp taxonomy list --field=name | xargs wp term recount

Important gotcha: with Defer term counting switched on, the standard recount above may not take effect. In that case use Scalability Pro’s own recount function instead:

wp eval 'spro_recount_items();'

If you’re logged in as root you’ll need to run WP-CLI as the web user (check the folder owner with ls -l, then su <username>). On a Plesk box the full form looks like sudo -u <plesk_user> /opt/plesk/php/8.3/bin/php /usr/local/bin/wp --path=/var/www/vhosts/<site>/httpdocs eval 'spro_recount_items();'.

A page builder, preview, or draft breaks, or My Account shows no orders

Symptoms include Elementor, Divi, Oxygen, Bricks or Beaver Builder editors throwing errors or 404s, post/product previews not working, drafts not saving, and (on older versions) WooCommerce My Account > Orders showing “No order has been placed yet” for everyone. The cause is the Remove OR check for private items on front end option, which hides anything that isn’t published. Disable that option on the Query Speed tab. This option caused so many builder conflicts that it was removed in version 6.04 – if you still see it, update, and if you genuinely need it you can re-add it via a targeted Custom Query Alteration.

Pagination, the XML sitemap, or the REST API breaks after removing SQL_CALC_FOUND_ROWS

The Remove SQL_CALC_FOUND_ROWS option changes behaviour on purpose (it stops WordPress counting total rows), so it can affect anything that relies on an accurate total: the native WordPress XML sitemap can lose its entries, some themes and builders (e.g. Divi) drop their pagination HTML, and external tools reading products through the WooCommerce REST API can pull back only the first page. First make sure you’re on the latest version (REST API requests have been excluded since 5.80). If it still causes trouble, either switch the front-end option off, or use the Custom Query Alterations tab to remove SQL_CALC_FOUND_ROWS only around specific hooks so it doesn’t touch the sitemap or API queries.

Bulk actions fail with “the link you followed has expired”, or you can’t trash products

If bulk-editing products, deleting to trash, or changing order statuses fails with “the link you followed has expired” or “you are not allowed to delete this item”, disable the Cache author counts option on the WP Admin tab. This was fixed in 5.55, so updating is the real fix, but turning that option off is the immediate workaround. Separately, if the WooCommerce Products > Trash link itself is missing, that’s a known issue – deactivate Scalability Pro to reach Trash, then recreate your indexes afterwards.

“Switch off phone home” broke logins, payments, reCAPTCHA or analytics

The Switch off phone home option blocks outbound HTTP requests from wp-admin, which can catch services you actually rely on – Google reCAPTCHA (so nobody can log in or register), WP Rocket, Klarna, analytics and so on. The fix is to whitelist those domains in the allowlist box using a wildcard pattern. As Dave puts it: figure out the domain, then put *domain* into the box – for example *wprocket.net* for WP Rocket, *google.com* and *gstatic.com* for reCAPTCHA, *klarna.com* for Klarna. Stripe and PayPal are excluded automatically on recent versions. If webhooks or payments start double- or triple-charging, that’s the same cause – whitelist *stripe.com* / *paypal.com* or update.

Creating indexes fails with a “sql_require_primary_key” error

Some hosts (GCP, Vultr, some Plesk setups) force the MySQL variable sql_require_primary_key on, which blocks the import staging (heap) table from being created. Update Scalability Pro – a primary key was added to that table to resolve this. As an immediate workaround you can run SET SQL_REQUIRE_PRIMARY_KEY = 0; before creating the indexes, then turn it back on afterwards.

The Slow Query Log table is huge, or keeps logging when it’s off

The Slow Query Log is a diagnostic tool, not something to leave running. If wp_spro_slow_query_log has grown to gigabytes (it can break database backups because it stores raw SQL), empty it with the “Empty Log Table” button on the Slow Query Log tab, or:

TRUNCATE TABLE wp_spro_slow_query_log;

Make sure logging is actually disabled – it’s controlled by the $SPRO_GLOBALS array in wp-config.php (enable_slow_log). Run the log only when you’re diagnosing a problem, ideally on staging, then switch it off.

Query Monitor can’t show “Queries by Component”

To see which plugin causes your queries (and per-query row counts), Query Monitor needs its db.php drop-in symlinked into wp-content. Only one db.php can exist at a time, so you can’t run Scalability Pro’s Slow Query Log and Query Monitor’s advanced mode together. If Scalability Pro’s symlink is in place, delete it (there’s a “delete symlink” link on the Slow Query Log tab, or remove wp-content/db.php via FTP – nothing breaks, it’s optional), then reactivate Query Monitor so it installs its own. Then order queries by row count, expand the blue + for the stack trace, and you’ll find the plugin fetching thousands of rows.

The whole site crashed a while after activating

If the front and back end both go down with a fatal error mentioning PluginUpdateChecker / PucFactory (or “Maximum call stack size reached” in the shared settings module), another installed plugin is bundling a conflicting copy of the same update-checker library. Disable Scalability Pro via FTP to recover, then update all your Super Speedy plugins – the fix (full namespacing) shipped in 6.17, and the alphabetically-first Super Speedy plugin supplies the shared module, so they all need updating. To find the offending plugin yourself, grep your codebase (including the theme) for PucFactory.

A simple lookup by ID (or a two-column indexed lookup) is still slow

Fetching one row on the primary key, or on a single index, is the fastest thing a database can do. If a query like ... WHERE meta_key='x' AND meta_value='y' takes seconds even with the indexes in place, the problem is your server or database, not the query. Run mysqlcheck -A --auto-repair (snapshot the server first); add EXPLAIN in front of the query – if it reads only 1-2 rows but is still slow, it’s your stack; check that your tables are InnoDB (not MyISAM), that MySQL has enough RAM in your my.cnf, and that the disk isn’t failing. Tables often corrupt after a power loss mid-write or running out of disk. Frequently the real fix is moving to better hardware.

Redis: intermittent 404s, blank pages or “broken” permalinks

If two WordPress installs share the same Redis instance with the same prefix, they trample each other’s cache, which shows up as intermittent 404s, missing content, or permalinks that only work again for a moment after you re-save them. Give each site its own Redis prefix and a dedicated Redis database, then flush Redis and save your permalinks.

“Index WP MySQL for Speed” wiped your indexes

If your Scalability Pro indexes disappear or the Indexes tab errors, check whether the “Index WP MySQL for Speed” plugin is installed. Clicking “update indexes” inside that plugin deletes all of Scalability Pro’s indexes, and it also alters core primary keys (which Scalability Pro deliberately avoids). Don’t run both. If you do keep it, revert its key changes and then recreate Scalability Pro’s indexes from the Indexes tab afterwards.

Repeated “Undefined index” / “Undefined array key” PHP warnings

Warnings like Undefined array key "sizes" or Undefined index: cacheshortcode_... in scalability-pro.php usually just mean an option hasn’t been initialised yet. Go to Settings > Scalability Pro and hit Save – that writes the missing keys and clears the warnings. Updating to the latest version resolves the underlying cause. These warnings are harmless, and they only appear at all when WP_DEBUG logging is on.

Multisite: dropping indexes on one subsite affected the whole network

On multisite, “Drop all indexes” run on one subsite can currently remove indexes across every site in the network, so be careful with it – recreate them per subsite from the Indexes tab if this happens. This is a known issue we’re fixing; if you hit a multisite regression after an update, roll back to an earlier version from your account downloads and let us know on Discord.

How to fix a high number of queries

If you have a high number of queries, click the Query Monitor bar and choose “View Queries by Component”. Query Monitor gives you a rundown of which plugins are causing the queries. If one component has a large count (often WooCommerce), it can actually be a plugin or widget hooking into WooCommerce actions, which makes it harder for Query Monitor to attribute the real source, so drill into individual queries and trace backwards through the files used to generate them.

Another approach is simply to disable half your plugins, check whether the query count dropped, and if it did, re-enable them a few at a time until you narrow down the culprit. If you have a low query count and your slow page speed is caused by slow queries, that’s exactly what Scalability Pro is for.

Consider replacing your WooCommerce widgets and shortcodes

The default WooCommerce shortcodes cause hundreds or thousands of queries as well as table scans, which will hurt performance even with Scalability Pro installed. The default WooCommerce Price Filter causes table scans too. Scalability Pro optimises the queries it safely can, but it can’t rewrite a filter or search plugin whose whole architecture doesn’t scale. If you’re looking for replacement filters and faster product widgets, use our Super Speedy Filters plugin (or ElasticPress). Filter and search plugins we repeatedly see struggle at scale include FacetWP, Search & Filter Pro, JetSmartFilters and WOOF.

Still stuck? Post your Query Monitor slow-query screenshot (ordered by row count) on our Discord, or read the Frequently Asked Questions.