By Greg Nowak. Updated 26 October 2026.
When checkout breaks or WordPress starts returning 500 errors, every change feels urgent. The business needs a working customer journey, and the person fixing it needs evidence. Changing several plugins, settings, and caches at once makes both harder.
A safer workflow is to contain the impact, capture the failing request, make one reversible change, and verify the outcome. Use staging wherever possible. If the problem only appears on the live site, agree who owns the investigation, what they may change, and when temporary diagnostics will stop.
Protect the business before changing WordPress
Define the failure precisely: the whole website, one checkout step, a form, login, or a scheduled import. Record the affected URL, time and timezone, error message, and recent changes. Ask whether orders, payments, or enquiries are still arriving behind the broken screen.
Give one person control of changes while someone else handles business updates. Pause unrelated deployments. Confirm a usable backup and restoration procedure, but distinguish reverting code from restoring the database: a database restore can overwrite orders and submissions received since the backup.
Check the administrator mailbox for a WordPress Recovery Mode message, which may identify a fatal error. Start with existing hosting and application logs before adding diagnostics.
| Symptom | First evidence to inspect | Controlled next step |
|---|---|---|
| Whole site fails after deployment | PHP log and deployment changes | Assess rollback compatibility, then revert the identified change |
| Checkout or a form fails | Failed request and integration records | Confirm whether anything was recorded before retrying |
| Only some visitors see the fault | Account state, cookies, and cache headers | Compare one affected session with a fresh session |
| A background job fails | Queue status, job log, and external service response | Check for partial completion before rerunning it |
Enable temporary logging without displaying errors
WordPress recommends local or staging environments for debugging. If production logging is necessary, edit existing definitions in wp-config.php rather than adding duplicates. Place them before the stop-editing comment:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );This normally logs PHP diagnostics to wp-content/debug.log. Because that location may be publicly accessible, prefer a private log outside the public document root. Replace the existing WP_DEBUG_LOG line with a real path your host supports:
define( 'WP_DEBUG_LOG', '/private/path/wp-errors.log' );The directory must exist and be writable by the PHP process. Restrict access, confirm entries arrive, and monitor file growth. Avoid logging credentials, payment details, or complete customer requests.
PHP recommends logging production errors rather than displaying them. Ask the host to confirm that PHP-level display settings are also off: runtime settings cannot protect against a failure that prevents those instructions from executing.
Capture one failure and follow its request
Note the timestamp, reproduce once, and read the matching log window. Prioritise a fatal error or uncaught exception tied to that request. A deprecation notice deserves maintenance work, but its presence does not prove it caused the outage.
If the WordPress log is empty, inspect the hosting, web-server, or PHP-FPM logs. In browser developer tools, check the failed request’s status and response. A page loading successfully does not mean its checkout API or JavaScript worked. Redact sensitive information before sharing screenshots or request exports.
Isolate a plugin without disabling the business
With shell access, run WP-CLI from the correct WordPress installation. Capture the active-plugin list, then deactivate the plugin supported by the evidence. Replace suspected-plugin with its actual slug:
wp plugin list --status=active
wp plugin deactivate suspected-pluginIf a plugin prevents WP-CLI from starting, try:
wp plugin deactivate suspected-plugin --skip-pluginsThe WP-CLI reference confirms that --skip-plugins still loads must-use plugins. On multisite, confirm the target site with --url and check network activation; --network affects the entire network.
Reserve bulk deactivation for a maintenance window with an agreed recovery plan:
wp plugin deactivate --all --exclude=critical-pluginReplace the exclusion with the actual essential plugin slugs, comma-separated. This can still interrupt forms, payments, authentication, and security controls. After each change, repeat the same test and record the result.
Clear the cache that matches the fault
Browser, CDN, page, object, and PHP opcode caches need separate handling. Start with the affected URL or relevant cache entry where supported.
wp cache flushThis flushes the WordPress object cache; it does not universally purge page caches or CDNs. With persistent object caching on multisite, it typically affects every site and can cause a performance spike.
WordPress configuration guidance also distinguishes WP_CACHE, which controls loading advanced-cache.php, from the separate object-cache.php drop-in. Treating it as a universal cache switch can leave the real problem untouched.
Keep expensive diagnostics purposeful: SAVEQUERIES adds overhead, and SCRIPT_DEBUG is for core JavaScript or CSS investigation. Also check WP_ENVIRONMENT_TYPE: a development environment can enable WP_DEBUG when it has not been explicitly defined.
Finish by testing the customer journey
Restore the original diagnostic settings, remove or securely archive temporary logs, and confirm the intended plugin state. Test the original failure as a customer would, including the resulting order, enquiry, or background task. A working homepage is insufficient evidence that checkout recovered.
Leave a brief handover covering impact, cause, changes, verification, and remaining work. If your team needs help coordinating the host, developers, and business priorities, contact Greg about your WordPress issue. Include the affected journey, when it started, and what changed recently.
Related on GrN.dk
- How to Check Whether a PHP Constant Is Defined (Without Breaking Production)
- MariaDB 10.6 EOL: quiet CMS hosting debt needs a real upgrade plan before July 2026
- Unzip with PHP on Shared Hosting: A Safer Way to Extract ZIP Files
Need help with this kind of work?
Discuss your WordPress issue with Greg Get in touch with Greg.
