Updated: Comment #N
Cache::invalidateTags() is called from
PerformanceForm::submitForm(), etc. However, that doesn't get run when the theme settings are changed from an API call, for example, within
UserPictureTest::testPictureOnNodeComment(). In general, cache invalidation needs to be triggered by configuration or content changes, regardless of whether it's a form submission that triggers the change.
Other examples can be found by searching HEAD for where Cache::invalidateTags() or cache_invalidate_tags() is called.
A cache tag per configuration name, like
User interface changes
AccessResult::cacheUntilConfigurationChanges(ConfigBase $configuration)(a sister method of
public function cacheUntilEntityChanges(EntityInterface $entity)).
EntityInterface::getCacheTags()). It ensures that each cache tag is of the form
config:<config object name>, so e.g.
config:system.performancefor the performance settings configuration object. When a configuration object is updated or deleted, this is used to invalidate the appropriate cache tags, as you'd expect.
Because of point 2, all cache tags of config entities have changed accordingly, e.g.
menu:<menu name> has become
config:system.menu.<menu name>. However, you should have been using the
getCacheTags() method on configuration entities already anyway, in which case this cache tag change will be picked up by your existing code automatically.
Beta phase evaluation
|Issue category||Bug because Config System imports/syncs today do not result in the necessary cache clears, making it seem as if the import/sync didn't work correctly. On top of that, changing simple config through the UI does not clear any caches whatsoever, and hence simple config that affects e.g. render cached output, doesn't cause that render cached output to be invalidated.|
|Issue priority||Critical because this breaks cacheability, makes Drupal seem broken.|
|Prioritized changes||The main goal of this issue is security/performance.|