On the page that doesn’t work, the links in the pagination are wrong. They reference 2 different blocks.
Did you try to refresh your database entities ? You can do it by navigation to https://floricolturaextra.it/dashboard/system/environment/entities
Also as a test, could you create a whole new page and add a new page list block to it and see if it works so we know if it’s a problem with the core or with that specific page.
It always worked like that. Only “real” pages visible in Sitemap are being cached.
It’s not only pagination after ? sign, there are other filters there and caching those is always tricky. Since you would need to create multiple combinations of cache files for every page.
Your basic example ?page=1 would be easy to cache, but there are more parameters in url than that: block id, order, direction, page. Count every possible combination and you will get close to “silly numbers” area.
In theory, core app could crawl through blocks, get options concerning filtering and be prepared to cache specific query string. Though this is not how it works right now and also it would not work with 3rd party blocks.
I agree, last option of forcing “Full page caching” in Dashboard is kinda stupid.
I can’t imagine situation, where you would use it and would not backfire.
“Full page caching when blocks allow it” is a proper solution, since some blocks will disable it to properly work.
Well, my mistake is that i have supposed for the page cache two layers the first with the standards page components in cache , the second with the query result in a dynamic layer that respond on request .
I have done this because mi customer have request a particular animation in home page that use a lot of server resources .
For reducing this consumption i have try to enable all cache options