You bumped your PHP version in cPanel — maybe because your host nudged you off 7.4, maybe because a plugin finally demanded it — and now the top of every page has a wall of orange text: Deprecated: Creation of dynamic properties is deprecated, repeated a dozen times, sometimes followed by Cannot modify header information - headers already sent. The site technically still works, but it looks broken, and your error log is growing by megabytes an hour. Here's what's actually happening and how to clean it up properly instead of just hiding it.
Symptom: Orange Warning Text, Broken Layout, or a Log File That Won't Stop Growing
This shows up in a few different ways depending on your setup:
- Warning text printed above your site's header, pushing the layout down or breaking a redirect entirely.
headers already senterrors on login, checkout, or any page that tries to redirect — because the deprecation notice was printed as output before PHP could send the redirect header.- A
error_logfile in your account's public_html (or a subfolder) that's suddenly gigabytes in size, sometimes tripping your inode or disk quota alerts. - Admin AJAX calls failing silently because the warning text got mixed into a JSON response and broke it.
None of this means your site is actually broken in the way a fatal error breaks it. Deprecation notices are PHP telling you "this still works today, but it's on its way out" — the problem is that by default, many hosting configs print those notices straight into the page instead of quietly logging them.
Cause: Old Plugin/Theme Code Meeting a Newer PHP Engine
Every PHP 8.x release removed a bit more tolerance for loose, old-style coding patterns that used to pass silently:
| PHP Version | Common New Deprecation |
|---|---|
| 8.1 | Passing null to a non-nullable internal function parameter (very common in older image/string handling code) |
| 8.2 | "Creation of dynamic properties is deprecated" — classes that set object properties never declared in the class |
| 8.3 | More of the same, plus stricter handling around enums, readonly properties, and a handful of built-in class changes |
Notice these are cumulative. If your account jumped straight from PHP 7.4 to 8.3 in one move — which is exactly what happens when a host retires an old version and auto-migrates everyone — you inherit every deprecation from 8.1, 8.2, and 8.3 all at once. That's why the warning flood after a version bump is usually much worse than people expect.
The actual source is almost always one of:
- An older, poorly maintained plugin that hasn't been updated in a year or two.
- A nulled or premium theme with no active updates.
- Custom code in a child theme's
functions.phpthat was written years ago and never revisited.
Fix: Stop the Bleeding, Then Fix the Real Cause
Step 1 — find out exactly which file is throwing the notices. The warning text itself tells you: look for a line like in /home/username/public_html/wp-content/plugins/plugin-name/file.php on line 42. That's your culprit, every time.
Step 2 — check for an update. Go to Plugins in wp-admin and see if that plugin has a pending update. A huge share of these warnings simply disappear once you update to the current release, because most active plugin authors have already patched for PHP 8.2/8.3 compliance.
Step 3 — if there's no update, stop the notices from printing to the page (without hiding real errors). This is a config change, not a code fix, and it's the difference between "ugly but works" and "actually broken." In cPanel:
- Open MultiPHP INI Editor under Software.
- Select your domain, switch to Editor Mode.
- Set
display_errors = Offand keeplog_errors = On, witherror_logpointed somewhere sane (or leave the default). - Save.
This stops PHP from printing anything to the browser — deprecated, warning, or notice — while still recording it in the log for you to review later. It's exactly what a production site should be doing anyway; showing raw PHP output to visitors was never a good idea, deprecation notices or not.
If you don't have MultiPHP INI Editor access (some reseller setups restrict it), add this to wp-config.php above the /* That's all, stop editing! */ line instead:
error_reporting(E_ALL & ~E_DEPRECATED & ~E_NOTICE);
ini_set('display_errors', '0');Step 4 — deal with the runaway log file. If error_log in your document root has ballooned, it's safe to delete via File Manager or SSH once you've noted which plugins were logged. cPanel won't regenerate the old size; a fresh file starts small.
Step 5 — fix the headers-already-sent errors specifically. These happen when warning output gets flushed to the browser before a plugin tries to call wp_redirect() or set a cookie. Once display_errors is off, this class of error usually disappears on its own, because there's no more stray output ahead of the headers. If it persists, check for a plain text character, BOM, or blank line before the opening <?php tag in any recently edited theme file — that's a separate, unrelated cause of the same symptom.
Prevention: Don't Let the Next Version Bump Catch You Off Guard
- Test on staging first. Clone the site (Softaculous or your own staging tool), bump PHP there, and browse the important pages before touching production.
- Keep plugins current. Most PHP compatibility breakage traces back to a plugin that's two or three major versions behind.
- Audit for abandoned plugins. If something hasn't been updated in over 18 months, treat it as a liability — look for an actively maintained alternative before your next PHP jump forces the issue.
- Set display_errors = Off as a baseline on every production site, regardless of PHP version. Debugging should happen on staging with errors visible, not on the live site with visitors watching.
- Move up one version at a time when you can. Going 7.4 → 8.1 → 8.2 → 8.3 over a few months surfaces issues in smaller, more manageable batches than one big jump.
None of this is really about deprecation notices being dangerous — they're not, on their own. The real risk is running a production site with PHP's raw output facing your visitors, which is a bad idea whether the message is a harmless deprecation notice or something more serious. Fix the config once and this stops being a recurring fire drill every time PHP moves forward.
Frequently Asked Questions
Will hiding deprecation warnings break something later?
No — setting display_errors to Off only changes whether errors are shown in the browser. They're still written to the log with log_errors on, so you can review them anytime. The underlying deprecated code still runs exactly the same either way; you're just choosing not to expose it to site visitors.
Should I just downgrade back to PHP 7.4 to make the warnings go away?
Not a good long-term move. PHP 7.4 has been end-of-life for years and no longer receives security patches, so running it reintroduces real vulnerabilities to dodge a cosmetic warning. Suppress the display, fix the plugins over time, and stay on a supported version.
Why did I only see these warnings after switching PHP versions, not before?
Deprecation notices are new to each PHP release — code that was perfectly valid on 7.4 can trigger a deprecated notice on 8.1 or 8.2 simply because that check didn't exist yet in the older engine. The code didn't change; the rules did.
My error_log file is inside public_html and visible to the public — is that a problem?
Yes, treat it as a minor information disclosure risk. Anyone who guesses or finds the URL can read your file paths and plugin versions. Once you've reviewed it, either delete it, move error logging outside the web root via the error_log directive in MultiPHP INI Editor, or block direct access to *.log files with a rule in .htaccess.
I fixed display_errors but headers-already-sent errors are still happening. What now?
Check for stray output ahead of the opening <?php tag in any theme or plugin file you or a developer touched recently — a blank line, a byte-order-mark character, or even a space before the tag will do it. That's a separate cause from the deprecation notices and needs to be fixed directly in the file.
