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 deleting and reinstalling
Deactivating Scalability Pro leaves its indexes in place, so a deactivate-reactivate cycle or a plugin conflict test costs nothing. Deleting the plugin removes its indexes while Delete Scalability Pro indexes when the plugin is deleted is ticked on the Advanced tab, which is the default. After a delete and reinstall, go to the Indexes tab, click Select All, then Update Indexes, and wait for it to finish.
Untick Delete Scalability Pro indexes when the plugin is deleted before you delete and reinstall the plugin, for example to replace a damaged copy. The indexes then survive and there is nothing to rebuild.
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 recountImportant 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.
A plugin’s licence or settings screen misbehaves after adding an HTTP API rule
Rules on the HTTP API tab block only the URL wildcards you add, and only while a wp-admin page renders. They never apply to the front end, logins, REST, cron or AJAX requests, to plugin, theme and update screens, to WooCommerce’s order, settings and payment screens, or to the built-in list of payment gateway domains. Checkout, payments and webhooks are outside their reach.
What a rule can affect is the plugin whose call it blocks. If that plugin’s licence status or settings page stops working, edit the rule:
- Fill in Owning plugin slug, so the rule steps aside on that plugin’s own pages
- Add the page to Allowed admin page wildcards, for example
*page=my-plugin* - Delete the rule if the call turns out to matter
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.
An old wp_spro_slow_query_log table is still in your database
Scalability Pro does not log queries, so nothing writes to this table. It is left over from an older release. On the first wp-admin page load after updating, Scalability Pro removes the old settings, its db.php drop-in and its config file, but keeps the table. Deleting the plugin drops it, and you can also drop it yourself:
DROP TABLE wp_spro_slow_query_log;Change the wp_ prefix if your site uses a different one. To find slow queries, see Finding Slow Queries.
Query Monitor can’t show “Queries by Component”
To see which plugin causes your queries (and per-query row counts), Query Monitor needs its own db.php drop-in in wp-content. Scalability Pro does not install a db.php, so it never blocks Query Monitor’s. If another plugin’s db.php is in place, only one can exist at a time; remove the other one, 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.
Comments