Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Services often temporarily store data in protected properties.
Occasionally this data needs to be cleared.
Plugin managers have \Drupal::service('plugin.cache_clearer')->clearCachedDefinitions() (called from drupal_flush_all_caches()), but clearCachedDefinitions() is linked directly to plugin discovery, and cannot be used generically.
Problematically, EntityManager uses clearCachedDefinitions() to clear more than its plugin definitions, clearing info on entity type bundles, entity fields, and entity type class names.
Proposed resolution
TBD
Remaining tasks
Find a solution.
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Comment | File | Size | Author |
---|---|---|---|
#24 | 2549143-nr-bot.txt | 144 bytes | needs-review-queue-bot |
#16 | 2549143-15.patch | 2.07 KB | alexpott |
#12 | 2549143.patch | 519 bytes | alexpott |
Comments
Comment #2
tim.plunkettComment #3
dawehnerideally that service would also use #2260187: [PP-1] Deprecate drupal_static() and drupal_static_reset() to clear those caches (hint, there is a review ... )
Comment #10
BerdirI'm not convinced this issue is necessary.
#3023799: Add @trigger_error() to deprecated EntityManager::clearCachedDefinitions() method removes all remaining calls to EntityManager::clearCachedDefinitions() and things are working.
There are still some @todos that point here, for example on useCaches() methods, but that has a very specific use case that goes beyond static caching and I think must not be removed (It's about disabling *persistent* caching, so that we can check the live that without having to invalidate caches, for status report checks).
And then there's \Drupal\Core\Entity\EntityTypeRepositoryInterface::clearCachedDefinitions(), but interestingly, there is no not a single call to that method as far as I see now in core because that being necessary is extremely rare, it would require a new entity coming into existence *without* a container rebuild *and* then being used through a static ThatEntityType::load() in the same request. Because unlike the other caches, it's really just a static cache while everything else actually mainly about persistent caches. So we could actually deprecate that fully with a @trigger_error() but I don't think we need a fancy generic solution as a replacement.
As a last resort, there's the option to unset a service on the container to have it re-intialized (does however not work if that is injected somewhere).
Comment #12
alexpottWell \Drupal\Core\Entity\EntityTypeRepositoryInterface::clearCachedDefinitions() is deprecated. Let's see what blows up if we deprecate it properly.
Comment #13
alexpottComment #14
catchThis issue has been taken over by #3047289: Standardize how we implement in-memory caches but we can maybe re-purpose it for that clean-up.
Comment #16
alexpottLet's see if we can complete the deprecation.
Comment #24
needs-review-queue-bot CreditAttribution: needs-review-queue-bot as a volunteer commentedThe Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #25
catchRe-titling.