This looks nice @joomdonation, thanks for working on this!

1. That setting should probably be called "Only use in Subform".
   As you are normally already free to use a field both as a normal field (so with category assignments) AND inside a subform.
   So since that toggle will make the Category Input hide, it should be used for fields you want to be used ONLY in subforms and nowhere else.
   So probably the param should be called something like "subform_only" rather than "use_in_subform"

2. Great!

3. Nice! What happens at the bottom part of the screen, where the Field Selection Dropdown would be? Does it still show an empty dropdown?

Naming

Of course all of this should be synced with any pending name-change we might decide for this type of field, see: #32864 (comment)

So it may end up being called something like "Only use in Nested Fields" or something like that

1. Easy. It is just a language item which we need to change. I haven't added it to language file yet :D. As I said, quick prototype PR only

2. It is still as before, empty dropdown. I want to leave it here so that the system will prevent user from saving the field without having to enter any any other coding works, check.....

Do you have any idea to indicate a field is Use In SubForm only on custom fields list screen?

It is still as before, empty dropdown. I want to leave it here so that the system will prevent user from saving the field without having to enter any any other coding works, check.....

Makes sense. The warning at the top should suffice.

Do you have any idea to indicate a field is Use In SubForm only on custom fields list screen?

Sure, nice idea!

We could put a label like this (pardon the J3 interface, just a quick draft to convey the idea):

or alternatively, since Category is set to None anyway, even something like this:

Whichever way you like better :)

Don't ask me for layout :D. I made a quick modification and now it looks like below

Looks good! I would probably put it on the side, rather than below. Similar to how "Hidden" is on the side for Hidden Menu Items. To optimize the available space.
Nice job :)

I will ask someone to help with layout things :). Now the next thing we should discuss about migrating data. Somehow, we will have to mark existing fields which is used in subform as Use In SubForm Only. For existing fields, what fields we should do that change?

• Fields which are part of subform
• And assigned to Category None ?

Is that enough?

And do you know when subform was added to Joomla? I want to ask this because it is just added to Joomla 4, maybe we will have to update the script at #32611 to do this conversion when migrating repeatable fields to subform fields from Joomla 3 to Joomla 4 only

Wait, let me take that back. Category "None" is not even part of J3. It's a J4 feature.

So I would say we shouldn't care about this in the migration.

Nice, less work for us :)

Actually, let me take that back again (sorry, ideas keep coming to mind lol).

In Joomla 3, we only had "Repeatable" field. Joomla 4 introduces the new Subform/Subfields type.

So this means, that ALL Repeatable fields that might have been created in Joomla 3, are ALL actually intended to be used only in Subform (there was no way to use it as normal field as well).

So, all fields part of the J3 repeatable field make sense to be migrated to "Subform Only", if you want to do that, as part of the migration process.

@brianteeman Could I ask you for suggestions about two terms:

• The setting which is used to determine if a field is used on SubForm only. Can we use Only use in Subform ? I need to know now because the name which use to store data in database table will depend on the terrm.
• The badge which is used to show on Custom Fields management screen to show that a field is used for SubForm only. Can we use the term SubForm Only?

Actually, let me take that back again (sorry, ideas keep coming to mind lol).

In Joomla 3, we only had "Repeatable" field. Joomla 4 introduces the new Subform/Subfields type.

So this means, that ALL Repeatable fields that might have been created in Joomla 3, are ALL actually intended to be used only in Subform (there was no way to use it as normal field as well).

So, all fields part of the J3 repeatable field make sense to be migrated to "Subform Only", if you want to do that, as part of the migration process.

I can update the migration script to have it works like that later after we finish this one. And just final question: With the change in this PR when it is ready, do you think we can close the release blocker #28389 ?

Some questions.

Why subform only and why no category?

Scenario

I have the following fields

• name
• date
• age
• school
• class
• city

I have a subform called english with the following fields

• name
• age

I have another subform that is only displayed in the category exam with the following fields

• name
• school
• class

For me all I would be changing on the list view of all fields would be to indicate if a field is used in a subform and the name of the subform. ie exactly like category but in addition to and not instead of

Am I missing something that prevents that?

oh and its not really a subform but a group/collection of fields

@brianteeman As far as "Why Category None", it's because a field that is set to be "only used in a Subform" is not (cannot) be assigned to a category.

Its assignment will then be solely related to the category of its "Subform / Parent Field", so hence why its own category becomes "None" - so it doesn't appear as a normal field on its own.

oh and its not really a subform but a group/collection of fields

Yeah, hence why not sure if we should call it Subform in your PR? #32864 (see my comment)

Actually, if you assign that field to a a category (not None), when you add an item (for example, an article), the field will be displayed both as standard field and as part of SubForm, so it is confusing (not sure if I understand the question correctly)

But if we introduce a new setting Use In SubForm Only (call it anything we like), the field can still be assigned to categories if we want. Then on dropdown when we add new SubForm field, we will only show field which has Use In SubForm Only set to Yes. When display form to allow add/edit item, we can hide these fields, I think.

I dont understand why "use in subform only" do you actually mean "this field is used in a subform called x"

I dont understand why "use in subform only" do you actually mean "this field is used in a subform called x"

It's just so to mark a field as usable ONLY in a subform, and not as normal field.

By default, you can use a field BOTH as part of a subform and a normal field.

So for example, you can have a field "Age" assigned to the "People" category as a normal field. And have it part of the "English" subform somewhere else.

By setting it as a "Subform only", you would do that if you want the field to not be normally assigned to any category (= None), and so only available for selection in Subforms.

It's also possible to use a field as part of more than one Subform. Even unlimited number of Subforms. So it's not as straight forward to say "this field is part of these subforms" (although it would certainly be nice to have it say that somewhere).

And if it is needed, when we add a new SubForm field type (called Subfields at the moment), we can only display fields marked as use in subform only

That would help choosing fields easier. Right now, it displays all fields in dropdown and in case you have many fields, It will be hard to choose the field

And if it is needed, when we add a new SubForm field type (called Subfields at the moment), we can only display fields marked as use in subform only

That would help choosing fields easier. Right now, it displays all fields in dropdown and in case you have many fields, It will be hard to choose the field

That depends. That would be a loss of functionallity. You would have to create SPECIFIC subform fields, instead of being able to choose from ANY field.

If we were do to that, then we would lose the ability to do this:

you can use a field BOTH as part of a subform and a normal field.
So for example, you can have a field "Age" assigned to the "People" category as a normal field. And have it part of the "English" subform somewhere else.

I think you are overthinking this. Just let me see if a field is being used in a subform and the name of the form. Doesnt need anything more than that My 2c.

@brianteeman In theory, a field could be used on multiple SubForm fields, and we do not have an easy way to know that it is used as part of subform at the moment, that's why we introduce a new setting

The ability to filter fields to see list of fields which are using is useful, too, I think

Finally, set Category to None automatically is good, too. See the reason in my earlier comment #33096 (comment)

So I would leave it works as how it is in this PR (beside change the terms if needed)

I rarely use field, so I am kind of novice user here.

First of all I have problems with the terminology - subfields - sub-field - subform - as a user I don't understand the whole fields terminology. (Not in scope of this PR - Why do we have Field groupp, which is a field catgegory? I know it from develoeprs point of view, but not as a user).

So my2cent:

If I understand this PR right, we have three constellations for fields:

• not in a subform
• used in a subform or stand alone
• only used in a subform

Filter
It is a good idea to have a filter with these options

New or edit Form

• Add an indicator for "used in subforms".
• Categories can have preset "All" as it is now, the category "none" is not needed

Overview:

• if a field is not in a subform, nothing changes
• if a field is used in a subform then add a button - "used in subforms" as suggested

Categories:

• not in a subform - show the categories
• used in a subform or stand alone - "used in subforms aa, bb, .." and show the categories
• only used in a subform - "used in subforms: xx, aa, ...". The categories can be hidden or set to "All"

I think that category none is not necessaty at all

@AndySDH When you have time, could you please give this PR a quick test to see if I am missing anything else (base on your suggestions) before I mark this PR as ready for review? As it contains change to database, please download the update package for this PR from https://ci.joomla.org/artifacts/joomla/joomla-cms/4.0-dev/33096/downloads/41974/ , then go to System -> Joomla -> Update to update the package to test.

@Quy Could you please commit your suggested changes to language/codestyle/layout please?

Small thing that I can see from the code: the new 'max_rows' parameter should only show if 'repeat' is set to 1
(it only applies if the field is repeatable)

Small thing that I can see from the code: the new 'max_rows' parameter should only show if 'repeat' is set to 1
(it only applies if the field is repeatable)

Done !

@AndySDH I don't know if the SQL command is executed when we install the update package or not. Maybe you can run this SQL command manually to your database via phpmyadmin

ALTER TABLE jos_fields ADD only_use_in_subform tinyint(1) NOT NULL DEFAULT 0;

(replace jos_ with the prefix of your site database)

@richard67 Do you know how to to execute the SQL changes in a PR like this one?

@joomdonation They will be executed when someone updates to the update package built for this PR by drone, and they can be run "manually" in an SQL client like e.g. phpMyAdmin, and they can be run by applying the PR and then going to "System - Manage - Database" and using the fix button.

@richard67 Thanks. This afternoon, I tried to download the update package for this PR from https://ci.joomla.org/artifacts/joomla/joomla-cms/4.0-dev/33096/downloads/42053/ , and go to System -> Update -> Joomla, upload that package to update but it seems the SQL is not executed. I had to run the SQL command manually via phpmyadmin

@joomdonation Wait with committing my suggestions above ... I might have to correct them by another mistake.

I tested all of the applied changes succesfully, great job @joomdonation!

However, I have a few notes for issues I encountered, or further improvements that should be made:

FIELD CREATION FORM

• Should we add a default to maximum number rows option? Now it's '0', should we maybe leave it empty? Not sure 0 looks nice.

FIELDS LISTING

• As mentioned before, I'd put the 'Subform Only' badge on the side of the field name, instead of under it (similar to how it's done for hidden Menu Items)

ARTICLE EDIT FORM

• I think we should surround the whole Subform with a fieldset, for clarity. When a field is not repeatable, it's not easy to tell the child fields apart from normal fields.

• A media file doesn't work inside a Subform. When you click "Select" to select a picture, nothing happens.

• The subform table doesn't occupy the 100% width of the space available in the backend edit form:
  

• The subform table exceeds the maximum width available in the frontend edit form, making it impossible to edit or add new rows.
  

REPEATABLE MIGRATION FROM JOOMLA 3

• All migrated child field from Joomla 3 should be marked as "only_use_in_subform" = 1

Apart from these fixes, everything else works as explained!

@richard67 I'm unsure what is the change? Feel free to commit it yourself

@AndySDH

• For the change in article edit form, it should be handled in a separate PR, I think. Please don't ask me to do the layout stuff, it would take me years for doing that :D. Someone with better frontend skill could help with that task

@joomdonation In SQL files we also have a newline at the end of the file. And in the MySQL file, the "COLUMN" was missing. It is also valid SQL syntax without it for MySQL, but the database fixer will not understand it. Therefore the golden rule when creating update SQL scripts for Joomla is to look for an already existing script which does the same (adding a column) and stay with the syntax of that.

@AndySDH

• For the change in article edit form, it should be handled in a separate PR, I think. Please don't ask me to do the layout stuff, it would take me years for doing that :D. Someone with better frontend skill could help with that task

Sure, just raising the issues :)

@Quy Could you help me with this:

As mentioned before, I'd put the 'Subform Only' badge on the side of the field name, instead of under it (similar to how it's done for hidden Menu Items)

As mentioned before, I'd put the 'Subform Only' badge on the side of the field name, instead of under it (similar to how it's done for hidden Menu Items)

Use span instead of div and move the code near the field name.

Oh, just noticed: The option "Only Use in Subform" should not display in fields of type 'subfields'. As we can't nest a subform inside a subform.

@AndySDH I noticed that this afternoon. I was thinking about using showon but for some reasons, it was not working when I tried this afternoon. Will try to look at it again later.

@AndySDH I implemented latest change request from you. I also updated testing instructions and mark this PR as ready to review. Please help testing it when you have time

I have tested this item ✅ successfully on 56c827e

Installed Blog Sample Data:

PHP Notice: Undefined index: only_use_in_subform in \administrator\components\com_fields\src\Model\FieldModel.php on line 171

For Subform type, hide Only Use In Subform?

@Quy

PHP Notice: Undefined index: only_use_in_subform in \administrator\components\com_fields\src\Model\FieldModel.php on line 171

When do you see that error? When you edit the field or save it?

For Subform type, hide Only Use In Subform?

Yes. It is working like that. I think you see this issue because you applied the PR #33200 . The code in current PR checks for Subfields, why the applied PR changed it to Subform. I will wait for that PR merged, then make the change and we can test it again. Thanks for reviewing and testing.

In PHP error log. The sample data installation stops at step 1.

I installed the download package without applying #33200.

In PHP error log. The sample data installation stops at step 1.

I installed the download package without applying #33200.

Ah, that explained why I could not install Blog Sample Data. I only think about field created using UI (which only_use_in_subform is always available in $data array). I can make a small modification to solve this issue.

Edit a subform field. Applied #33262.

Getting errors testing 339096
I am getting this error The file marked for modification does not exist: administrator/components/com_fields/src/Field/SubfieldsField.php

Getting errors testing 33096
I am getting this error The file marked for modification does not exist: administrator/components/com_fields/src/Field/SubfieldsField.php

@kiki-G If it is possible, please setup a fresh installation (generated by this PR) and test it

You can download the full package for this PR here https://ci.joomla.org/artifacts/joomla/joomla-cms/4.0-dev/33096/downloads/42296/Joomla_4.0.0-beta8-dev+pr.33096-Development-Full_Package.zip

Thanks

I have tested this item ✅ successfully on a0dbc20

@Quy My last commit should fix your last issue (with field editing). Please help running a new test/

I have tested this item ✅ successfully on a0dbc20

Installed https://ci.joomla.org/artifacts/joomla/joomla-cms/4.0-dev/33096/downloads/42296/Joomla_4.0.0-beta8-dev+pr.33096-Development-Full_Package.zip and everything works!

I have tested this item ✅ successfully on a0dbc20

RTC

@joomdonation One thing I figured out is that we missed one case.

The Users Component also has custom fields, however, they have no "Categories".

So if you create a field in the Users Component, and you mark it as "Only Use In Subform", nothing is done with that setting, and it still remains in the form when you go to edit user profile (either from backend or frontend).

So to fix this, in this scenario, the field should be removed from the user form when marked as "Only Use in Subform". @joomdonation let me know

@AndySDH Will look at it later. Busy these days to have all my own extensions compatible with J4. Today is the last day :).

Sure, thanks!