-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Paginate the list of JUGs & search #17
Comments
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: And this is how it looks like (near the footer you can see links with the number of pages and the 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 😞 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? 😣 |
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 #5 to basically: References: https://gist.github.com/joyrexus/16041f2426450e73f5df9391f7f7ae5f 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. |
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 😉 |
Yeah, after a while, I got it ! 😃👌👏 @cesarhernandezgt You can see it, deployed from the branch I was using as a test: 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 😉 |
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.
The text was updated successfully, but these errors were encountered: