WordPress Update & Rollback Runbook

This is fixable, and the fact that wp-admin still loads helps a lot: you can do most of the repair from the dashboard and cPanel, with no SSH. Below is the rollback for your situation first, then the full plan so the next update doesn't do this again.

Your situation: shared hosting with cPanel, no SSH or WP-CLI, Elementor updated yesterday, front page now a white screen, wp-admin works, and as far as you know no backup was taken before the update. Every step below uses wp-admin, cPanel File Manager, phpMyAdmin or your host's backup tool. None of it needs a command line.

Do this first: the rollback (Section 6, no-shell path)

Step 0: Back up the broken site as it is now (5 minutes)

Do this even though the site is broken. If a fix makes things worse, this copy is your way back to "only the front page is broken", and it also keeps any orders, form entries or comments from the last 24 hours.

cPanel → phpMyAdmin → select your WordPress database in the left column →

Export → Quick → SQL →

Go. Save the .sql file to your computer. If you're not sure which database is the right one, open wp-config.php in File Manager and read the DB_NAME line.
2.

cPanel → File Manager → open your site folder (often public_html) → right-click wp-content →

Compress → ZIP → then download the ZIP.
3.

cPanel → Backup → download a

MySQL Database backup and a

Home Directory backup if you can. These partial backups are the ones you can restore yourself. A Full Account Backup usually can't be restored by the account user on shared hosting.

Step 1: Check whether you already have a backup from before yesterday

You may have one without knowing it. Many shared hosts take automatic daily backups.

• In cPanel, look for

JetBackup,

Backups,

Softaculous → Backups, or

WP Toolkit. If you find a restore point dated

before yesterday's update, you have a full way back (Path D below).

• If you can't find anything, contact host support and ask: "Do you have a server-side restore point for my account from before [date/time of the update]?"
• Don't restore anything yet. Finish Steps 2 to 4 first. A restore is the biggest hammer, and the smaller fixes below often work.

Step 2: Find out what is actually failing (diagnose before changing anything)

Check the site admin's email inbox (the address under Settings → General) for a message from WordPress titled

"Your Site is Experiencing a Technical Issue". If it's there, it names the plugin and the file that failed, and it includes a recovery-mode login link.
2.

Look for an error log. In File Manager, check for a file called error_log in your site's root folder (next to wp-config.php) and in wp-admin/. Open it and look at the newest lines near the bottom for PHP Fatal error. The file path in that line tells you which plugin broke, for example wp-content/plugins/elementor-pro/....
3.

If no log exists, turn logging on. In File Manager, edit wp-config.php. Above the line /* That's all, stop editing! */, add:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

First search the file for WP_DEBUG. If it's already defined, change the existing line instead of adding a second one, because defining the same constant twice causes its own error. Save, load the front page once, then open wp-content/debug.log.

Step 3: Check the most likely cause, an Elementor / Elementor Pro version mismatch

In general, the most common cause of a white screen right after an Elementor update is that Elementor (free) and Elementor Pro (or an Elementor add-on) no longer match. One of them was updated and the other wasn't.

Go to Plugins → Installed Plugins and write down:

• the Elementor version
• the Elementor Pro version, if you have Pro (assumed)
• any Elementor add-on plugins (e.g. "Essential Addons", "Happy Addons", "Ultimate Addons") and their versions
• whether any of them shows "There is a new version available"

If Elementor Pro or an add-on has a pending update: update it now from the Plugins screen (⚠ changes state; Step 0 is your safety net), then test the front page (see "Check after every fix" below). Bringing the pair back in sync is often the whole fix.

If you can't update Pro (expired licence, or no update offered), roll Elementor (free) back to the version that matched instead (Step 4).

Step 4: Path A, roll back the plugin that broke

Use whichever option fits. All of them ⚠ change state, and Step 0 is your safety net.

Elementor's built-in rollback (easiest): Elementor → Tools → Version Control → choose the version you had before yesterday →

Reinstall. Elementor Pro has its own rollback on the same screen if Pro is the plugin that broke.

Upload the old version: download the previous version's ZIP (wordpress.org plugin page →

Advanced View →

Previous versions for free Elementor, or your elementor.com account for Pro) →

Plugins → Add New → Upload Plugin → choose the ZIP →

Replace current with uploaded.

• A rollback plugin such as WP Rollback does the same job for wordpress.org plugins.

Never delete the plugin first to "start clean". Deleting from wp-admin runs the plugin's uninstall routine, which can remove its settings and data. Always replace it instead.

Note: if yesterday's update skipped several major versions or ran an Elementor data update ("database update" notice), the old code may not cope with data the new version already changed. If the site is still broken or new fatal errors appear after the downgrade, stop and go to Path D. Don't keep chasing the error.

Step 5: Clear every cache

A white page can keep showing after the fix if it's cached.

1. Elementor → Tools → General → Regenerate CSS & Data (button label may vary slightly by version).
2. Purge your caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache, etc.) (assumed: you may have one).
3. Purge Cloudflare or your host's CDN if you use one.
4. Test in a private/incognito browser window.

Path B, if things get worse and wp-admin also goes down

In

File Manager, go to wp-content/plugins/ and rename the plugin folder that the error log names, e.g. elementor-pro → elementor-pro.off (⚠ changes state). WordPress can no longer load that plugin, and wp-admin comes back.

Be aware: if your front page is built with Elementor, switching Elementor off makes that page show raw or empty content until Elementor is back. Use this only to get access back. Then upload the old version (Path A, it goes into a fresh elementor-pro folder), check under

Plugins that it is active and activate it if not, and delete the elementor-pro.off folder once the site works. Do not rename .off back: that folder holds the broken version.

Path D, full restore from a backup (only if A doesn't work)

⚠ changes state, and anything created after the backup is lost.

1. Make sure you've done Step 0. That export is how you recover orders, form entries or comments made since the backup.
2. If you run a shop, list the orders newer than the backup time (WooCommerce → Orders) and export or write them down

(assumed: only if you have WooCommerce).
3. Restore files and database from the restore point you found in Step 1 (JetBackup, cPanel Backup, Softaculous or WP Toolkit), or ask host support to restore it for you.
4. After the restore:

Plugins → Installed Plugins → turn off auto-updates for Elementor and Elementor Pro so it doesn't update itself again straight away.

Check after every fix (smoke test, about 2 minutes)

In a private browser window, open:

• your front page: does it show and look as before (layout, menus, fonts)?
• one or two other Elementor pages
• your contact form page, and submit a test message
• /wp-login.php, and log in
• the shop / cart / checkout if you have one (assumed)

Then reopen error_log / wp-content/debug.log and check that no new PHP Fatal error lines appeared. Notices and "deprecated" warnings are common on healthy sites and aren't a reason to roll back on their own.

When it works again

• Leave auto-updates off for Elementor and Elementor Pro for now.
• Write down the version that broke, so you know where to start next time.
• Remove the three WP_DEBUG lines you added to wp-config.php (or set WP_DEBUG back to false). Delete wp-content/debug.log too, since it can expose file paths.

The full plan, so the next update goes safely

Blockers to check

PHP version (assumed: unknown). Look in

Tools → Site Health → Info → Server for your PHP version, and compare it with "Requires PHP" on the Elementor / Elementor Pro version you want to move to. If your PHP is older, that update is blocked until you raise PHP in

cPanel → Select PHP Version (or MultiPHP Manager). That's a separate job: test it carefully, because it affects every plugin.

Section 1: Inventory

Fill this in from

Dashboard → Updates and

Plugins → Installed Plugins. Values are placeholders until you paste yours.

Inactive plugins with pending updates still get updated (attackers can exploit them even while inactive). Delete them if you don't use them.

Section 2: Risk scoring

0–2 = Low (batch), 3–4 = Medium (one at a time), 5–8 = High (one at a time, staging first if you have it).

Rule for next time: update Elementor and Elementor Pro (and add-ons) in the same sitting, free version first, then Pro straight after.

Section 3: Rollback manifest (no shell)

Before every future update
1.

Backup: use your host's backup tool (JetBackup / cPanel Backup → MySQL + Home Directory) or a backup plugin (e.g. UpdraftPlus), and

download the copy to your computer. If your host has no on-demand backup: phpMyAdmin → Export, plus a File Manager ZIP of wp-content, as in Step 0 above.
2.

Check the backup is real: the .sql file is more than a few kilobytes, and the ZIP opens and contains a plugins folder.
3.

Versions list: copy the version of every plugin and theme into a text file named with the date. This list is what makes a targeted rollback possible.
4.

Turn off auto-updates for the plugins you're about to update (Plugins screen → "Disable auto-updates" per plugin) so nothing changes in the middle. Note which ones were on so you can switch them back.
5.

On a shop: note the newest order number before you start, and pause checkout during the WooCommerce update. The WooCommerce update changes the database on first load, so from that point a file-only rollback isn't enough.

Section 4: Update sequence (no shell)

1. Tell whoever needs to know (client, team) that a short maintenance window is starting.
2. Low batch: Dashboard → Updates → tick the low-risk plugins → Update. Run the smoke test.

Medium/High, one at a time: update one plugin, run the smoke test, and if it fails, roll that one back immediately (Path A) before going on.
4. Elementor → Elementor Pro → add-ons, back to back, then the smoke test.
5.

Database update notices (Elementor, WooCommerce, core): click them deliberately and note the time. After that point, rolling back needs the database backup.
6. Theme last among the add-ons. Child themes don't update from the directory; just check they still render.
7. WordPress core: after the plugins. For a major release, run the smoke test right after.
8. Re-check Dashboard → Updates: some plugins only offer their update once core is newer. Do those one at a time.
9. Turn auto-updates back on where they were on before (except for anything you've pinned).
10. Purge caches: Elementor regenerate CSS, the cache plugin, the CDN.

Section 5: Smoke test

The same 2-minute check as above, every time:

• / (front page): loads and looks the same
• /wp-login.php: login works
• /contact/ (assumed URL): test message arrives
• /shop/, /cart/, checkout

(assumed, only if you have a shop): reach the payment step. A real purchase on a live shop must be refunded, and gateway fees usually aren't returned, so use the gateway's test mode where possible.

• No new PHP Fatal error lines in error_log / debug.log

Section 6: Rollback paths

These are covered in detail at the top

Path A (Elementor Version Control / upload old ZIP → Replace),

Path B (rename the plugin folder in File Manager),

Path D (host backup restore, after exporting the current database). Path C (rolling back WordPress core) isn't needed here, because core wasn't part of yesterday's update.

Section 7: Update report (pre-filled, paste into your log or send to a client)

• Window: update <date/time yesterday>; fix <date/time today>
• Smoke test after fix: <pass/fail>: front page, login, contact form, <shop>
• Rollback: <Path A / Path D>, because <error log line / mismatch found>

Backups: no backup before the update; broken-state backup taken <today> (phpMyAdmin SQL + wp-content ZIP), stored <where>; host restore point used: <yes, dated … / no>

Held back: Elementor <new version> pinned until Elementor Pro <matching version> is available / staging test done. Auto-updates off for Elementor and Pro.

To give you an exact plan for your site

Answer whatever you can, or say "skip":

1. You've told me there's no SSH. Is there a

staging copy (many cPanel hosts offer one in Softaculous or WP Toolkit)?
2. Paste what you see under

Plugins → Installed Plugins for anything with "Elementor" in the name (name and version), plus anything on

Dashboard → Updates. If you found a PHP Fatal error line in error_log, paste that line too. It usually points straight at the cause.
3. Which pages make you money or bring leads (shop checkout, booking, contact form, member login)?
4. When is a quiet time for maintenance, and does anyone (a client, a boss) need to be told before and after?