[wp-trac] [WordPress Trac] #64950: wp_using_ext_object_cache can return null, causing type failures, potential fatals
WordPress Trac
noreply at wordpress.org
Tue Mar 31 22:30:06 UTC 2026
#64950: wp_using_ext_object_cache can return null, causing type failures, potential
fatals
--------------------------+--------------------------
Reporter: ronalfy | Owner: westonruter
Type: defect (bug) | Status: reviewing
Priority: normal | Milestone: 7.1
Component: Cache API | Version: 3.7
Severity: normal | Resolution:
Keywords: has-patch | Focuses:
--------------------------+--------------------------
Changes (by westonruter):
* owner: (none) => westonruter
* status: new => reviewing
* milestone: Awaiting Review => 7.1
Comment:
@liaison Inside `wp_using_ext_object_cache()`, wouldn't it be helpful if
it emitted a `_doing_it_wrong()` if `$_wp_using_ext_object_cache` is
`null`?
I'm trying to reproduce the issue here. In the wordpress-develop
environment with `LOCAL_PHP_MEMCACHED=true` added to `.env`, I'm seeing
that `wp_using_ext_object_cache()` is returning `true` even when when an
mu-plugin is added with:
{{{#!php
<?php
var_dump( wp_using_ext_object_cache() );
}}}
However, I ''do'' see it output `NULL` if added to `db.php`. So it seems
this is specifically an issue with `db.php`.
Nevertheless, if I have `LOCAL_PHP_MEMCACHED=false` in my `.env`, then
`wp_using_ext_object_cache()` is returning `NULL` even very late in the
execution cycle.
{{{#!php
<?php
add_action( 'template_redirect', function () {
var_dump( wp_using_ext_object_cache() );
} );
}}}
So it seems the function has always returned `null` if there is no
`object-cache.php` drop-in? Apparently its return values are `null|true`?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/64950#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list