![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 16 months ago
Closed 15 months ago
#63194 closed defect (bug) (fixed)
Fix type of last_changed cache time
| Reported by: | tillkruess | Owned by: | audrasjb |
|---|---|---|---|
| Priority: | normal | Milestone: | 6.8 |
| Component: | Cache API | Version: | 6.3 |
| Severity: | normal | Keywords: | has-patch dev-reviewed |
| Cc: | Focuses: | docs |
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.
16 months ago
#1
- Keywords has-patch added
#2
@
16 months ago
- Milestone Awaiting Review → 6.9
- Owner set to
- Status new → accepted
- Version trunk → 6.3
This function was introduced in [55702].
@peterwilsoncc commented on PR #8615:
16 months 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:
16 months 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