[#48230] - [6.2] Support multi-category for Joomla items
- Pending
- Medium
- Build: 6.2-dev
- # 48230
- Diff
- Reda-Muhamed:reda-multicategory
User tests: Successful: Unsuccessful:
Pull Request resolves # .
- I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.
Summary of Changes
This PR adds support for assigning Joomla items to more than one category.
Each item still has one main category. The main category is stored in the normal catid field.
Items can also have one or more Additional Categories.
This feature supports:
- Articles
- Contacts
- Banners
- News Feeds
The item edit form now has an Additional Categories field.
Additional Categories respect category state and access levels.
Items are shown through an Additional Category only when the category is published and the current user can view that category.
Additional Categories do not replace the main category for item ownership and permissions.
The administrator item lists show the main category and the Additional Categories.
The batch for adding/removing additional category.
The Category Match filter now has these options:
- Main Category
- Additional Categories
Category item counts now show the main category count and the Additional Category count. For example, 10 (+5) means 10 items use this category as their main category and 5 items use it as an Additional Category.
The new Include Additional Categories menu option controls whether items assigned through Additional Categories appear in category blog and category list views.
Frontend pages show all visible categories in one line.
For example, the frontend can show: Categories: Main Category, Additional Category.
When Include Additional Categories is disabled, the frontend shows only the main category.
Custom fields assigned to Additional Categories are supported for Articles and Contacts.
Example:
- An article has Category A as its main category.
- The article has Category B as an Additional Category.
- A custom field is assigned to Category B.
- The article can use this custom field.
The API supports Additional Categories for Articles, Contacts, Banners, and News Feeds.
- API responses return
secondary_categories. - API requests can create or update Additional Categories.
- A PATCH request keeps existing Additional Categories when
secondary_categoriesis not sent. - Sending
secondary_categories: []clears all Additional Categories.
System and API tests were added for the new behaviour.
Testing Instructions
Administrator Tests
Run:
npm run cypress:run -- --spec tests/System/integration/administrator/components/com_content/Article.cy.js,tests/System/integration/administrator/components/com_content/Articles.cy.js,tests/System/integration/administrator/components/com_contact/Contact.cy.js,tests/System/integration/administrator/components/com_contact/Contacts.cy.js,tests/System/integration/administrator/components/com_banners/Banner.cy.js,tests/System/integration/administrator/components/com_banners/Banners.cy.js,tests/System/integration/administrator/components/com_newsfeeds/Newsfeed.cy.js,tests/System/integration/administrator/components/com_newsfeeds/Newsfeeds.cy.jsThese tests check that:
- The Additional Categories field is shown.
- Additional Categories can be assigned.
- The final Additional Category can be removed.
API Tests
Run:
npm run cypress:run -- --spec tests/System/integration/api/com_content/Articles.cy.js,tests/System/integration/api/com_contact/Contacts.cy.js,tests/System/integration/api/com_banners/Banners.cy.js,tests/System/integration/api/com_newsfeed/NewsFeed.cy.jsThese tests check that:
- An item can be created with multiple Additional Categories.
- Additional Categories can be replaced.
- PATCH keeps existing categories when
secondary_categoriesis not sent. secondary_categories: []clears all Additional Categories.- API responses return
secondary_categories. - Articles and Contacts return custom fields assigned to Additional Categories.
Frontend Tests
Run:
npm run cypress:run -- --spec tests/System/integration/site/components/com_content/Article.cy.js,tests/System/integration/site/components/com_contact/Contact.cy.jsThese tests check that:
- The frontend shows one combined Categories line.
- Additional Categories are shown when enabled.
- Only the main category is shown when Additional Categories are disabled.
Manual Test
- Create Category A and Category B.
- Create an Article, Contact, Banner, or News Feed.
- Set Category A as the main category.
- Select Category B as an Additional Category.
- Save the item.
- Open the item again and confirm that Category B is selected.
- Remove Category B.
- Save the item.
- Open the item again and confirm that Category B is no longer selected.
- Open the item list and use Search Tools.
- Select a category and test both Category Match options.
Expected result:
- The item has one main category and one or more Additional Categories.
- The final Additional Category can be removed.
- The Category Match filter works for both main and Additional Categories.
Custom Fields Test
- Create Category A and Category B.
- Create a custom field for Articles or Contacts.
- Assign the custom field to Category B.
- Create an item with Category A as the main category.
- Assign Category B as an Additional Category.
- Open the item form.
Expected result:
- The custom field assigned to Category B is available in the item form.
Actual Result Before Applying This Pull Request
Joomla items could only have one category.
Articles, Contacts, Banners, and News Feeds could not be assigned to extra categories.
Category Match worked only with the main category.
Custom fields assigned to another category were not available when an Article or Contact belonged to that category only through an Additional Category.
The API did not support Additional Categories.
Expected Result After Applying This Pull Request
Articles, Contacts, Banners, and News Feeds can have:
- One main category.
- One or more Additional Categories.
The main category remains the main ownership category.
Additional Categories are extra category memberships. They can be used for category views, filtering, custom fields, API responses, and frontend category display.
Link to Documentations
Please select:
-
Documentation link for guide.joomla.org:
-
No documentation changes for guide.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | SQL Administration com_admin Postgresql com_banners com_categories com_contact com_content |
| Title |
|
||||||
| Labels |
Added:
PR-6.2-dev
|
||
Shouldnt this feature be behind a config option with the default being off - thats what we've done with other new features - something in the component options integration field set - in the same way that workflows is enabled
For sites that want this feature I can see it being useful but for other sites its just extra noise
Please check the suggestions I made - especially the xml - github.com sometimes mangles the indentation
Please check the suggestions I made - especially the xml - github.com sometimes mangles the indentation
thanks for your review
I will check
Shouldnt this feature be behind a config option with the default being off - thats what we've done with other new features - something in the component options integration field set - in the same way that workflows is enabled
For sites that want this feature I can see it being useful but for other sites its just extra noise
but I think it is simple. If user don't need this feature, he can ignore the extra field, and everything will be normal
| Labels |
Added:
Feature
NPM Resource Changed
|
||
| Labels |
Removed:
NPM Resource Changed
|
||
And the filters?
And the filters?
It lists all items that belong to the selected category, whether it is their main category or an additional category, by default. This means that if a user doesn't need multiple categories, they will still see the same results as before
Thank you for implementing this feature.
Thank you for implementing this feature.
Thank you for your ideas and suggestions :)
In the select list for additional categories the main category is removed from the list. This can create problems as you can no longer see what the parent category is. IT would be better imho if the category was not removed from the list but was marked as parent and disabled
And the filters?
It lists all items that belong to the selected category, whether it is their main category or an additional category, by default. This means that if a user doesn't need multiple categories, they will still see the same results as before
Not quite
As soon as you select a filter in the category selector a NEW filter magically appears
The accessibility people will I am sure tell you that this is a failure but its also completely unnecessary if you are not using any secondary categories on the site. Thats the main point I am trying to get across by saying that this feature should be something a site onwer enables
Content Versions
Need to do some work here to get the values not just the numbers
In the select list for additional categories the main category is removed from the list. This can create problems as you can no longer see what the parent category is. IT would be better imho if the category was not removed from the list but was marked as parent and disabled
I see your point. But the main category is already visible in the field above. If we keep it in the Additional Categories list as a disabled option and mark it as the main category, I feel the same information would be shown twice - once in the main category field and again in the additional categories field. That's why I thought it would be cleaner to remove the selected main category from the additional categories list
And the filters?
It lists all items that belong to the selected category, whether it is their main category or an additional category, by default. This means that if a user doesn't need multiple categories, they will still see the same results as before
Not quite
As soon as you select a filter in the category selector a NEW filter magically appears
The accessibility people will I am sure tell you that this is a failure but its also completely unnecessary if you are not using any secondary categories on the site. Thats the main point I am trying to get across by saying that this feature should be something a site onwer enables
Make sense
please dont misunderstand me. I can see there is a lot of work in here and overall it seems to be working. I just think that its not something that should be enabled by default as it just adds clutter
In the select list for additional categories the main category is removed from the list. This can create problems as you can no longer see what the parent category is. IT would be better imho if the category was not removed from the list but was marked as parent and disabled
I see your point. But the main category is already visible in the field above. If we keep it in the Additional Categories list as a disabled option and mark it as the main category, I feel the same information would be shown twice - once in the main category field and again in the additional categories field. That's why I thought it would be cleaner to remove the selected main category from the additional categories list
its also an accessibility failure as you cant look at the additional category list on its own and understand what the parent is of a category. It appears to be a child of a completely different category
please dont misunderstand me. I can see there is a lot of work in here and overall it seems to be working. I just think that its not something that should be enabled by default as it just adds clutter
I understand what you mean so i said make sense to me
please dont misunderstand me. I can see there is a lot of work in here and overall it seems to be working. I just think that its not something that should be enabled by default as it just adds clutter
I understand what you mean so i said it make sense to me
@brianteeman thank you for testing. We will collect all opinions and see what we can do.
tested the urls and they appear to work as expected
Deleted as not related to this pr
Deleted as not related to this pr
On a menu item of type single article these options are confusing and do not appear to be working correctly. Are they mislabelled? Is there a missing showon?
test 1
produces
test 2
produces
test 3
produces
test 4
produces
These options are as always. They always follow the main category.
Yes, they are confusing since j4.0, and many other options too. Is it related to multicategories?
These options always follow the main category.
Yes, they are confusing since j4.0, and many other options too. Is it related to multicategories?
Sorry, you are correct they are present before this pr. Never noticed it before.
We've done even more at RadicalMart. In addition to the main and additional categories, we've added pathway and route :
category - Main category (affects state, permissions, and fields)
categories_additional - Additional categories
category_route - Category responsible for the URL (very useful when people need to create a single-level site structure, for example, all articles in posts) Main Category if empty
category_pathway - Category for breadcrumbs. Convenient when you need to make breadcrumbs work with a single-level structure. Main Category if empty
@Reda-Muhamed it works a lot better than I expected it to. All those years that we said it wasnt possible :(
@Reda-Muhamed it works a lot better than I expected it to. All those years that we said it wasnt possible :(
Just give it a try and after that you can decide if it is possible or not 🙂
| Labels |
Added:
PBF
|
||
tested the recent change for content history
The category is now displayed correctly - thanks - but is there any value in additionally displaying fieldscatid?
tested the recent change for content history
The category is now displayed correctly - thanks - but is there any value in additionally displaying fieldscatid?
no, it is better to hide
thank you - content history is much better now
thank you - content history is much better now
you are welcome
Thinking about the filters (especially the way the additional category filter that just appears - not good for a11y) and I am wondering it there is a real use case for this filter even existing.
If we are truly talking about multi-category does it even matter if the category is the main or additional catgegory
Thinking about the filters (especially the way the additional category filter that just appears - not good for a11y) and I am wondering it there is a real use case for this filter even existing.
If we are truly talking about multi-category does it even matter if the category is the main or additional catgegory
I did it to make the user have more control, but I think we can remove this new filter field (to make the functionality normal) and make the feature without a config option to enable or disable
Agree with filters. This filter is interesting from the developers point of view for users.
In the select list for additional categories the main category is removed from the list. This can create problems as you can no longer see what the parent category is. IT would be better imho if the category was not removed from the list but was marked as parent and disabled
But I disagree here. W
One category is the main category of a article and it is clearly visible. All other categories are can be selected as additional categories, no matter if they are parent or not.
If I am user, it would "make me think" why there is a category disable which I have alredy selected.
Agree with filters. This filter is interesting from the developers point of view for users.
In the select list for additional categories the main category is removed from the list. This can create problems as you can no longer see what the parent category is. IT would be better imho if the category was not removed from the list but was marked as parent and disabled
But I disagree here.
One category is the main category of a article and it is clearly visible. All other categories are can be selected as additional categories, no matter if they are parent or not.
If I am user, it would "make me think" why there is a category disable which I have alredy selected.
Agree with filters. This filter is interesting from the developers point of view for users.
But I disagree here.
In the select list for additional categories the main category is removed from the list. This can create problems as you can no longer see what the parent category is. IT would be better imho if the category was not removed from the list but was marked as parent and disabled.
One category is the main category of a article and it is clearly visible. All other categories are can be selected as additional categories, no matter if they are parent or not.
If I am user, it would "make me think" why there is a category disable which I have alredy selected.
Agree with filters. This filter is interesting from the developers point of view for users.
But I disagree here.
In the select list for additional categories the main category is removed from the list. This can create problems as you can no longer see what the parent category is. IT would be better imho if the category was not removed from the list but was marked as parent and disabled.
One category is the main category of a article and it is clearly visible. All other categories are can be selected as additional categories, no matter if they are parent or not.
If I am user, it would "make me think" why there is a category disabled which I have alredy selected.
| Category | SQL Administration com_admin Postgresql com_banners com_categories com_contact com_content | ⇒ | SQL Administration com_admin Postgresql com_banners com_categories com_contact com_content com_contenthistory |
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-08-12 12:06:18 |
| Closed_By | ⇒ | Reda-Muhamed |
I did it to make the user have more control, but I think we can remove this new filter field (to make the functionality normal) and make the feature without a config option to enable or disable
@brianteeman can you check
| Status | Closed | ⇒ | New |
| Closed_Date | 2026-08-12 12:06:18 | ⇒ | |
| Closed_By | Reda-Muhamed | ⇒ |
| Status | New | ⇒ | Pending |
We already have had issues where the removal of an item from a list because it was selected has created confusion because a child looks like it has the wrong parent. We should learn from that and not repeat a known issue
I misinterpreted - got it now.
@Reda-Muhamed much better now - thanks
Shouldnt this feature be behind a config option with the default being off - thats what we've done with other new features
For sites that want this feature I can see it being useful but for other sites its just extra noise