WordPress critical error after an update: collect evidence without exposing debug output

Preserve the first error and the change history

Record what changed immediately before the problem: plugin, theme, WordPress or PHP version. Ask the authorised administrator to inspect existing PHP or WordPress logs first. Preserve a short redacted fatal-error excerpt with its time and component name. An HTTP 500 by itself does not identify the cause.

• Do not repeatedly update or deactivate live components before recording the baseline.
• Do not share full logs containing visitors, filesystem paths, tokens or private data.
• If admin access is also broken, ask the host or maintainer for its authorised recovery route.

Keep debug messages away from visitors

WordPress documents separating logging from display: with debugging enabled on a development or staging copy, WP_DEBUG_LOG can record messages while WP_DEBUG_DISPLAY is false. Settings use actual booleans; the quoted string 'false' is a nonempty string and can act as true. A staging log still needs controlled access and redaction.

• Place settings in the documented wp-config.php position through an authorised maintainer.
• Do not display internal errors on the public page.
• Disable investigative logging once it has served its purpose and retain only necessary redacted evidence.

Prove the suspected component

Reproduce the same failure on a safe copy with the recorded versions. Use the error location to choose a focused comparison, such as the preceding plugin version or supported theme. A site loading after every plugin is disabled is not proof that its booking, checkout or membership functionality was repaired.

• Check the original visitor flow after the change.
• Check admin access and one unaffected path.
• Identify any data or configuration changes that a code rollback will not reverse.

When to stop

Stop ordinary update troubleshooting if evidence suggests a compromise, unknown privileged changes or untrusted injected code. That requires a security incident scope, not a routine compatibility repair. For a normal error enquiry, send platform versions, affected flow and the redacted first error, never logins or a production backup.