[Bug]: Saving a Document doesn't clear the full page cache

[bitbirddev]

[Bug]: Saving a Document doesn't clear the full page cache

[bitbirddev]

@bitbirddev #16453 (comment) may be fixed with #16467

@hadl: i don't see any relation to this Bug to be honest, at least not for the full page cache clearing problem.

[bitbirddev]

Additionally it seems like in the backend, the Cache => Clear Full Page Cache - Button doesn't actually clear the cache.

[bitbirddev]

here is where the Cache is cleared via the Button in the Backend

here is where the Cache gets cleared when saving a Document

here is where the cache-entry is created

[kingjia90]

thank you for reporting, just wondering, have you set the lifetime option by any chance? If so,
https://pimcore.com/docs/platform/Pimcore/Development_Tools_and_Details/Cache/Full_Page_Cache/#:~:text=If%20there%20is%20a%20lifetime%20the%20item%20stays%20in%20the%20cache%20even%20when%20it%20is%20changed%20until%20the%20TTL%20is%20over.

[kingjia90]

confirming the issue, but for me Clear Full Page Cache works

update: it was a false positive, tried with lifetime and it was still displaying the cache until it expired to me

[bitbirddev]

@kingjia90 in my tests i think the lifetime was set to "null".

    full_page_cache:
        enabled: true
        lifetime: null
        # exclude_cookie: ''
        exclude_patterns: '@^/health-check@'

[bitbirddev]

there is also another issue with the full page cache.

when using frontend-prefixes, for example when you want to deliver your images via cdn. when frontend prefixes are enabled, on the first page load the srcset for each image is generated (no thumbnails) and then when the browser loads a URL of the srcset, the corresponding thumbnail is generated - but only the one the browser loads, assuming you have an srcset with 4 different formats and your browser requests the .webp thumbnail there are still 3 thumbs that haven't been created.

now on the SECOND pageload the frontend-prefixes get added to those entries in the srcset where a thumbnail has been generated already.

so the problem here is that the full page cache caches the FIRST pageload where we might have 0 thumbnails generated. Even the SECOND Pageload is not the one that should be cached due to missing frontend prefixes because not alle thumbnails have been generated.

So the question here is, how can the cache check if frontend-prefixes are used and if all thumbnails for a page are generated before caching it.

[kingjia90]

Could you please share the response header of the cached page from developer tools?

[bitbirddev]

this screenshot is taken right after editing and saving a document in pimcore. i was still logged in thats why the cache is disabled. the strange thing is that i cant see my changes in the frontend despite the cache being disabled.

[bitbirddev]

this is after logging out from the backend. my content is behind a login in the frontend so it also makes sense here that the cache is disabled... but my changes are still not shown...

[bitbirddev]

Hitting "Clear Full Page Cache" didnt work so i cleared the data cache

after clearing the cache the changes are visible in the frontend

[hadl]

@bitbirddev #16453 (comment) may be fixed with #16467

[fashxp]

@bitbirddev what kind of changes are you doing?
Just tried to reproduce this with a simple document and a text editable. Everything worked like expected.

If a page is delivered from full-page-cache, you should see X-Pimcore-Output-Cache-Tag: header in the response. Do you see that?

Maybe, you have activated static page generator with some livetime? But also with that activated, in my tests the response is updated after document is saved.

[fashxp]

there is also another issue with the full page cache.

when using frontend-prefixes, for example when you want to deliver your images via cdn. when frontend prefixes are enabled, on the first page load the srcset for each image is generated (no thumbnails) and then when the browser loads a URL of the srcset, the corresponding thumbnail is generated - but only the one the browser loads, assuming you have an srcset with 4 different formats and your browser requests the .webp thumbnail there are still 3 thumbs that haven't been created.

now on the SECOND pageload the frontend-prefixes get added to those entries in the srcset where a thumbnail has been generated already.

so the problem here is that the full page cache caches the FIRST pageload where we might have 0 thumbnails generated. Even the SECOND Pageload is not the one that should be cached due to missing frontend prefixes because not alle thumbnails have been generated.

So the question here is, how can the cache check if frontend-prefixes are used and if all thumbnails for a page are generated before caching it.

Please create a separate issue for that, and maybe you even have an idea how to solve it.

[bitbirddev]

@fashxp just had that problem again.

I've changed the contents of a wysiwyg editable (added that "Datenschutz-Einstellungen" Link). Then i've saved and published the document. No Errors popping up, everything seems fine.

When opening the page in the frontend i see the old version... even though the cache should be completely disabled because i'm still logged in. Im using the real frontend link not a Version-Preview Link etc. My Browser Cache is also disabled.

this is my cache configruation:

framework:
  cache:
    prefix_seed: '%env(REDIS_CACHE_PREFIX_SEED)%'
    pools:
      pimcore.cache.pool:
        public: true
        default_lifetime: 31536000 # 1 year
        adapter: cache.adapter.redis_tag_aware
        provider: 'redis://%env(REDIS_CACHE_HOST)%/%env(REDIS_CACHE_DB)%'

this is my full page cache config

  full_page_cache:
    enabled: true
    lifetime: 300
    # exclude_cookie: ''
    exclude_patterns: '@^/health-check@'

Static Page generation is disabled.

The changes are only reflected if i clear the Cache manually

[fashxp]

Could you please try to debug that on your end?
Maybe also try once without redis. Thy very much.

[fashxp]

@bitbirddev any new insights on that one? thx for the update.

[bitbirddev]

@fashxp i did some further research and it seems like this was a problem with tinymce removing tags in combination with the new 2000 char limit in symfonys html_sanitizer. i think we can close this for now. if the problem occurs again i'll open a new issue.

[fashxp]

thx for checking and sharing!