Find And Fix Deprecated Code In PhpStorm

PhpStorm can find deprecated functions, methods, classes, properties, and language features while you type or across an entire project. The useful workflow is not simply to replace every warning. First confirm the target PHP, WordPress, WooCommerce, and library versions, then test each supported replacement.

Quick path: Open Settings > Editor > Inspections, search for deprecated, enable the relevant PHP inspection, then use Code > Inspect Code to scan a chosen scope.

What deprecated code means

A deprecated API still exists but its maintainer advises against new use and may remove it later. Deprecation is a migration signal, not proof of a security vulnerability or performance problem. The replacement can also require different parameters, return values, error handling, or minimum versions.

Configure the project before scanning

Set the project’s PHP language level to the production target, not the newest version installed locally.
Configure the correct PHP interpreter and Composer dependencies so PhpStorm can resolve symbols.
Load WordPress, WooCommerce, plugin, and theme stubs or source code where appropriate.
Exclude generated files, vendor code you do not own, caches, and build output from the remediation scope.
Create a version-control branch and capture a passing test baseline.

Wrong project metadata creates noisy or misleading results. A function may be valid for production but deprecated in a newer configured language level. A WordPress wrapper may be preferred even when raw PHP is available.

Enable and tune the inspection

Open Settings on Windows or Linux, or Preferences on macOS.
Go to Editor, then Inspections.
Search for deprecated and review the matching PHP inspections.
Enable the inspection and choose a severity that fits the team’s policy.
Save the inspection profile in the project when the team should share it.

PhpStorm inspection profiles define enabled checks, severities, and scopes. Use a stricter scope for application code and a different policy for tests, fixtures, generated code, or supported compatibility layers.

Scan a file, change set, directory, or whole project

PhpStorm checks open files continuously. For a complete report, choose Code > Inspect Code, select the scope and profile, then run the analysis. Useful scopes include uncommitted files for daily work, a plugin or theme directory for focused upgrades, and the whole project before a platform migration.

To run only one check, use Run Inspection by Name and search for the deprecated inspection. Review results in the Problems or inspection results window, group them by library or owner, and export findings when a larger migration needs tracking.

Review each result before applying a fix

Open the upstream deprecation notice and identify the supported replacement.
Check the version in which the replacement became available.
Confirm parameter, return-type, exception, and side-effect differences.
Search for indirect callers, hooks, filters, mocks, and integrations.
Decide whether a compatibility wrapper is required during a staged upgrade.
Add or update tests before changing risky behavior.

Use Alt+Enter or Option+Enter to inspect available quick fixes. Apply them in small batches. An automated replacement can be syntactically valid while changing behavior.

WordPress-specific deprecation checks

PhpStorm understands PHP deprecation metadata, but WordPress also reports deprecated functions and hooks at runtime. In a non-production environment, enable WordPress debugging and exercise representative journeys. Add WordPress Coding Standards and PHPCompatibility rules to CI for another layer of detection.

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

Never expose debug output on a public production site. Review logs for _deprecated_function, _deprecated_argument, hooks, constructors, and notices from real request paths.

Make deprecation checks part of delivery

Run inspections on modified files before commit.
Store the shared inspection profile in version control.
Use Qodana or another supported CI method to run the same policy centrally.
Combine IDE findings with PHPUnit, integration tests, WPCS, PHPCompatibility, and representative browser tests.
Set a baseline for legacy findings and block newly introduced deprecations.
Assign owners and deadlines based on removal version and business risk.

A safe remediation sequence

Inventory supported runtime and dependency versions.
Group findings by PHP, WordPress, WooCommerce, vendor library, and custom API.
Fix code that will fail in the next planned upgrade first.
Use compatibility layers only while multiple supported versions require them.
Test editor, frontend, cron, REST API, CLI, checkout, and background jobs as relevant.
Deploy gradually, watch logs, and retain a rollback artifact.
Remove temporary compatibility code after the older platform version is retired.

Common mistakes

Scanning against the wrong PHP language level
Editing vendor code instead of upgrading or patching the dependency responsibly
Accepting every quick fix without tests
Suppressing warnings without a documented reason and review date
Treating deprecation as proof of a vulnerability
Checking only code paths opened in the IDE
Upgrading production before testing cron, CLI, REST, and background tasks

For a large plugin, theme, or enterprise platform upgrade, enterprise WordPress development consulting can turn the findings into a staged compatibility and release plan.

Primary sources

Frequently asked questions

It can detect deprecations visible through configured language metadata, source, stubs, and inspections. Runtime-only paths and dynamically resolved APIs still need tests and logs.

Prioritize items that block a planned upgrade, affect supported platforms, or carry meaningful risk. Track justified exceptions with an owner and review date.

They are useful starting points, but they cannot guarantee equivalent behavior. Review the upstream migration notes and run tests.

Choose an uncommitted-files scope in Inspect Code or configure code analysis as a commit check.

Yes. JetBrains documents Qodana and command-line inspection options. Use a shared profile so local and CI results match.

Combine PhpStorm with WordPress debug logs, WPCS, PHPCompatibility, automated tests, and representative requests across web, cron, REST, and WP-CLI.