Page list (Blog index) + Pretty URLs + Cache = Pagination doesn't work

Permalink
After hours of messing around with the pagination code in the page list block, I have to say, there is a bug. If you use any of the views (default, blog_index or blog_index_thumbnail), with pretty urls and cache, the navigation won't work. You will be able to see the "next" and "previous" links. And the number of pages ("1 2 3 4"), but clicking on any of them will be like reloading the same page. Even the url changes, but the articles will be the same.
If you disable pretty urls, pagination will work (not SEO).
If you disable cache to that page specifically, pagination will work (SEO!)

webbasica
View Replies:
ronyDdeveloper replied on at Permalink Reply
ronyDdeveloper
I've already discussed about this topic.
http://www.concrete5.org/community/forums/usage/full-page-caching-c...

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.

Rony
mkly replied on at Permalink Reply
mkly
Hello,
@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 5.6.1.3.

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.

Best Wishes,
Mike
ronyDdeveloper replied on at Permalink Reply
ronyDdeveloper
Hey Mkly
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.

Rony
mkly replied on at Permalink Reply
mkly
Absolutely,
Give me a moment and I'll push it to a branch on my github fork.

Best Wishes,
Mike
mkly replied on at Permalink Reply
mkly
Here you go.
https://github.com/mkly/concrete5/commit/3b3711adcafd3c26999440c9f7d...

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.

Best Wishes,
Mike
ronyDdeveloper replied on at Permalink Reply
ronyDdeveloper
Thanks mkly
I'll have it a try when I get back to home & surely let you know.
Thanks very much.

Rony
JohntheFish replied on at Permalink Reply
JohntheFish
Just speculating wildly about the changes made.

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?
jshannon replied on at Permalink Reply
jshannon
Looks like it, yeah. By definition, anything that dodges page caches without some intelligence (ie, list of params) will cause this problem. And even a whitelist of params could cause an issue if someone wanted to be nasty (?ccm_paging=1 -> ?ccm_pageing=99Million).

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.
webbasica replied on at Permalink Reply
webbasica
I'm not a developer (obviously), but seems to me everyone else (joomla, wordpress, drupal) allready addressed this with a solution. It would be too hard to have something like this?

/blog/page2/
/blog/page3/
etc
mkly replied on at Permalink Reply
mkly
Hi @webbasica,
I wouldn't be so sure everyone has such a thing sorted out to their liking ;)

https://drupal.org/node/1245482...
mkly replied on at Permalink Reply
mkly