eZ Platform Discussions

Organizing Article Content Type


#1

In the past I have created articles inside folders for organizing Articles into categories. The hierarchy would look something like this for example.

  • Article Library
    – Food
    – Medicine
    – Environment
    – General Interest

An article could belong to multiple categories so I would give it multiple locations. There’s nothing wrong with doing it this way but I’m curious if there is a better way to do this.

My Idea:
In my article contentType I could add a metadata field called ‘Category’ which would be a multiselect fieldtype. That solves having to use folders to organize my content and all articles would live in just one folder. However, I would need to come up with an admin UI extension so I can filter articles in the back end by category for Editorial purposes. I would also need to figure out how to inject the multiselect fieldtype into the url name alias pattern so the url would reflect all category selections. I’m not even sure if the content creation process could even do that by generating a dynamic url based on the multiselect fieldtype. On the front end I would have to create a custom controller and query type for filtering results from the article library based on url routing paths.

This all seems like a lot of work to avoid having to use multiple folders for category organization. The articles could be stored in multiple locations which solves the url generation issue. Maybe I just talked myself out of doing this but would be curious for any feedback. I also considered using tags however tags would span content types and I would not want anything to bleed over by mistake.


#2

Why not using Tags Bundle?


#4

I thought about using the Tags Bundle but got tripped up with the following.

A product and article could both be tagged as ‘Environment’, so my front end controller would have to account for that. I assume a custom queryType for content items that are of article contentType and tagged ‘Environmental’. This doesn’t seem impossible but a lot of overhead to build out when it could just be handled with folders and locations.

The bigger concern is the URL name. If the article belongs to multiple tags I would need the URL to be /technical-library/environment/article-1 and /technical-library/food/article-1 for example since it belongs to two categories. So how would the url name pattern work then for tags? Or would the URL from the name pattern be /technical-library/article-1 and then since the tags hierarchy would be:

  • technical library
    – environmental
    – food
    the urls would then be as desired.

I’m looking to see if anyone has done something similar or if I should just use folders and move on.


#5

There is no general solution, it really depends on your use case. To find the optimal solution you need to think about several angles.

  1. Are you categories changed/added often? Is it possible that you create articles before you create categories? If both answers are true then I recommend Tags. Tags are generally better for more dynamic taxonomies and are easier to manage on the go. For example we have a often use case where editors enter bunch of articles and tag them, then chief editors create category objects later, tag them and show articles with the same tag

  2. Editor experience. It is quicker for editors to just create taxonomies while adding content. Usually bad experience is to start with an article, then realize there is no category, then go back to create an article. If the category is set and changes rarely, then this is less of a problem

  3. SEO. Your solution with multiple locations could be ok, but it generates more links to the same content, which is not good for SEO. Then you need to handle it in the full view (making rel links in the head, etc). Its usually better to stick to one url, either having all articles under some main node or under some rarely changed main categories. If you need to have all your categories mentioned in the url, you can always put the tag attribute in the content type url schema

Btw, showing tag related content (and traversing content in general) is super simple with Site API:
https://docs.netgen.io/projects/site-api/en/latest/reference/query_types/content_relations_tag_fields.html