Fix WordPress Uncaught TypeError errors on PHP 8

What an Uncaught TypeError means in WordPress

PHP uses a TypeError when code violates certain type requirements. Examples include passing an array where a function expects a string, returning a value that does not match a declared return type, or assigning a value that does not match a typed property.

The error normally includes the message, file, line and stack trace. Read the complete message because PHP often states both the value it received and the type it expected. That is much more useful than treating every TypeError as a generic PHP failure.

PHP 8 also changed a number of behaviours that older code could previously get away with. Some invalid operations and arguments now result in TypeError or other Error exceptions. For a WordPress site upgraded from an older PHP release, an existing plugin or theme defect can therefore become visible immediately after the server change.

Common causes of PHP 8 TypeErrors in WordPress

The file path and stack trace usually show whether the failure begins in a plugin, theme or custom integration.

• Outdated plugin or theme code. A component may pass null, false, an array or an object into a function that now expects another type.
• Custom code built against an older API. A function or hook may now receive different data than the custom callback expects.
• Unexpected database or option values. Old, empty or malformed stored values can reach code that assumes a string, integer or array.
• PHP version changes. PHP 8 introduced backward incompatible behaviour in several areas, so code that ran on an older PHP version may require correction.
• Method signature conflicts. Child classes, interfaces or traits can fail when parameter and return declarations are incompatible.
• Bad assumptions about external data. API responses, form values and metadata should be validated before code performs typed operations on them.

The component named in the final line is not always the root cause. Follow the stack trace to find where the incorrect value originated.

How to fix PHP 8 TypeErrors in WordPress safely

Take a full backup of files and database before changing the PHP version, plugins, themes or code. Use a staging copy for compatibility testing whenever possible.

1. Record the complete TypeError, including the expected type, actual type, file, line and stack trace.
2. Check for updates to WordPress, the affected plugin and the affected theme. Do not update everything blindly on a broken production site. Prioritise the component identified by the trace and test the change.
3. If the problem began immediately after one plugin update, theme update or custom deployment, restore the previous known working version from backup while the incompatible change is investigated.
4. If wp-admin is unavailable and the first relevant application path belongs to a plugin, rename that specific directory under wp-content/plugins. A successful page load afterwards identifies an important dependency, but disabling the plugin is not necessarily the final repair.
5. If the fault followed a PHP upgrade, compare the affected code with the PHP migration documentation and the plugin or theme's stated compatibility. WordPress currently recommends PHP 8.3 or greater, but the surrounding extensions and custom code must also support the chosen version.
6. For custom PHP, correct the data at its source rather than simply casting every value. Check for null, false or unexpected arrays before calling a typed function. Blanket casts can hide bad data and create a different defect later.
7. Use WordPress debugging to capture enough context without exposing error details to visitors:

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

   Turn debugging off when finished and remove or protect logs containing sensitive information.

Do not suppress a TypeError with the @ operator. Fatal error behaviour changed in PHP 8, and suppression does not correct the invalid value or incompatible code.

When a PHP 8 TypeError needs professional investigation

Stop if the trace passes through bespoke integrations, checkout logic, subscription code or other functionality where changing data types could affect stored data or transactions. The same applies if reverting one component creates errors elsewhere or the site contains several older plugins that have not been tested with the current PHP environment.

A production PHP downgrade can sometimes appear to restore service, but it should not be treated as a permanent compatibility fix without considering the support and security status of that PHP release. The underlying application code still needs a planned resolution.

Web Support Services provides an Emergency Fix for £249 per incident with a response within 2 working hours. For ongoing updates and compatibility work, care plans start from £59 a month.