Page list (Blog index) + Pretty URLs + Cache = Pagination doesn't work
If you disable pretty urls, pagination will work (not SEO).
If you disable cache to that page specifically, pagination will work (SEO!)
If you logged in as admin, the you can see the pagination will work perfectly.
Pagination and other dynamic elements, are known not to work with full caching enabled. It's not a bug, just a behavior thing.
@ronyDeveloper is correct about that for right now. With that said, last night I was experimenting with some new things and made some modifications to make full page caching work with pagination. It was a pretty simple fix and I'm going to be submitting it for review into the core once I test it a bit more and take a second look. Hopefully this will make it into 220.127.116.11.
Feel free to open/chime in on bug reports about this. While technically not a bug, I'm planning on changing this behavior for the next release.
That's a great news. Could you please share that small changes so that I can also test it. I'm in a need of it since last 3 months. Still wondering how to solve this. But seems like you save my time.
Give me a moment and I'll push it to a branch on my github fork.
I didn't test that version at all yet. Previously I was just using $_SERVER['REQUEST_URI'] with success so you can always try that instead of Request::get()->getRequestPath()
Let me know how it goes.
I'll have it a try when I get back to home & surely let you know.
Thanks very much.
Does this mean that appending a random query string parameter to the end of a page path will dodge a page cached copy of the page (and as a side effect save a new version in the cache)?
Whilst such a trick could be useful, it could also result in an explosion in cache size. Could that be anticipated so to not add such random parameter versions of pages in the cache? Is such anticipation in code even feasible?
I've been thinking of a more intelligent way to cache blocks. Basically, you let the block control its own caching, sort of like today with those 5 properties (cacheOnPost, etc), but with more properties and a method (which can be overridden if you want control). Basically a isCacheable() that can do things like look a the query parameters and decide if it's even cacheable and then, if so, a key() which returns a relevant cache key (e.g., one that takes into account the paging querystring.
I was thinking that putting something similar into the single page and page type controllers might serve useful, though I'm not sure.
Maybe... another way of doing it is by generating a page cache key from the individual blocks' cache keys (and you can bust the cache if one of the blocks returns "don't cache"... though this would require loading the blocks, i guess.
I wouldn't be so sure everyone has such a thing sorted out to their liking ;)