Skip to main content

Refactoring Legacy PHP: Fixing 'Creation of dynamic property is deprecated' in PHP 8.2

 The logs on your newly upgraded PHP 8.2 server are likely flooding with a specific deprecation notice:

Deprecated: Creation of dynamic property ClassName::$propertyName is deprecated

For over a decade, PHP treated objects as open structures. If you assigned a value to a property that didn't exist in the class definition, PHP silently created it at runtime. This behavior was foundational for many legacy ORMs, CodeIgniter models, and WordPress plugin settings parsers.

As of PHP 8.2, this implicit behavior is deprecated. In PHP 9.0, it will throw a fatal ErrorException. This shift signals PHP's maturation into a language that prioritizes structured, predictable type systems over runtime flexibility.

The Root Cause: Why PHP Changed

Historically, dynamic properties were a side effect of PHP's dynamic typing. Under the hood, if a property wasn't found in the class definition (the object's hash table of properties), PHP would simply append it to the object instance.

While convenient, this caused two major architectural issues:

  1. Fragility: A typo in a property assignment ($user->nmae = 'John') would silently succeed, creating a new property instead of updating $user->name. This leads to logical bugs that are incredibly difficult to trace.
  2. Performance & Memory: To support dynamic properties, the PHP engine cannot optimize memory layout for objects as aggressively as it can for strictly defined classes (shapes).

PHP 8.2 enforces the concept that a Class is a strict blueprint, not a dynamic hash map. Exceptions are made strictly for stdClass and classes implementing __get/__set magic methods.

The Fix: Three Strategies

Do not blindly suppress these errors. Depending on the context of your legacy code, choose one of the following three implementation strategies.

Strategy 1: The Modern Refactor (Explicit Definitions)

Use case: Domain entities, Services, and core business logic.

This is the technically correct approach. It involves explicitly declaring properties. This improves IDE autocompletion, static analysis (PHPStan/Psalm), and memory usage.

Legacy Code (Broken in 8.2):

class UserProfile {
    public function __construct(array $data) {
        // Legacy "hydration" pattern
        foreach ($data as $key => $value) {
            $this->$key = $value; // Triggers Deprecation in 8.2
        }
    }
}

$user = new UserProfile(['id' => 101, 'role' => 'editor']);

Refactored Code (PHP 8.2+):

class UserProfile {
    // 1. Explicitly declare properties
    // 2. Use types for strictness (optional but recommended)
    public int $id;
    public string $role;
    public ?string $bio = null; // Nullable for optional fields

    public function __construct(array $data) {
        $this->id = $data['id'];
        $this->role = $data['role'];
        
        // Handle optional fields safely
        if (isset($data['bio'])) {
            $this->bio = $data['bio'];
        }
    }
}

$user = new UserProfile(['id' => 101, 'role' => 'editor']);

Strategy 2: The "Hotfix" Attribute

Use case: Vendor libraries you cannot deeply refactor, massive legacy God-objects, or WordPress plugins relying on hook-injected properties.

PHP 8.2 introduces the #[AllowDynamicProperties] attribute. This instructs the compiler to disable the deprecation check for that specific class and its children.

Legacy Code (Broken in 8.2):

namespace MyPlugin\Legacy;

class APIResponseParser {
    public function parse($json) {
        $data = json_decode($json);
        $this->original_payload = $json; // Undeclared property
        $this->timestamp = time();       // Undeclared property
        return $data;
    }
}

Refactored Code (PHP 8.2+):

namespace MyPlugin\Legacy;

// Import the attribute (built-in to PHP 8.2)
use AllowDynamicProperties;

#[AllowDynamicProperties]
class APIResponseParser {
    public function parse(string $json): object {
        $data = json_decode($json);
        
        // These assignments are now valid and silent
        $this->original_payload = $json;
        $this->timestamp = time();
        
        return $data;
    }
}

Note: Classes extending a class marked with #[AllowDynamicProperties] inherit this behavior.

Strategy 3: The Data Bag Pattern (stdClass)

Use case: Configuration arrays converted to objects, or JSON blobs where the shape is unknown or highly variable.

If a class has no methods and is used purely to transport arbitrary data, it shouldn't be a custom class. stdClass is explicitly exempt from the deprecation.

Legacy Code (Broken in 8.2):

class ConfigContainer {}

$config = new ConfigContainer();
$config->debug = true;        // Deprecated
$config->cache_ttl = 3600;    // Deprecated

Refactored Code (PHP 8.2+):

// Option A: Use stdClass directly
$config = new \stdClass();
$config->debug = true;
$config->cache_ttl = 3600;

// Option B: Extends stdClass (if you need type hinting)
class ConfigContainer extends \stdClass {
    // stdClass subclasses inherit dynamic property capabilities
}

$config = new ConfigContainer();
$config->custom_flag = 'enabled'; // Valid

Architectural Explanation

The chosen fix determines the future maintainability of the codebase.

  1. Explicit Declaration moves the code toward Type Safety. It allows tools like PHPStan to detect bugs during CI/CD rather than in production. It documents the intent of the class: "This object must have an ID and a Role."
  2. #[AllowDynamicProperties] is an opt-in degradation of strictness. It is essentially a flag telling the engine, "I know this is legacy behavior, suppress the warning." It is useful for migration but should ideally be treated as technical debt in domain logic.
  3. stdClass indicates that the data is unstructured. It tells future developers not to expect a consistent interface from the object.

Implementation Logic

When the PHP interpreter encounters a property assignment:

  1. It checks if the property exists in the class definition. If yes, it assigns the value.
  2. If no, it checks if __set() is defined. If yes, it calls the magic method (no deprecation).
  3. If no, it checks if the class (or parent) has #[AllowDynamicProperties] or extends stdClass. If yes, it creates the property dynamically (no deprecation).
  4. If none of the above apply, it raises the Deprecation notice.

Conclusion

The deprecation of dynamic properties is a push toward better software architecture. While #[AllowDynamicProperties] provides a quick path to silence logs and maintain uptime, the Principal Engineer's roadmap should prioritize refactoring core entities to use explicit property declarations. This aligns your legacy codebase with modern standards, enabling better tooling, performance, and reduced logical errors.

Labels: