Pinging fellow custom field lovers @coolcat-creations @woluweb @web-eau-net

Can you explain the purpose of the "max elements"

Similar to the purpose of “max rows” in subforms. If there are design, technical, or usability constraints in the site template, it helps the site integrator accommodate for them. For example, if some of the elements are more resource-heavy or have larger image rendering/files, you might not want to have 100 of them on a page.

On Jan 16, 2022, at 8:29 PM, Brian Teeman @.***> wrote:


Can you explain the purpose of the "max elements"

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.

I like the idea. Thanks @crystalenka

Maybe a field to load a subform group
This field Can be a select with all subform group allowed
Like a
group car
Group plane
Etc
And user Can select plane and that load all field in subform plan
?
Ex: https://www.joomreem.com/extensions-store/k2-datasets#.YeRzw2jfsVE

Maybe a field to load a subform group
This field Can be a select with all subform group allowed
Like a
group car
Group plane
Etc
And user Can select plane and that load all field in subform plan
?
Ex: https://www.joomreem.com/extensions-store/k2-datasets#.YeRzw2jfsVE

So like, load a single instance of a subform row instead of loading a subform with repeatable fields?

each repetable have a "master" field to select group

each repetable have a "master" field to select group

I think that's what I'm trying to achieve here - the "master" is the element type as written above

So far my usecase for CF has always been like "plenty of CF for one given Category (Films or whatever)"
I have never had the usecase to use CF for "single articles Layouts" but it would indeed be interesting!

What I think is that we definitely need the Render Layout option for each CF
(beyond the regular use of Render Layout, it means that you could also add conditions in your Alternate Layouts like "if article is 147 or 221 or whatever then render like this otherwise render like that").

For the sake of brainstorming, here is also a nice little pluging allowing to show a CF in the interface conditionally on another CF (not tested personally):
https://github.com/JoomTools/plg_system_jtcfshowon (listed on https://magazine.joomla.org/all-issues/august/custom-fields-episode-6-make-more-with-extensions)
This means you could have a first CF "choose layout" and in function of that show the other corresponding CF (bg image, ...).

This could probably solve your design issue.
Of course, this does not solve the fact that in Joomla we need to assign CF to Categorie(s).
In J3, I regularly use an ISIS (backend template) user.css to customize the Tabs of my CF (Tabs when editing the articles), like

• adding an icon
• changing bg color
• changing order
  This makes me think: maybe there is also a possibility to override the CF rendering in the backend. In that override we could then specify "if article is 147 or 221 or whatever then show the CF otherwise don't".

While I like your Idea @crystalenka I think we should be careful to change custom fields into something we always expected them to be for us (but they were never meant for). As far as I am concerned and talked to developers custom fields should be rather used to save small bits of information here and there and not be responsible for whole page layouts.

I am currently working on a project with > 150.000 articles using one of my favorite ccks. As you know I am a huge fan of custom fields and I was thinking of upgrading the site to Joomla 4 and getting rid of the cck and only using custom fields.

But this would result in a single table with 6 Million rows ...

So I need to stay with the cck because Joomla does not offer to save data in the structure it is saved by the cck (and works perfect)

So the approach to use 50 fields per page and save it all in the custom field value table would only work for very small sites as far as I understood.

I understand your use case and I also need a solution like this but maybe it's worth thinking about something new. Like a custom content type where I can save all the article-related values in one row or something? Or the possibility to have field value tables per content type.

Pardon and correct me if something I said above is wrong, its just the conclusion I made talking to developers in the past.

Thanks both for your comments!

@woluweb:

For the sake of brainstorming, here is also a nice little pluging allowing to show a CF in the interface conditionally on another CF (not tested personally):
https://github.com/JoomTools/plg_system_jtcfshowon (listed on https://magazine.joomla.org/all-issues/august/custom-fields-episode-6-make-more-with-extensions)
This means you could have a first CF "choose layout" and in function of that show the other corresponding CF (bg image, ...).

This could probably solve your design issue.

I actually use this plugin on all of my sites! It works great for many custom fields, but due to the nature of subforms, does not work in subform rows. Your brainstorm was my first thought, too, but sadly it didn't work that way!

Of course, this does not solve the fact that in Joomla we need to assign CF to Categorie(s).
In J3, I regularly use an ISIS (backend template) user.css to customize the Tabs of my CF (Tabs when editing the articles), like

adding an icon
changing bg color
changing order
This makes me think: maybe there is also a possibility to override the CF rendering in the backend. In that override we could then specify "if article is 147 or 221 or whatever then show the CF otherwise don't".

Adding additional options to custom fields rendering is an interesting idea, and I like what you do with the tabs - I'll have to get more details on how you do that another time because it could be helpful for my clients too. :) That being said, I think that it's outside of the scope of this particular RFC as your suggestion would change custom fields rendering globally and my suggestion is an additional, self-contained custom field plugin. I'd be interested in discussing on another issue what those rendering options might look like though!!

@coolcat-creations:
Your concern is valid and a good point! That being said, someone could still shoot themselves in the foot with any custom field the same way (or, well, with a lot of Joomla options).

(One interesting exception seems to be the subform - no matter how many fields are available in each subform row, all the data for the entire subform custom field is stored in one database row as json...so it might be that, if the multiform structure echos the subform structure, both these field types would save on database rows in the fields_values table?)

Either way, I think that it makes sense to have something like this "multiform" because it would only make sense to use it on showcase pages like I said above; even sites with 100,000 probably have only a handful of "showcase" pages that would need such a flexible structure like this, and the other 99,995 articles would likely be more standard, otherwise it's hard to manage as a user.

So it basically a subform, but each row can use own predefined form instead of fixed one, I am correct?

So it basically a subform, but each row can use own predefined form instead of fixed one, I am correct?

That's the general idea, yes.

Been thinking about this a bit more lately.

Perhaps instead of trying to make a completely new field type it would be better to build on the existing ones.

So, revised idea: (mentally calling it a Flex Form because that's more accurate and easier to say)

Each "form element" as described above would be self-contained subforms. Like normal custom fields now, there would be a toggle in the subform to say "flex form only" or something like that.

When creating a new flex form custom field, you'd be able to select which subforms you'd want to be available, and how many can be used on that specific flex form.

When rendering the flex form on an article:

Instead of the "drag elements into the page" pattern I mocked up above, we could use the same repeatable subform layout that we already have, but show a drop down when you click "add" to decide which subform you'd want to add next. Subforms that didn't have any more available would be disabled.

This way it's not too far a departure from how things work/look now, but adds a ton of flexibility to subforms.

Additional thoughts welcome.

@crystalenka I am still not convinced that custom fields were made for such an excessive usage. :-( Sorry

@crystalenka I am still not convinced that custom fields were made for such an excessive usage. :-( Sorry

What would you suggest instead?

• Changing the Database Structure for Custom Fields to make it more performant and to group them by article and custom content type
• creating custom content types instead of field groups (that do not make sense to me)
• add versioning and search before anything else

Then in custom content types you could select another content type to be repeatable or so.

creating custom content types instead of field groups (that do not make sense to me)

Field groups are essential

creating custom content types instead of field groups (that do not make sense to me)

Field groups are essential

Yes, but they do not do what I expect them to do. I want to assign a field group to a content type or a category. And not every single field.

Creating fields is really exhausting: assign category, assign field group, set display to none, set html filter to safe html

assign a field group to a content type or a category

That is an interesting train of thought. Right now the display of custom fields is tied to categories, based on the assumption I suppose that articles in the same category will all be the same "content type". Often that's true - blog articles, etc - but not always.

Creating fields is really exhausting: assign category, assign field group, set display to none, set html filter to safe html

I have been annoyed by the over complex process of setting up fields and stuff too. (One of the reasons I rely so heavily on subform fields is that I can assign the category/field group ONCE and reuse the same "subform only" fields in multiple subforms.)

I don't think the problem here is necessarily field groups, because they are a flexible tool and helpful for organizing fields by purpose (I like to put "advanced" stuff in its own field group, for example). But exploring the idea of "content types" as a way to assign fields/field groups wholesale to certain articles is interesting.

For my use case in this hypothetical scenario, it would be nice to link content type to default layout, because the layout overrides I build usually call in custom fields manually. Right now, if you pick the wrong layout, or the article is in the wrong category, you're out of luck.

Hmmm.....

The other side of this is that even though we are usually talking about custom fields in com_content, they're available to (theoretically) any component. Off the top of my head, I think they're also in com_categories and com_contact in core, as well as many 3rd party components.

So would content types be a com_content only thing? If not, how could that apply to other components? Because if we change the way custom fields works, it applies across all of them.

I can show you how fields are managed in one of my favorite ccks - in my eyes it's way better. We do not need to replicate the cck but following the same logic would be very beneficial for Custom fields.

You have Content Types -> for example Blog Posts or Car or House Property or whatever
Your can assign fields to this content type and build your very own edit form for that
You can create global fields that will be available for each content type but you have of course to assign it to the edit template to use it
You can use another content type in your content type to use it as a repeatable fieldgroup
You can build Search forms with those fields too
You have a logical database entry that contains all the fields
Your have versioning

Can imagine XML form for "multiform", because in Joomla every form is XML ?

<field type="multiform" name="foobar">
  <form name="fruit" label="Fruit">
    <field type="text" name="title" label="Title">
    <field type="textarea" name="description" label="Description">
  </form>
  <form name="building" label="Building">
    <field type="text" name="title" label="Title">
    <field type="text" name="height" label="Height">
  </form>
  ...
</field>

Where each subform of the field would be an "option" for a new section, in multiform field.

That will submit data in next structure:

For Fruit:
jform[foobar][i..row index][fruit][... fruit form fields] 
jform[foobar][i..row index][fruit][... fruit form fields] 

For Building:
jform[foobar][i..row index][building][... fruit form fields] 
jform[foobar][i..row index][building][... fruit form fields] 

And mix:
jform[foobar][0][fruit][... fruit form fields] 
jform[foobar][1][building][... fruit form fields] 
jform[foobar][2[building][... fruit form fields] 
jform[foobar][3][fruit][... fruit form fields] 

This can be a starting point.

Upd: also should accept form files:

<field type="multiform" name="foobar" formsource="path/to/fruit.xml,path/to/building.xml"/>

After many trials I have decided to use an own solution, based only on xml files instead of custom fields (own component, not core-component).
@Fedik your solution looks very promising.

I can show you how fields are managed in one of my favorite ccks - in my eyes it's way better. We do not need to replicate the cck but following the same logic would be very beneficial for Custom fields.

You have Content Types -> for example Blog Posts or Car or House Property or whatever
Your can assign fields to this content type and build your very own edit form for that
You can create global fields that will be available for each content type but you have of course to assign it to the edit template to use it
You can use another content type in your content type to use it as a repeatable fieldgroup
You can build Search forms with those fields too
You have a logical database entry that contains all the fields Your have versioning

I don't think ALL of that would make sense in Joomla, but a lot of it could be used as inspiration. Versioning, adding custom fields to search is critical, I agree with you. More and more content is going into custom fields as people learn how to use them.

Creating custom edit forms would probably be too complex for core Joomla (in my opinion, I could be wrong!) but I know that @webgras and @pe7er are working on d2profiles for J4 and that helps that need.

You can use another content type in your content type to use it as a repeatable fieldgroup

What is the difference between this and repeatable subforms as they exist today?

Because of the way that field data is stored it will require an architectural database change to add version history. Not saying its not needed just pointing out the complexity

Because of the way that field data is stored it will require an architectural database change to add version history. Not saying its not needed just pointing out the complexity

Yes, but it's the right thing to do and I think it's very important. Right now it's also not clear at all to end users that custom fields are not saved in versioning, so we have a mismatched expectation that would become relevant exactly when someone is already in panic mode.

You can use another content type in your content type to use it as a repeatable fieldgroup

What is the difference between this and repeatable subforms as they exist today?

The ease of setup and the better overview :-)

You can use another content type in your content type to use it as a repeatable fieldgroup

What is the difference between this and repeatable subforms as they exist today?

The ease of setup and the better overview :-)

I think that the content type discussion is a good one to have but maybe separate from this multiform/flex form discussion - what do you say?

It seems that "content types" would not replace anything from custom forms in Joomla, but would maybe provide the missing link between field/field group assignments to items and layouts or templates, and make it a little more intuitive for people to manage. Should we start a new RFC / discussion for this?

You can use another content type in your content type to use it as a repeatable fieldgroup

What is the difference between this and repeatable subforms as they exist today?

The ease of setup and the better overview :-)

I think that the content type discussion is a good one to have but maybe separate from this multiform/flex form discussion - what do you say?

It seems that "content types" would not replace anything from custom forms in Joomla, but would maybe provide the missing link between field/field group assignments to items and layouts or templates, and make it a little more intuitive for people to manage. Should we start a new RFC / discussion for this?

Yes I would be happy about this. Maybe Content Types would make it possible to change the db structure to add the missing link for search and versioning as well.

Should we start a new RFC / discussion for this?

There are several already - one in the discussions and one in the RFC repo

Started a new discussion about content types here: #38639

Back to multiforms, @Fedik , I think that's a good start!