- 🇭🇺Hungary huzooka Hungary 🇭🇺🇪🇺
My team uses preinstalled Drupal instance for testing and in case of a time-based caching workaround, I need to be able to mock (request) time.
Re #3
The idea is good, but we cannot rely on ::time() as we are so low level that we need to work within the bootstrap container as well and request() needs the request, which does not exist at that time.
What if we follow the same logic as we have at ::debug()? So, trying to return
\Drupal::time()->getRequestTime()and if it fails, fall back to the actual logic(int) $_SERVER['REQUEST_TIME'] ?? time();Also,
- It is unclear to me why this issue is postponed - maybe it was just stuck in this state accidentally?
- My suggestion is to change this to a task (or to a feature request). Imho this is not a bug anymore.
I want to share my local path with you.
- Merge request !41Issue #2999614: Use Drupal core time service with fallback → (Open) created by huzooka
- 🇭🇺Hungary huzooka Hungary 🇭🇺🇪🇺
* Updated (created) issue summary.
* Changed category to feature request.
* Changed priority to normal.Feel free to change them if you disagree.
- 🇭🇺Hungary huzooka Hungary 🇭🇺🇪🇺
I see a test failure with the next minor core release, but imho it is a preexisting issue.
- 🇫🇷France andypost
it affects performance as instead of variable (expected and documented) we'll get a set of function calls for no reason (each get doing validation and each invalidate of tag)
generally not clear why this method is public at all and moreover not clear why it has no static cache for result now
