To test a WordPress plugin properly before it goes live, run it on a staging copy of the real site, on every PHP version that site could be running, with debugging switched on, with the site's actual plugins active and its real data volume, and with a written rollback plan agreed before anything is deployed. Most plugin failures in production come from skipping one of those, not from a bug that was impossible to find. This is the list we work through before handover, written so that you can hand it to any developer and ask which items they have done.
Why you should demand this rather than trust it
You do not need to run these tests yourself. You need to know they exist, ask for the evidence, and refuse to approve a deployment until you have it. A developer who has done the work will have a staging URL, a debug log, a list of the PHP versions covered and a rollback note. A developer who has not will have "it works on my machine". Our plugin development process runs this list on every project and has a second senior developer sign it off before you see the work.
1. Staging that matches production
A staging site is only useful if it is a copy of production: same theme, same plugins at the same versions, same PHP version, same server software, and a recent copy of the database. Ask for the staging URL and ask when the database was last refreshed from production. If the answer is "months ago", the test is not representative.
2. The PHP version matrix
The plugin should be run on the PHP version the site is on today and on the next one the host will move to. PHP versions reach end of life on a schedule, hosts force the upgrade, and each major release removes functions and changes behavior that older code relied on. A plugin that passes on the current version and throws a fatal error on the next one will take the site down the day the host flips the switch. Ask which versions were tested. The answer should be a list, not a shrug.
3. WP_DEBUG on, and the log read
WordPress has a debug mode that surfaces PHP notices, warnings and deprecation messages that are otherwise hidden. A plugin should be developed with it on and should produce nothing in the log under normal use. Notices are not cosmetic: a deprecation notice today is a fatal error on the next PHP version, and a warning about an undefined index is a logic error that happens to be silent. Ask for the debug log from staging with the plugin exercised, and ask that it be empty of anything from the new code.
4. Query Monitor on every screen the plugin touches
Query Monitor is a free plugin that shows, for each page load, every database query, its time, which plugin or function triggered it, plus PHP errors, hooks fired and HTTP calls made. It is the fastest way to catch a plugin that runs the same query two hundred times in a loop, or one that makes a remote API call on every page load rather than caching the result. Ask the developer to open the pages the plugin affects with Query Monitor active and to report the query count and total time before and after. A feature that adds fifty queries to the product page is not done.
5. Real data volumes
A plugin that filters products works fine on a store with twelve products and falls over on one with twenty thousand, because WooCommerce keeps product data in posts and postmeta and filtering that at scale is slow. The same applies to orders, customers, and any custom table the plugin creates. Staging needs the production data, or a generated set of comparable size, and the plugin's screens and queries need to be timed against it. Ask what the largest data set the plugin was tested with, and compare it to what the live site holds now and will hold in a year.
6. Plugin conflict testing
With the plugin active on staging alongside everything else, work through the site's main flows: browse, search, add to cart, checkout, log in, view an account, and every admin screen a store manager uses. Then do the reverse test: deactivate the new plugin and confirm the site returns to its previous behavior with nothing left behind. Conflicts show up as JavaScript errors in the browser console, missing elements, duplicated elements, or a form that silently stops submitting. Ask for a list of which plugins were active during testing. It should match the live site.
7. WooCommerce test orders across gateways
Any plugin that touches the cart, checkout, orders or emails needs real test orders placed through each payment gateway in its sandbox or test mode, including the failure cases: a declined card, an abandoned payment, a refund. Two things are regularly missed. First, the classic shortcode checkout and the block-based checkout are different codebases, and a plugin that works on one may do nothing on the other; older stores mostly still run classic, new stores default to blocks since WooCommerce 8.3. Test whichever the site uses, and both if a switch is planned, which is a large part of what our checkout customization work involves. Second, High-Performance Order Storage has been the default for new stores since WooCommerce 8.2, and a plugin that reads order data the old way can break on an HPOS store. Ask whether the plugin declares HPOS compatibility and was tested with it on.
8. Multisite, if the site is one
On a WordPress multisite network, a plugin can be activated per site or across the network, and each mode has different rules for where settings and tables live. A plugin that assumes a single site will put its data in the wrong place or expose one site's settings to another. If the site is part of a network, or will be, that has to be in the scope and in the test plan.
9. A rollback plan written before deployment
Before the plugin goes live, there should be a note that says: the deployment happens at this time, this is the backup taken immediately before, this is how the plugin is deactivated if something goes wrong, and this is who is watching for the first hour. Deployment during the store's busiest period is a choice, not an accident, and a good developer will refuse it. If the plugin creates database tables or changes existing data, the rollback note has to say how that is reversed too, because deactivating the plugin does not undo a migration.
The checklist as a table
| Check | What to ask for |
|---|---|
| Staging matches production | Staging URL and date of last database refresh |
| PHP version matrix | List of versions tested, including the next one |
| WP_DEBUG | Debug log with nothing from the new code |
| Query Monitor | Query count and time, before and after, on affected pages |
| Data volume | Size of the test data set compared to production |
| Conflicts | List of active plugins during testing; deactivation test done |
| WooCommerce orders | Test orders per gateway including failures; checkout type and HPOS covered |
| Multisite | Network and per-site activation tested, if applicable |
| Rollback | Written plan: backup, deactivation steps, data reversal, who is watching |
For agencies running this across many client sites
An agency with twenty or fifty client sites cannot run this list by hand for every plugin update, and the risk of skipping it grows with the number of sites. This is the case for a staging-first update routine with a fixed checklist, run by the same people every time. It is what our white-label maintenance for agencies covers: updates tested on staging, conflicts caught before they reach the client, and a rollback taken before every deployment. Your clients see your name, not ours.
Common questions
Can I skip staging for a small plugin?
No. Small plugins take a site down as thoroughly as large ones, and a fatal error on activation is the most common way it happens. If the site does not have staging, setting one up is the first task, not an optional extra.
What is Query Monitor and do I need to install it on the live site?
It is a free diagnostic plugin that shows queries, errors, hooks and remote calls for each page load. Use it on staging during testing and remove it before launch. It is not for production unless you are diagnosing a live problem, and then only briefly.
How long should testing take compared to the build?
It varies with what the plugin touches, but for anything on the checkout or order path, expect the testing and review to be a substantial share of the total. A quote that leaves no room for it is a quote that assumes nothing will go wrong.
What if the developer says the tests passed but will not show them?
Treat the tests as not done. The evidence is cheap to produce if the work happened: a staging URL, a log, a list of versions, a note. Its absence is the information.
Next step
If you have a plugin in progress and want a second opinion on whether it is ready, or want a new one built to this standard, send us the details and a developer will reply.
Want a senior developer to look at your site?
Tell us what you need. You get a written scope and a fixed price, usually within one business day.
