A white screen means Drupal hit a fatal PHP error and, sensibly, chose not to tell the whole internet about it. The site isn’t gone — it’s just not talking. Your job is to get it talking to you, read what it says, and fix that one thing. You’ll need drush, SSH access, and to know where your error logs live.

Turn the errors back on

Drupal hides errors from visitors on purpose. Temporarily un-hide them for yourself — add this to the bottom of settings.php (or better, settings.local.php if you have one):

$config['system.logging']['error_level'] = 'verbose';
ini_set('display_errors', TRUE);
error_reporting(E_ALL);

Reload the page. Nine times out of ten, the white screen is now a specific error with a file name and a line number — and you can skip straight to acting on it.

Read the actual fatal in the log

If the screen is still blank, the error went to the logs instead. Check Drupal’s own log first:

drush watchdog:show --severity=Error --count=20

Then the PHP/web-server error log (its location is host-specific — the error logs lesson covers finding it). You’re looking for the first fatal, not the last: read the message, the file path, and especially which module’s directory the path runs through. That path is your suspect.

Rule out the disk-full and memory-limit classics

Two boring causes produce dramatic white screens, so clear them before blaming code:

df -h
php -i | grep memory_limit

A full disk means Drupal can’t write cache or temp files and dies quietly — free up space and the site often just comes back. Allowed memory size exhausted in the log means the PHP memory_limit needs a raise (256M is a reasonable floor for modern Drupal); set it in PHP’s config or ask your host.

Disable the suspect module from the command line

If the fatal points at a module, the admin UI is no help — it’s white too. Drush still works, because it bootstraps without rendering the broken page:

drush pm:uninstall MODULE_NAME

If drush itself fatals on that module, get the code back to a state where it parses: composer install restores a missing or mangled package, and git status shows you anything edited by hand. Fix the code first, then uninstall cleanly. Deleting a module’s folder while it’s still installed just trades one problem for a stranger one.

Rebuild the caches

Stale caches can keep serving the broken page after the cause is gone — or be the whole cause, if a deploy left them pointing at code that moved:

drush cache:rebuild

Cheap, safe, and occasionally the entire fix. Run it after every change you make in this process, not just once.

Verify, then turn error display back off

Load the front page, log in, click through a couple of admin screens and whatever pages earn the site its keep. Then — and this is the step people skip — go remove those three lines from settings.php and rebuild caches once more. Verbose errors on a live site hand out file paths and stack traces to anyone who asks, and you’ve already got what you needed from them. You’re done when the site renders, the log shows no new fatals, and the error display is back to quiet. Take a note of what the culprit was; white screens are repeat visitors, and the second diagnosis goes a lot faster than the first.