The one thing we dont have right now is an easy way to assign a collection of fields to categories. I remember there was a discussion about this when fields were added to Joomla but I completely forget the reasoning that this was not done. maybe @laoneo can enlighten us on that aspect

This is a great start ~!

My only issues is that Categories are hierarchical, and Types are not (?), buuuttt.... I am thinking that through and cannot see why this would not be a great step forwards and cover most of the issues in previous chats !

Adding Tags filtering in the menu and making sure that sub categories inherit the Custom Fields would be important in my view..

My only issues is that Categories are hierarchical, and Types are not

Look at it as a feature. You can have nested types. Eg a type "car" and then a subtype "Opel" and another one "Ford". ?

@brianteeman The easiest way would be a batch command to assign multiple fields to a category. From my point of view there is no issue doing that.

Also hence this related topic "Improve admin menu items" #17407

@laoneo except that functionality doesnt currently exist

I understand that field groups = tabs
I understand that a field can be assigned to a category

Wouldnt it also make sense that a field group can be assigned to a category

No issue with that as well.

maybe its my memory failing but I seem to recall there was a discussion about putting field groups in caategories when you did the original PR

At that time field groups have been categories. I guess you mix things up.

that explains that

Wouldnt it also make sense that a field group can be assigned to a category

This may become interesting as soon as the assigned field category and field group category aren't matching. Which one should then have precedence?

It is only about assignment, it will be then assigned to both.

Yes, indeed, this is a simple (?cleaner?) solution
it bonds well with the existing assignment of custom fields by category

and it is usable by any component

• i would say that Joomla already has "types" for all components since the custom fields were added per category,

just some UI work is needed, to expose what is already possible

To make this more automatic i would say to do this

• Optionally "Flag" categories as types (add a new column to categories table: is_type)

1. (as mentioned) You have nested types with ACL (create / edit / etc) per type
2. Items assigned to a flagged category (or to its any sub-categories) will (automatically) appear in (?frontend?) / backend management as items of the type in the types menu, that have the same name as the category, an item inside 'Automobile' Category is-an "Automobile" and if you move it to sub-category "Truck" it is both an "Automobile" and a "Truck", thus if you filter by "Automobile" you should also see the "Truck" items
3. When creating content the types selector (a new form element) is populated according to create ACL of the flagged categories
4. If creating an item of type "Automobile" limits category selector to "Automobile" category and to its descendants, if creating a "Truck" limits category selector to "Truck" category and its descendants

Specially for com_content (J4) rename "articles" term to "items" , no need to change DB table name or context name (com_content.article), just change all language strings and documentation everywhere

[EDIT] this last one is probably bad idea, see comment below #20233 (comment)

Optionally "Flag" categories as types (add a new column to categories table: is_type)

Might as well do the content/post types thing in the other issue if you're doing that. Because that's what you're leading up to.

Specially for com_content (J4) rename "articles" term to "items" , no need to change DB table name or context name (com_content.article), just change all language strings and documentation everywhere

Bad idea. That's changing labels for the sake of changing labels (inherently breaking all documentation ever written) and leaving the code and the UI massively inconsistent.

Thinking out loud, with the lack of experience in how new installable demodata actually works, but could this approach be provided with installable "demo packages"?
Core provided installable packages of setups similar to demo data but being useful starter type kits.

You can do almost anything with a sampledata plugin.

Might as well do the content/post types thing in the other issue if you're doing that. Because that's what you're leading up to.

hhmm i am continueing discussion already done in this topic,
which is about using something that is already implemented

Bad idea. That's changing labels for the sake of changing labels (inherently breaking all documentation ever written) and leaving the code and the UI massively inconsistent.

Well, ok, you could keep as articles, just the term will feel wrong
plus once you add the "types" terminology you have this already:
"and leaving the code and the UI massively inconsistent"

Article is already a generic term. There's nothing gained from changing the term and breaking 12 years of history for the sake of replacing a generic UI term for another more generic UI term.

Article is already a generic term. There's nothing gained from changing the term and breaking 12 years of history for the sake of replacing a generic UI term for another more generic UI term.

Good argument, indeed, probably not worth the troubles changing this term

Funny enough this is something myself and @GeraintEdwards have talked about in the past. We were originally looking at handling it with a plugin, but if the core natively adopts it then awesome!

Would make it much better when using com_content for more than just site pages..

There are no needs for any dB changes and nor should there be any to achieve this

If the admin menu item passed an extra parameter e.g. &type=catid then it would be easy for the edit page to use slightly different language strings??

@GeraintEdwards you're the dev not me. so i can't answer that but it sounds feasible

I have started working on this. I have been able to add category selection to the admin menu link.

But the url is generated as index.php?option=com_content&view=articles&category_id=8
and it needs to be filter.category_id

Any hints

OK that part done thanks to @tonypartridge

Just downloaded and tested this feature in Joomla 3.9.

Great work Brian et al ! Thanks for doing this - it makes a content admins life much easier.

To see this, and workflows being incorporated into Joomla 3.9/4.0 is frankly extremely satisfying.

Especially for government opportunities where document workflow (and accessibility) are key factors in the platform.

Now we just need standard template overrides for category list pages, and to also be able to actually 'delete my article' from the front end and I think Joomla will have made significant strides interface wise.