Make WordPress Core

Opened 6 weeks ago

Closed 5 weeks ago

#63194 closed defect (bug) (fixed)

Fix type of last_changed cache time

Reported by: tillkruess's profile tillkruess Owned by: audrasjb's profile audrasjb
Milestone: 6.8 Priority: normal
Severity: normal Version: 6.3
Component: Cache API Keywords: has-patch dev-reviewed
Focuses: docs Cc:

Description

The wp_cache_set_last_changed action currently says that $time is and int, however it's a string.

I propose changing the microtime() call to return a float instead of string which is quite annoying to compare against.

Change History (9)

This ticket was mentioned in PR #8615 on WordPress/wordpress-develop by @tillkruess.


6 weeks ago
#1

  • Keywords has-patch added

The timestamp for queries currently is stored as 0.91192600 1743003204, not as a numeric value. This makes it hard to compare, plus it consumes unnecessary bytes in the key name.

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

#2 @audrasjb
6 weeks ago

  • Milestone changed from Awaiting Review to 6.9
  • Owner set to audrasjb
  • Status changed from new to accepted
  • Version changed from trunk to 6.3

This function was introduced in [55702].

@peterwilsoncc commented on PR #8615:


6 weeks ago
#3

There are a number of plugins using the setter and associated getter (which would also be affected by the type change) in the plugin repo. I expect there are a few unlisted plugins using it too, for example the WordPress.com VIP MU Plugins.

Changing the type would affect plugins running something like this:

$lc = explode( ' ', wp_cache_(set|get)_last_changed('group') );
$time = $lc[1] + $lc[0];

With this change these would start throwing a warning as $lc[1] isn't set. I expect that this is exactly the code you wish to avoid running.


A concern I have is that the return type of wp_cache_get_last_changed('group') would become unpredictable after this change. For frequently invalidated caches, such as posts, it would quickly become a float. For infrequently invalidated caches, such as users, it would remain a string.

This could be resolved by flushing the global cache upon upgrade, but that would miss a lot of enterprise type sites that don't run the upgrade script as frequently as they could.

@tillkruess commented on PR #8615:


6 weeks ago
#4

@peterwilsoncc I agree. I changed the type of the filter to string so at least it's accurate now, it was never int. Thanks for checking.

#5 @peterwilsoncc
5 weeks ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 60128:

Docs: Fix types for wp_cache_set_last_changed filter.

Corrects the type for the $time and $previous_time parameters in the filter to indicate the times are expressed as strings. The values are generated from a call to microtime() which returns the time as a string in the form msec sec.

Props tillkruess, westonruter.
Fixes #63194.

#6 @peterwilsoncc
5 weeks ago

  • Focuses docs added
  • Keywords dev-feedback added
  • Milestone changed from 6.9 to 6.8
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening and moving to the 6.8 milestone for r60128 to be considered for merging to the 6.8 branch.

#7 @audrasjb
5 weeks ago

Committer sign-off: @peterwilsoncc this is good for a 6.8 backport 👍

#8 @audrasjb
5 weeks ago

  • Keywords dev-reviewed added; dev-feedback removed

#9 @peterwilsoncc
5 weeks ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 60133:

Docs: Fix types for wp_cache_set_last_changed filter.

Corrects the type for the $time and $previous_time parameters in the filter to indicate the times are expressed as strings. The values are generated from a call to microtime() which returns the time as a string in the form msec sec.

Reviewed by audrasjb.
Merges [60128] to the 6.8 branch.

Props tillkruess, westonruter.
Fixes #63194.

Note: See TracTickets for help on using tickets.