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

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

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

Absolutely,
Give me a moment and I'll push it to a branch on my github fork.

Best Wishes,
Mike

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

Thanks mkly
I'll have it a try when I get back to home & surely let you know.
Thanks very much.

Rony

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?

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.

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

Hi @webbasica,
I wouldn't be so sure everyone has such a thing sorted out to their liking ;)

https://drupal.org/node/1245482...

Beta Discussion Started
http://www.concrete5.org/developers/beta/beta_discussion/full-page-...