## PHP errors and the white screen
URL: https://hub.jkdevstudio.com/knowledge-base/troubleshooting/php-errors
Updated: 2026-09-06
Summary: Get the real error text behind a white screen, understand the common PHP messages, and read the file path to find which plugin caused it.
A report that says "I get a white screen" cannot be acted on. A white screen is the absence of a description rather than a description. What is needed is the error text.
So the order here is strict: turn on `WP_DEBUG`, reproduce the problem, take the error from `debug.log`, and only then read on.
How to diagnose a problem and report a bug
**"There has been a critical error on this website" is a WordPress placeholder, not the error.**
The real text is always in the log. WordPress also emails the admin address about a fatal error, and that email carries a recovery mode link, which is usually the fastest way back into the admin.
## Two causes out of three
Nearly every PHP error on a fresh site comes down to one of two things: a PHP version below what is required, or a missing PHP extension.
So the first action after getting the error text is to compare the environment against the [server requirements](/knowledge-base/installation/server-requirements), not to write a ticket. Diagnostics does that comparison for you, with separate checks for the PHP version and for the extension set.
The third cause is a conflict with third party code, usually an old or abandoned plugin.
## The messages you are likely to see
**Allowed memory size exhausted.** The script ran out of memory. Raise `memory_limit`. It usually appears during a [demo import](/knowledge-base/setup-guide/how-demo-import-works), thumbnail generation, or with heavy plugins.
**Maximum execution time exceeded.** The operation did not finish in the time allowed. Raise `max_execution_time`. Same situations: imports and bulk media operations.
**Call to undefined function.** The code called a function this server does not have. Almost always a missing PHP extension: `mbstring`, `gd`, `curl`, `zip` or `dom`. The other possibility is code written for a newer WordPress or PHP than you run.
**Call to a member function on null**, and similar type errors. The code received something other than what it expected. There is nothing to interpret in the message itself: the file path in it is what matters, because that names the culprit.
**Syntax error, unexpected...** A file was edited and the edit is broken. The classic case is editing through the built in code editor in the admin. Restore the file to its previous state, over SFTP if you can no longer reach the admin.
**Cannot redeclare function.** The same code is loaded twice: a duplicate plugin, an old copy of the theme in another folder, or a snippet pasted in two places.
**cURL error, and connection errors generally.** The server cannot reach the outside world: outbound requests blocked, an SSL problem, or a firewall. This one hits licensing, updates and demo import together.
## Whose error is it
**The error text always contains a file path, and the path names the culprit.**
A path inside another plugin's folder under `wp-content/plugins/` means the cause is there. A path inside the theme folder or the Pro plugin means it is ours, and that is exactly the report we want to receive.
An honest word about compatibility: we cannot guarantee the theme works with everything ever released for WordPress. Old and abandoned plugins break against current themes, and that is not a defect in the theme.
The practical method, slow and reliable: deactivate all third party plugins, check, then enable them one at a time.
Third party plugins and where responsibility sits
## What to send
The full fragment from `debug.log`: the message, the path and the trace. Not a screenshot with a truncated line.
Plus the PHP, WordPress, theme and Pro plugin versions, and the System Info report.
## Common questions
The log is empty
Then either debugging was switched on after the problem happened, or the folder is not writable, or the failure happens before WordPress loads at all, and your host's own PHP error log catches all three cases.
I cannot reach the admin to switch debugging on
Both `WP_DEBUG` and `WP_DEBUG_LOG` are constants in `wp-config.php`, so they can be set over SFTP without the admin, and the recovery mode link in the WordPress fatal error email is the other way back in.
The site works for me and shows a white screen to visitors
That is usually a cache serving a broken copy of the page to everybody who is not logged in, so clear the page cache and the CDN before looking for a PHP error that may no longer exist.