Support rebuild of all caches, including APCu, via the browser

Connecting the issue which triggered this issue.

Does changing the deployment identifier → fix this situation? It may not. Even if it does, this feature may be helpful.

Thanks for the link @cilefen. I am not sure if it could help. Like, how do you suggest it should be used to solve the task outlined in this issue?

My aim is to make it easier to clear all caches without editing settings.php, but simply by visiting an URL, or some other "one step" action, like clicking a button, issuing a command on the CLI, etc. and I have updated the Issue Summary to make this clearer.

I found a comment in another issue #3492523-41: Class "Doctrine\Deprecations\Deprecation" not found → which looks really interesting:

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

That would take care of the stale paths after switching from a core to a contrib module, since composer.lock will have changed.

Adding Composer issue about APCu cache.

Mention 📌 Use a better container cache key Active in the Issue Summary.

Like, how do you suggest it should be used to solve the task outlined in this issue?

The reason I asked because switching the deployment identifier "fixes moved class autoloader caching". According to what I've read it is an underused configuration so in the context of evaluating the value of this feature request I thought more information would add context.

Does browsing core/rebuild.php also do this? I think it runs apcu_clear_cache. Again, this is only to get more information.

First of all, I need to emphasize, that I am extremely grateful for your fast and investigative questions, I feel quite privileged.

So I am sorry if I sounded irritated, when I asked the question, which I am definitely not -- I just don't know anything at all about the inner workings of Composer, Symfony, autoloaders, etc. since I am not a developer, but a simple site builder.

My approach here is trying to report down from the Drupal trenches, trying as best as I can to investigate, and try out different things, in an actual "regular user" scenario (i.e. using recommended project in DDEV with plain vanilla settings, meaning default caching, no configuration tweaks, etc.)

So when I asked "Like, how do you suggest ...", my point was simply this:

How does this new method in actual effect differ from adding $settings['class_loader_auto_detect'] = FALSE; in settings.php? Because editing settings.php is what I want to avoid ...

But it's interesting :) So I have now tried adding a dummy $settings['deployment_identifier'] = "forum_102"; in settings.php and rebuilding caches, and it works equally well as setting class_loader_auto_detect, so now there are two methods.

core/rebuild.php or update.php do not clear caches
Browsing core/rebuild.php nor update.php clears the caches, and so far only class_loader_auto_detect or deployment_identifier in settings.php has worked.

Also, I have noticed that after getting everything set up for test, you need to rebuild the caches while the core (or original module) is the only one present, before proceeding with downloading contrib version and clearing caches -- I guess to populate the caches?

Otherwise, you might check the /forum/1 path, download contrib, clear cache, and then contrib code will be in effect.

I have updated the Issue Summary with a reproducible method, which yields the same stale caches result every time. I first tried using DDEV's snapshots feature, but it looked like the caches were not totally emptied.

Perhaps you can give it a shot, and check if you see the same thing that I do? Feel free to ask, if anything in the process is unclear.