How to Fix the WordPress “Critical Error” on the Widgets Page After a PHP Upgrade

Upgrading your server to PHP 8+ is essential for site performance and security, but it can occasionally trigger unexpected backend crashes. A common issue after a PHP upgrade is navigating to Appearance > Widgets (/wp-admin/widgets.php) only to be greeted by the dreaded message:

“There has been a critical error on this website. Please check your site admin email inbox for instructions.”

If your post editor works fine but your widget manager suddenly throws a critical error, the culprit is almost always a strict typing conflict between PHP 8 and corrupted sidebar data in your database.

Here is how to turn on debugging, locate the exact array_merge() error, and fix it permanently using phpMyAdmin or a single SQL query.

Step 1: Turn On WordPress Debug Mode

To fix a critical error, you first need to see the exact PHP error message instead of the generic WordPress placeholder screen.

1. Connect to your server via FTP or your host’s File Manager.
2. Locate and open the wp-config.php file in your WordPress root directory.
3. Find the line containing WP_DEBUG and just change the false to true, so that it reads:

define('WP_DEBUG', true);

4. Save the file and reload /wp-admin/widgets.php.

If you are doing this on a published website, rather than a developer site, after you have reloaded the widgets.php file, to get the error to display, you will want to updo your wp-config.php file changes and resave, to avoid errors being displayed for your visitors on your WordPress blog.

Step 2: Identify the Stack Trace

Instead of the white error screen, you should now see a detailed PHP stack trace similar to this:

Plaintext

Fatal error: Uncaught TypeError: array_merge(): Argument #5 must be of type array, null given 
in /wp-includes/widgets.php on line 1354 
Stack trace:
#0 /wp-includes/widgets.php(1354): array_merge(Array, Array, Array, Array, NULL, NULL, NULL)
#1 /wp-includes/rest-api/endpoints/class-wp-rest-sidebars-controller.php(300): retrieve_widgets()
...
#9 /wp-admin/widgets-form-blocks.php(26): block_editor_rest_api_preload(...)

Why Does This Happen?

In older versions of PHP (like PHP 7.4), array_merge() was lenient and would handle or ignore NULL values silently. However, PHP 8.0 introduced strict typing. Passing a NULL argument into array_merge() now causes an unhandled TypeError that crashes the page.

Notice frame #9 in the trace: when WordPress tries to load the modern Block Widget Editor, it runs retrieve_widgets(). If any inactive sidebar area stored in your database holds a NULL value instead of an empty array, PHP 8 halts execution immediately.

Step 3: Inspecting the Corrupted Database Option

The sidebar data for your WordPress theme is stored in your database inside the wp_options table under the option_name sidebars_widgets.

If you inspect this serialized string in phpMyAdmin, a corrupted record triggering this error usually looks like this:

a:8:{s:19:"wp_inactive_widgets";N;s:19:"primary-widget-area";a:4:{i:0;s:8:"search-2";i:1;s:14:"recent-posts-2";i:2;s:12:"categories-2";i:3;s:6:"meta-2";}s:21:"secondary-widget-area";a:0:{}s:24:"first-footer-widget-area";a:0:{}s:25:"second-footer-widget-area";N;s:24:"third-footer-widget-area";N;s:25:"fourth-footer-widget-area";N;s:13:"array_version";i:3;}

Notice the N; entries? In PHP’s serialized string format, N; represents NULL. When WordPress tries to parse those keys as arrays to merge them, PHP 8 throws a fatal exception.

Step 4: The Fix (Replacing NULL with Empty Arrays)

To resolve the error, all N; (NULL) values in that database row must be converted into valid empty arrays (a:0:{}).

Option A: Edit the Option via phpMyAdmin

1. Log into phpMyAdmin via your hosting account or cPanel.
2. Select your blog’s database and open the wp_options table (or your custom prefix, e.g., wp_xyz_options).
3. Search for option_name = sidebars_widgets.
4. Click Edit on that row.
5. Replace the corrupted text with a clean string where all empty sidebar arrays are properly formatted as a:0:{}:

a:8:{s:19:"wp_inactive_widgets";a:0:{}s:19:"primary-widget-area";a:4:{i:0;s:8:"search-2";i:1;s:14:"recent-posts-2";i:2;s:12:"categories-2";i:3;s:6:"meta-2";}s:21:"secondary-widget-area";a:0:{}s:24:"first-footer-widget-area";a:0:{}s:25:"second-footer-widget-area";a:0:{}s:24:"third-footer-widget-area";a:0:{}s:25:"fourth-footer-widget-area";a:0:{}s:13:"array_version";i:3;}

Option B: Run a Quick SQL Query

If you prefer running a direct SQL command in phpMyAdmin’s SQL tab:

UPDATE wp_options 
SET option_value = 'a:8:{s:19:"wp_inactive_widgets";a:0:{}s:19:"primary-widget-area";a:4:{i:0;s:8:"search-2";i:1;s:14:"recent-posts-2";i:2;s:12:"categories-2";i:3;s:6:"meta-2";}s:21:"secondary-widget-area";a:0:{}s:24:"first-footer-widget-area";a:0:{}s:25:"second-footer-widget-area";a:0:{}s:24:"third-footer-widget-area";a:0:{}s:25:"fourth-footer-widget-area";a:0:{}s:13:"array_version";i:3;}' 
WHERE option_name = 'sidebars_widgets';

(Make sure to update wp_options if your site uses a custom table prefix.)

Step 5: Quick Alternative (Bypassing Block Widgets)

If you don’t want to touch the database directly, you can also bypass the block-based widget editor completely by restoring the lightweight classic widget manager.

Simply add this filter to your active theme’s functions.php file:

// Disable block-based widget editor and restore classic widgets
add_filter('use_widgets_block_editor', '__return_false');

This skips the REST API sidebar preloading routine altogether, keeping your admin panel fast, lightweight, and completely error-free.

*It is advised that you do Step 4 instead.

Step 6: Cleanup

Once the widgets.php screen loads smoothly again, don’t forget to open your wp-config.php file and turn debugging back off for security and performance, if you haven’t yet.

define('WP_DEBUG', false);

---

Frequently Asked Questions (FAQ)

Q: Why didn’t I receive the WordPress admin email that the critical message said I would?

There are three main reasons why you likely didn’t receive the automated WordPress recovery email:

1. PHP mail() Isn’t Configured on the Server

By default, WordPress attempts to send system emails using PHP’s native mail() function. If your server environment isn’t explicitly configured with an active mail transport agent (like Sendmail or Postfix), PHP’s mail() fails silently in the background without throwing a site error.

2. Missing or Unauthenticated SMTP

Because server-generated PHP emails lack proper authentication headers (like SPF and DKIM signatures), major mail providers like Gmail, Yahoo, or Outlook frequently block them at the gateway or route them straight to Spam/Junk folders before they reach your inbox. Without an SMTP plugin routing your emails through a authenticated service (like Postmark, SendGrid, or your domain’s mail server), transactional emails rarely land reliably.

3. Fatal Error Caught Before the Mailer Initialized

The critical error message you saw is generated by WordPress’s wp_die() exception handler. To send a recovery email, WordPress needs to boot up far enough to execute wp_mail(). If the fatal TypeError on widgets.php triggered during early REST API preloading before the core email system fully loaded into memory, WordPress halts execution before it can compose and transmit the alert message.

In this critical error bug, it is mostly likely #3 here.

How to Check/Update Your Admin Email

When you do set up transactional SMTP on your server, make sure your notification address is current:

1. Go to Settings > General in your WordPress dashboard.
2. Check the Administration Email Address.
3. Ensure this address is monitored and uses a domain that matches your hosting environment to reduce spam filtering.

Q: Will modifying the sidebars_widgets option delete my existing sidebar widgets?

No. Replacing the N; (NULL) values with empty arrays (a:0:{}) only fixes the inactive or unassigned widget areas that were crashing PHP 8.

As long as you preserve the key data for your active sidebars (like primary-widget-area in the example above), all your active widgets, custom menus, search bars, and settings will remain intact and immediately functional once the page reloads.

Q: What if my database table prefix isn’t wp_?

If your WordPress installation uses a custom table prefix for enhanced security (e.g., wp_a1b2c_), running a query directed at wp_options will return an error stating the table does not exist.

Before running the SQL fix in Step 4 (Option B), look at the list of tables in your database sidebar in phpMyAdmin. Identify your specific prefix (the characters before _options), and update the query accordingly:

UPDATE wp_a1b2c_options 
SET option_value = 'a:8:{s:19:"wp_inactive_widgets";a:0:{}s:19:"primary-widget-area";a:4:{i:0;s:8:"search-2";i:1;s:14:"recent-posts-2";i:2;s:12:"categories-2";i:3;s:6:"meta-2";}s:21:"secondary-widget-area";a:0:{}s:24:"first-footer-widget-area";a:0:{}s:25:"second-footer-widget-area";a:0:{}s:24:"third-footer-widget-area";a:0:{}s:25:"fourth-footer-widget-area";a:0:{}s:13:"array_version";i:3;}' 
WHERE option_name = 'sidebars_widgets';

---

Related:

What Makes UltimateWB Easier to Use Than WordPress

The Latest WordPress Core Exploit (wp2shell) and Why Forced Updates Break Websites

How to Safely Merge Categories in WordPress Using PHP (Free Script)

---

Looking for a website builder that is easier than using WordPress while juggling third-party plugins? Learn more about UltimateWB! We also offer web design packages if you would like your website designed and built for you.

Got a techy/website question? Whether it’s about UltimateWB or another website builder, web hosting, or other aspects of websites, just send in your question in the “Ask David!” form. We will email you when the answer is posted on the UltimateWB “Ask David!” section.