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

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

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 🙂

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.

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

@brianteeman can you check

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

This pull request has conflicts, please resolve those before we can evaluate the pull request.

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@Reda-Muhamed Does testing this PR require a complete dev environment with NPM? If no, could you modify the testing instructions in a way that non-developers can test it?

I have tested this item ✅ successfully on 55ef123

I wasn't able to run the Cypress tests on my end, so I only performed the manual tests.

I tested the following components in the multilingual version, as described:

• Banner
• Contact
• News Feeds
• Articles with Custom Fields

Everything worked as described.

However, the setup instructions for testing it should be included in the initial post:

• Add this PR with the patch tester
• Run npm ci
• Update the database: System -> Maintenance -> Database

I have tested this item ✅ successfully on 55ef123

I wasn't able to run the Cypress tests on my end, so I only performed the manual tests.

I tested the following components in the multilingual version, as described:

• Banner
• Contact
• News Feeds
• Articles with Custom Fields

Everything worked as described.

However, the setup instructions for testing it should be included in the initial post:

• Add this PR with the patch tester
• Run npm ci
• Update the database: System -> Maintenance -> Database

@Reda-Muhamed Does testing this PR require a complete dev environment with NPM? If no, could you modify the testing instructions in a way that non-developers can test it?

Yes, npm ci is required to build the JavaScript files

I have tested this item ✅ successfully on 55ef123I wasn't able to run the Cypress tests on my end, so I only performed the manual tests.

I tested the following components in the multilingual version, as described:

• Banner
• Contact
• News Feeds
• Articles with Custom Fields

Everything worked as described.

However, the setup instructions for testing it should be included in the initial post:

• Add this PR with the patch tester
• Run npm ci
• Update the database: System -> Maintenance -> Database

This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48230.

thanks for testing

ah, okay I forgot to add this in the testing instruction. Thank you

@Reda-Muhamed Does testing this PR require a complete dev environment with NPM? If no, could you modify the testing instructions in a way that non-developers can test it?

Yes, npm ci is required to build the JavaScript files

alternatively you can set your Joomla update url to custom and the link from here https://artifacts.joomla.org/drone/joomla/joomla-cms/6.2-dev/48230/downloads/95776/

Or do a fresh install using the prebuilt packages from here https://artifacts.joomla.org/drone/joomla/joomla-cms/6.2-dev/48230/downloads/95776/

I have tested this item 🔴 unsuccessfully on 55ef123

* Tested with JBT on 6.2-dev and PostgreSQL

• Applied PR by Patch Tester, running npm ci and updating the database
• ✅ Tested all the 11 enhanced System Tests, each single executed and running two times
• Created categories and child and grandchild categories
• ✅ Tested for articles, contacts, banners and news feeds:
  • Assigned category, child or grandchild category as addional category
    • Great, the category, that is selected as main category, is not selectable as additional category
    • Great, if I select one of the additional categories as main category, the category is removed from additional categories
  • Multiple additional categories are selectable and all are removeable
  • Additional Categories are correct shown (including parent) in the list view
    • Great, if there are no additional categories, no entry is existing in the list view
• ✅ Tested using categories in Articles Site module, articles are selected from main or additonal category, excluding or including child category articels
• In Article view setting an additional category with 'Save' some times fails:
  • ❌ Red error 'Save failed with the following error: SQLSTATE[HY093]: Invalid parameter number: :preparedArray1'
  • I can not give exact instructions how to reproduce
    • Second attempt to use 'Save' is working
    • Having article with 'Uncategorised' main category, new open the article and assign or delete an additional category
    • It doesn't matter it is a simple category, a child or a grand child category
    • Nothing in the logs
    • Screen recording is attached
• Comments
  • As we have 'Category' and 'Additional Categories' fields, I would recommend to rename the first to 'Main Category' (the field labels and in the lists)
  • Categories are linked in articles list, but not in contacts, banners and news feed lists; I would recommend to link the categories in contacts, banners and news feeds lists too

    ---

    _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48230.}

I have tested this item 🔴 unsuccessfully on 55ef123

* Tested with JBT on 6.2-dev and PostgreSQL

• Applied PR by Patch Tester, running npm ci and updating the database
• ✅ Tested all the 11 enhanced System Tests, each single executed and running two times
• Created categories and child and grandchild categories
• ✅ Tested for articles, contacts, banners and news feeds:
  • Assigned category, child or grandchild category as addional category
    • Great, the category, that is selected as main category, is not selectable as additional category
    • Great, if I select one of the additional categories as main category, the category is removed from additional categories
  • Multiple additional categories are selectable and all are removeable
  • Additional Categories are correct shown (including parent) in the list view
    • Great, if there are no additional categories, no entry is existing in the list view
• ✅ Tested using categories in Articles Site module, articles are selected from main or additonal category, excluding or including child category articels
• In Article view setting an additional category with 'Save' some times fails:
  • ❌ Red error 'Save failed with the following error: SQLSTATE[HY093]: Invalid parameter number: :preparedArray1'
  • I can not give exact instructions how to reproduce
    • Second attempt to use 'Save' is working
    • Having article with 'Uncategorised' main category, new open the article and assign or delete an additional category
    • It doesn't matter it is a simple category, a child or a grand child category
    • Nothing in the logs
    • Screen recording is attached
• Comments
  • As we have 'Category' and 'Additional Categories' fields, I would recommend to rename the first to 'Main Category' (the field labels and in the lists)
  • Categories are linked in articles list, but not in contacts, banners and news feed lists; I would recommend to link the categories in contacts, banners and news feeds lists too

    ---

    _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48230.}

I have tested this item 🔴 unsuccessfully on 55ef123


Tested with JBT on 6.2-dev and PostgreSQL

• Applied PR by Patch Tester, running npm ci and updating the database

• ✅ Tested all the 11 enhanced System Tests, each single executed and running two times

• Created categories and child and grandchild categories

• ✅ Tested for articles, contacts, banners and news feeds:

  • Assigned category, child or grandchild category as addional category
    • Great, the category, that is selected as main category, is not selectable as additional category
    • Great, if I select one of the additional categories as main category, the category is removed from additional categories
  • Multiple additional categories are selectable and all are removeable
  • Additional Categories are correct shown (including parent) in the list view
    • Great, if there are no additional categories, no entry is existing in the list view

• ✅ Tested using categories in Articles Site module, articles are selected from main or additonal category, excluding or including child category articels

• In Article view setting an additional category with 'Save' some times fails:

  • ❌ Red error 'Save failed with the following error: SQLSTATE[HY093]: Invalid parameter number: :preparedArray1'
  • I can not give exact instructions how to reproduce
    • Second attempt to use 'Save' is working
    • Having article with 'Uncategorised' main category, new open the article and assign or delete an additional category
    • It doesn't matter it is a simple category, a child or a grand child category
    • Nothing in the logs
    • Screen recording is attached: https://github.com/user-attachments/assets/973cab30-5f3a-44cd-93e9-b1b26cbe449b

• Comments

  • As we have 'Category' and 'Additional Categories' fields, I would recommend to rename the first to 'Main Category' (the field labels and in the lists)
  • Categories are linked in articles list, but not in contacts, banners and news feed lists; I would recommend to link the categories in contacts, banners and news feeds lists too

    ---

    _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48230.}

I have tested this item 🔴 unsuccessfully on 55ef123 Tested with JBT on 6.2-dev and PostgreSQL

• Applied PR by Patch Tester, running npm ci and updating the database

• ✅ Tested all the 11 enhanced System Tests, each single executed and running two times

• Created categories and child and grandchild categories

• ✅ Tested for articles, contacts, banners and news feeds:

  • Assigned category, child or grandchild category as addional category

    • Great, the category, that is selected as main category, is not selectable as additional category
    • Great, if I select one of the additional categories as main category, the category is removed from additional categories

  • Multiple additional categories are selectable and all are removeable

  • Additional Categories are correct shown (including parent) in the list view

    • Great, if there are no additional categories, no entry is existing in the list view

• ✅ Tested using categories in Articles Site module, articles are selected from main or additonal category, excluding or including child category articels

• In Article view setting an additional category with 'Save' some times fails:

  • ❌ Red error 'Save failed with the following error: SQLSTATE[HY093]: Invalid parameter number: :preparedArray1'

  • I can not give exact instructions how to reproduce

    • Second attempt to use 'Save' is working
    • Having article with 'Uncategorised' main category, new open the article and assign or delete an additional category
    • It doesn't matter it is a simple category, a child or a grand child category
    • Nothing in the logs
    • Screen recording is attached: https://github.com/user-attachments/assets/973cab30-5f3a-44cd-93e9-b1b26cbe449b

• Comments

  • As we have 'Category' and 'Additional Categories' fields, I would recommend to rename the first to 'Main Category' (the field labels and in the lists)
  • Categories are linked in articles list, but not in contacts, banners and news feed lists; I would recommend to link the categories in contacts, banners and news feeds lists tooThis comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48230.

Thanks for testing :), I haven't encountered this issue during my testing, but I'll investigate and try to find the cause.
I agree that renaming Category to Main Category makes sense.
For the category links, I was planning to make the main category a link as well, so I didn't want to add links only for the additional categories. I think this is probably out of scope for this PR, so I'll handle it in a separate PR

I have tested this item 🔴 unsuccessfully on 55ef123 Tested with JBT on 6.2-dev and PostgreSQL

• Applied PR by Patch Tester, running npm ci and updating the database

• ✅ Tested all the 11 enhanced System Tests, each single executed and running two times

• Created categories and child and grandchild categories

• ✅ Tested for articles, contacts, banners and news feeds:

  • Assigned category, child or grandchild category as addional category

    • Great, the category, that is selected as main category, is not selectable as additional category
    • Great, if I select one of the additional categories as main category, the category is removed from additional categories

  • Multiple additional categories are selectable and all are removeable

  • Additional Categories are correct shown (including parent) in the list view

    • Great, if there are no additional categories, no entry is existing in the list view

• ✅ Tested using categories in Articles Site module, articles are selected from main or additonal category, excluding or including child category articels

• In Article view setting an additional category with 'Save' some times fails:

  • ❌ Red error 'Save failed with the following error: SQLSTATE[HY093]: Invalid parameter number: :preparedArray1'

  • I can not give exact instructions how to reproduce

    • Second attempt to use 'Save' is working
    • Having article with 'Uncategorised' main category, new open the article and assign or delete an additional category
    • It doesn't matter it is a simple category, a child or a grand child category
    • Nothing in the logs
    • Screen recording is attached: https://github.com/user-attachments/assets/973cab30-5f3a-44cd-93e9-b1b26cbe449b

• Comments

  • As we have 'Category' and 'Additional Categories' fields, I would recommend to rename the first to 'Main Category' (the field labels and in the lists)
  • Categories are linked in articles list, but not in contacts, banners and news feed lists; I would recommend to link the categories in contacts, banners and news feeds lists tooThis comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48230.

Thanks for testing :), I haven't encountered this issue during my testing, but I'll investigate and try to find the cause.
I agree that renaming Category to Main Category makes sense.
For the category links, The main category isn't clickable, so I think it's better to keep the additional categories the same for now. We can add clickable category links as a feature in a separate PR.

I have tested this item 🔴 unsuccessfully on 55ef123 Tested with JBT on 6.2-dev and PostgreSQL

• Applied PR by Patch Tester, running npm ci and updating the database

• ✅ Tested all the 11 enhanced System Tests, each single executed and running two times

• Created categories and child and grandchild categories

• ✅ Tested for articles, contacts, banners and news feeds:

  • Assigned category, child or grandchild category as addional category

    • Great, the category, that is selected as main category, is not selectable as additional category
    • Great, if I select one of the additional categories as main category, the category is removed from additional categories

  • Multiple additional categories are selectable and all are removeable

  • Additional Categories are correct shown (including parent) in the list view

    • Great, if there are no additional categories, no entry is existing in the list view

• ✅ Tested using categories in Articles Site module, articles are selected from main or additonal category, excluding or including child category articels

• In Article view setting an additional category with 'Save' some times fails:

  • ❌ Red error 'Save failed with the following error: SQLSTATE[HY093]: Invalid parameter number: :preparedArray1'

  • I can not give exact instructions how to reproduce

    • Second attempt to use 'Save' is working
    • Having article with 'Uncategorised' main category, new open the article and assign or delete an additional category
    • It doesn't matter it is a simple category, a child or a grand child category
    • Nothing in the logs
    • Screen recording is attached: https://github.com/user-attachments/assets/973cab30-5f3a-44cd-93e9-b1b26cbe449b

• Comments

  • As we have 'Category' and 'Additional Categories' fields, I would recommend to rename the first to 'Main Category' (the field labels and in the lists)
  • Categories are linked in articles list, but not in contacts, banners and news feed lists; I would recommend to link the categories in contacts, banners and news feeds lists tooThis comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48230.

Thanks for testing :), I didn't see this problem before but i will check
I agree that renaming Category to Main Category makes sense.
For the category links, The main category isn't clickable, so I think it's better to keep the additional categories the same for now. We can add clickable category links as a feature in a separate PR

@muhme could you please describe your testing environment? I made so many tests with many categories but unable to reproduce yur error.

@muhme could you please describe your testing environment? I made so many tests following your video with many categories but unable to reproduce yur error.

I wonder about the custom field assignments. I tested if they are shown when at least one of the categories are matching. But what if I only want to show them on the main categories selections?

I wonder about the custom field assignments. I tested if they are shown when at least one of the categories are matching. But what if I only want to show them on the main categories selections?

I think this is one of the strong parts of this feature. If a custom field is assigned to a category, I think it makes sense to show it when the article has this category, even as an additional category.

@Reda-Muhamed maybe it needs another PR with another scope to be able to finetune the display of custom fields. I will continue to test this PR now.

In Search Result Page I have following errors, are they related to this PR?

( ! ) Warning: Undefined property: stdClass::$id in joomla/joomla-cms/administrator/components/com_finder/src/Indexer/Result.php on line 576

( ! ) Warning: Attempt to read property "state" on array in joomla/joomla-cms/administrator/components/com_finder/src/Indexer/Result.php on line 577

( ! ) Warning: Attempt to read property "access" on array in joomla/joomla-cms/administrator/components/com_finder/src/Indexer/Result.php on line 578

I have tested this item ✅ successfully on 55ef123

I tested with Multilanguage and also did some misconfiguration on purpose and it did not break anything. My test is successful. The error message in result page did not occur on a second test site so its probably unrelated. Thank you!

I have tested this item ✅ successfully on 55ef123

I tested with Multilanguage and also did some misconfiguration on purpose and it did not break anything. My test is successful. The error message in result page did not occur on a second test site so its probably unrelated. Thank you!

@Reda-Muhamed Thanks for your hard work on this PR. I wonder if there was any discussion about whether we should also have a record for main category in the #__category_item_map table? As of right now, only additional categories are stored there, so the query to filter items in categories is complicated, especially when we also need to filter by categories level (we have to check for both catid and id in the query)

If we have a record for main category in the #__category_item_map, the query will be simpler, easier to understand because we only need to check for id in where clause, not for catid anymore (I don't know which one is faster thought).

@muhme could you please describe your testing environment? I made so many tests following your video with many categories but unable to reproduce yur error.

@chmst Even I was not able to document reproduceable steps, but on every 3 ... 5 attempt to add or to delete an additional category the error was shown. And strange, if I try a second attempt to save, it was always working. I guess it is easier to think backward from error 'Invalid parameter number: :preparedArray1'. However used was JBT on Intel-based macOS with PostgreSQL. The web server container is a Debian GNU/Linux 13 with PHP 8.5.

@muhme could you please describe your testing environment? I made so many tests following your video with many categories but unable to reproduce yur error.

@chmst Even I was not able to document reproduceable steps, but on every 3 ... 5 attempt to add or to delete an additional category the error was shown. And strange, if I try a second attempt to save, it was always working. I guess it is easier to think backward from error 'Invalid parameter number: :preparedArray1'. However used was JBT on Intel-based macOS with PostgreSQL. The web server container is a Debian GNU/Linux 13 with PHP 8.5.

@Reda-Muhamed Thanks for your hard work on this PR. I wonder if there was any discussion about whether we should also have a record for main category in the #__category_item_map table? As of right now, only additional categories are stored there, so the query to filter items in categories is complicated, especially when we also need to filter by categories level (we have to check for both catid and id in the query)

If we have a record for main category in the #__category_item_map, the query will be simpler, easier to understand because we only need to check for id in where clause, not for catid anymore (I don't know which one is faster thought).

#__category_item_map stores the additional many-to-many relationships. The primary category is already the canonical relationship in each item’s catid column.
Adding a primary-category row to the mapping table would duplicate the same fact in two places without identifying which row is primary (so we need an extra flag column). Every category change would need to update both tables atomically, otherwise stale mappings could expose incorrect results

i see it is better to handle the union of item.catid and additional mappings, while preserving the existing Joomla invariant: exactly one primary category in catid, and zero or more additional categories in #__category_item_map

However used was JBT on Intel-based macOS with PostgreSQL. The web server container is a Debian GNU/Linux 13 with PHP 8.5.

Maybe someone with such an environment can repeat. I have access to macOS

administrator/components/com_categories/src/Field/CategorymultipleField.php

it is not related to any changed files in this PR :)

i have this situation one article 1 main category and 2 additional category 1 of them meanwhile has been trashed

the article view show like this

when i go to articles categories to delete the trashed category, i got an error, and it should not, i should be allowed to delete a trashed category

@alikon thank you for testing. This is expected behaviour and has not changed since years. If an article is connected with a category, the category cannot be deleted.

from the article edit is not connected

anyway how i can delete a trashed category ?

but i can delete from the DELETE endpoint api/index.php/v1/content/categories/9
this inconsistent behaviour

but i can delete from the DELETE endpoint api/index.php/v1/content/categories/9
this is an inconsistent behaviour

but i can delete from the DELETE endpoint api/index.php/v1/content/categories/9 this is an inconsistent behaviour

from the article edit is not connected

anyway how i can delete a trashed category ?

I think you should publish the category and make sure that there is no article that assign this category, then you can delete

better if cannot trash a category connected with an article ,
and have a consistent behavior from backend and webservices, if i cannot delete from backend why i can from webservice, and for sure imho

I think you should publish the category and make sure that there is no article that assign this category, then you can delete

this is too much task for a normal user

@alikon agree.
is something which I found always strange. It schould not be possible to trash a category with connected published items. This causes permanent questions in the forum. Why do get a 404? My articles are published!

But not related to this PR.

@alikon agree.
is something which I found always strange. It should not be possible to trash a category with connected published items. This causes permanent questions in the forum. Why do get a 404? My articles are published!

But not related to this PR.

@alikon agree.
is something which I found always strange. It should not be possible to trash a category with connected published items. This causes permanent questions in the forum. Why do I get a 404? My articles are published!

But not related to this PR.

Save failed with the following error: SQLSTATE[HY093]: Invalid parameter number: :preparedArray1

I was asked how to reproduce the error. I can’t reproduce this error straight away with MariaDB, but it occurred immediately with PostgreSQL. I have saved my instance this time and if you are interested I can hand-over 164 MB for JBT installation:

scripts/import 48230.zip 48230.sql

Save failed with the following error: SQLSTATE[HY093]: Invalid parameter number: :preparedArray1

I was asked how to reproduce the error. I can’t reproduce this error straight away with MariaDB, but it occurred immediately with PostgreSQL. I have saved my instance this time and if you are interested I can hand-over 164 MB for JBT installation:

scripts/import 48230.zip 48230.sql

ps. Don’t be confused: the 6.3-dev branch is currently still named 6.2.0-beta2-dev.

testing with postgres and i cant reproduce that error
what version of postgres are you using
I am using 18.2

PS as I know some of you reading this use laragon you can easily test with postgres and laragon - I documented the setup here https://brian.teeman.net/joomla/1034-using-joomla-with-postgresql-and-laragon

what version of postgres are you using

postgres (PostgreSQL) 15.16 (Debian 15.16-1.pgdg13+1)

#48230 (comment)

Unable to reprodduce the error. Laragon and postgres 18 on win11

It’s a worthwhile thing. But I thought that categories should be self‑contained, without multicategories.
I’ll explain why.
A long time ago:

1. They created rigid categories: Favorites, Published, Trash.
2. They created nested categories. Classic customizable categories.
3. Multicategories have existed in Joomla for a long time.

Let’s not impose functions from point 1 onto point 2 and vice versa; we shouldn’t confuse the Trash and favorites with categories. The functionality is roughly similar, but these are different levels of responsibility.
Multi‑categories are called Tags. Tags inherently imply multi‑categorization. At the same time, the flexibility of multi‑tags is so great that it fits very well with multi‑categories.
The problem with Joomla is that there are no modules implemented to display Tags as categories.
However, the scope of responsibility for Multi‑categories is exactly the same as for Tags.

Such a PR has already been done before, but for some reason it’s being ignored.
The solution to the Multi‑categories problem has, in principle, already been solved here for a long time...

[6.2] New module - Category Tags

It’s a worthwhile thing. But I thought that categories should be self‑contained, without multicategories.
I’ll explain why.
A long time ago:

1. They created rigid categories: Favorites, Published, Trash.
2. They created nested categories. Classic customizable categories.
3. Multicategories have existed in Joomla for a long time.

Let’s not impose functions from point 1 onto point 2 and vice versa; we shouldn’t confuse the Trash and favorites with categories. The functionality is roughly similar, but these are different levels of responsibility.
Multi‑categories are called Tags. Tags inherently imply multi‑categorization. At the same time, the flexibility of multi‑tags is so great that it fits very well with multi‑categories.
The problem with Joomla is that there are no modules implemented to display Tags as categories.
However, the scope of responsibility for Multi‑categories is exactly the same as for Tags.

Such a PR has already been done before, but for some reason it’s being ignored.
The solution to the Multi‑categories problem has, in principle, already been solved here for a long time...

[6.2] New module - Category Tags

The responsibility of categories is what is precise and unambiguous. For example, categories: Orders, Reviews, Products, News.
And what is required for multi‑categories, for example, for phone sales: Bluetooth, WiFi, 4Gb. This is what is assigned to a single product at the same time.
At the same time, the tags themselves are also stored in the categories. This allows them to be grouped specifically for a product category — separate tags for Reviews, and separate tags for News, without mixing them up.

It was only necessary to create a couple of modules for a tree‑like display of Tags with a category view.
And it can display the number of tags in the articles table column.

It’s a worthwhile thing. But I thought that categories should be self‑contained, without multicategories.
I’ll explain why.
A long time ago:

1. They created rigid categories: Favorites, Published, Trash.
2. They created nested categories. Classic customizable categories.
3. Multicategories have existed in Joomla for a long time.

Let’s not impose functions from point 1 onto point 2 and vice versa; we shouldn’t confuse the Trash and favorites with categories. The functionality is roughly similar, but these are different levels of responsibility.
Multi‑categories are called Tags. Tags inherently imply multi‑categorization. At the same time, the flexibility of multi‑tags is so great that it fits very well with multi‑categories.
The problem with Joomla is that there are no modules implemented to display Tags as categories.
However, the scope of responsibility for Multi‑categories is exactly the same as for Tags.

Such a PR has already been done before, but for some reason it’s being ignored.
The solution to the Multi‑categories problem has, in principle, already been solved here for a long time...

[6.2] New module - Category Tags

The responsibility of categories is what is precise and unambiguous. For example, categories: Orders, Reviews, Products, News.
And what is required for multi‑categories, for example, for phone sales: Bluetooth, WiFi, 4Gb. This is what is assigned to a single product at the same time.
At the same time, the tags themselves are also stored in the categories. This allows them to be grouped specifically for a product category — separate tags for Reviews, and separate tags for News, without mixing them up.

It was only necessary to create a couple of modules for a tree‑like display of Tags with a category view.
And it can display the number of tags in the articles table column.

By the way, why wasn’t this PR module accepted? It’s already 4 years old.

It’s a worthwhile thing. But I thought that categories should be self‑contained, without multicategories.
I’ll explain why.
A long time ago:

1. They created rigid categories: Favorites, Published, Trash.
2. They created nested categories. Classic customizable categories.
3. Multicategories have existed in Joomla for a long time.

Let’s not impose functions from point 1 onto point 2 and vice versa; we shouldn’t confuse the Trash and favorites with categories. The functionality is roughly similar, but these are different levels of responsibility.
Multi‑categories are called Tags. Tags inherently imply multi‑categorization. At the same time, the flexibility of multi‑tags is so great that it fits very well with multi‑categories.
The problem with Joomla is that there are no modules implemented to display Tags as categories.
However, the scope of responsibility for Multi‑categories is exactly the same as for Tags.

Such a PR has already been done before, but for some reason it’s being ignored.
The solution to the Multi‑categories problem has, in principle, already been solved here for a long time...

[6.2] New module - Category Tags

The responsibility of categories is what is precise and unambiguous. For example, categories: Orders, Reviews, Products, News.
And what is required for multi‑categories, for example, for phone sales: Bluetooth, WiFi, 4Gb. This is what is assigned to a single product at the same time.
At the same time, the tags themselves are also stored in the categories. This allows them to be grouped specifically for a product category — separate tags for Reviews, and separate tags for News, without mixing them up.

It was only necessary to create a couple of modules for a tree‑like display of Tags with a category view.
And it can display the number of tags in the articles table column.

By the way, why wasn’t this PR module accepted? It’s already 4 years old.

@richard67 @brianteeman

I already wrote on that pr that I thought it was a good idea for the core. But thats just my opinion. I have no role or authority to make any decision - I can just exprerss an opinion which is what I did. Asking me the same question again wont suddenyl give me the authority to accept a PR

I already wrote on that pr that I thought it was a good idea for the core. But thats just my opinion. I have no role or authority to make any decision - I can just express an opinion which is what I did. Asking me the same question again wont suddenly give me the authority to accept a PR

😊😊I understand you. The ways of Joomla are inscrutable, thorny, and don’t necessarily have to be understandable to everyone.

As no one has been able to reproduce the error Save failed with the following error: SQLSTATE[HY093]: Invalid parameter number: :preparedArray1, I created a throwaway Ubuntu VPS with JBT running the Joomla 6.3-dev branch with this PR applied.

I also created a private Mattermost group with the access details. Please ask me on Mattermost if you would like to have a look.

I finally saw the error on your site. Took me a lot of attempts to see it but i did eventually

This pull request has conflicts, please resolve those before we can evaluate the pull request.

This pull request has conflicts, please resolve those before we can evaluate the pull request.

I've allowed myself to solve the merge conflicts caused by the upmerged PRs #48011 and #47966 .

I have tested this item ✅ successfully on 55ef123

I tested the API Part with

1. two articles with different sub category sets

• read json's per API get
• patch call to update to different category sets

2. one contact

• read json's per API get
• patch call to update to different category sets
• invalid sub category ids are ignored

3. Banners

• read json's per API get
• patch call to update to different category sets

3. News Feeds

• read json's per API get
• patch call to update to different category sets
• invalid article sub category ids are ignored

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48230.}

I have tested this item ✅ successfully on 55ef123

I tested the API Part with

1. two articles with different sub category sets

• read json's per API get
• patch call to update to different category sets

2. one contact

• read json's per API get
• patch call to update to different category sets
• invalid sub category ids are ignored

3. Banners

• read json's per API get
• patch call to update to different category sets

3. News Feeds

• read json's per API get
• patch call to update to different category sets
• invalid article sub category ids are ignored

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48230.}

A summary of the testing carried out on the VPS and the Mattermost discussions on 3 and 4 September:

• @muhme set up a throwaway VPS Ubuntu 24.04 LTS command line with JBT, accessible from Internet with PostgreSQL from 6.3-dev branch and with this PR applied
  • Error Error 'Save failed with the following error: SQLSTATE[HY093]: Invalid parameter number: :preparedArray1' seen
• @brianteeman could reproduce the error after a lot of attempts
• It figured out that this postgres error is going to stderr and visible with docker logs jbt-pg, but i can not see related on first view, and the error is typically raised by PDO while binding parameters, before PostgreSQL executes the statement
• @Reda-Muhamed stated and has submitted a patch:
  • He analysed that he removed the generated :preparedArray* placeholders from some mapping write queries, but getManageableSecondaryCategoryIds() in SecondaryCategoriesSaveTrait.php still used whereIn(). That method is executed before saving the article, and whereIn() internally uses bindArray(), so it can still generate :preparedArray1.
  • Therefore he updated additionally the two files :
    • libraries/src/Helper/SecondaryCategoriesHelper.php
    • libraries/src/Helper/SecondaryCategoriesSaveTrait.php
  • This additional change avoids bindArray() / whereIn() in the secondary category save path and uses explicit named placeholders instead
• Both files were applied to the VPS, and neither @muhme nor @brianteeman were able to reproduce the error, it appears to be fixed
• VPS was deleted and @Reda-Muhamed added the fix to this PR

For info: Started Update Branch to get a Downloadable package for the PR, as there is currently no downloadble package existing and on creating a banner I am getting:

0 There is no "joomla.batch-secondary-category-addremove" asset of a "script" type in the registry. 

multiple times with Patch Tester and fixing database, even after new Joomla installation. Will restore the one successful test afterwards.

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

I really think this feature should not be on by default and i am surprised not more people think of it that way. There are some serious issues with performance with this PR as it sits and even if those are fixed it does impact performance and i don't think it is fair to slow down 95% of websites for the other 5% that actually need this feature.

I ran a before/after performance test on this PR, because the category queries change for every site, not only for sites that use additional categories.

Setup

• Baseline: merge-base of this branch with 6.3-dev (9708fa7). PR: da8dff6.
• PostgreSQL 16 and MySQL 8.0, one database per site, installed with the CLI installer.
• 20 000 published articles in 60 categories (10 parents, 5 children each), identical in all databases. On the PR databases 30% of the articles have one or two additional categories.
• Apache Bench, one concurrent client, five interleaved rounds per view, median per request. Queries re-run with EXPLAIN ANALYZE.

Page timings (median)

Spread between rounds is under 3%. With an empty #__category_item_map the numbers are the same, so this is the query shape, not the data.

The cost grows with categories × articles, so larger sites will see more than this.

Regarding performance: Having a subquery in a where clause is almost always bad for performance, and it could almost always be replaced by a join to that table and the necessary conditions in the where clause which is almost always better for performance. But I do not have the time to have a deeper look on it.

for the other 5% that actually need this feature.

If you have a 5-page website, then you really don't need multi-categories, you don't even need Joomla, you can make a 5-page website on pure HTML and CSS, without using a CMS, or have a business page on a Social Media.

People choose CMS to make it easier to add multiple articles, categories, and lots of information to their website without creating a separate HTML page in an HTML editor each time.

Multi-category features are intended for those who choose to build their website using a CMS rather than plain HTML.

There are some serious issues with performance with this PR

I remember that the transition from regular Search to Smart Search also slowed down websites that enabled Smart Search indexing a lot, but over the years various optimizations have been made to how Smart Search works, so I think there are optimizations to be made with multi-categories as well to increase website performance.

There are some serious issues with performance with this PR

I remember that the transition from regular Search to Smart Search also slowed down websites that enabled Smart Search indexing a lot, but over the years various optimizations have been made to how Smart Search works, so I think there are optimizations to be made with multi-categories as well to increase website performance.

Exactly my point. Who enabled it. This is enabled by default. Our users don't get to choose to enable it or not.

Exactly my point. Who enabled it. This is enabled by default. Our users don't get to choose to enable it or not.

but this is not a problem with multi-categories as a feature, it is a problem with the current code, which can be improved and optimized, because there are other CMS and there are 3rd-party extensions for Joomla, where there is no performance problem with the multi-category feature enabled.

I think we should work on optimizing this code, but not deprecate this feature.

Who is talking about deprecating this feature?

I'll take a closer look at the queries used here and see if there are any opportunities to optimize them

Regarding disabling the feature by default, I'm not sure that's the best approach. I think being able to assign an item to multiple categories is a reasonable capability to have in a CMS, even if not every website needs it

I'll take a closer look at the queries used here and see if there are any opportunities to optimize them

@Reda-Muhamed As said, do not use a subquery in a WHERE clause, use a left join instead and put the WHERE conditions of the subquery into the conditions for the join or the WHERE clause of the main query.

Maybe performance can also be improved by adding the one or other index. That mainly depends on the conditions used in WHERE clauses.

A subquery in a FROM clause is something else because it is not really a subquery, it is a so-called instant view. Such a thing can improve performance.

imho this feature should be opt-in not default

Fable 5.2 had this as proposed fix.

Count the two memberships separately so each half can use its own index. Measured on the same PR data at 22 ms on PostgreSQL (baseline 12 ms, PR 212 ms) and 34 ms on MySQL (baseline 27 ms, PR 2 300 ms).

(SELECT COUNT(*) FROM #__content i
   WHERE i.catid = c.id AND i.access IN (…) AND i.state = 1 AND …)
+
(SELECT COUNT(*) FROM #__category_item_map m
   INNER JOIN #__content i ON i.id = m.item_id
   WHERE m.context = 'com_content.article'
     AND m.category_id = c.id
     AND i.catid <> c.id
     AND i.access IN (…) AND i.state = 1 AND …)

The list and pagination queries have the same shape (a.catid IN (…) OR a.id IN (subquery)). On PostgreSQL that costs a few milliseconds, on MySQL it drops the catid index on every category page. A UNION of the two id sets, or an EXISTS per side, keeps both on the index.

Please don't take this for the truth. It is merely as guidance. I have not confirmed this is the correct solution. But we do have a lot of smarter people here than me who can make that judgement.