Scalability Pro testing
Testing › Scalability Pro
Last full run: version 6.41.1 · 11 November 2026
Summary
Scalability Pro has one registered list of the test suites that make up its full run. This page describes that list: what each suite proves, how it drives the plugin, and the result of the last full run. Every suite runs on its own WordPress test site. Where WooCommerce is installed, HPOS order storage is switched on before any test runs.
Most of what Scalability Pro does is change how WordPress queries the database. A faster query that returns different products, a different order or a different page count would be a broken shop, so many suites run the same real request with an option off and then on, and require the same results both times while the SQL changes.
The suites
| Suite | What it proves | How it runs |
|---|---|---|
| Core suite | 57 test files inside a real WordPress with WooCommerce. Real queries are run through the query optimisations, and the SQL that actually ran and the posts it returned are checked: row counts, pagination and the one-row lookahead, GROUP BY and sort removal, taxonomy EXISTS rewrites and the attribute filter join. It also covers the database indexes, the options autoload optimiser, the outbound HTTP blocker in wp-admin, the caches, Fast Ajax rule matching, the checkout purge shield, settings permissions, the MCP abilities, and what deactivation and uninstall remove. | WordPress itself, called directly |
| Settings in the browser | Every settings tab on desktop and phone width, saving, exporting and importing settings (including a file that is not valid JSON), the native bulk editor, and a real options autoload scan, apply and revert. A measurement that fails must not be recorded as a success. | Browser |
| Apply good settings | Pressing Apply Good Settings through two real Performance Analysis runs, applying real changes, with no server error or browser error at any step. A separate test installs Performance Analysis from the Main tab with no licence key. | Browser |
| Slow index builds | Database indexes on a big table can take longer to build than your web server allows for one request. A real index build is held up in the database for 13 minutes, for 150 seconds, and until it is killed, on both the Main tab and the Indexes tab. The screen must keep waiting while the build runs, finish when it completes, and say clearly when a build has stopped. A server that answers “busy” must be retried until it gets through. | Browser, with the build held in the real database |
| Taxonomy EXISTS setting | The option is off by default, describes what it changes, and saves on and off correctly. | Browser |
| Fast Ajax | Fast Ajax loads fewer plugins for chosen AJAX and REST requests. On a fresh site nothing is trimmed. With the switch off every plugin loads. An ambiguous rule trims nothing. A rule applies only to its exact endpoint and method. A request that fails with a 503, a fatal error or a plugin reacting badly turns off only that one rule until you review it, and can never leave a plugin deactivated. The whole workflow is driven through the real screens: discovering endpoints, editing a rule, saving, reloading, the failure notice, and plugins you have marked as always loaded. | Real HTTP requests and browser |
| Performance Analysis evidence | The request evidence Scalability Pro reads from Performance Analysis has the agreed shape and contains exact endpoint names and measured counts, but no request payloads or literal route data. | Real HTTP requests |
| Plugin unloads | The page unload workflow from start to finish: finding candidates from real measurements, the guided popover, verifying that a page still renders the same before a rule goes live, a verification that fails and why, two tabs scanning at once, and visitors always getting every plugin while a candidate is still being verified. | Browser and real HTTP requests |
| Imports and page builders | Real Super Speedy Imports variable-product imports and updates produce the same products, metadata, lookup rows and categories with term-count deferral off and on, and the term counts are correct afterwards. An Elementor shortcode widget renders the same with the shortcode cache off and on. | WP-CLI and real HTTP requests |
| Outbound HTTP blocking | Requests are counted as they arrive at a local test server. Blocked destinations are blocked only on eligible wp-admin screens; checkout, cron, WP-CLI and other protected contexts still get through. | Real HTTP requests |
| Term counts and the Products screen | The Run now button for the manual term recount repairs a category count that was deliberately left wrong. The Products screen category cache skips the expensive count query on a warm cache, keeps the hierarchy, counts and selected filters, rebuilds an expired cache once, and caches nothing when the option is off. | Browser |
| Multisite | A subsite administrator who is not a network super admin can only touch their own subsite’s tables. | Browser, on a real multisite network |
| With Super Speedy Filters and Search | The taxonomy EXISTS rewrite leaves pages that Super Speedy Filters serves exactly as Filters built them, and still rewrites the pages it does not, with the same products, order and totals throughout. Super Speedy Search results paginate 20 then 1 with no overlap and no SQL errors. | Real HTTP requests |
Last full run: version 6.41.1
Run on 11 November 2026 on WordPress 7.1, PHP 8.5 and MariaDB 10.11, with WooCommerce 10.5.3 and HPOS.
| Suite | Result |
|---|---|
| Core suite | 57 of 57 test files passed, 1,154 checks |
| Settings in the browser | 57 of 57 passed |
| Apply good settings | 27 of 27 passed. Installing Performance Analysis: 6 of 6 passed |
| Slow index builds | 21 of 27 passed. The build killed part way, the 150-second build on the Indexes tab and the busy server: all passed. The 13-minute build: 2 of 8 passed, and it failed the same way when re-run on its own (below) |
| Taxonomy EXISTS setting | 8 of 9 passed. The one failure was in the test, not the plugin; the test was fixed and 9 of 9 passed when re-run (below) |
| Fast Ajax | Runtime: 28 of 28 passed. Workflow: 33 of 33 passed. Failure notice: 4 of 4 passed. Always-loaded plugins: 10 of 10 passed |
| Performance Analysis evidence | 13 of 13 passed |
| Plugin unloads | 124 of 124 passed |
| Imports and page builders | Imports: 18 of 18 passed. Elementor: 7 of 7 passed |
| Outbound HTTP blocking | 30 of 30 passed |
| Term counts and the Products screen | Manual recount: 5 of 5 passed. Products screen cache: 29 of 29 passed |
| Multisite | 8 of 8 passed |
| With Super Speedy Filters and Search | Filters: 20 of 23 passed on the first run, 23 of 23 when re-run with no code changed (below). Search: 1 of 1 passed |
The 13-minute index build: not yet explained
In this scenario the test holds a real index build in the database for 13 minutes, and the Main tab must keep waiting and then finish. On the full run, and again when the scenario was re-run on its own, the web server process that started the build ended part way through the hold, after about 11 minutes the first time and about 6 minutes the second. When that process ends, the database abandons the build. The screen then said the build had stopped without creating the index, which was true: the index had not been created. Because the build never finished, the six checks that wait for it to finish failed.
We checked the database on its own: the same build, held the same way without the web server involved, waited 997 seconds and then completed normally. This scenario passed on 29 October 2026. What ended the web server process this time is not yet known, so we have not called it a fault in the plugin or in the test. It stays listed as a failure until it is explained.
The taxonomy EXISTS setting test
One check failed: the one that reads the setting’s description. The fault was in the test, not the plugin. In version 6.37.8 the description was deliberately rewritten to say that the option changes how the SQL is written, never which products are shown, and the test was still looking for a sentence from the old wording. The test now checks for the current scope statement, and the whole test passed 9 of 9 when re-run. The plugin code was not changed.
The Super Speedy Filters test
On the first run, one of the two pages in this test, a category page filtered by colour, answered with a redirect instead of the page, so its three checks could not run. The other page passed every check. Re-run a few minutes later with no code changed, the same page loaded normally and all 23 checks passed. We have not found what caused the redirect on the first run, so we show both results.
Not part of this run
- Search on a 1,000,000 product catalogue. A test that checks the database does not plan logged-out product searches through the wrong index. The problem only shows on a very large table, so it runs on its own large test site when the indexes change.
- The release ZIP. These suites test the code itself. Building and checking the ZIP file you download is a separate step and was not part of this run.
What the tests do not cover
- Your server. Tests run on our development machine with one PHP version and one MariaDB version, not every host and database you might use.
- Your catalogue size. The test sites in this run hold small catalogues, enough to prove results do not change. Speed on your own catalogue depends on its size, your other plugins and your server.
- Every other plugin. Plugins we integrate with, such as WooCommerce, Performance Analysis, Super Speedy Imports, Super Speedy Filters, Super Speedy Search and Elementor, are tested where a suite names them. Other plugins on your site are not.
