Rename "Caching mode: " to "Page caching mode: on /admin/settings/performance.

I've seen so many support requests where people thought they'd disabled all caching when switching this off, subscribe.

I agree. We should make sure we change every instance of 'caching mode' in the text to be clear that it's page caching.

Changed "Caching mode" to "Page caching mode" for the radio group title under Administer > Site configuration > Performance -> Page cache.
Changed "cache mode" to "page cache mode" (2 instances) in the description for the above.

Wow, great! I love this idea. I too have walked many a completely befuddled person through this page.

Here's a review based on the screenshot:

In response to webchick's last question of the three, because minimum cache lifetime is broken, see #186638: Add a 'keep until' column for cache tables. Not sure what to do about that here really.

Agree with the other changes.

subscribe

Ok, going on the assumption that minimum cache lifetime is broken, I don't see that there's a fix here. This patch would be the wrong place to fix that. At best we could move it a little bit but we'd have to just agree that minimum cache lifetime is kind of broken anyway. I guess the easy fix is to say it deserves its own section of the page, to try and ensure that it is not directly associated with the page cache, but it still needs to be there because that is the largest thing that it affects.

Um, the patch as it stands is a big improvement and self contained. I see no basis to do a review of this whole form in this issue. feel free to disagree and change status.

The "compatibility note" is slated to be removed with the 'simplify page cache' patch that is RTBC.

I agree with moshe in #11 but I'll let Angie doe the commit. She did the previous review already, and it are her concerns we're trying to address.

One of Angie's comments makes sense; it was the addition of a 'page' to the description of the caching. That should be added to this patch. The moving of the lifetime patch should probably be handled in a different issue, IMO.

I'm fine with postponing the minimum cache lifetime location/description/whatever, but if we're going to clarify "page" caching, let's clarify it everywhere. The other two arrows still stand. :)

"aggressive caching" replaced with "aggressive page caching" (2 instances)
"you will need to check this page again" replaced with "you will need to check this setting again"

Thanks for all your comments and help.

@kresmir: Make sure to roll your patches from the Drupal root directory (the place where INSTALL.txt etc. are). That'll make testing bot happy.

Also, make sure to change the string for when all modules are not compatible with aggressive caching.

Thanks, webchick.

In addition to the above,
"The following enabled modules are incompatible with aggressive mode caching"
replaced with
"The following enabled modules are incompatible with aggressive page caching mode"

Looks good to me.

Committed to HEAD. Thanks a lot! :D

Thank god this patch made re-rolling #370454: Simplify page caching harder, which will essentially remove all but 1 string that were re-phrased in this patch.

You know.

@sun: I appreciate that you are trying to uphold an impeccable level of quality in Drupal core. I really do. We need more people who are that conscientious to detail, since (obviously) we are not perfect.

But when you do so in a way that belittles people who are trying their best to make Drupal better, you are hurting the project's spirit in exchange for the project's quality. And personally, I would rather deal with a few bugs than see contributors turned completely off from core development because they were made to feel humiliated.

It's fine to point out bugs, flaws in approaches, etc. By all means, please do! But do so as a mentor; not as a be-littler.

This is the wrong issue to discuss. My most recent mail to the development list contained a bit more in-depth thoughts and reasoning.