First page of pagination doesn't generate properly

[fitzage]

I posted a comment on the SSG pagination gist because I thought this was just related to that. However, it appears that it's an issue with the SSG + pagination, whether or not that pagination setup is used.

The reason I came to this conclusion is that I've been using the pagination feature in kind of an unusual way, and it doesn't generate correctly with the SSG. I have a list of related articles in the sidebar, and I use the pagination feature to check if there is more than one page. If there is, I display a "see more" link. Well this little list generates with random pages, which means just like the original issue, it's sometimes empty.

So for now, I'll just change this to always show the "see more" link even if there aren't more pages, but there's something weird going on with the SSG and the pagination feature.

[adnweedon]

Have you tried manually routing the first page as well as the others? It sounds a little like an issue I had, which I sorted like this: Route::statamic('blog', 'page', ['load' => '81e89da5-975e-419b-bed9-1d1ff819f348']); Route::statamic('blog/page/{page}', 'page', ['load' => '81e89da5-975e-419b-bed9-1d1ff819f348']);

[globalexport]

Although I did not dig into the code yet, I can confirm that there has something turned wrong when requesting data for index pages. My index pages now hold content of random sub-pages (sometimes page 7, then 14 or 1).

What changed? I updated PHP, Statamic and SSG to their latest versions to profit from parallel generation.

[fitzage]

The comment above, manually routing the index page, solved the problem for me.

[globalexport]

Interesting. In my case it did not work. I still get wrong content after some repeated generations.

[jasonvarga]

Does it work if you disable the concurrency?

[globalexport]

Hi @jasonvarga,

It seems to work at the moment after I restarted my docker container and deleted cache and routes. I have to continue the observation. Thanks!

[globalexport]

Hi again @jasonvarga,

Just wanted to inform you that the error did occur again. I then disabled concurrency and got the right output.

@fitzage, Do you generate your pages on multiple threads?

[fitzage]

I don’t use multiple threads because the deploy services I use don’t support PHP 8 because it’s not part of standard Ubuntu repos still, last I checked.

On Nov 4, 2021, at 7:43 AM, globalexport @.***> wrote:

 Hi again @jasonvarga,

Just wanted to inform you that the error did occur again. I then disabled concurrency and got the right output.

@fitzage, Do you generate your pages on multiple threads?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[globalexport]

Thanks for the info.

[globalexport]

I am really confused now. The problem is independent of concurrent threads. My cron job created the wrong index page again this morning, although it was processing on only 1 worker thread.

[globalexport]

Hi @jasonvarga!

Did you find time to look into the issue?
I did not find a reason for this behaviour yet, although I temporarily solved the issue by server redirect of /blog to /blog/page/1.

[duncanmcclean]

Unless there's an update here, chances are it's not been looked into further by the Core Team (eg. Jason/Jesse/Jack).