12.2. Clearing the Cache currently mentions using Drush or the admin UI.
In some cases, a site may be unusable due to cached information, so the UI will be unavailable. Rebuild.php allows clearing all site caches without requiring Drush.
a) If you are able to run programs on the command line:
1) Run scripts/rebuild_token_calculator.sh to generate required url arguments
2) Visit /core/rebuild.php?timestamp={{ timestamp }}&token={{ token }}, replacing the parameters with the generated values.
b) If you are unable to run programs on the command line:
1) Edit your settings settings.php to add $settings['rebuild_access'] = TRUE;
2) Visit /core/rebuild.php. No additional URL parameters are required.
3) Restore settings.php by removing the previously added code.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | interdiff.txt | 723 bytes | jhodgdon |
| #5 | 3017104-5.patch | 1.88 KB | jhodgdon |
Comments
Comment #2
jhodgdonThanks! That does seem like something that would be useful to add to the Cache Clearing topic. I think maybe just option B, which is much simpler to accomplish, for the User Guide (which is aimed at beginners).
Anyone want to make a patch?
Comment #3
jhodgdonHere's a patch. Note that we also have similar editing instructions in the Update Core and Update Modules topics for editing settings.php; I copy-pasted and edited those lines from there.
Comment #4
eojthebraveI think it might be worth mentioning that this is also useful in the case where you need to clear the cache, but can't access the UI because something in the cache is breaking it. I suspect this is the most likely use for people who are not using Drush, and also want to perform a full rebuild.
Maybe; "If this doesn't resolve the problem that caused you to want to clear the cache or if you're unable to access the _Performance_ page via the administrative interface, try a rebuild instead.
Comment #5
jhodgdonGood idea! I thought it was probably better to add the note in the first step under UI. How's this?
Comment #6
amber himes matzShould we mention that
$settings['rebuild_access'] = TRUE;is active if you are using settings.local.php? Maybe "If you are not utilizing settings.local.php, open settings.php..."Comment #7
jhodgdonYou're right, that setting is set to TRUE by default in the example.settings.local.php file in the sites directory... but as far as I can see, we do not mention settings.local.php anywhere in the User Guide currently. And the use of settings.local.php is commented out of the default.settings.php file in sites/default, and we don't actually encourage people to edit settings.php directly in our install instructions.
So... I am inclined to say we should not mention this? The instructions in this topic would still work -- if you added the line in settings.php, then did the rebuild, then removed the line, it would not hurt the fact that it is also in settings.local.php if someone had decided to use that file.
Thoughts?
Comment #8
eojthebraveI'm also inclined to leave settings.local.php out for the reasons @jhodgdon mentions. Plus, I think we open up a potential can of works were we don't actually know if the settings.local.php someone has is a copy of example.settings.local.php or not. And therefore don't actually know if it does contain this setting.
Comment #9
jhodgdonAny other thoughts/reviews, especially @Amber Himes Matz ?
Comment #10
amber himes matzI agree that it would be confusing to mention settings.local.php, since it isn’t explained elsewhere in the guide.
So I think the patch in #5 is fine.
Comment #12
jhodgdonThanks for all the reviews! Committed, and I'll send out an update shortly to the translation email list.
Comment #14
ressaThanks, this is really useful information. Perhaps it could be added that the
/core/rebuild.phpmethod also clears APCu cache? Because it looks like using Drush and the administrative interface does not ... see #3540339: Rebuild all caches, including APCu, when clicking "Clear all caches".