Discourse Docs Card Filter is to be used with the Discourse Docs Plugin and allows you to place “Cards” that act as a clickable filter for quicker filter results upon entering the /docs page by your users.
You can select custom icons for each category or tag card filter. You can also allow category descriptions to be rendered in the category card filters.
Name
Description
category icons
Choose icons & topics order for corresponding category IDs. ex. ‘6,heart,title-asc’ would assign the heart icon to category 6 & will order topic list by ascending activity. NOTE: order can be (title,activity)-(asc/desc)
category description
Enable the category description to be displayed in the category card filters for the docs page.
tag icons
Choose icons & topics order for corresponding tag slugs. ex. ‘featured,heart,activity-desc’ would assign the heart icon to featured tag & will order topic list by ascending activity. NOTE: order can be (title,activity)-(asc/desc)
Translation
Default
topics
Topics
topic
Topic
Hosted by us? Theme components are available to use on our Standard, Business, and Enterprise plans.
Thanks for building this! Is it the case that if a user doesn’t have view permissions on a (private) category, the card for that private category won’t appear above the search box? (Or I suppose on the sidebar, but just want to confirm the behavior is consistent.)
Excellent. That will make it a real easy-to-use tool for people in our multiple workgroups who want quick access to their group(s) reference materials, and quickly filter our Group A from Group B, etc. Thanks!
Is there a way to change the sort order for the cards, even if it requires modifying the code? I’d like for it to be Alphabetical rather than by topic count. Thanks!
Hi all. Docs and this extenstion of Docs are fantastic. Just one thing though. Can anyone assist me with somehow adding these cards to the top_menu or homepage sections? Would be awesome to have a standard homepage with ‘Latest’ by default, yet having these cards at the top. Then clicking on a card with take it to the filtered Docs page.
Also, I have another plugin (Search box) sitting in the top_menu section. I havent been able to figure out how to change order if multiple plugins are showing in this section.
We tried the tc and it works great for your use case. Now we can create a KB
In this context, I have a question: Can you suggest any workaround to add some parameters to each category or tag card? That way we would like to append &order=title in order to affect the sorting for each individual category or tag card.
We could add a sorting parameter in category icons theme setting. For the example, in case of the 6,heart, we can add an additional sorting command, e.g. to sort by topic title ascending, it would be 6,heart,title-asc.
When opening the category card, it would then just append the docs parameters such as: /docs?ascending=true&category=71&order=title
While it’s possible this could work well on a site, without much feedback around this topic focusing on the ability to sort the cards, I dont necessarily feel the time spent on getting this to work properly is currently warranted.
That being said, we do encourage PRs on components, as well as forking a component to use in your own way!
Please feel free to make a PR with this functionality, or fork it to develop for yourself.
We definitely welcome beneficial PRs to our components!
If you were to add the ability to sort these cards, I would suggest creating a new value-list where you can put in the order of the cards by category ID and tag ID. I would not add them to an already existing value list for something unrelated.
Fair enough. But could you at least change the category icons setting to value-list? It’s much easier to manage the cards in multiple text fields rather than a single one.
And as temporary workaround, it would be super helpful if each docs card had a CSS class with the respective category or tag slug.
After thinking over it more, I have decided against changing the category icons setting to a value list as without a fallback option, would cause current users components to break.
Adding a fallback would look like checking to see if either the users has set the icons in the current field, or the new value-list field and I feel that is just too cumbersome to add onto this component, as it would add another level of settings and cause possible confusion.
As for the class additions, its a great idea, but I do not have a timeline for when this will be added as there are more pertinent things needing my attention.
That being said, when possible we also welcome PRs to our components, we are open source after all!