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
This comes out of a discussion with @graham.arrowsmith, @guptahemant and @wouter.adem. Please credit them 😊🙏
See https://www.drupal.org/node/2988067 (introduced in #2985297: Generalize the concept of entity synchronization, first shipped in Drupal 8.7) and in particular https://www.drupal.org/node/3098920 (introduced in #2914174: Improve hook_install() to include recommendations for config import and pass an $is_syncing argument, first shipped in Drupal 8.9).
- Configuration
-
When importing configuration, there is a large number of cache tags being purged. It does not make sense to trigger
PURGErequests to reverse proxies for each of those individually. The Purge module should be aware of a sync going on, and if so, purge the entire domain afterwards. Unless only a small number of config is imported.
→ Note that this occurs not only when (un)installing modules, but also when importing/syncing configuration.
→ That would make https://www.drupal.org/project/purge_control obsolete.
- Content
- It is also possible that the "syncing" flag will be set on content entities (since #2985297: Generalize the concept of entity synchronization). This can happen when:
- Importing/updating migrated content — could also be from non-Drupal data sources into Drupal, for example for Commerce warehouse info.
- https://www.drupal.org/project/entity_share, https://www.drupal.org/project/acquia_contenthub, https://www.drupal.org/project/entity_pilot
- Workspaces in Drupal core.
There is a point where if the scale of the import (i.e. the number of invalidated cache tags) becomes large enough, that it makes no sense anymore to purge each cache tag individually, but instead purge the entire site on all active reverse proxies (e.g. both Varnish + CDN). That would remove the need for https://www.drupal.org/project/purge_everything_queuer.
Comments