Jekyll is not meant to be used to process user input, especially this kind of input. In your example, your field only has 3 values that each can be on or off, leading to 2^3=8 possible combinations. This mean that achieving what you want would require Jekyll to generate 8 static pages (1 for each possible combination) when you build the site. Now imagine you have more than 3 “on/off” variables : the number of generated pages will grow exponentially. With 10 categories Jekyll will need to generate 1024 pages, and with 20 categories that would be over a million different pages. This could quickly lead to extremely slow build times and/or a built website that takes a lot of disk space (even with as few as 7 different categories, that’s still over a hundred different HTML files generated just to achieve what you want)
This is due to the fact that Jekyll is a static site generator. As such, you build the whole website once, upload the resulting directory (usually _site) to a server, and the pages your users see do not change until you rebuild your website with new content. The website remains static, with all contents that a user could possibly ever see being generated and stored before the website is even online.
“Building” the website means combining your liquid templates such as layouts or includes with your contents/data (markdown files or json/yaml in the _data dir). This process outputs the HTML files that you will upload to the server.
This is different from the more “traditional” approach of building a dynamic website using programming languages (such as PHP). In this case, some code is executed on the server every time a visitor loads a page. The code generates the HTML depending on several data sources (such as a database or user input) and sends the generated HTML to the visitor. This way, among all the possibles category combinations, the server only generates the pages that actual visitors are requesting.
There is no “build” for dynamic sites as the HTML is generated on-demand on each page-load and is not stored persistently. Another way to think about this is that the server re-builds the relevant page on each page load and discards the result immediately after sending it to the visitor’s browser.
To sum it up, when building a static website, the code for the whole website gets executed exactly once per deployment (when you run jekyll build or when jekyll serve detects a change and rebuilds the site). On the other hand, dynamic websites have the code for specific pages executed exactly once per page load, which is what makes them “dynamic”.
At this point, it may seem like static websites got all the cons and none of the pros. However, they still offer some advantages over their dynamic counterparts :
- A static website, once built, will consume a lot less resources on the server hosting it, but comes with the limitation of pre-generating all the HTML at once. Dynamic websites, on the other hand, can easily start requiring more resources from the server as the traffic increases. Such a tradeoff reflects on the price of hosting, such as it is easy to find free hosting providers for static websites (Github pages comes to mind) while PHP hosting usually requires you to spend a few bucks on it every month.
- This also have implications on security. A dynamic website features code that usually processes user input. This opens the possibility for developer mistakes that can ultimately lead to vulnerabilities (see SQL injections for instance). Since static websites will never be able to process user input from code that is executed on the server, they will never have such issues.
- Last, but not least, static websites are a huge win for maintainability. Dynamic websites rely on server software updates to remain secure after a vulnerability in the software that powers it is found and made public. However, as these tools evolve, they may (intentionally or not) drop compatibility with previous versions. This means that with every update to the spftware it runs on, a dynamic website may break. Keep in mind that not updating this software is a big no because of known security vulnerabilities being exploited by malicious actors and the fact that your website, by essence, is a server that is publicly exposed on the internet. On the other hand, static websites only rely on the most basic features of HTTP server software : the ability to transfer files from a server to a client (usually a browser). Both this feature, and browsers backward compatibility with ancient HTML, are not likely to break anytime soon. This means that once built and uploaded, your website will most likely keep working through any update of the server or the visitors’ browsers.
This does not tell you how to solve your issue, but should help you decide if you should move to a dynamic website or if the static approach is mostly fine for your needs.
Fortunately, there is a third way to execute code in a website that works with both the static and dynamic approach : you can include Javascript code in HTML pages and have the visitors’ browsers execute it in the context of the page.
To achieve what you want, you can start with making a page that includes all unfiltered results. Some Javascript code on this page would be able to access the values of the inputs on this page and accordingly hide any filtered-out result.
Trying to do this would actually be a good intro to Javascript (as this is a pretty common thing to do with JS and covers a good part of what is specific to this language), and there are a lot of good resources online to help you learn. If you get stuck on this, I’d be glad to help you with specific issues
