Expiry date not being set when entry is saved

[KevinSleegers]

Hi,

I have a question regarding the expiry date not being set when an entry is saved. We are using refresh mode '0' (Expire the cache, regenerate manually) and the cache duration is set to '0'.

During the initial cache generation, all cacheable pages are stored in the database (table blitz_caches) with an expiry date of null, which works as expected.

With the above configuration we expect that once an entry is saved a new expiry date is stored in the database. However that's not the case. The expiry date always remains null. That causes the blitz/cache/refresh-expired cron job to do nothing and old page content is shown forever.

Is our assumption correct or is this not how this functionality should work? If not, is there any way we could make this work using this or a different configuration?

Used versions:
Craft: 4.4.10.1
Blitz: 4.4.4
Php: 8.2.6

Kind regards,
Kevin

[bencroker]

With the above configuration we expect that once an entry is saved a new expiry date is stored in the database.

Yes, that is the expected behaviour, provided the entry has actually been modified and is live.

[KevinSleegers]

Hi Ben,

Thanks for your reply. I've just checked and the entry is indeed live and has been modified, but the expiry date was not set unfortunately.

Kind regards,
Kevin

[bencroker]

Does changing the title of the entry also have no effect? Or is it only when changing custom fields?

[KevinSleegers]

Hi Ben,

It does work when I change the title of an entry. When I change any other field it doesn't seem to set the expiry date.

Kind regards,
Kevin

[bencroker]

Ah, in that case I wonder whether you cleared or refreshed the cache after updating to version 4.4.0? As per the changelog:

Tracking of attributes and custom fields takes place when pages are cached, therefore it is important to clear or refresh the cache after this update completes.

[KevinSleegers]

Hi Ben,

Yes we have cleared the cache after updating to the latest version. After further investigation it seems like the issue is caused by fields within a matrix field. When those fields get changed nothing happens, but when a field that's directly on an entry gets changed the expiry date gets set.

Kind regards,
Kevin

[bencroker]

Ok, thanks for the info, I’ll investigate this and let you know what I find.

[bencroker]

After further investigation it seems like the issue is caused by fields within a matrix field. When those fields get changed nothing happens, but when a field that's directly on an entry gets changed the expiry date gets set.

What fields specifically are you testing this with? Can you please test with a plain text field (after clearing the cached page)?

[KevinSleegers]

Hi Ben,

We're testing this with a plain text field that is within a block of a matrix field. When that field is changed, the expiry date is not set and remains null. As mentioned, when I change a field that is directly on an entry, such as the title or a redactor field, it is working without any issue.

For now our workaround to make sure the expiry date is set is to enable the 'refreshCacheWhenElementSavedUnchanged' option.

Kind regards,
Kevin

[bencroker]

We're testing this with a plain text field that is within a block of a matrix field. When that field is changed, the expiry date is not set and remains null.

Hmm, I’m unable to replicate this locally. When this field is changed and the entry is saved, is the cached page also not refreshed?

Do you by any chance have the autosaveDrafts config setting set to false, or anything else out of the ordinary that could be affecting this? If you can send your config/general.php and config/blitz.php (if you use one) files to support@putyourlightson.com then I’ll look for any discrepancies with my local setup.

[KevinSleegers]

Hi Ben,

Our 'autosaveDrafts' option is set to true. I have sent our config files via mail to support@putyourlightson.com. Hopefully that helps to reproduce the issue.

Kind regards,
Kevin

[bencroker]

Thanks!

[bencroker]

Kevin, thanks for your patience on this. There was a bug that was preventing eager-loaded custom fields from being tracked on cached pages, fixed in 5d0f47d and released in version 4.4.5. Note that to ensure the fix is applied, the cache should be cleared or refreshed after this update completes.