You followed the advice, moved your site to a newer PHP version, and now something looks wrong. Maybe a yellow warning box sits above your header. Maybe the Elementor editor will not load. Maybe the whole site shows a white screen. Do not worry. Most PHP errors in WordPress after an upgrade come from a short list of causes, and almost all of them can be fixed in under an hour.
This guide is part 2 of our PHP series. In part 1 we covered how to update the PHP version safely. Here we look at what happens when something breaks anyway, what each error means in plain words, and exactly what to do about it.
Why PHP upgrades cause errors
PHP is the language WordPress, your theme and every plugin are written in. Each new PHP version removes old features and gets stricter about sloppy code. Code that ran fine on PHP 7.4 or 8.1 can throw warnings or stop completely on PHP 8.3, 8.4 or 8.5.
The upgrade itself is still the right move. As of late 2026, PHP 8.1 no longer gets any fixes, PHP 8.2 only gets security fixes until 31 December 2026, and PHP 8.4 and 8.5 are in active support. WordPress now recommends PHP 8.3 or newer, and WordPress 6.9 and 7.0 fully support PHP 8.5. So the goal is not to go back. The goal is to fix the code that is not ready.
First, turn on the error log (safely)
Before you fix anything, find out what the error actually says. WordPress has a built-in debug mode. Open the wp-config.php file in your site root (through your host’s file manager or SFTP) and add these lines above the line that says “That’s all, stop editing”:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );This writes every PHP error to a file called debug.log inside the wp-content folder, without showing errors to your visitors. Reload the broken page, then open debug.log. The last few lines will name the error type, the file and the line number. That file path tells you which plugin or theme is to blame, because it will include something like wp-content/plugins/plugin-name/.
When you are done, set WP_DEBUG back to false. Do not leave the log running on a live site for weeks, because the file can grow large and may reveal details about your setup.
The 7 most common PHP errors in WordPress (and the fix for each)
| Error you see | What it means | Quick fix |
|---|---|---|
| Deprecated: … | Old code still works but will break in a future PHP version | Update the plugin or theme; hide notices on live sites |
| Warning: Undefined variable or array key | Code reads something that does not exist | Update the plugin; report it to the developer |
| Fatal error: Uncaught Error: Call to undefined function | A removed PHP function or missing extension | Update the plugin or ask your host to enable the extension |
| Fatal error: Uncaught TypeError | Code passes the wrong kind of value | Update or replace the plugin |
| Allowed memory size exhausted | PHP ran out of memory | Raise WP_MEMORY_LIMIT or the host memory limit |
| Maximum execution time exceeded | A task took too long | Raise max_execution_time or split the task |
| Parse error: syntax error | Code uses syntax this PHP version does not accept | Update the file or restore the original version |
Let’s go through them one by one.
1. Deprecated notices
A line that starts with “Deprecated” is a warning about the future, not a crash. For example, PHP 8.2 deprecated dynamic properties, and many older plugins still trigger this notice. Your site keeps working, but the plugin will break in a later PHP version.
Fix: update the plugin or theme named in the message. If you are on the latest version, report the notice to the developer and keep WP_DEBUG_DISPLAY set to false so visitors never see it.
2. Undefined variable or array key warnings
PHP 8 turned many silent problems into visible warnings. “Undefined array key” means the code tried to read a value that was never set. It rarely breaks the page, but a wall of warnings looks bad and can break AJAX requests, which is a common reason the Elementor editor gets stuck loading.
Fix: update the plugin. If the warnings appear only in the editor, temporarily switch WP_DEBUG off and test again.
3. Call to undefined function
This is a fatal error, which means the page stops loading. It usually has two causes. Either the plugin uses a PHP function that was removed, or your new PHP version is missing an extension such as mbstring, intl, gd or imagick.
Fix: check the function name in the log. If it is an old function, update or replace the plugin. If it belongs to an extension, ask your host to enable that extension for the new PHP version. Many hosts install extensions per PHP version, so switching versions can quietly drop one.
4. TypeError and ArgumentCountError
Newer PHP versions are strict about types. Passing null where text is expected, or calling a function with the wrong number of values, now stops the page instead of being ignored.
Fix: this is a bug in the plugin or theme code, so the real fix is an update. If no update exists and the plugin has not been touched in a year or more, it is time to replace it.
5. Allowed memory size exhausted
The message looks like “Allowed memory size of 134217728 bytes exhausted”. That number is 128 MB. Page builders, WooCommerce and large imports use more memory than a simple blog, and a new PHP setup on your host may have reset the limit to a lower default.
Fix: add this line to wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );If the error stays, the host’s own PHP memory_limit is lower than what you asked for. Raise it in your hosting panel (often under PHP settings) or ask support to do it.
6. Maximum execution time exceeded
PHP stops any task that runs longer than the max_execution_time setting, often 30 seconds. Imports, backups, image regeneration and big Elementor template imports are the usual victims.
Fix: raise max_execution_time to 120 or 300 in your hosting panel, or split the job into smaller parts.
7. Parse errors
A parse error means PHP could not even read the file. After an upgrade this happens when very old code uses syntax that newer PHP rejects. It also happens if someone edited a file by hand and left a typo.
Fix: the log gives the exact file and line. Update the plugin or theme, or restore the original file from a backup. If you edited functions.php yourself, undo that change first.
When you cannot get into wp-admin
If a fatal error locks you out, WordPress usually sends a recovery mode email to the admin address with a special login link. Use it to log in and deactivate the broken plugin.
No email? Rename the plugin’s folder inside wp-content/plugins (for example, add “-off” to the end). WordPress will deactivate it, and the site should load again. As a last resort, switch back to your previous PHP version in the hosting panel, fix the plugin on a staging copy, then upgrade again.
How to avoid PHP errors next time
- Test every PHP upgrade on a staging site first.
- Update WordPress, your theme and all plugins before you switch PHP.
- Remove plugins that have not been updated in over a year.
- Keep a fresh backup you know how to restore.
- Check the “Tested up to” and PHP requirement on each plugin page before you install it.
Fewer plugins also means fewer things that can break. One well-maintained addon that covers many widgets is easier to keep compatible than ten small plugins from ten different developers. That is one reason we built Bright Addons as a single package: the free version gives you 40 Elementor widgets, and Pro adds 70+ more plus 10 extensions, all in one plugin to keep updated.
Conclusion
PHP errors in WordPress look scary, but they follow clear patterns. Turn on the debug log, read the file path, and match the message to one of the seven errors above. Deprecated notices and warnings can wait for an update. Fatal errors need the plugin updated, replaced or switched off. Memory and time limits just need a bigger setting. Fix them once, and your site will be faster and safer on modern PHP.
If you want to keep your plugin list short, take a look at the Bright Addons widgets or read the setup docs. Pro starts from $16 a year.
FAQ
Should I go back to an older PHP version to stop the errors? Only as a short-term rescue. Older versions like PHP 8.1 no longer get security fixes. Roll back, fix or replace the plugin on staging, then upgrade again.
Are deprecated notices dangerous? No. They do not break your site today. They warn that the code will stop working in a future PHP version, so update the plugin before that happens.
Where is the WordPress debug log? With WP_DEBUG_LOG set to true, WordPress saves errors to wp-content/debug.log. Turn it off again when you are finished.
Which PHP version should my WordPress site use in 2026? WordPress recommends PHP 8.3 or newer. PHP 8.4 is a safe, well-tested choice for most sites, and PHP 8.5 is supported by WordPress 6.9 and 7.0.
