How We Fixed a WordPress Critical Error Caused by a 38 MB Database Option

Introduction

A WordPress website can suddenly show “There has been a critical error on this website” even when the hosting account appears healthy and PHP already has a generous memory limit. In this case study, the dashboard became inaccessible, standard recovery attempts did not help, and PHP logs repeatedly reported memory exhaustion.

We eventually found an Elementor option in the WordPress database that occupied 38,404,156 bytes (about 36.6 MiB) and claimed to contain more than 1.46 million serialized array entries. After backing up that value and replacing it with a compact valid list for Posts and Pages, WordPress backend access was restored. The commands below document the investigation so the process can be understood and repeated carefully.

Symptoms and recovery attempts

The initial PHP fatal error reported that the request had exhausted a 512 MB memory limit while running inside WordPress’s database class. A later error showed the same memory limit being exhausted inside a WordPress functions file while trying to allocate about another 32 MB.

The reported PHP file and line were where memory allocation failed; they did not, by themselves, prove the underlying cause.

1. Renamed the plugins directory to disable ordinary plugins.
2. Reinstalled WordPress core files.
3. Retried the WordPress dashboard, but the critical error persisted.

Because those actions did not solve the problem, we moved to the PHP error log and read-only database checks instead of continuing with broad reinstall attempts.

Step 1: Capture the actual PHP fatal error

When the dashboard is unavailable, use the hosting control panel’s File Manager or error-log tools. If you need WordPress debug logging, first make a copy of wp-config.php. Add these definitions before the “That’s all, stop editing!” line only if they are not already defined; edit existing definitions rather than duplicating them.

Reproduce the error, then inspect wp-content/debug.log or the PHP error log provided by the host. On a live site, keep error display disabled so visitors do not see diagnostic details. Turn debugging off after the investigation.

In this case, PHP reported that it had reached 536,870,912 bytes (512 MiB) and failed to allocate a further 33,558,528 bytes. That was evidence of extreme memory use, not proof that the memory limit itself was the root cause.

Step 2: Use the correct WordPress database and table prefix

Open phpMyAdmin from the hosting control panel, select the database used by the affected WordPress installation, and open the SQL tab. The examples below use wp_ as a generic table prefix. Your site may use a different prefix: replace wp_ in every query with the actual prefix shown in the database. Do not run these queries against a different site’s database.

Start with read-only queries. They inspect data but do not change it.

Step 3: Check the size of database tables

This query identifies the largest tables and helps establish whether a specific table deserves further investigation. InnoDB row counts shown by TABLE_ROWS may be estimates.

In our investigation, post metadata was about 52.5 MB, the options table about 40.6 MB, and the posts table about 20 MB. These figures were useful context, but table size alone did not identify the fault.

Step 4: Check the amount of autoloaded options

WordPress loads autoloaded options into memory during many requests. A very large autoload total can contribute to performance and memory problems, so check it separately from the overall options table size.

Autoload values can vary across WordPress versions and plugins. Review the result in the context of the site. In this case, 361 rows totalled about 0.16 MB, so the autoloaded options were not an obvious explanation for a request consuming 512 MB.

Step 5: Find the largest individual option values

A large option can exist even when it is not autoloaded. This query lists the largest option values, their autoload setting, and a short preview. It is read-only.

This was the decisive diagnostic step. It revealed an option named elementor_cpt_support with a stored value of 38,404,156 bytes (about 36.6 MiB). Its autoload setting was auto-off, so it was not part of the small autoloaded total. It was still an abnormal value worth investigating.

Step 6: Inspect the suspicious option more closely

Before changing it, inspect the start and end of the value. This does not display the entire 38 MB value or modify the database.

The beginning looked like a PHP serialized array and claimed 1,463,528 entries: a:1463528:{...}. The tail contained values that looked like custom post-type names, including names resembling portfolio and team content. The setting is intended to store the post types for which Elementor support is enabled; a list of over a million entries and tens of megabytes was highly abnormal.

The size and entry count made this the strongest lead, but the log alone did not prove it was the sole cause. We therefore preserved the original value before testing a targeted correction.

Step 7: Back up the suspicious row before changing it

First, export a full database backup from phpMyAdmin or the hosting control panel and store it separately from the live database. Then, if you want a quick row-level rollback copy, create a separate backup table. Choose a unique backup table name and make sure it does not already exist.

Verify that the backup row exists and that its size matches the original value:

The expected result is one row with approximately 38,404,156 bytes in this case. A table inside the same database is not an external backup, so do not rely on it as the only recovery copy.

Step 8: Correct the oversized setting carefully

Only after confirming the backup did we update the one affected option. In this case, the setting was reset to a compact serialized array containing the standard post types “post” and “page”. Replace the generic table name below with your site’s actual prefixed options table.

This query changes only the value for the named option. It does not delete posts, pages, Elementor layouts, or other rows. However, resetting this option can change which custom post types Elementor supports. If the site uses Elementor to edit portfolios, teams, products, or other custom content types, review and re-enable the required types in Elementor settings after admin access returns.

Do not copy this update blindly to every WordPress site. First confirm that the option is the same one, the oversized value is abnormal, a backup exists, and the proposed reset fits the site’s requirements.

Step 9: Verify the repair and retest

Confirm that the stored value is now small and valid:

The new value should be a tiny serialized list rather than tens of millions of bytes. Then test the public website and /wp-admin/ in a private browser window. If the critical error remains, inspect the newest fatal error log rather than making more speculative database changes.

1. Check the public website and WordPress dashboard.
2. Open important pages and inspect Elementor layouts.
3. Review any custom post types that need Elementor editing support.
4. Keep the backup until the site has been tested successfully.
5. Turn off temporary WordPress debug logging after troubleshooting.

The result

After the targeted update, access to the WordPress backend was restored. The result strongly implicated the abnormal Elementor setting in this incident. It is more accurate to describe this as the cause identified in this particular case than to claim that every WordPress memory error is caused by Elementor or this option.

What this case taught us

1. A 512 MB memory limit does not rule out a malformed option or request that consumes excessive memory.
2. The file shown in a fatal error often identifies where allocation failed, not where the underlying problem began.
3. Disabling plugins and reinstalling core files are not universal fixes.
4. Table size, autoload size, and individual option size are different measurements and should be checked separately.
5. Use read-only queries to narrow the cause before editing production data.
6. Back up both the full database and the specific row before a targeted repair.
7. Re-test custom post types and site functionality after changing plugin settings.

Frequently asked questions

Why does WordPress show “There has been a critical error on this website”?

It is a generic message shown after a fatal PHP error. The underlying issue may involve a plugin, theme, PHP compatibility, database data, or memory exhaustion. The PHP error log is the best starting point.

Can a database option cause WordPress to run out of memory?

Yes. An abnormally large or malformed option may consume significant memory when code reads or processes it. Check the option size and usage before changing it.

Should I increase PHP memory above 512 MB?

Not automatically. When a request already reaches 512 MB, investigate the source of memory use before increasing the limit again.

Is it safe to edit WordPress options directly in phpMyAdmin?

It can be appropriate for a targeted repair, but only after verifying the option, backing up the database, understanding the setting, and planning a rollback.