“Creation of dynamic property … is deprecated” in WordPress

What the message means

A class is the blueprint a plugin uses to create objects, and it lists the named values (the properties) those objects have. For a long time PHP also let code store a value under a name the class never listed: PHP quietly created a dynamic property. PHP 8.2 deprecated that: “The creation of dynamic properties is deprecated, unless the class opts in by using the #[\AllowDynamicProperties] attribute.” (php.net)

This is the real message PHP 8.2 writes for a plugin that does it:

Output on PHP 8.2.34

Deprecated: 1Creation of dynamic property Newsletter_Box::$title is deprecated in /var/www/html/2wp-content/plugins/newsletter-box/includes/3class-newsletter-box.php on line 4
Subscribe to our newsletter

What happened: the class Newsletter_Box stores a value called title that it never declared.
Which plugin: the folder after wp-content/plugins/ (or wp-content/themes/) names the plugin (or theme): here, newsletter-box.
Where exactly: the file and line, for whoever fixes the code.

Is it urgent?

No. A deprecation notice doesn’t stop anything: PHP writes the message, then does exactly what it did before. We ran the same code on PHP 8.1 to 8.5: PHP 8.1 says nothing, PHP 8.2 to 8.5 add the notice, and the result is the same on all five (the outputs are in the developer section below).

It will need a fix at some point. The proposal that introduced the notice, accepted by PHP’s developers, says: “The creation of dynamic properties on classes that aren’t marked with the #[AllowDynamicProperties] attribute is deprecated in PHP 8.2 and becomes an Error exception in PHP 9.0.” (PHP RFC) The PHP versions released so far, up to 8.5, only show the notice.

It is one of several deprecations since PHP 8.2; the ones PHP 8.5 adds are in WordPress and PHP 8.5: what breaks, what only shows notices.

Who fixes it

The notice comes from the plugin’s or theme’s code, not from a setting on your site, so the fix belongs there:

Find the plugin or theme: it’s the folder name after wp-content/plugins/ or wp-content/themes/ in the message.
Update it (Dashboard → Updates). Its developer may already have fixed the notice.
Already on the latest version? Send the full message to its developer, through the plugin’s support forum on wordpress.org or its website. The fix is a small change for them.
Don’t edit the plugin’s files yourself: your changes are lost with its next update.

Keep it off your pages

Visitors should never see PHP messages. If “Deprecated: …” appears on your pages, the site is set to display PHP messages:

On a live site, WP_DEBUG in wp-config.php is normally false. WordPress then asks PHP to report fatal errors and warnings, but not notices or deprecation notices (WordPress 7.1.2 source).
If you want a record while you follow up with the developer, write messages to a log instead of the page: WP_DEBUG and WP_DEBUG_LOG on, WP_DEBUG_DISPLAY off (developer.wordpress.org).

New to wp-config.php? How to edit it safely

Make a copy first. Download the file, or duplicate it, so you can put it back if something goes wrong.
Open the file. In your hosting control panel, open the File Manager and go to your WordPress folder (often called public_html). wp-config.php is usually there, next to the wp-admin and wp-content folders. You can also use an FTP program with the FTP details your host gives you.
Find the right place. Add new lines above the line /* That's all, stop editing! Happy publishing. */ (on older sites it ends with “Happy blogging”). If a line with the same name is already there, for example define( 'WP_DEBUG', false );, change that line instead of adding a second one.
Save, then reload your site. If it shows an error, put your copy back.

Not comfortable doing this? Ask your host’s support to make the change; it’s a routine request.

Keep in mind that this only hides the message from visitors: the plugin still does the deprecated thing until its code changes.

For developers

Each example ran on the official PHP builds; the outputs are unedited.

The notice appears in PHP 8.2. The same class on PHP 8.1 and 8.2:

wp-content/plugins/newsletter-box/includes/class-newsletter-box.php

<?php
class Newsletter_Box {
    public function __construct() {
        $this->title = 'Subscribe to our newsletter';
    }
}

$box = new Newsletter_Box();
echo $box->title, "\n";

Output on PHP 8.1.34

Subscribe to our newsletter

Output on PHP 8.2.34

Deprecated: Creation of dynamic property Newsletter_Box::$title is deprecated in /var/www/html/wp-content/plugins/newsletter-box/includes/class-newsletter-box.php on line 4
Subscribe to our newsletter

The same code on PHP 8.3, 8.4 and 8.5

Output on PHP 8.3.35

Deprecated: Creation of dynamic property Newsletter_Box::$title is deprecated in /var/www/html/wp-content/plugins/newsletter-box/includes/class-newsletter-box.php on line 4
Subscribe to our newsletter

Output on PHP 8.4.26

Deprecated: Creation of dynamic property Newsletter_Box::$title is deprecated in /var/www/html/wp-content/plugins/newsletter-box/includes/class-newsletter-box.php on line 4
Subscribe to our newsletter

Output on PHP 8.5.11

Deprecated: Creation of dynamic property Newsletter_Box::$title is deprecated in /var/www/html/wp-content/plugins/newsletter-box/includes/class-newsletter-box.php on line 4
Subscribe to our newsletter

php.net lists three ways to address it; the first is “Declaring the property (preferred).” (php.net) One line in the class, and it works on older PHP versions too:

wp-content/plugins/newsletter-box/includes/class-newsletter-box.php

<?php
class Newsletter_Box {
    public $title;

    public function __construct() {
        $this->title = 'Subscribe to our newsletter';
    }
}

$box = new Newsletter_Box();
echo $box->title, "\n";

Output on PHP 7.4.33

Subscribe to our newsletter

Output on PHP 8.5.11

Subscribe to our newsletter

When a class really needs values under names it can’t know in advance, it can allow them with an attribute, “which also applies to all child classes” (php.net). PHP 7.4 reads the line as a comment, because it starts with #, so this is safe for older sites as well:

wp-content/plugins/newsletter-box/includes/class-newsletter-box.php

<?php
#[\AllowDynamicProperties]
class Newsletter_Box {
    public function __construct() {
        $this->title = 'Subscribe to our newsletter';
    }
}

$box = new Newsletter_Box();
echo $box->title, "\n";

Output on PHP 7.4.33

Subscribe to our newsletter

Output on PHP 8.5.11

Subscribe to our newsletter

Two cases without a notice: __get()/__set() and stdClass

“Usage of the __get() / __set() magic methods is not affected by this change.” (php.net) A class with __set() decides itself where values go:

wp-content/plugins/newsletter-box/includes/class-newsletter-box.php

<?php
class Newsletter_Box {
    private $settings = [];

    public function __set($name, $value) {
        $this->settings[$name] = $value;
    }

    public function __get($name) {
        return $this->settings[$name] ?? null;
    }

    public function __construct() {
        $this->title = 'Subscribe to our newsletter';
    }
}

$box = new Newsletter_Box();
echo $box->title, "\n";

Output on PHP 8.5.11

Subscribe to our newsletter

And “stdClass allows dynamic properties.” (php.net)

example.php

<?php
$box = new stdClass();
$box->title = 'Subscribe to our newsletter';
echo $box->title, "\n";

Output on PHP 8.5.11

Subscribe to our newsletter

For data attached to objects your code doesn’t own, php.net’s third way is “Using a WeakMap if additional data needs to be associated with an object which one does not own.” (php.net)

Finding it before you upgrade

A check that reads the code finds this before you switch to PHP 8.2 or later:

CompatNav reports a method of a class that writes $this->name for a name the class doesn’t declare, and it follows parent classes defined in the same plugin or theme. It stays silent when the class allows dynamic properties or has __set(). To avoid false alarms, it doesn’t report every case: a value written from outside the class, a class that uses traits, or a class whose parent comes from another plugin or from WordPress. On a site already running PHP 8.2 or later, the log shows the cases that actually ran. How to read the report: Reading the report.

Code: a value written from outside the class

wp-content/plugins/newsletter-box/newsletter-box.php

<?php
class Newsletter_Box {
}

$box = new Newsletter_Box();
$box->title = 'Subscribe to our newsletter';
echo $box->title, "\n";

Output on PHP 8.1.34

Subscribe to our newsletter

Output on PHP 8.2.34

Deprecated: Creation of dynamic property Newsletter_Box::$title is deprecated in /var/www/html/wp-content/plugins/newsletter-box/newsletter-box.php on line 6
Subscribe to our newsletter

Key takeaways

It’s a deprecation notice from PHP 8.2 and later. Tested on PHP 8.2, 8.3, 8.4 and 8.5: the code keeps working and only adds the message.
The message names the class and the property, and its file path shows which plugin or theme it comes from.
The accepted plan turns it into an error in PHP 9.0: it needs a fix, but not an emergency one.
The fix belongs in the plugin’s code: update the plugin, or send the message to its developer. Don’t edit the plugin yourself.
Visitors shouldn’t see PHP messages at all: keep WP_DEBUG off on a live site, or log messages instead of displaying them.

Frequently asked questions

Can I ignore it?

For now, yes: the site works the same with or without the message. It’s still worth passing on to the plugin’s developer, because the accepted plan for PHP 9.0 turns it into an error.

Will it break on PHP 8.3, 8.4 or 8.5?

No. We ran the same code on PHP 8.3, 8.4 and 8.5: each shows the same notice and the code keeps working. The change to an error is planned for PHP 9.0.

Why do I only see it in the debug log?

Because your site writes PHP messages to a log instead of showing them on pages, which is the right setup for a live site. With WP_DEBUG off, WordPress doesn’t even ask PHP to report deprecation notices.

Do I need to edit the plugin?

No. Changes to a plugin’s files are lost with its next update. Update the plugin, or send the full message to its developer: for them it’s a small change.

Check your own site before you upgrade

CompatNav is a free WordPress plugin. It reads the code of your plugins and themes on your own server and tells you, in plain words, what will break and what will only show notices on the PHP version you choose. It never changes your code. It can’t see problems that only appear while code runs with real data, so a quick check of your site after the upgrade still matters.

Get CompatNav on wordpress.org How it works

Sources

About the code examples: each output is the real output of the code shown, run with the official PHP builds, without a php.ini, with all errors reported and displayed. Only the file path was replaced by a neutral server path.