Rebuild all caches, including APCu, when clicking "Clear all caches"

Problem/Motivation

Files from a module lower in the module discovery hierarchy may wrongly be in use, due to APCu caches not getting cleared. (Is there a drupal.org documentation page which explains how the module discovery hierarchy works?)

It is currently a bit tedious to clear the APCu cache, which can be necessary, for example after switching from using a deprecated Drupal core module (for example Forum) to its new contrib counterpart.

But the tediousness of the process is a minor factor, and there's a much bigger problem:

Users who run into this problem, may spend quite a long time trying different things and failing. Only after spending even more time searching for a solution via the search engines, Drupal forum, etc., they might find the tricky solution.

So getting to the bottom of this, both understanding the source of the problem, and fixing it can eventually save many users a lot of time.

Note: After rebuilding caches via the browser or Drush, contrib Forum 1.0.2 version of the module (modules/contrib/forum) may be listed on the Extend page, as the only Forum module, even while files used are from Drupal core Forum version (core/modules/forum).

UPDATE, Oct 2025: See also @apotek's deep analysis in Drush cache:rebuild does not completely rebuild cache like rebuild.php or admin/config/development/performance "clear all caches" does #6406.

Workarounds via settings.php: class_loader_auto_detect, deployment_identifier, or rebuild_access

1. One workaround is to clear the APCu cache, by adding this in settings.php and rebuild caches:

   $settings['class_loader_auto_detect'] = FALSE;

   From https://www.drupal.org/docs/administering-a-drupal-site/troubleshooting-...

2. Another workaround is to change the deployment identifier, by adding this in settings.php and rebuild caches, which works equally well (the value can be anything, as long as it changes):

   $settings['deployment_identifier'] = "forum_102";

   From #3153335: Document $settings['deployment_identifier'] (and that it fixes moved class autoloader caching).

3. A third option is adding this in settings.php and visit /core/rebuild.php:

   $settings['rebuild_access'] = TRUE;

   From #3017104: Clearing the Cache: mention rebuild.php.

If Composer cleared APCu caches when Drupal core version changes, or when contrib modules are added or removed (basically any time composer.lock changes), it could update stale module paths and #3509069: Use a better container cache key may enable this.

Still, actually clearing all caches, by also clearing APCu with the standard method, would be great.

Another case, where it's difficult to clear all the relevant caches is #3050261: index.php randomly appears in friendly URLs. It seems that the "Clear all caches" UI button works better than Drush.

Steps to reproduce

1. Create a fresh Drupal installation with DDEV
2. To check if the Core module is used, tweak a line in core/modules/forum/src/Controller/ForumController.php to this:
   'title' => $this->t('CORE -- Add new @node_type', [
3. Install the Drupal core Forum module
4. Rebuild caches -- this one is important, to populate the caches, otherwise you might not see the stale caches at the end of the process:
   drush cache:rebuild
5. Check under /forum/1 that it says "CORE -- Add new Forum topic"
6. Download its contrib version with Composer:
   composer require drupal/forum
7. Rebuild caches:
   drush cache:rebuild
8. Expect modules/contrib/forum to be used, before core/modules/forum but see that the files from the old core module may still be used -- it still says "CORE -- Add new Forum topic"
9. Add $settings['class_loader_auto_detect'] = FALSE; in settings.php and rebuild caches
10. See that files from modules/contrib/forum are now used, it says "Add new Forum topic"

Reliably reproduce stale cache behaviour

Use this method to reliably reproduce the above behaviour, again and again, and tweak the "Add new" text, to track if cache is stale:

1. SET UP Drupal 11

ddev config --project-type=drupal11 --docroot=web
ddev start
ddev composer create drupal/recommended-project
ddev composer require drush/drush
git clone https://git.drupalcode.org/project/forum web/core/modules/forum
sed -i "s|Add new|CORE -- Add new|g" web/core/modules/forum/src/Controller/ForumController.php
drush site:install -y

Check that it says "CORE -- Add new" under /forum/1.

2. REPEAT THIS after each try, for a fresh start:

ddev composer remove drupal/forum && \
ddev delete --omit-snapshot -y && \
ddev start && \
drush site:install -y && \
drush install forum && \
xdg-open $(drush uli forum/1)

Important step! Rebuild caches, to populate them:
ddev drush cache:rebuild <<<<<<< This cache rebuild makes all the difference

3. Download Forum and rebuild caches
Download Contrib forum, rebuild caches and check in browser

ddev composer require drupal/forum
ddev drush cache:rebuild

The text is still "CORE -- Add new [...]", should be just "Add new [...]" ...

Proposed resolution

It would fix the challenge of updating stale module paths, if Composer cleared APCu caches when composer.lock changes. Though, being able to clear all caches (including APCu) manually would be a great feature ... so maybe both tasks should be pursued.

• Actually clear all caches, including APCu, when clicking "Clear all caches"

  The button says "Clear all caches" on the "Performance" page at /admin/config/development/performance, so when a user clicks it -- or runs drush cache:rebuild -- it is reasonable to expect that all caches are actually cleared.

  Could a more efficient method be used, something similar to running /core/rebuild.php, which clears all caches? ... or simply make rebuild.php the default method?

  For edge cases such as multisite installations, where one site clearing the APCu cache would in effect clear it for all for multi-sites, there could be a "Keep APCu cache" setting on the "Performance" page (/admin/config/development/performance), or simply just support for a $settings['keep_apcu_cache'] = TRUE; in settings.php?

• Add a built-in secrets system for /core/rebuild.php, same as for Cron

  Alternatively, make it easier to clear all caches, including APCu, by performing a "one step" action, such as visiting an URL in the browser, where the unique token prevents outsiders from running it, like with Cron: https://example.org/core/rebuild-caches/s5sWtcux_ddf22[...], but ideally, the standard method to clear cache should be fixed.

  Adding such a built-in secrets system for /core/rebuild.php, like Drupal core does for cron requests would allow Drush integration. @weitzman:

  Drush isnt going to hit rebuild.php until core provides a built-in secrets system for it like it does for cron requests.

  From Drush cache:rebuild does not completely rebuild cache like rebuild.php or admin/config/development/performance "clear all caches" does #6406

  ... and also in Clear user caches like core/rebuild.php does. #2450:

  If Drupal provides some endpoint on the web that we can hit to clear APCU et al for the webserver, that would be ideal.

• Clear all caches, also APCu, if composer.lock changes

  Ideally, Composer should clear the APCu cache, after a project is added or removed:

  Shouldn't Composer clear the apcu cache whenever the composer.lock hash changes?

  From #3492523-41: Class "Doctrine\Deprecations\Deprecation" not found.

  from the Composer issue Package of version 1.1.4 is missing the lib folder #72:

  If you enable Composer's APCu autoloader, then yes, you could clear the APCu cache when installing dependencies.

  #3509069: Use a better container cache key may enable this.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet