I already pushed the beta1 date to next week, so it is time to discuss the PR (I haven't read atm ;-))

@rdeutz thanks. I had a few sleepless nights to learn the fields and get it working in time. ?
BTW, will fix the CS issues now...

THANK YOU +1 for improving before making improvements impossible due to B/C

First I have to say I still disagree with this approach. I don't see the reason to add yet another layer of complexity to custom fields. And in the end it reduces flexibility as you can't reuse the same field for different use cases, they have to be tied to a specific form and only that form can be assigned to categories.
Currently, you can add and remove any field for any category which is much more flexible.

Second there are multiple issues just from having a first look at it:

• Since forms are required, I now need to first create an arbitary form before I even can start create a group or field. Even if I only need a single field, I still need to create a form.
• ACL is completely broken on the forms.
• I find it very confusing that I can specify multiple forms for a given item (eg article), but they show up as regular fieldsets. So they are not really forms but groups of groups (fieldsets).
• I don't get the point of having a subform when it's not repeatable, except that it is yet another way to group fields together.
• Even if the subform plugin is disabled, forms still allow to set them as subforms. Which actually shows the major flaw in this proposal. It's basically an approach to include the (repeatable) subform fieldtype by hacking com_fields to allow it. That's not how the fieldtype plugins should work. If you need to adjust com_fields so the fieldtype works, then either the fieldtype isn't a good candidate for custom fields (which I think is the case here) or you did it wrong.
• Language strings are missing all the way
• Fields in subforms that are assigned to a field group don't show up in the subform. This is confusing.
• As you wrote, the display part of the subform doesn't work. And I honestly doubt we can provide a way that works for most users. Subforms will become very complex soon, especially if they are repeatable.

If we wanted to add subform functionality to com_fields, all that is really needed is to make the groups a nested set and allow to select a parent group. Similar to how categories. There is zero need for yet another table and all it's accompagning code.
However personally I don't see the need for this. Custom Fields are meant to add a few fields to existing items. They are not meant to build complex forms. That's where you should use a real CCK.

Another thought: Why can't the subform field just use the existing field groups? Just let it select a group instead of a form and you basically have the same thing. You could even get rid of that funny "is Subform" toggle.

He said it´s raw because he wants to submit it before beta is published.
I like the idea of having Forms but i also agree that Field Groups as they are called are not needed then. It will be too complex. Can we have instead of field groups and Forms just 1 Option where both things can be set?

I honestly don´t like seeing Fields and Field Groups in each menu, it clutters the Overview and confuses the users. Can´t we have a mainmenu item Fields and manage there Fields for users, contacts and content? (please?)

Can we have instead of field groups and Forms just 1 Option where both things can be set?

Technically there is no difference between forms and groups except that forms have that "is Subform" toggle and the category assignment is moved from fields to forms. Both things I don't like personally.

I honestly don´t like seeing Fields and Field Groups in each menu, it clutters the Overview and confuses the users.

I agree with that, and this PR even adds one more.

Can´t we have a mainmenu item Fields and manage there Fields for users, contacts and content? (please?)

I had that code proposed back when I moved the code from categories to field groups but it was said to be a bad idea as it is confusing to users. Technically it is no problem to do it, it's just an UX question.
See #13019 for the discussion about it (the selector at the top).

So we could "merge" this systematic with the subform toggle ? That would be great.
Also commented on #13019 directly there.

Thanks!!!

So we could "merge" this systematic with the subform toggle

I don't think it needs a toggle. All that toggle does is imho tell the subform plugin if it should list the form to be selected or not. And in the field group the subforms don't appear in the form selector. That's all. as far as I saw. This sure could be done different.

@coolcat-creations

I like the idea of having Forms but i also agree that Field Groups as they are called are not needed then. It will be too complex. Can we have instead of field groups and Forms just 1 Option where both things can be set?

I kept the groups because it was already part of the whole and I didn't want to throw away work done by @laoneo. Instead, I wanted to expand on it. I like your suggestion though, and I also think they ought to be combined. Thanks.

I honestly don´t like seeing Fields and Field Groups in each menu, it clutters the Overview and confuses the users. Can´t we have a mainmenu item Fields and manage there Fields for users, contacts and content? (please?)

You have a point there. I also thought about that, but wanted to finish up with this one, first. However, keep in mind that a lot of other components might (and should, in my opinion) make use of this extra functionality.

@Bakual

First I have to say I still disagree with this approach. I don't see the reason to add yet another layer of complexity to custom fields. And in the end it reduces flexibility as you can't reuse the same field for different use cases, they have to be tied to a specific form and only that form can be assigned to categories. Currently, you can add and remove any field for any category which is much more flexible.

Actually it's the opposite. It gives you more flexibility while maintaining manageability.
Fields are always tied to forms. Since we are introducing custom fields, the structural correct way of managing them in a GUI, is a container. Groups as they are now, are not the right fit for various reasons. Forms are.
It's not unnecessary complexity. It is structurally correct for overview, manageability and context. You don't go in HTML and throw fields wildly into the DOM. You put them inside a form, and exactly one field in one form. If it were possible to have the same fields (manage and storage-wise) in different containers, it would at some point become a chaos.

Since forms are required, I now need to first create an arbitary form before I even can start create a group or field. Even if I only need a single field, I still need to create a form.

Yes, and that's ok. It's not as you would create 100 different forms at a time. And even then, you would be grateful for the functionality as more things are added and manageability becomes more difficult.

ACL is completely broken on the forms.

Yes, as I wrote, it has some rough edges, still.

I find it very confusing that I can specify multiple forms for a given item (eg article), but they show up as regular fieldsets. So they are not really forms but groups of groups (fieldsets).

Actually not. As I explained, Forms and Groups both provide fieldsets, as this is what we can work with. The difference in terms of layout, is that forms are the anchors if you will and the groups of the forms are appended to the right of each form.

I don't get the point of having a subform when it's not repeatable, except that it is yet another way to group fields together.

I don't quite understand. Subforms are of course repeatable. I demoed it in the video. Maybe it's a bug that got in, last minute? Can you share some insight on what you did?

Even if the subform plugin is disabled, forms still allow to set them as subforms. Which actually shows the major flaw in this proposal. It's basically an approach to include the (repeatable) subform fieldtype by hacking com_fields to allow it. That's not how the fieldtype plugins should work. If you need to adjust com_fields so the fieldtype works, then either the fieldtype isn't a good candidate for custom fields (which I think is the case here) or you did it wrong.

Again, I learned a few things about the fields, by trying to implement an idea that I had. I wanted to get a working implementation out, so it gets seriously considered for inclusion. I wanted this to be something one can try out. Yes, I agree, some parts of the implementation might look as hacks, but those can be improved upon. The important thing with this PR is the concept.

Language strings are missing all the way

All the way? Where?

Fields in subforms that are assigned to a field group don't show up in the subform. This is confusing.

Yes, there should be a restriction for that. Subforms do not support that at the moment. Unless we decide that subforms can have groups, which will essentially make sub tabs under the main forms tab.

As you wrote, the display part of the subform doesn't work. And I honestly doubt we can provide a way that works for most users. Subforms will become very complex soon, especially if they are repeatable.

I see the subform's (especially the repeatable) with plugins that build upon the data that has been provided that. Think for example of better image galleries (not only with images, but with texts and other data).

If we wanted to add subform functionality to com_fields, all that is really needed is to make the groups a nested set and allow to select a parent group. Similar to how categories. There is zero need for yet another table and all it's accompagning code.

Not sure if all is so easily fixable with the categories approach, but it sounds like a good idea. I will look into that, too.

However personally I don't see the need for this. Custom Fields are meant to add a few fields to existing items. They are not meant to build complex forms. That's where you should use a real CCK.

Why are they meant to be this way? Why not make them better? If we are to think that way, why do we improve Joomla at all? Why not just leave it at that? It does what most people want. No need then to try to get more people on board, who want to do that much more, that Joomla can't provide, but for whom the added complexity and maintainability of a CCK is overkill. But that's only my five cents.

Another thought: Why can't the subform field just use the existing field groups? Just let it select a group instead of a form and you basically have the same thing. You could even get rid of that funny "is Subform" toggle.

No, they are not basically the same. If at all I would combine them to be forms.
Why should I remove the toggle? I am very happy that it makes people laugh...

I don't think it needs a toggle. All that toggle does is imho tell the subform plugin if it should list the form to be selected or not. And in the field group the subforms don't appear in the form selector. That's all. as far as I saw. This sure could be done different.

Actually, the toggle does a lot more than that. However, everything can be done in a lot of ways, and this PR can still be improved if there is the will to do so.
But frankly, I would like to see a bit more positive attitude towards someone who invests time to contribute to the community effort.

Groups as they are now, are not the right fit for various reasons. Forms are.

Technically, it's the exact same thing you do with forms as is done with groups. Except that forms are required and groups are optional.
Semantically, "form" is an incorrect term as you don't create a new form with them, your "forms" get included into an existing form. Even multiple of your "forms" can be included into a single item edit form. It's only a group of fields you define in your "form".

You put them inside a form, and exactly one field in one form. If it were possible to have the same fields (manage and storage-wise) in different containers, it would at some point become a chaos.

Actually, we have the same field (title, alias, state, ...) in many forms regulary in Joomla, no issue at all. With custom fields it's absolutely no problem at all to do that as well. I don't see the issue you seem to have.

I don't quite understand. Subforms are of course repeatable. I demoed it in the video. Maybe it's a bug that got in, last minute? Can you share some insight on what you did?

You can set to to be repeatable or not. But there is no point having a non-repeatable subform. So that option is useless here and should be repeatable always. That's what I meant.

The important thing with this PR is the concept.

Yep, and that's were I still disagree completely.

All the way? Where?

From memory, at least plugin description and several messages. I didn't wrote them down as it was many times I saw an untranslated string.

Yes, there should be a restriction for that. Subforms do not support that at the moment. Unless we decide that subforms can have groups, which will essentially make sub tabs under the main forms tab.

The restriction only works when the form is set to be a subform from the beginning. If you change an existing form to be a subform later on, the groups will already be assigned and it breaks.

Not sure if all is so easily fixable with the categories approach, but it sounds like a good idea. I will look into that, too.

No, save your time. It will just be useless.

Why are they meant to be this way? Why not make them better?

Because that was the intention behind com_fields. And because there are existing solutions already if you need more fucntionality. There is no point trying to build a complex CCK into core.
It should be simple and easy to manage in future.

Why should I remove the toggle? I am very happy that it makes people laugh...

Because it's a hack to support a subform plugin.

But frankly, I would like to see a bit more positive attitude towards someone who invests time to contribute to the community effort.

I would love people would listen before they invest their time. Especially when things already were discussed.
Keep in mind it's not only you that invest time into your proposal. I already invested a few hours reading through the code, discussing it and testing it. Where I should have better invested the time into another, better proposal in hindsight.

bad idea too complicated for end users.
why complicate something that doesn't need the complication?

I second the arguments of @Bakual. This pr turns com_fields into a half baked CCK. You are targeting here a very small group of Joomla professionals which can make use of it. The majority of people will not need more than what we have now.

Talking with the hut as extension developer now. When we start to build functionality into Joomla which is done trough extensions already (there are very good CCK extensions out there), then this will be very harmful for the Joomla ecosystem and a bad signal to the extension developers. To keep the Joomla eco system in a healthy state, the core needs offer a platform which will attract extension developers and not scream them away.

All I'm going to say is UCM was at one point envisioned as a way to introduce CCK like functionality into core. That code hasn't changed in any way since 2013, thankfully.

OK, then. Nothing left to do, here, than to close this PR.

A few things that I take away from all this, though;

There are only two ways of operation. The "simple Joomla" content mode (with the new fields for simple stuff) and the full fledged CCK mode through extensions.
There is no in-between for people who want a bit more but no additional CCK. And I am not talking about the cost of an additional CCK, as there are also CCK's out there which are free.
I am talking about the added overhead in managing and supporting an additional extension. Or, to take it one step further, adding another attack point by using one more big extension which might have its own security issues, for example.

Not harming the extension eco-system is a good point, @laoneo, I agree. But didn't Joomla get improvements in the past, that made some extensions obsolete? And also, if a CCK developer wants to keep the product viable, it can always be extended with more added value, that can make it preferable over Joomla's implementation. I don't believe progress should be stopped for that reason.

On a final note, I still believe that due to the added technical complexity of sites now and in future, Joomla will need some better approach to this, built in. That was my idea behind this. I do believe that the "small group of Joomla developers" is not that small and the demands for this will be there. The result will be that those users will be switching from Joomla to whatever else will provide such functionality. And the prospect new users of Joomla, who would consider it, will probably not even touch it, as they would see that Joomla has not enough functionality built-in for that. And which newcomer-developer will try out all CCKs to find which one might fit the bill for his needs?

Thank you all for your time and valuable input.

All I'm going to say is UCM was at one point envisioned as a way to introduce CCK like functionality into core. That code hasn't changed in any way since 2013, thankfully.
@mbabker why thankfully?

If you really think the Joomla core should become a CCK (you are not the only one) and you will offer time to help on that. Then I recommend to get in touch with the UX team to work out a plan. The new leadership and maintainers should need to acknowledge that idea, otherwise it will become very difficult to get support for your project.

Custom fields was on the radar since ages to get into core. DPFields was a showcase where people could understand my approach upfront, if it would get rejected right from the beginning I would never try to bring it into the CMS. Perhaps you can try that way as well. Build your own CCK extension on top of com_fields that people can see what you want to do. You still can then publish the extension in the JED and the users which need to functionality between com_fields and a full blown CCK have then an option more.

Thank you @laoneo for pointing me there. I hadn't read that issue. From a quick read, I agree with a lot of what is written there.

My problem, at the moment, is that I needed that kind of solution for a project that I am working on. That's why I tried to improve upon your efforts, instead of building my own CCK (or using other ones). And while doing so, I would contribute that for the greater good.

In the past hours, I have already thought of rolling my own CCK and try to get it included in core or put it on the JED as you correctly suggested, however, at this moment, it would blow up the timeframe for my project. I will have to think about my options...

But you also mentioned getting in contact with the UX Team. How does one do that?

Glip is the platform Joomla uses to communicate with each other. There is a public UX channel you can join and ask for help.

From my experience, it is far better to make your own thing, get some feedback from users and when you think it is ready, offer it to the core. It was a long process till com_fields went to it's current state and many things have been sent to trash where I'v invested a large amount of time. But at the end, we all want to make Joomla better. New ideas just need time.