Problem with page list pagination

hi, i have a problem with page list pagination, working only if i’m logged

this the web site

i have set
type of page *all
topic associded products
filtering for data : show all
show pagination interface
position under page products
order by sitemap

in working in only logged

i have clear the cache in apache server, in web site in the browser .

somebody can help me?

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

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.

i have refresh the database entity , not work
i have created a test page
not work

i have suspicious that omni gallery give me the problem .

i have the following entity in database



There are no Omni Gallery blocks on the test page and no Omni Gallery assets being loaded on that page, so the problem cannot originate from Omni Gallery.

It looks like your theme is based on Elemental. Perhaps the pagination from v9 (which is BS5) does not work so well with Elemental (which is BS3). That is a guess, not a conclusion.

Ok thank, but is the same version of concrete5 and theme that i have used in Notizie :: Moto Club Valdarno Doriano Morandi , were working without problem

In that case, maybe my guess is wrong.

Another guess:

Comparing the Moto and flori & test page URLs, the flori and test pages are missing order by and direction parameters for pagination of the page list.

Moto, page 2 URL params

Flori page 2 URL params


no, sorry ;

in products is order by site map, in test i have just now order by last insert

but don’t work

I am out of quick guesses.

By all appearances it’s a cahching issue. If i go to a particular page in the pagination and do a hard refresh I’ll get one click to a different page in the pagination and then it’s stuck again…

Yess. thank you , i have disable “page cache” . but is absurd, because with different php variable in the url, it must be considerate a different page

products?page=1 isn’t products?page=2

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