Real-world reality (read this first)
PHP 8.1 reaches its absolute end-of-life (EOL) on 31 December 2025. After this date, it will receive no security fixes and no bug fixes. As a result, PHP 8.2 becomes the minimum supported PHP version for any Magento project that intends to remain secure, compliant, and supportable.
In an ideal world, every Magento merchant would already be running on PHP 8.2 or newer. In reality, that is rarely the case.
In real Magento projects:
• Many merchants have not yet migrated to PHP 8.2
• Some are not even on a currently supported PHP version
• Upgrades are blocked by third-party extensions, hosting constraints, or budget cycles
• Production, CI, and local development often run different PHP versions
It is common for production to lag behind while CI pipelines, Docker images, or cloud environments already run PHP 8.2+. When this happens, legacy code that “worked yesterday” suddenly starts emitting deprecation warnings or failing builds.
Dynamic properties are one of the most common examples. Nothing new was added to the codebase — the environment changed, and the code was never future-proof.
This is why these issues must be fixed proactively, regardless of the merchant’s current PHP version.
Introduction
PHP 8.2 introduced stricter object-model rules that directly affect legacy Magento 2 code. The most common issue that surfaces immediately is:
• Dynamic property creation is deprecated
In Magento projects, this problem is amplified by interceptors, generated code, and long-lived legacy patterns copied from older Magento versions.
This post explains what changed in PHP 8.2, why Magento makes the issue more visible, how to fix it correctly, and how AI can be used to systematically scan and refactor all custom code safely. A reusable, agent-agnostic refactoring prompt is included at the end.
What changed in PHP 8.2
Before PHP 8.2, assigning to an undeclared property silently created it at runtime:
$this->_dependency = $dependency;
From PHP 8.2 onwards, this behaviour is deprecated and emits warnings that are expected to become fatal errors in future PHP releases.
Dynamic properties are now treated as a clear signal of outdated code rather than a harmless convenience.
Why Magento surfaces this problem everywhere
Magento generates interceptor classes for most injectable classes. Interceptors extend the original class and proxy method calls.
This has an important consequence:
• Interceptors do not declare your dynamic properties
• PHP raises the deprecation at runtime
• The warning references the interceptor, not your class
• The real bug still lives in your custom code
Generated code must never be modified. The fix always belongs in the original class.
Problem: Dynamic properties
A very common legacy pattern in custom Magento modules looks like this:
$this->_dependency = $dependency;
$this->_logger = $logger;
$this->_resource = $resource;
When these properties are not declared on the class, PHP 8.2 flags them immediately.
Incorrect pattern:
class ExampleCommand extends Command
{
public function __construct(SomeService $service)
{
$this->_service = $service;
parent::__construct();
}
}
Why this fails
• _service is never declared on the class
• PHP creates it dynamically at runtime
• PHP 8.2 deprecates this behaviour
• Magento interceptors expose the issue immediately
Correct fix
Declare the property explicitly, type it, and assign to it.
class ExampleCommand extends Command
{
protected SomeService $service;
public function __construct(SomeService $service)
{
$this->service = $service;
parent::__construct();
}
}
Constructor property promotion may be used where appropriate:
class ExampleCommand extends Command
{
public function __construct(
protected SomeService $service
) {
parent::__construct();
}
}
Both approaches are fully compatible with PHP 8.2 and Magento interceptors.
Using AI to scan and fix custom code
In real Magento codebases, dynamic properties are rarely isolated to a single class. They are typically spread across dozens or hundreds of custom modules, often introduced over many years.
This is where AI-assisted refactoring becomes practical.
By using an AI or LLM-based code agent, you can:
• Systematically scan all custom modules
• Identify dynamically assigned properties
• Detect missing property declarations
• Apply consistent, safe refactors
• Preserve behaviour while modernising the code
This allows teams to clean entire Magento codebases quickly and safely, instead of fixing warnings one file at a time.
Why #[AllowDynamicProperties] is not a solution
You may see suggestions to add:
#[AllowDynamicProperties]
This only suppresses the warning.
Problems with this approach:
• It hides real issues
• It preserves legacy patterns
• It provides no long-term value
• It will not survive future PHP versions
This should not be used in production Magento code.
Why fixing this matters even if the merchant is behind
Even if a merchant is not yet on PHP 8.2:
• CI or local environments may already be
• PHP 8.1 EOL on 31 December 2025 makes upgrading unavoidable
• Platform upgrades will force it eventually
• The fix is backward-compatible
• Runtime behaviour does not change
• Technical debt is reduced immediately
Declaring properties explicitly works on older PHP versions and is mandatory on newer ones, making this change both safe and future-proof.
Agent-agnostic refactoring prompt
This prompt can be used with any code agent or LLM-based refactoring tool, not tied to a specific vendor or product.
Act as a senior Magento 2 developer targeting PHP 8.2+.
Task:
Refactor Magento 2 custom module classes to be compatible with PHP 8.2+, fixing
dynamic property usage.
Given a single Magento 2 PHP class:
- Identify any dynamically assigned properties that are not explicitly declared
- Refactor the class to eliminate dynamic properties
Requirements:
- Declare all properties explicitly where they belong
- Use typed properties
- Prefer constructor property promotion where appropriate
- Use Magento dependency injection correctly
- Preserve existing behaviour and logic
- Be compatible with Magento interceptors
- Do NOT modify generated or interceptor code
- Do NOT use #[AllowDynamicProperties]
- Use strict typing
- Avoid deprecated classes or patterns
Target environment:
- Magento 2 / Adobe Commerce
- PHP 8.2+
- No Breeze usage
Input:
- One PHP class
Output:
- The corrected version of that class only
Conclusion
PHP 8.2 is not merely stricter — it is enforcing correctness. With PHP 8.1 reaching end-of-life on 31 December 2025, dynamic properties are no longer a theoretical concern but a concrete upgrade blocker.
Using AI to scan and refactor all custom Magento code allows teams to remove this technical debt quickly, consistently, and safely — turning a painful upgrade blocker into a controlled, automated cleanup.
Comments