WordPress.org

Make WordPress Core

#22232 closed enhancement (invalid)

Setting Transient Expiration to 0 Causes Transient To Never Expire

Reported by: cgrymala Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.8
Component: Cache API Keywords:
Focuses: Cc:

Description

I realize this may be by design, but the way the set_transient() function handles expiration timeouts that are set to 0 is a little counter-intuitive.

Logically, it seems like setting a transient's expiration to 0 would cause the transient to expire immediately (essentially, you wouldn't even set the transient). However, in reality, setting the expiration to 0 actually causes the transient to never expire (like a standard option, just with the _transient_ prefix on the option name). The biggest issue with the way it's currently handled is the fact that those transients also auto-load; so an unsuspecting developer could easily start to fill up the memory buffer with auto-loading transients that should logically have never been set.

This issue may become even more important now that the concept of filtering a transient's expiration has been introduced (http://core.trac.wordpress.org/ticket/21330).

I would propose simply exiting the function without storing the transient if the $expiration parameter is empty.

Change History (1)

comment:1 nacin18 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

What purpose would setting a transient that expires immediately have? Storing a non-expiring transient *does* have its purposes.

This is the same behavior as caching backends: http://us1.php.net/manual/en/function.apc-store.php, http://www.php.net/manual/en/memcached.expiration.php, http://www.php.net/manual/en/memcache.set.php. For this kind of caching, 0 means "Store forever" (until deleted or forced out of cache) not "Don't store at all."

Either way, changing this would break existing code.

Note: See TracTickets for help on using tickets.