White Screen of Death

How a nulled plugin brought down a client’s live site at 5am,  diagnosed, resolved, and rebuilt within the hour.

Total Resolution
< 1 hr
Call time
5 am

Incident Summary

A business owner called in a panic at 5am, their entire website was completely blank. No error message, no admin access, nothing. This is a the usual sign of the White Screen of Death (WSOD): a fatal PHP error that WordPress suppresses, leaving only a blank white page. Investigation revealed the culprit was a nulled (pirated) version of the PRO-Elements Elementor plugin, which had fatally broken the site.

The Challenge:

Complete White Screen Website Error:
  • Both the front end and wp-admin dashboard were completely blank. No error messages, no partial content — the site was totally inaccessible to the client and all visitors.
Plugin dependancy on nulled software:
  • The client’s page layout had been built using the nulled plugin’s features. Simply deactivating it would restore the site but leave sections of the layout broken and missing.

Diagnosis: Identifying the root cause

Gained server access via FTP
With wp-admin completely inaccessible, the only route in was at the file system level. FTP’d into the server to access the WordPress installation directly and begin diagnosis without needing the admin dashboard.

Enabled WordPress debug mode via wp-config.php
Opened wp-config.php via FTP and enabled debug logging to capture the suppressed PHP error

Checked the debug log — culprit identified
Opened wp-content/debug.log. The log immediately pointed to the PRO-Elements plugin — a nulled version of a premium Elementor add-on — as the source of the fatal PHP error. The error was being triggered on every page load, causing the full white screen.

Restoring the site, step by step

  • Deactivated the nulled plugin by renaming its folder ⭐ Site restored Navigated to wp-content/plugins/ via FTP and renamed the PRO-Elements folder to force WordPress to auto-deactivate it:
  • Logged back into wp-admin and took a full site backupWith the site restored and wp-admin accessible again, the first action before touching anything else was to take a complete backup using the All-in-One WP Migration plugin. This created a safe recovery point before any further changes were made — a critical step that is often skipped under pressure but should never be.
  • Updated all outdated plugins one by one Reviewed the full plugin list in wp-admin and identified several plugins with pending updates. All were minor version updates, no major upgrades were required. Updated them individually rather than all at once, starting with non-critical plugins and working up to higher-priority ones. This approach limits blast radius: if an update causes an issue, you know immediately which plugin was responsible.
  • Created a Hostinger staging environment to rebuild the broken layout: Deactivating the nulled plugin had resolved the WSOD, but sections of the client’s page layout that relied on that plugin’s features were now missing or broken. Rather than rebuilding directly on the live site, a Hostinger staging environment was spun up to safely reconstruct the affected sections. This protected the live site from any further disruption during the rebuild process.
  • Rebuilt all missing sections to match the original layout exactly : Reconstructed every section of the layout that had depended on the nulled plugin, replicating the design precisely using legitimate tools. Once the rebuild was verified against the original design, the staging changes were pushed live. The site was fully restored — visually identical to its pre-incident state — without any reliance on nulled software.