How PHP 8.2 Warnings Broke WordPress Tools (And How to Fix It)

Imagine a frustrating scenario: your multi-site WordPress maintenance tool reports that everything is fine—all diagnostics pass, the WP-CLI connection works, the version check returns green—but when it runs the actual operation, the whole thing fails. You're seeing "all tests pass, but production breaks." On July 4, 2026, this exact problem was documented in a post on DEV Community, and it reveals something important about how software fails: sometimes the gap between a passing diagnostic and a failing operation hides a subtle structural problem.

The Problem: Warnings Pollute Your JSON

When older WP-CLI 2.x runs on PHP 8.2 or newer, something unexpected happens. PHP 8.2 added a new deprecation warning: you cannot assign to a dynamic property on a class unless that class explicitly allows it with the #[\AllowDynamicProperties] attribute. Older WP-CLI—which still uses dynamic properties internally—triggers these warnings constantly. By itself, that's not a disaster. Warnings are just warnings. Code still runs.

The real trouble comes from your server's php.ini configuration. Depending on the display_errors setting, those warnings end up printing directly to stdout—the same output stream where your JSON data appears.

So when you run a command like wp plugin list --format=json expecting clean JSON, you get something like this instead:

PHP Deprecated: Creation of dynamic property WP_CLI\Dispatcher\CompositeCommand::$longdesc is deprecated... [ {"name":"akismet","status":"active","update":"none"...}, ... ]

That warning line before the JSON array breaks json_decode(). Your tool tries to parse it, fails, and crashes.

Why Diagnostics Lie

Here's the insidious part: diagnostics can pass while the real operation fails because they test different things.

When you run an SSH connection test—say, echo ok—the test just checks that "ok" appears somewhere in the output. Extra lines are fine. When you run wp --version, the test just looks for a version number. Find it? Pass.

But when you run wp plugin list --format=json, the real operation parses the output as JSON. The warnings that simple-text tests ignore suddenly matter. A diagnostic that doesn't actually parse JSON as JSON never sees the problem coming.

This is why the user sees "all my tests are green, but the real call fails"—a frustrating asymmetry between what the diagnostics check and what the actual operation requires.

Three Layers of Defense

You could try to suppress all the warnings globally, but you can't predict every hosting provider's PHP configuration. Instead, the solution uses three independent defense layers. If one fails to catch the noise, the next one does.

Layer 1: Silence Warnings at the Source

WP-CLI accepts an environment variable called WP_CLI_PHP_ARGS that gets passed to the underlying PHP invocation. You can use this to adjust the error_reporting level, telling PHP to ignore Deprecated and User Deprecated warnings:

php WP_CLI_PHP_ARGS="-d error_reporting='E_ALL ~E_DEPRECATED ~E_USER_DEPRECATED'"

The syntax ~E_DEPRECATED means "exclude Deprecated warnings." You still see Parse Errors and Fatal Errors—those are real failures—but the noise gets quieted.

This layer works for most hosting environments. When a host hasn't added extra runtime overrides, the warnings never make it to stdout.

Layer 2: Strip Noise Lines Before Parsing

But some hosts are aggressive. They run ini_set() in their PHP scripts, overriding error_reporting at runtime after you've set it via WP_CLI_PHP_ARGS. The warnings slip through anyway.

For defense in depth, you can regex-match and remove recognized noise lines from the output before trying to parse JSON:

python PHP_NOISE_LINE_RE = re.compile( r'^\sPHP\s+(Deprecated|Warning|Notice|Strict Standards):.$', re.MULTILINE | re.IGNORECASE )

def strip_php_noise(text): return PHP_NOISE_LINE_RE.sub('', text)

Note what this regex doesn't match: "Parse error" and "Fatal error." Those are real failures, not noise. The deliberate omission matters. You want to strip annoyances, but let real breakage through.

Layer 3: Try JSON Parse Before Trusting Exit Codes

A small number of hosts return exit code 1 (failure) just because warnings were emitted—even though valid JSON sits in stdout. If you bail out on a nonzero exit code without checking, you miss the data that's actually there.

Instead, attempt to parse JSON from stdout first, then check the exit code:

python stdout_clean = strip_php_noise(res.stdout or '').strip() plugins = None

if stdout_clean: try: plugins = json.loads(stdout_clean) except json.JSONDecodeError: plugins = None

if plugins is None: # Only here do we give up if not res.ok: return error_response(res.stderr or res.stdout)

If the JSON parses, treat the call as successful even if the exit code says otherwise. The structured data is what matters.

How to Apply This to Your Code

Step 1: Wrap WP-CLI Calls with Quiet PHP Args

Create a helper that prepends the environment variable:

python def wp_with_quiet_php(wp_cli_path): quiet_args = "-d error_reporting='E_ALL ~E_DEPRECATED ~E_USER_DEPRECATED'" return f"WP_CLI_PHP_ARGS='{quiet_args}' {wp_cli_path}"

Step 2: Clean Stdout Before JSON Parse

Always strip noise lines before attempting json.loads():

python output = run_command(wp_with_quiet_php(wp_path) + ' plugin list --format=json') clean_output = strip_php_noise(output.stdout).strip() if clean_output: plugins = json.loads(clean_output)

Step 3: Check for JSON Before Exit Code

Attempt parsing first. Only trust the exit code if parsing fails:

python if plugins is None and not result.ok: raise Exception(result.stderr or result.stdout)

Step 4: Fix All Call Sites

Search your codebase for every place that calls json.loads() on WP-CLI output. Apply the same three-layer defense everywhere. One unfixed call site leaves the vulnerability alive on a different code path.

Step 5: Write Tests

Add regression tests that check:

• Noise line removal works correctly
• Parse errors and Fatal errors are not stripped
• Environment variable quoting is safe
• All three API endpoints use the fix

If a future developer adds a fourth API that calls json.loads() directly on raw output, tests should fail immediately.

Why This Matters in 2026

We're in a transition period. PHP 8.2 and 8.3 are now standard on many hosting providers, but plenty of older WordPress plugins and tools haven't been updated yet. WP-CLI 2.x is widely deployed. The gap between "the code still works" and "the output is clean enough to parse" is real, and it's invisible to simple diagnostics. As more teams adopt structured outputs (JSON APIs, logging pipelines, automation), this class of bug—where warnings poison the data stream—will keep surfacing until libraries modernize.

Conclusion

The real lesson isn't specific to WordPress or PHP 8.2. It's about layering independent defenses and testing at the right abstraction level. When diagnostics only check for "does the substring appear," they miss failures that show up only at the parsing stage. When you silence warnings globally, you risk hiding real errors. When you trust exit codes over data, you miss valid output that still matters.

The three-layer fix—suppress at the source, filter before parse, and prioritize structured data over exit codes—works because each layer catches a different failure mode. One layer fails, the next catches it.

Merits

• Catches invisible failures. Diagnostics can now detect the real problem, not just the symptoms.
• Defense in depth. No single hosting quirk breaks the tool; multiple layers catch different leakage paths.
• Preserves real errors. Parse errors and Fatal errors still surface; only noise is filtered.
• Works with existing WP-CLI. No need to update or replace the older tool; the fix layers around it.
• Testable. Each layer can be tested independently; regressions are caught early.

Demerits

• Adds complexity. Three layers instead of one means more code to maintain and understand.
• Regex brittleness. The noise-filtering regex might miss new warning formats introduced in future PHP versions.
• Doesn't fix the root cause. These are workarounds, not upgrades to modern WP-CLI or PHP compatibility.
• False negatives possible. If a future PHP version changes its error message format, the regex won't match it.

Caution

This article is educational. When applying the code examples, replace any placeholder values (like wp_cli_path or command paths) with your actual environment values. Test thoroughly in a non-production environment first. Verify all claims and examples against the original source material on DEV Community before relying on them in production. The specific error_reporting flags and regex patterns should be tested against your own PHP and WP-CLI versions to ensure compatibility.

Frequently asked questions

• What is dynamic property deprecation in PHP 8.2?
• How do I check if my host has display_errors enabled?
• Can I upgrade WP-CLI instead of using these workarounds?
• Why don't simple exit code checks catch this problem?
• How do I test that my JSON parsing is noise-resistant?
• What other command outputs might have the same warning-pollution issue?
• Should I disable all PHP warnings globally?
• How do I know if a warning is safe to filter out?

Tags

#php #wordpress #wpcli #json #devops #errors #automation #hosting