Opened 6 weeks ago
Closed 5 weeks ago
#63194 closed defect (bug) (fixed)
Fix type of last_changed cache time
Reported by: |
|
Owned by: |
|
---|---|---|---|
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
#2
@
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.
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