← Back to all briefings
Developer 5 min read Published Updated Credibility 86/100

Runtime Briefing — PHP 8.2 Introduces Readonly Classes

PHP 8.2 adds readonly classes, disallows dynamic properties by default, introduces standalone true/false types, and expands sensitive parameter redaction—requiring developers to plan code audits, performance tests, and staged rollouts.

Zeph Tech Research Lead

Research lead, Zeph Tech

Timeline plotting source publication cadence sized by credibility.
3 publication timestamps supporting this briefing. Source data (JSON)

Executive briefing: PHP 8.2.0 became generally available on 8 December 2022, introducing language features and hardening changes that affect application design, backward compatibility, and security posture. Highlights include readonly classes, a new #[SensitiveParameter] attribute for redacting secrets in stack traces, and the enforcement of disallowed dynamic properties by default. The release also brings standalone true, false, and null types, improvements to enums, and updates to bundled extensions like random. Engineering teams should plan migrations carefully, combining static analysis, integration testing, and operational readiness checks to ensure a smooth upgrade from PHP 8.0 or 8.1.

PHP 8.2 continues the language’s rapid cadence of feature releases following the JIT improvements in PHP 8.0 and the enums and fibres introduced in PHP 8.1. Organisations should treat this update as part of their application modernisation roadmap, particularly as PHP 7.4 reached end of life in November 2022. Upgrading to PHP 8.x is now essential to maintain security support.

Language and runtime features

  • Readonly classes. Applying the readonly keyword to a class declaration makes all its properties readonly, reinforcing immutability and thread safety. This is especially useful for DTOs, value objects, and configuration carriers. Developers must ensure properties are initialised in the constructor and avoid reflection-based modifications.
  • Disallow dynamic properties. PHP 8.2 promotes the #[AllowDynamicProperties] attribute but, by default, assigning to undeclared properties triggers a Deprecated notice (and will become fatal in PHP 9). Legacy code relying on dynamic property injection must be refactored to use typed properties, magic methods, or stdClass. Static analysers such as PHPStan and Psalm can help identify violations.
  • Standalone types. The type system now supports true, false, and null as standalone types, enabling more precise signatures. For example, function flag(): true enforces a function returning only true.
  • Disjunctive Normal Form (DNF) types. While introduced in PHP 8.1, PHP 8.2 improves DNF type handling, allowing complex unions of intersections that benefit advanced generics and framework internals.
  • Constants in traits. Traits can now declare constants, aiding reuse patterns in codebases that rely heavily on mixins.
  • Fetch enum properties in const expressions. Developers can access enum case properties within constant expressions, facilitating configuration arrays.

Security and observability enhancements

The new #[SensitiveParameter] attribute masks annotated arguments in stack traces and error logs, reducing accidental exposure of secrets. Framework maintainers should adopt the attribute in controllers, authentication flows, and payment integrations. Operations teams should validate that logging configurations respect the new masking behaviour and adjust scrubbing rules accordingly.

PHP 8.2 updates the random extension, providing a new Random\Randomizer class with pluggable engines, including secure and fast generators. Applications should review usage of mt_rand() or rand(), migrating to the new APIs for improved clarity and testability.

The release hardens password hashing and OpenSSL integrations, shipping with updated libraries and supporting libargon2 improvements. Ensure container images or OS packages provide the required crypto libraries.

Backward-incompatible changes and deprecations

Migrations must account for several breaking changes:

  • Dynamic properties on user-defined classes now emit deprecation notices. Use #[AllowDynamicProperties] temporarily while refactoring.
  • ${var} string interpolation now throws a deprecation warning when ambiguous. Update code to use curly braces explicitly.
  • Partially supported callables (e.g., strings referencing non-static methods) produce deprecation notices. Transition to first-class callables.
  • Locale-sensitive strtolower() and strtoupper() conversions have been aligned to use Unicode semantics, which may change behaviour in legacy applications.
  • The utf8_encode() and utf8_decode() functions are deprecated. Migrate to mb_convert_encoding().

Review the migration guide for a complete list, including adjustments to XML parser warnings, setcookie() options, and libcurl default behaviours.

Migration planning

Successful adoption of PHP 8.2 requires disciplined project management:

  • Inventory and assessment. Catalogue PHP applications, CLI scripts, and background workers. Record PHP versions, framework dependencies (Laravel, Symfony, WordPress), and third-party extensions. Identify components still on PHP 7.x and prioritise upgrades.
  • Static analysis. Run PHPStan/Psalm with PHP 8.2 rulesets to surface dynamic property usage, deprecated APIs, and incompatible signatures. Integrate results into issue trackers with remediation owners.
  • Automated testing. Execute unit, integration, and end-to-end tests under PHP 8.2. Configure CI to run test matrices across PHP 8.0, 8.1, and 8.2 until cutover.
  • Performance benchmarking. Measure response times and memory usage. YJIT remains optional but consider enabling opcache.jit adjustments as part of tuning.
  • Dependency upgrades. Update Composer dependencies to versions compatible with PHP 8.2. Check for extensions that lag behind (e.g., ionCube loaders, proprietary drivers) and coordinate with vendors.
  • Operational readiness. Validate monitoring agents, APM integrations, and error reporting tools (Sentry, New Relic) for PHP 8.2 support. Update Dockerfiles, Helm charts, and configuration management to install the new runtime.

Outcome testing and validation

After deployment, conduct post-upgrade assurance:

  • Monitor deprecation logs to ensure no residual dynamic property usage persists.
  • Track error rates, slow queries, and CPU utilisation to confirm stability.
  • Audit logs for secrets to confirm #[SensitiveParameter] masking works as intended.
  • Validate security scanners (SCA, SAST, DAST) against new runtime, updating baselines and rulepacks.

Training and documentation

Update internal coding standards to incorporate readonly patterns, precise typing, and sensitive parameter usage. Provide lunch-and-learn sessions or documentation on migrating frameworks (Laravel 9+, Symfony 6.2) that already support PHP 8.2. Encourage developers to run php -m and php -i to verify extension compatibility during local development.

Roadmap alignment

PHP 8.2 marks the latest annual release in the PHP calendar. Security support for PHP 8.1 continues through November 2025, while PHP 8.2 receives active support for two years and security support for an additional year. Plan lifecycle management accordingly, scheduling upgrades to PHP 8.3 (expected December 2023) once frameworks provide compatibility. Maintaining currency reduces exposure to unpatched vulnerabilities and keeps pace with ecosystem tooling enhancements.

By embracing PHP 8.2 with structured testing, security reviews, and developer education, organisations can improve code quality, strengthen defences, and deliver more predictable software releases.

Support lifecycle and governance

PHP 8.2 will receive active support with bug fixes until December 2024 and security fixes until December 2025. Organisations running long-lived applications should align upgrade cycles with this cadence and ensure decommissioning plans for PHP 7.4 and 8.0 are executed because those branches no longer receive security updates. Governance forums—such as the PHP Foundation and framework maintainers (Laravel, Symfony, Magento)—have published compatibility matrices that can be referenced during change approvals.

Security and compliance teams should also revisit secure coding standards, update secure configuration baselines (php.ini templates, OpCache settings, FPM pool definitions), and document how PHP 8.2 aligns with frameworks like OWASP ASVS or PCI DSS. Creating architecture decision records that capture the rationale for upgrading, test evidence, and rollback plans will support audits and knowledge transfer.

Timeline plotting source publication cadence sized by credibility.
3 publication timestamps supporting this briefing. Source data (JSON)
Horizontal bar chart of credibility scores per cited source.
Credibility scores for every source cited in this briefing. Source data (JSON)

Related briefings

Curated signals from the same pillar or overlapping topics.

Continue in the Developer pillar

Return to the hub for curated research and deep-dive guides.

Visit pillar hub

Latest guides

  • PHP release
  • Application modernization
  • Secure coding
  • Migration testing
Back to curated briefings