[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