New plugin: inline hierarchical taxonomy tree for Tainacan sidebar filters

Desenvolvimento Contribuições
1

I have always hated the way the hierarchy filters work in Tainacan when everything important is hidden behind “View all” and a modal flow.

So I built a small plugin that replaces that compact hierarchy behavior with a permanently visible inline tree in the sidebar, while still using native Tainacan filtering/query behavior.

Repo:

What it does

  • Replaces compact hierarchical taxonomy filter UI with an expanded inline tree

  • Keeps native taxquery[…] filtering compatibility

  • Supports nested terms, branch collapse/expand, and integration with existing filter collapse controls

  • Tries to stay generic for typical Tainacan installations

Before

before1
before1518×416 13.3 KB

before2
before22836×880 121 KB

After

after
after692×988 37.6 KB

Notes

I have not done a ton of testing yet, especially across many different themes and unusual edge-case setups.

That said, it should be fairly generic and work with typical Tainacan installations.

Feel free to try it if it may be useful. It is open source, so you can use it or modify it however you see fit.

If anyone tests it in other environments, I’d really appreciate feedback and issue reports.

You can check it out on any of the archives on:

1 curtida
2

Hi @Aaron!

Sorry for the late answer, last week I couldn’t find a moment to take a look at the code!

The plugin provides a really nice visualization! :star_struck:

We’ve never went down that road because there are lots of use cases for the plugin and many include taxonomy terms that are too many (hundreds and hundreds) or too nested (levels inside levels inside levels), which ends up forcing us to rely on a paginated UI as the modal that you know. This is critical specialy for the facets endpoint (the one that renders both filter values and the amount of items that contain that term in the current search query). But this is the exact scenario where I think plugins can be of good fit because it certainly works well for your scenario! And the fact that you are releasing it publicly is great so others can play with it as well.

By looking at the code I would give some suggestions, but they are merely future improvements as I believe what you have now is enough for your project:

  • Try looking for filters instead of taxonomies when defining which to load. You may be in a repository items list, where more than one filter to the same taxonomy may exist, via different metadata. Besides that, the filter object will have the filter name and the metadatum ID. The metadatum itself contains the taxonomy ID. You can see a couple of examples of how to work with Tainacan entities in here, but feel free to ask for better documentation, we know it is a lot.

  • When you do:

    if (
   has_shortcode($post->post_content, 'tainacan_items_list')
   || has_shortcode($post->post_content, 'tainacan_items_list_tag')
   || has_block('tainacan/faceted-search', $post)
   || has_block('tainacan/items-list', $post)
) {

    I think you could just do has_block('tainacan/faceted-search', $post) || has_shortcode($post->post_content, 'tainacan-search'). The others don’t exist.

  • I see that your JS listens to a lot of changes via observer.observe(document.body, { childList: true, subtree: true });. That might be resource-heavy. One idea is to call your mounting functions whenever there are changes in the loading state:

    document.addEventListener('tainacan-items-list-is-loading-items', function (e) {
       // do something here
 });

    I’m not 100% sure if it will work in your scenario, but may be worth a shot.

  • Since your plugin is entirely made for Tainacan, mabe you could add Requires Plugins: tainacan to our main .php header. This would ensure people only activate it when Tainacan is also activated.

  • Since your filter do not use the Facets API, you might want to visit “Tainacan” → “Settings” and disable either “Filter dynamic values” or “Facets count” to make the other filters behave more similar to the one generated by the plugin. You can read about this options here.

  • If you wish to have arrow icons that are similar to the filter collapse ones, try this html:

    <span aria-hidden="true" class="icon">
      <i class="tainacan-icon-arrowdown tainacan-icon tainacan-icon-1-25em"></i>
</span>

  • For the future, you might want to give a try to more advanced developer features that we’ve been working on:

    • Options in the Settings page: You can register from your plugin options that would be configurable via the Settings page. This can be useful to register plugin-wide features such as a maximum number of terms to load or identation limits. Docs and example here.
    • Entity Form Hooks: This allows you to add options to some entity forms inside Tainacan, such as the Taxonomy or the Filter form. This way you could make it more configurable to define which filter will have this feature. Docs and example here.
    • Registering a Filter Type: the ultimate goal would be to actually register a Filter Type. This is possible for extenders but unfortunately we don’t have a documentation ready for it yet. There are however examples for registering Metadata types, which follow a similar flow. This would be well integrated, as the filter would appear in the Admin side, have its custom name, order and benefit of the Facets API. But it would also require more knowledge of how Tainacan admin works, including using some Vue.js probably.

If you’re willing to go into any of these ideas and need help feel free to ask us here :slight_smile:

Congrats on the plugin! :fire: