Custom Forms: easier management with "content types"?

[crystalenka]

The problems

In an ongoing RFC (#36710) it's come up that currently, custom fields have a lot of potential, but are time-consuming to set up and hard to manage.

Subforms help ease that a little bit, but even so, making sure they are assigned to the correct pages depends heavily on categories.

Currently, custom field assignments are solely dependent on the category of items. This makes an assumption that all sites are organized into categories based on information type, when that's not necessarily the case or even the best solution for all sites. (For example, it makes sense when you have a recipe site, or a blog, but might make less sense for an association with different chapters that needs to organize the content by chapter.)

This problem is compounded by the way menu routing works, so even if you create sub categories for different types of information, you will have additional categories in the URL unless you create menu items that would otherwise be unnecessary. It gets complicated really fast.

Additionally, if you are using custom layout overrides on an item level (like an article) instead of on a custom-field level, it creates a situation where you have to ensure that every item selects the correct layout override AND is in the correct (and possibly unnecessary) category.

A possible solution

I think it makes sense to decouple categories from field display. Categories should be to organize the content in a way that makes sense for the content of each site; as it is now, we are forcing site builders into using categories for 'types' of content.

So, perhaps a missing link: content types?

A step between custom fields and items (articles, contacts, etc, whatever components use custom fields) that allows you to assign custom fields (still optionally organized into field groups) to content types instead of categories.

It would be nice to also optionally select the default layout for a specific content type, so that in cases where the layout is tightly dependent on certain custom fields, you could ensure they are present.

This may help people understand better the relationship between custom fields, field groups, and content items, because right now we are making assumptions about how people think about information in their specific use case.

How would it work?

In my mind, content types would be opt in (like how workflows are), not required by default. (At least in the beginning?)

It would still make sense to be able to select a default content type in the menu item settings for a category, but critically, you would be able to override it on an item level and have the appropriate custom fields show up.

Content types would be per component, like how fields are per component.

If not enabled, fields etc would work like they do now.

However, if enabled, when adding a field you would be able to assign it only to a field group.

Then, when managing the content types, you would be able to add which fields belong to the content type. (This is easier to do all at once per type instead of on a field-by-field basis.)

Open questions

• How, if at all, would this affect the database structure of custom fields?
• Opt-in would make it backwards compatible. Is this possible?
• Would we be able to take advantage of field sets somehow with custom fields? They are supported in xml forms but currently not accessible in custom fields. (I recently discovered that even repeatable subforms can group fields by field set, but it's not possible through the UI currently.)
• Versioning?
• Searchable?

---

This isn't the first time the idea of content types have come up:

• [4.0] Multiple Content Types (feature request) #19150
• Custom Content #24822
• (more? I can add additional links if necessary)

I am opening a new discussion because of the age of previous discussions/issues, and because of the significant changes to custom fields/Joomla since then.

Thanks @coolcat-creations for bringing it up again. :)

[brianteeman]

Re searching custom fields please see (and test) #38650

[coolcat-creations]

It says "Make sure that #38585 is merged" Which is not - so not sure when to test or if the test can be done?

[richard67]

You can apply both pull requests #38585 and #38650 e.g. with patchtester because these 2 pull requests change different files.

[krileon]

This seams like it's over complicating content types. Why does it need to extend to other components? I suggest just extending the content component and focusing it there. Fields and field groups can already be assigned to categories. Simply extend them to also be assigned to content types as well. So you'd have a content type of Photos and it'd have a subform with an image field in it assigned to that type. Now you can upload a bunch of photos for that content type.

I don't think management of all this is complicated. It's mainly the rendering. Joomla would need to have different layouts per content type and those would need to be easily edited so you can make a new layout per content type to customize how all this looks. Joomla should also come with a couple content types default out of the box. Just your standard stuff like Article, Photos, etc..

Extensions can then extend all this by just making new Joomla fieldtype plugins to add new fields to those content types easily.

I suppose you could also extend this to content categories so you can have categories specific to content types as well, but probably not entirely necessary.

As for menus/SEO there isn't anything to worry about here. They'll just be content served by the content component after all so that's already taken care of by core.

[crystalenka]

It's not me overcomplicating it; it's how custom fields work. They are available to many core and third party components so any changes to custom fields will also change how custom fields work elsewhere.

Unless maybe it's a plugin for com_content only? I'm not sure if/how that would work.

[krileon]

It would apply to com_content only. Verify the context when applying any of this behavior. Content types don't really make any sense outside of content. This would prevent needing to do any sort of massive rewriting to how fields, field groups, and their categories function. Another solution maybe to improve how field tags work so they could effectively be used as your content type, but that doesn't really handle the rendering behavior noted in my reply.

[brianteeman]

I think it makes sense to decouple categories from field display. Categories should be to organize the content in a way that makes sense for the content of each site; as it is now, we are forcing site builders into using categories for 'types' of content.

Can you give an example please of where you would have different content types in the same category. Every example I think of would only have 1 content type per category. Perhaps this is because I always build with bultiple content views (blog, list etc) and never single pages?

[crystalenka]

Sure. One example is a nonprofit client I have that does literacy tutoring for people who don't speak English or for adults who don't read or write. The site is here.

In addition to the typical nonprofit audiences of donors etc, their site also had to appeal to and inform potential tutors, and inform and help current and potential students.

These are categories based on persona, not content types.

Both categories had a mix of content types: informative pages, as well as pages which had to include schedules of various types (for classes or training), and pages which had embedded registration forms (via iframe due to organizational restraints).

In order to make this work in Joomla, I had to create hidden subcategories for each page type. This is less than ideal and makes it hard for my client to add new pages to the site by herself because of the factors I mentioned in the initial post.

Content types would be much easier.

[coolcat-creations]

@crystalenka so instead:
Content type A
Content type B
Content type C

you have:

Category A
Content type A
Content type B
Content type C
Category B
Content type A
Content type B
Content type C

Is that correct?

I rather use the first structure too. I have to think about how that could be solved.

[brianteeman]

@crystalenka from the descrption you are describing a scenario where you are trying to make your content architecture match your site navigation architecture.
I have a large site with the following structure and the users have no problems creating content. Here the content types are of course components but they would have been content types if availalable

menu (simplified)

Menu A

• News (com_content)
• Events (dpcalendar)
• Booking forms (rsforms)

Menu B

• News (com_content)
• Events (dpcalendar)
• Booking forms (rsforms)

Content Structure (simplified)

com_content

• Category A
• Category B
  com_dpcalendaar
• Category A
• Category B
  com_rsforms
• Category A
• Category B

summary

for me this si the simplest and most efficient way and supports a quite complex set of acl rules very easily.

If I had content types I would not change this structure but I would possibly change from an external component to a content type

[coolcat-creations]

Maybe we could add a setting to the field group and define the field group to be a content type, then the field only has to be assigned to the content type and not anymore to a category. The content type could control then all settings like which category it's assigned to? Just thinking loud how we could integrate it into the existing structure.

[crystalenka]

I see where you're going, but I feel like that just moves the problem to a different part of the existing structure.

I think that content types would have to be something new, not reworked into a different part of custom fields, because it depends on how you use field groups. Maybe it's one field group per content type, maybe it's not. :)