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
The page cache is currently in a poor state. At least two attempts have been made to entirely rearchitect the system (#1597696: Consider whether HttpCache offers any significant benefit over the existing page cache and later #2177461: Refactor page caching into a service). However the current system suffers from several defects and one major design issue (see step 1 below). As a consequence the conversion from procedural to object-oriented code is not straight forward and risky.
Proposed resolution
In order to unblock progress it is necessary to subdivide the undertaking into multiple steps:
- #2257709: Remove the interdependence between the internal page cache and management of the Cache-Control header for external caches
- #2263981: Introduce a robust and extensible page cache-policy framework
- Convert the internal page cache into a service or a kernel-wrapper (possibly based on Symfony HttpCache) #2348679: Move the remaining procedural page cache code to the page cache stack middleware or #1597696: Consider whether HttpCache offers any significant benefit over the existing page cache
Related defects / issues:
- #2216161: Simplify performance settings page
- #2062463: allow page cache cid to be alterable
- #2218463: Private file and image style downloads throw 500 error when page cache is active
- #1576322: page_cache_without_database doesn't return cached pages without the database
- #1215464: Variable 'page_cache_without_database' is poorly named
- #1573064: Remove unique ETag hack as it is no longer necessary
Comments
Comment #1
znerol CreditAttribution: znerol commentedComment #2
znerol CreditAttribution: znerol commentedComment #3
znerol CreditAttribution: znerol commentedComment #4
dawehnerThank you for splitting this up and making progress in multiple areas.
Comment #5
Wim LeersThanks, that should make this much easier to get done! :)
Comment #6
znerol CreditAttribution: znerol commentedComment #7
Wim Leers#2263981: Introduce a robust and extensible page cache-policy framework landed. I unpostponed #1597696: Consider whether HttpCache offers any significant benefit over the existing page cache, but since that was moved to 9.x-dev now, I wasn't sure we would be able to work on it. Crell said we can. So that's probably the current issue in focus.
Comment #8
znerol CreditAttribution: znerol commented#1597696: Consider whether HttpCache offers any significant benefit over the existing page cache is postponed again, therefore let's stackify the remaining procedural page cache code: #2348679: Move the remaining procedural page cache code to the page cache stack middleware
Comment #9
znerol CreditAttribution: znerol commentedThere is currently no progress here because #2348679: Move the remaining procedural page cache code to the page cache stack middleware is still blocked on #2347877: Move DrupalKernel::initializeCookieGlobals() into a SessionConfiguration service.
Comment #10
moshe weitzman CreditAttribution: moshe weitzman commentedNothing to review here. Can we close this meta?
Comment #11
Wim LeersThe NR state was wrong, but the child issues are still being worked on, so I don't think we can close this just yet.
Comment #12
BerdirDiscussed with @znerol, I think we can close this one now. #2368987: Move internal page caching to a module to avoid relying on config get on runtime is the last step, but we don't need a meta issue to track that, it wasn't even in here.
All other issues have been fixed or closed, so closing this :)
Comment #13
Wim LeersAnd #2368987: Move internal page caching to a module to avoid relying on config get on runtime has now been committed! So definitely fine to close this. Yay!