Drop the explicit clear of plugin caches in drupal_flush_all_caches()

Could we swap the $themeHandler argument in the constructor for the parameter, because the theme handler isn't needed otherwise.

Alternatively, we could do this with cache tags? (which means injecting the invalidator instead)

drupal_flush_all_caches():

  foreach (Cache::getBins() as $cache_backend) {
    $cache_backend->deleteAll();
  }

...

  \Drupal::service('plugin.cache_clearer')->clearCachedDefinitions();

Why do we need the plugin cache clear after we just wiped all bins?

edit: and given that we clear statics and rebuild the container if no kernel is passed in:

  // Reset all static caches.
  drupal_static_reset();

...

  if (!$kernel instanceof DrupalKernel) {
    $kernel = \Drupal::service('kernel');
    $kernel->invalidateContainer();
    $kernel->rebuildContainer();
  }

then any static caches inside plugin manager services should be gone too.

I just did some manual instrumentation and by the time we get to

\Drupal::service('plugin.cache_clearer')->clearCachedDefinitions();

the only plugin manager with any data is the entity type manager, and that's only because BlockHooks::rebuild() validates regions for all blocks.

So, perhaps we can just drop this?!

If we don't do that we should try reordering as follows:

  // Clear all plugin caches.
  \Drupal::service('plugin.cache_clearer')->clearCachedDefinitions();

  // Rebuild all information based on new module data.
  \Drupal::moduleHandler()->invokeAll('rebuild');

  // Rebuild the menu router based on all rebuilt data.
  // Important: This rebuild must happen last, so the menu router is guaranteed
  // to be based on up to date information.
  \Drupal::service('router.builder')->rebuild();

This is because hook_rebuild primes the entity type manager cache (and perhaps others, depending on what's installed), then that immediately gets cleared again, then during route rebuild the entity type manager (and again, maybe others) are primed for a second time.

This is also out of scope for this particular issue and I should just create a followup :)

This is green! But we should probably look why this was added where it was, in case there is some edge case we're missing...

I asked Claude to do some research, here's a summary of what it found:

2013:

#1892462: EntityManager should use the CacheDecorator added plugin.manager.entity->clearCachedDefinitions() under a comment @todo Rebuild the kernel/container

#1982984: Create Drupal::entityManager for improved DX changed this to Drupal::entityManager()->clearCachedDefinitions()

2014:

#2155635: Allow plugin managers to opt in to cache clear during module install adds the plugin.cache_clearer service

#2326409: Annotate render element plugins generalises the single entity manager flush to use plugin.cache_clearer instead

2015:

#2493665: Add centralized container invalidation method fixes the original @todo

Now that we rebuild the container on cache clear and also module install, it looks like the original reason for plugin.cache_clearer to exist might be gone.

No, we still need the plugin cache clearer for the module/theme install/uninstall scenarios, because those don't wipe the discovery cache bins. But I still think it's safe to drop from drupal_flush_all_caches().

I've had a think about drupal_rebuild() and the way it passes the kernel into drupal_flush_all_caches (to prevent unnecessary rebuilds). I think this is fine because there is no way for services to pollute their statics from cache here. Well there is one potential place - there's the \Drupal\Core\DrupalKernelInterface::CONTAINER_INITIALIZE_SUBREQUEST_FINISHED event - this event is very poorly named - but it does not trigger on rebuild.php because the request is not on the stack when the container is rebuilt.

Committed and pushed 0394ef0b0ab to main and f0da424363b to 11.x and e94fef706cf to 11.4.x. Thanks!