Refresh cache URL action no longer warms

[joepagan]

Hi,

I recently updated an app to use the following settings:

// Whether the cache should automatically be cleared when elements are updated.
'clearCacheAutomatically' => false,
// Whether the cache should automatically be warmed after clearing.
'warmCacheAutomatically' => false,

Since then hitting the controller action with an api doesn't warm the cache, neither does pressing the button in the controller panel. It appears that it does work if I run via the CLI.

Is there something obvious I have missed here?

Craft 3.7.27.2 Blitz 3.9.0

Thanks

[mattstein]

Hi Joe! A few questions just to clarify:

1. Are you using the Refresh Site Cache or Refresh Cached URLs buttons from Utilities → Blitz Cache in the control panel? (And are you using the equivalent action via CLI where it works?)
2. What Refresh Mode do you have set in Settings → Blitz → General Settings?
3. If you reverse those two settings ('clearCacheAutomatically' => true + 'warmCacheAutomatically' => true,) does warming work consistently as you’d expect?
4. Is this something that only happens in a specific environment, or are you able to reproduce the same behavior in different environments?

[joepagan]

Hey Matt,

Thanks for getting back, yeah of course.

1. Are you using the Refresh Site Cache or Refresh Cached URLs buttons from Utilities → Blitz Cache in the control panel? (And are you using the equivalent action via CLI where it works?)

I am referring to the "Refresh Cache" button in "Utilities → Blitz Cache" & the action at: https://domain.com/actions/blitz/cache/refresh?key=x

2. What Refresh Mode do you have set in Settings → Blitz → General Settings?

I don't see a setting for this sorry, is this a craft4 setting? I only see: Caching Enabled lightswitch: on, included uri patterns: .*, excluded url patterns I have 3

3. If you reverse those two settings ('clearCacheAutomatically' => true + 'warmCacheAutomatically' => true,) does warming work consistently as you’d expect?

Just tested and I can confirm that warmCacheAutomatically appears to be the culprit. With that true, warming occurs on the "refresh" action, but with it false it does not. When warmCacheAutomatically is true debug mode is on I can see in the blitz.log I get a line:

Blitz cache successfully refreshed and queued for warming.

If warmCacheAutomatically is false I get:

Blitz cache successfully refreshed.

4. Is this something that only happens in a specific environment, or are you able to reproduce the same behaviour in different environments?

I'm sorry my dev environment is heavily bastardised at the moment due to updating this app's versions and can't really test that.

[bencroker]

Both the "Refresh Cache" command and controller actions will only warm the cache if warmCacheAutomatically is set to true, so what you're experiencing is the expected behaviour.

[joepagan]

I had maybe naively presumed that warmCacheAutomatically (in combo with clearCacheAutomatically: false) was required to help prevent this common issue which my app was experiencing where saving an entry with lots of relations could cause these queue items to stack up.

But after re-testing warmCacheAutomatically: true, it looks like that's not the case on the app and it seems to behave! And it was just clearCacheAutomatically: true being the issue contributing to that.

I do find it a bit weird that this manual request for the cache to be warmed on "Refresh Cache" does not work unless warmCacheAutomatically is true, especially when clicking "Warm Cache" works when warmCacheAutomatically is false.

The label for refresh cache is: Refreshes (clears, purges, flushes, warms, deploys) all of the pages. and doesn't suggestion of this setting would prevent this, though appreciate the description above the config setting suggests it might.

But if that's how it is ok!

[bencroker]

Yes, that is intentional. I agree that perhaps the wording could be improved, but it is explained in the config setting, as you pointed out. Naming things is hard, after all!

[joepagan]

Sure no probs thanks for the information and making that clear. You're always super helpful with my annoying questions so appreciate it. Of course been there plenty with names too! Looking forward to copilot being able to come up with the best possible name someday 😅