wp-activate.php tries to set undefined property

[skithund]

wp-activate.php tries to set cache_enabled property, which doesn't exist on all object cache implementations, triggering Creation of dynamic property WP_Object_Cache::$cache_enabled is deprecated error on PHP 8.2.

<?php
if ( is_object( $wp_object_cache ) ) {
        $wp_object_cache->cache_enabled = false;
}
?>

Check that cache_enabled property exists on object cache object.

Trac ticket: https://core.trac.wordpress.org/ticket/61675

[jrf]

@skithund Thank you for reporting this. This shouldn't be possible with the WP native object cache classes as the #[AllowDynamicProperties] attribute is set.

Having said this, as the property is explicitly used and set in WP Core, I think it would be prudent to make this property an explicitly declared one on the WP_Object_Cache class anyhow (visibility: public) with documentation stating that "overload" classes should declare that property.

As for existing "overload" classes, I believe patches would be needed to explicitly declare the property on those as well.

While the patch proposed protects against the deprecation notice, it does not work with magic methods in place (which the WP_Object_Cache class has), so as things are, it would effectively disable the cache in most cases, which would break the functionality, which I don't think is your intention.

Also see: ​https://3v4l.org/kLAYu

### Changes Made

• Added the cache_enabled property to the WP_Object_Cache class.

Trac ticket: https://core.trac.wordpress.org/ticket/61675

[snehapatil02]

@jrf "I've updated the WP_Object_Cache class to explicitly declare the cache_enable property and documented it accordingly. Please review the PR.

@spacedmonkey Can we get this merged?

[desrosj]

Unfortunately, this one missed the boat with 6.7 RC1 due out any moment. I'm going to punt this to 6.7.1 for consideration in the next minor release.

[desrosj]

Because of a few bug reports opened since 6.7 was released, the Core team is evaluating the need for a short 6.7.1 cycle (possibly next week).

To help prepare for this scenario in case it's decided to move forward, I'm going to punt this one. This issue was not introduced in 6.7, so it now falls outside of the focus for 6.7.1 as currently defined.

Also, I'm choosing 6.8 instead of 6.7.2 because it seems this may be better suited for a major release in order to properly communicate and test.