Paginate the list of JUGs & search

[icougil]

Based on the number of JUGs we have... it will be really great to paginate all the "records" to be able to paginate all of them.

Also, it would be great to be able to offer a search feature to find exactly the JUG the user wants.

[icougil]

After a while, I had time to work on this issue.

If you have a look at this branch you can see an idea of pagination: https://github.com/World-Wide-JUGs/GlobalWWJugs/tree/feature/paginate-jugs

And this is how it looks like (near the footer you can see links with the number of pages and the Prev 1 2 Next links to navigate through):

It is based on this plugin

The thing is as I found, it is NOT supported by Github pages (as it is stated here). But nowadays I don't know if there is a better alternative for Jekyll and paginate content

The bad news is that it seems that because of this, this approach is working in local, but not when we publish in github 😞 (we can see it if we change the branch used for publishing GitHub pages / Settings > Github pages)

Also, based on this question in SO, one of the options is to build & deploy the site manually (we can do it automatically when pushing/merging into a particular branch via GitHub actions, for example, like this) instead of letting Github doing it -as we are doing right now- or use another hosting provider like Netifly.

So, what do you think? 😣

[cesarhernandezgt]

Hi @icougil

Thank you for the work and context provided.

I vote -1 to depend on a manual build approach. Back in 2020, I opened https://github.com/World-Wide-JUGs/GlobalWWJugs/issues/5 to basically: Have a collapsable rendering in alphabetical order.

References: https://gist.github.com/joyrexus/16041f2426450e73f5df9391f7f7ae5f https://github.community/t/collapsible-markdown-inside-details-summary-summary-details-fails-to-render/10489

I think this approach will have a max of 27 rows. It doesn't resolve the other feature you mention about search but it fulfills the expectation of not having a busy index page and keeps the automation on deployments.

[icougil]

I think I haven't explained very well 😅, my fault @cesarhernandezgt

I never recommend deploying anything manually ever. What I was suggesting is, instead of letting Github directly recognize that we are using Jekyll (and therefore build the site and deploy the files generated by it), just generate the files (as Jekyll does, note the contents of your ignored _site folder) and then publish this automatically generated content (via github action) so that it is what is displayed on the web.

TBH, I don't see that your approach could work in the medium to long term (I hope we have a lot of JUGs on this page, of course), and that approach

In summary: no worries, give me please some time, I will work on that approach of generating the files and deploying them automatically 😉

[icougil]

Yeah, after a while, I got it ! 😃👌👏 @cesarhernandezgt

You can see it, deployed from the branch I was using as a test: https://world-wide-jugs.github.io/GlobalWWJugs/

Here we have the PR that provides the functionality to paginate all the JUGs on the homepage and looks exactly as I shared in my previous comment 😉