add years to pagination (tricky one, maybe impossible?)

[joe_g]

Hey experts,

I had this cool idea I would love to implement, but so far I didn't manage to do it with good enough performance. I've got some date fields on a page, and I'd like to have years indicate on the pagination pages, like so:

What I tried is to read all the results, read all the years for each results, then slice them up in pages. This is way to slow, obviously.

Only thing i could think of is to make a nightly batch job that calculates the pagination, but it starts to get a bit messy and could easily be out of sync.

This is no life-and-death situation, it's just something I would like to do. If you have any ideas how to solve this I'm curious to hear it.

 

[da²]

Hi,

First thing I see is you are trying to display too much pagination. Ten elements is usually enough, with 3 dots in the middle: 1 2 3 4 ... 9992 9993 9994 9995.
But then there's no really interest in displaying years. ^^

I bet the problem is only a design question: what kind of data do you want to display to the user? Is is truly ergonomic to display an infinite line of links?
Wouldn't it be better to display only years at first, then when user clicks a year, display the pagination? Maybe think about it and you'll find a solution better for user and the developer. 🙂

3 hours ago, joe_g said:

What I tried is to read all the results, read all the years for each results, then slice them up in pages. This is way to slow, obviously.

Anyway, the solution will be a good designed MySQL query, but never to load "all" data.

Edited December 18, 2024 by da²

[joe_g]

Yes, it's a sidescroll so you can easily swipe right as if the pages form a timeline. Since a page corresponds to the amount of stuff you already see on the current page you get a kind of intuitive feel for how much a year contains. A sort of physical representation of everything that has happened.

Although it could become years instead of pages for past years, but it gets a bit tricky with a 2 level pagination perhaps. I imagine you click 2022, see pages and you would need to go back to 2024. 

Now, since you brought this up. The whole thing could potentially be only months and years instead of pages - but that is equally hard to calculate. Not all months have events and should be represented.

Yes it would need to be custom sql, i suppose

[bernhard]

What about something like this?

$start = 0;
$chunkSize = 100;
$oldYear = false;
while ($chunk = $pages->findIDs("sort=created,limit=$chunkSize,start=$start")) {
  if (count($chunk) < 1) break;
  $p = $pages->get($chunk[0]);
  $year = date('Y', $p->created);
  $y = $oldYear === $year ?: " ($year)";
  echo "#$p{$y}<br>";
  $start += $chunkSize;
  $oldYear = $year;
}

Result:

#1 (2023)
#1148
#1265
...
#2269 (2024)
#2395
#2496
#2598
...

[joe_g]

Hey yes, thank you. I tried this (findID) but it's too slow unfortunately, since I read all records for every request. I did consider caching, perhaps doing this nightly and cache the response, but it felt too complicated (and might also lead to weird cases with mismatch).

I think the alternative is to do this with SQL, the grouping needs to happen on a sql-level. That's also a bit complicated, probably :D Especially since I usually don't spend too much time with the actual schema underneath processwire... 

 

 

[joe_g]

Aha, now I get it! You suggest doing it in chunks of 100. Interesting, this I have to try! thanks.

[bernhard]

How many pages are we talking?

I've just created 10k pages for a testrun and my script took 330ms with a chunksize setting of 100 and 46ms with a chunksize of 1000

Did you use my exact script implementation? It's not only about using findIDs... Details matter 😉