this hardcodes com_fields in categories. IMHO we need a more flexible way to not show associations in categories if not needed for a particular category context.

There are several cases in which that happens:
1. Com_banners categories
2. Com_users notes categories
3. Third party components categories

Don't know if it would be possible with the component specific category.xml file?

the fact is that com_fields has already modified com_categories...
@andrepereiradasilva @rdeutz @wilsonge
i guess plt has to take a decision/propose an alternative.

this is IMO an issue that existed before com_fields, but since before com_fields the core didn't have any two category contexts in the same component the issue never have been treated.

@mbabker

@laoneo
any way you can think of using another new table and code something to replace the use of com_categories?
we do not need imho the parent/child aspect of com_categories anyway.

I would not introduce a new table just because of some minor issues. Having the full advantage of categories weights for me more. I think in the future we can then do more things like nested tabs which reflects the category structure.

@laoneo
This, I guess, will be the decision of PLT.
While I am here, please look at other issues I found out:
#12693
#12692
#12691

If we have to start adding com_fields code into com_categories, it is a strong indicator to me that categories is misused for com_fields and should be done with own code and tables.
Also seeing that the category "extension" field is specified eg as "com_content.articles.fields" instead of "com_fields.foo.bar" looks a bit problematic to me. It indicates the category belongs to com_content, but in fact it's managed by com_fields.

That's just commenting based on this PR and what I see in the database tables, not looking at the code. It's some stuff that raises a question flag to me.

#12701 does the same, but the coupling between com_categories and com_fields doesn't exists anymore. What do you think about this approach?

#12701 does not delete the existing com_fields specific code in com_categories and now forces the plugin to be enabled at all times when it was not necessary until deciding to display the fields.
See
https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_categories/views/categories/tmpl/default.php#L33-L50
and
https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_categories/models/categories.php#L377-L386

Also it does not take care of the associations column in field groups manager

@laoneo
Let me explain better my comment.
This PR here exists because there is already some specific code concerning com_fields in com_categories (see blobs above).
The issue is not this PR (it works fine), if the existing code remains and is accepted by PLT/maintainers. It is that last aspect which is in question.

Currently there are at least two places where com_fields has special case code in com_categories:

• https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_categories/models/categories.php#L381-L385
• https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_categories/views/categories/tmpl/default.php#L44-L49

This PR would only add one more. If we go this route, then this PR is fine and more such code will come in future quite sure.
However myself I believe we shouldn't go this route.

@laoneo could you explain why you are adding com_fields specific code to com_categories? For me this is a warning sign that your architecture is not as it should be.

Because the link to com_fields for the countItem functionality here

has to point to com_fields and not com_content or the other components integrating com_fields. I'm well aware that com_categories should be unaware and I was looking long for a more decoupled approach but could not find one. I'v added it because Brain and me I thought that functionality would be helpful (joomla-projects/custom-fields#61).

Next question would probably be why does the category not point to com_fields instead of the components. I wrote this code long time ago in DPFields. But as far as I could remember is that linking like the options and other stuff should point to the component and not com_fields, because there is no menu item in the back end for com_fields.

I think we need to add a table #__field_groups here and remove the usage of categories for the field groups. For me it is the wrong usage of categories and it can confuse users. The first thing I struggled was that in my default installation I have versions enabled so the question would be what does it mean for fields? Can I have different versions of field groups? The 2nd question for me is what is the result when I use a category-tree and don’t add a leaf of the tree? Do I get all fields then? It makes it more complicated as it have to be, we can have 1 level of field_groups. We don't need parent/child here and if someone can make a custom field "FieldGroup".

I don’t think this is a such big deal to add the table and we can avoid changing com_categories, what is bad from an architectural POV.

Just my two cents here. I would reuse as much code as possible, that's why I'v used categories. Using categories gives us many features out of the box, otherwise I think that Field groups will be on some point in the future more or less a copy of a com_categories.

Tree is a good example. At the moment all fields are displayed in top level tabs. Perhaps on some point we need tabs in tabs. I would be prepared for future changes and categories is giving them us.

If we need tabs in tabs, we have much bigger issues to solve. To my knowledge neither our JLayouts nor the form xml definitions support that. And I honestly doubt com_fields should be the starting point to support that.

The thing is that com_categories does a lot more than what field groups need. And this will be confusing to users if we don't hide those options (which means code specific to com_fields in com_categories -> noGo)
Field groups wouldn't be copy-paste code from com_categories. It would be a much simpler code.

I would be prepared for future changes and categories is giving them us.

Actually I think the opposite will happen. In future we may very well want to add something to field groups which isn't needed in categories. Like default options specific to the fields in that group (eg display position). That wouldn't be possible with com_categories to my knowledge.

That wouldn't be possible with com_categories to my knowledge.

It would with categories.xml files where a component can add new parameters to a category.

What I just want to say is that we have categories which dos a similar job than what we need in groups and I would reuse that. If com_categories lacks of flexibility then we should consider to add it instead of copy it. But looks like the decision is made already #12800 (comment).

It would with categories.xml files where a component can add new parameters to a category.

Learned something today, wasn't aware this is possible ?

Point still is that we may want to add things to fields groups which isn't possible (or suitable) for com_categories and we're going to limit us.

But looks like the decision is made already

I'm not sure if it's an official decision already. It was mainly a comment in the maintainer chat by the release leader (who can decide such things). It's based on the fact that there is custom com_fields code in com_categories. Which is a big red flag.

If it is only because of the com_fields code in com_categories, then I'm sure we will find a way to decouple it properly as it is only because of the countItem functionality. I see it as a plus when we can showcase the flexibility of com_categories. We will see where it goes...as it will be a bigger change.

#12887 does remove the hard coupling between com_categories and com_fields. One argument less to not use com_categories ?

#12887 does remove the hard coupling between com_categories and com_fields. One argument less to not use com_categories ?

I don't think it does.

Is this still relevant now that field groups has been decoupled from categories

Closing as the com_categories code isn't used anymore for com_fields