Topic Lists only Filter Top Level Topics
Permalink 1 user found helpful
I've been playing with Topic Trees and TopicList block along with PageList block to see how all these things work. Couple of observations/questions to see if anybody can offer some ideas or thoughts about how to use it in packages.
First off great that C5.7 has this Tree API which I'll say is similar in concept to taxonomy categorization in Drupal and WP. However I find it works quite a bit differently in practice.
- I've noticed that if I want a TopicList to filter a PageList it only does that if I put topics at the top-level directly under the main tree category. If I make subcategories, then instead of filtering, no results show. Not sure if this is by design or a bug, but I find on PageLists that are working for top-level filtering (using the allowExternalFiltering flag) only top-level topics will find matching pages. Lower levels, nested topics will product 0 results. Could this be because the path-matching used by the blocks to find which pages have a certain topic does not take into account the subcategories?
- I don't really understand the point of "topics" as opposed to "categories". The difference in function is categories can have children, topics cannot. In most taxonomy systems all the nodes can have children. The problem with this approach is what if you make something a topic thinking it doesn't need children, such as "suv", then later you want to have children such as "small suv" and "large suv". Are you supposed to create a category, delete a topic, edit every page to move it from the topic "suv" to the category "suv"?
- I feel this system would do everything that Drupal or WP taxonomy can do (and possibly more) if we only use categories (but never use topics). That way all our nodes can have children when/if needed. However, currently this approach wouldn't work if you plan to use TopicList because that block only makes the categories labels, and only the topics are links to pages. Which also seems strange to me because if I make a category "fruit" and I put a bunch of fruit products into it, I would expect to have a link to that category (as well as any subcategories). Clearly a different version of the TopicList block needs to be created that works in this manner, named something like "CategoryTreeMenu" where it's a truly "full menu" where every node is a link.
- I remember back in D5 or D6 that taxonomy API in Drupal had the limitation that categories were just names. Even then they could have descriptions and photos attached. But they were not "fieldable", meaning you could not add data to them and make taxonomy pages more interesting. I see the same limitation with TopicTrees now. What if you make a category "cars" and then you want to have a photo of a car on the cars list page? I think there has to be a way to make pages attached to each category or topic. Then collection attributes can be added to them.
Again so the search engines pick this up I'll mention if you're searching around for C5 taxonomy or C5 categorization, see the C5 API for Trees and TopicTrees or search for TopicList block because in C5 taxonomy is tree and topics, categories are taxonomy nodes.
First off great that C5.7 has this Tree API which I'll say is similar in concept to taxonomy categorization in Drupal and WP. However I find it works quite a bit differently in practice.
- I've noticed that if I want a TopicList to filter a PageList it only does that if I put topics at the top-level directly under the main tree category. If I make subcategories, then instead of filtering, no results show. Not sure if this is by design or a bug, but I find on PageLists that are working for top-level filtering (using the allowExternalFiltering flag) only top-level topics will find matching pages. Lower levels, nested topics will product 0 results. Could this be because the path-matching used by the blocks to find which pages have a certain topic does not take into account the subcategories?
- I don't really understand the point of "topics" as opposed to "categories". The difference in function is categories can have children, topics cannot. In most taxonomy systems all the nodes can have children. The problem with this approach is what if you make something a topic thinking it doesn't need children, such as "suv", then later you want to have children such as "small suv" and "large suv". Are you supposed to create a category, delete a topic, edit every page to move it from the topic "suv" to the category "suv"?
- I feel this system would do everything that Drupal or WP taxonomy can do (and possibly more) if we only use categories (but never use topics). That way all our nodes can have children when/if needed. However, currently this approach wouldn't work if you plan to use TopicList because that block only makes the categories labels, and only the topics are links to pages. Which also seems strange to me because if I make a category "fruit" and I put a bunch of fruit products into it, I would expect to have a link to that category (as well as any subcategories). Clearly a different version of the TopicList block needs to be created that works in this manner, named something like "CategoryTreeMenu" where it's a truly "full menu" where every node is a link.
- I remember back in D5 or D6 that taxonomy API in Drupal had the limitation that categories were just names. Even then they could have descriptions and photos attached. But they were not "fieldable", meaning you could not add data to them and make taxonomy pages more interesting. I see the same limitation with TopicTrees now. What if you make a category "cars" and then you want to have a photo of a car on the cars list page? I think there has to be a way to make pages attached to each category or topic. Then collection attributes can be added to them.
Again so the search engines pick this up I'll mention if you're searching around for C5 taxonomy or C5 categorization, see the C5 API for Trees and TopicTrees or search for TopicList block because in C5 taxonomy is tree and topics, categories are taxonomy nodes.
You have a good point, but one of the reasons for why we have categories vs. topics is that you should really only be able to choose a topic (one or more) for a given content item. Not a topic category. For example, If have an Articles topic category, with "Tech" underneath it, I may not want to give my end users the ability to tag something as an "article." Everything in my system is an article. Don't tag it with the article topic.
That said, you're right that we should lift the restriction that topics can't have children. That would fix everything – those who want more flexibility can have it, those who want to have a tree but only restrict parts of that tree for choosing can have that too. This would be a good github issue to add.
And finally, the other issue with topics not filtering if they're at a lower level sounds like a bug. I don't believe that's the case in our sample content. We should get more information on that and get an entry in the bug tracker for it.