Spin-off from #2429617-239: Make D8 2x as fast: Dynamic Page Cache: context-dependent page caching (for *all* users!) :

- page cache was moved to a middleware provided by page_cache.module
- Drupal\Core\PageCache does not contain "page cache" code, but only the interfaces and base implementations of the concept of "cache policies"
- that concept is independant of the "page cache" functionality, and has nothing to do with page_cache.module's PageCache middleware class. It is primarily used to determine a response's Cache-Control headers (FinishResponseSubscriber::onRespond)
- then, page_cache.module and the new smart_cache.module both leverage cache policies as well to control their own scope.

Thus, Drupal\Core\PageCache should be something like ResponseCacheControl or ResponseCachePolicy ?

Comments

yched’s picture

yched commented

Also, the current naming means that smart_cache.module has a src/PageCache folder (containing its custom cache *policies*) - which is a bit mind-bending :-)

dawehner’s picture

dawehner
Primary language German
commented

I would vote for CacheControlPolicies given that there are both request and response policies ...

yched’s picture

yched commented

I find CacheControlPolicy ties it strongly to just the Cache-Control header, while :
- it does not really command the content of the header, it's only about boolean killswitches to opt-in / opt-out from caching
- it's used for more than the header

The rationale behind ResponseCachePolicy was that those are policies about response caching (external via the Cache-Control or header or internal via PageCache or SmartCache), rather than about the low-level Cache API - which we should make clear for a subfolder of Drupal/Core.
There are policies based on the Request and policies based on the Response, but all of them are about caching the Response (or not).

I still like ResponseCachePolicy :-)
Or maybe HttpCachePolicy ?

znerol’s picture

znerol commented

I understand the term page cache more like the high level concept (page level caching), I do not perceive it as the name of the implementation (page cache module). That said I think that the name of the namespace is quite natural. But if there is a better one, I'm not opposed to the rename. In that case I'd prefer HttpCachePolicy.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#2527126: Only send X-Drupal-Cache-Tags and -Contexts headers when developer explicitly enables them

Quoting @effulgentsia in #2527126-161: Only send X-Drupal-Cache-Tags and -Contexts headers when developer explicitly enables them:

+++ b/core/modules/page_cache/src/StackMiddleware/PageCache.php
@@ -207,33 +207,56 @@
+    // - Custom applications that wish to provide internal page cache support
+    //   for responses that do not implement CacheableResponseInterface may do
+    //   so by replacing/extending this middleware service or adding another
+    //   one.
     if (!$response instanceof CacheableResponseInterface) {
       return $response;
     }

When I wrote this, I thought, hm, maybe this check should be moved to a response policy instead of being baked into this class. But I'm unclear on whether the page_cache_response_policy service tag is to only control what is cached by page_cache module, or whether those policies should also control what gets cached by reverse proxies and CDNs (via the corresponding integration module). If the latter, then this should not move to a response policy, since we only want this affecting page_cache itself. Do we have/need an issue to discuss/document this aspect of response policies?

Quoting myself at #2527126-163: Only send X-Drupal-Cache-Tags and -Contexts headers when developer explicitly enables them:

Do we have/need an issue to discuss/document this aspect of response policies?

I think we need to discuss that, yes. Given that these are used by both the PageCache middleware and the FinishResponseSubscriber to determine the Cache-Control headers that are sent to the world, the page_cache_response_policy policies actually do affect both Drupal's internal page cache and external proxies.

I think it's worth taking this aspect into consideration in #2540684: Rename Drupal\Core\PageCache namespace, so I propose we continue that discussion there.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Version: 8.0.x-dev » 8.1.x-dev

I think BC can be kept? If not, this needs to move to D9.

dawehner’s picture

dawehner
Primary language German
commented

Right a BC can be kept, on the other hand the question is, how much do we really gain.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Clarity. That's it. I guess we just leave it open, so that if somebody runs into this and is frustrated is able to take this on :)

dawehner’s picture

dawehner
Primary language German
commented

Ha, fair point. Well we could that in so many places all over the system.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#2665062: ResponsePolicyInterface doxygen needs clarifications

#2665062: ResponsePolicyInterface doxygen needs clarifications also is voicing confusion about this.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Active » Closed (outdated)

No updates since 2016, so it looks ike at this point, nobody really considered this a problem?