I have tested this item ✅ successfully on 1d916cb

Tested successfully. Changes work as expected.

I have tested this item ✅ successfully on 1d916cb

@pjdevries can you please merge latest 4.0-dev branch into this pr.

@HLeithner Apologies for the mistake. Latest 4.0-dev branch is now merged into the pr.

I've restored previous test results because the commit after that was just a clean branch update.

Thanx @richard67

this does not looks right,
a "value" property should be set from "default" already, no need to read "default" directly

this does not looks right,
a "value" property should be set from "default" already, no need to read "default" directly

@Fedik I agree, that's why I waited with RTC. So if we have a bug with that, it has to be solved at another place. Do you have an idea where?

okay, I have checked, there no bug, all works as expected without this patch.

@pjdevries if you need default value per subform field, please set "default" attribute to that field:

<field
  name="subform_fix_test"
  type="subform"
  label="Subform field"
  multiple="true"
>
    <form>
        <field
            name="subform_fix_test_field"
            type="text"
            label="Text field"
            default="Default text field value"
        />
    </form>
</field>

Changing status to "Discussion" in the issue tracker.

okay, I have checked, there no bug, all works as expected without this patch.

@pjdevries if you need default value per subform field, please set "default" attribute to that field:

@Fedik I do not need a value per subform field. If you take a look at my example XML snippet, it's obvious that I set a default value for the subform and not one of it's fields. It's the only way to add one or more default rows to a subform field.

@richard67 I seems a good idea to revert that "Discision" status setting.

I seems a good idea to revert that "Discision" status setting.

@pjdevries As soon as Fedik has confirmed.

You do not have to fix in Subform field anything, you have to correct your xml.

Some more examples for subform[multiple]:

Set default value per subform field:

<field name="subform_test" type="subform" label="Subform field"
  multiple="true"
  default='[{"child_field": "Default text field value"}]'
>
    <form>
        <field
            name="child_field"
            type="text"
            label="Text field"
        />
    </form>
</field>

This mainly "initial value", user free to edit child value, even leave it empty. however when user remove all rows, then will be used "initial value" again.

Set default value per field IN subform:

<field name="subform_test" type="subform" label="Subform field"
  multiple="true"
>
    <form>
        <field
            name="child_field"
            type="text"
            label="Text field"
            default="Default text field value"
        />
    </form>
</field>

This will take a default value for child field. User able to save "empty", but on next form render the default value will back.

Make sure at lest 1 row is set, with default value:

<field name="subform_test" type="subform" label="Subform field"
  multiple="true"
  min="1"
>
    <form>
        <field
            name="child_field"
            type="text"
            label="Text field"
            default="Default text field value"
        />
    </form>
</field>

Same as previous but this will force at least 1 row to be in the subform.

Easy no? ?

We are going around in circles here. Like I mentioned before, this issue is about a default value for a subform field. It is not about default values for fields contained within subforms.

First of all, as long as Joomla! allows setting a default value for a subform, which it does according to the subform documentation, it should work as documented and expected. Currently it does not.

Secondly you are proving that a solution exists for a different requirement.

This mainly "initial value", user free to edit child value, even leave it empty. however when user remove all rows, then will be used "initial value" again.

Not sure if I understand you correctly, but if I do, this is exactly how I expect it to work. But currently it does not. Your suggested alternative is a solution for a different requirement: a default field value for each new row added to the subform. However, it does not allow me to add one or more default rows, each with different values for the containing fields. Do you now see the difference?

hmhm I see, yesterday it worked, today it is not ?

Well, but fix still wrong, the bugs comes from Form:filter, and affect Joomla 3.x, so should be fixed there first, and then will be merged to 4.x also.
The problem is here:

Warning: Invalid argument supplied for foreach() in <root>/libraries/src/Form/Form.php on line 1572

It tries to foreach a "default" string value, that of course is wrong, and then return an empty array, that also is wrong.

@pjdevries Do you want to try to make a fix for Joomla 3 (i.e. staging branch) as @Fedik suggested above, as a replacement for this pull request here? If not, we can find someone else. Anyway, thank you for your pull request here and your engagement. Even if it might turn out that it has to be fixed in a different way, you have reported the issue and have helped with investigating the real cause, and that's much appreciated.

@richard67 If there is no hurry, I will try to take a look at it.

@richard67 and @Fedik I really don't know what's going on here. I just tried to reproduce the warning @Fedik mentions but got no warning whatsoever. This is what I did:

• Create a fresh clone and install it.
• Set "Error Reporting" in "Global Configuration - Server" to "Development".
• Run my own J4 pull request test instructions.

Not only don't I see any warnings, the J3 version of subform also handles a default value correctly. So as far as I can see, there is nothing wrong with the J3 subform, but there still is with the J4 version.

Not only don't I see any warnings, the J3 version of subform also handles a default value correctly.

you will not see it, normally,
normally you will get the page reload and redirect, because of saving process

Put at line 1575 inside if ($field->multiple) and after foreach loop:

var_dump($value);exit;

and try to save the form with your subform field from the backend

and try to save the form with your subform field from the backend

This seems to be a completely different issue. Shouldn't there be a separate issue and pull request for that?

This pull request has already been polluted with a lot of posts diverting from the original issue. Let's not do that please.

hmhm, how it different?
it is a reason why your "default" not works, why it different?

@Fedik If you look at my test instruction more closely, you can see that I am not saving the form. I'm just opening the form and expect to see a default row.

I'm just opening the form and expect to see a default row.

and this is working perfectly,
if you tried to save the form at least once, then it will be broken

and this is working perfectly,

Against which J4 version are you testing?

j4 and j3

First I want to thank @roland-d for his unequalled helpful attitude and endless patience. Thanks to him the real issue that resulted in this pull request emerged.

Let me try to explain what the real issue is.

When you set a default value for a subformfield, this default is applied the first time the form is displayed. This is because the field in which the form values are stored, column params in case of the test example above, is empty at first. When the user removes all default rows and saves the form, an empty subform fields is saved, in other words a subform field without any rows. For the test example above that would result in the params column containing {"subform_fix_test":[]}. The form will now contain an empty subform without the default values.

This mainly "initial value", user free to edit child value, even leave it empty. however when user remove all rows, then will be used "initial value" again.

I was under the same impression as @Fedik. That's why I was wrong footed by this counter intuitive behaviour. After all, any other, simple form field behaves the way @Fedik describes: if you clear the content of a field with a default value, Joomla! will set it back to that default value.

this does not looks right,
a "value" property should be set from "default" already, no need to read "default" directly

@Fedik might be right here, but I am having a hard time seeing where it should be solved then. Default values for all form fields are handled by class Joomla\CMS\Form\Form, but this issue is quite subform specific.

There is one thing I'm asking myself. @Fedik and @roland-d never ran into the problem I experienced. Then why is it that both @adityataware-01 and @vijaykhollam both tested the issue positively.

So how do we go from here?

but this issue is quite subform specific

Because Form::filter() has very subform specific hack (#31332 (comment))

I will try to make a patch, later, when will get some time.

please test #31399

and for j4 #31400 please test also

@Fedik Your PRs make this one here obsolete, is that right? If so: @pjdevries Could you close this PR in this case? Thanks anyway for contributing and making this PR, it pointed us in the right direction at least.

Your PRs make this one here obsolete, is that right?

yeap

@pjdevries It's ok for you to close this PR here in favour of #31400 ? If so, you can close it yourself, or I can do it for you. And again thanks for all.

@pjdevries Thanks, and again thanks for your contribution, which helped to solve the issue for sure.