@crystalenka tagging you as I am sure you created an issue for this but I cant see it now

Iirc this will change the way subform fields are called in templates and would majorly break existing templates. I ran into this with the subform issue in the contact display issue I believe

I just checked and this is the exact same thing I ran into in issue #38737

Check the comments for what I found it affects and why I decided not to change it at that point. (It would be a hard b/c break for templates due to the way JSON is returned.)

Thanks @crystalenka for hint about json.

Comment says:

// Override the fieldname attribute of the subform - this is being used to index the rows

I guessing it was made only for array access, like $value['row1'], $value['row2'] ...
And that a ?

Correct would be to use the value as indexed array, before save the value (or before use):

if ($multiple) {
  $value = array_values($value);
}

And that what you always should do when manipulating with subform "rows".
That key newer should be used in PHP, it was made for some fancy manipulation in javascript, in past.

But I not sure that we can fix it in 4.2.x, such changes can introduce a litle break, for anyone who use this key.

Yes the only "issue" I see is, that when someone access the value directly (the subform itself works) on row0, row1.
As Crystal anyways changed the output, we could add a directly deprecated fallback somehow.

I did not change the output of the subform plugin, but this PR would

A fallback to avoid breaking layouts would be good because I do think I've seen tutorials (maybe in the magazine?) which instructed people to access the fields directly

A fallback to avoid breaking layouts would be good because I do think I've seen tutorials (maybe in the magazine?) which instructed people to access the fields directly

and in the docs site

Do you have a link? Accessing the field shouldn't be a problem, accessing the value is worse

I know that I personally have accessed the value in some templates and I don't think I came up with it out of nowhere since layout overrides/templates using subforms had to be refactored from Joomla 3 to Joomla 4.

I recall some discussion about it (maybe here in GitHub somewhere? or on Facebook?) about why the fields are indexed by id instead of field name in the JSON, it was an intentional choice at the time that was heavily defended by some contributors but I can't recall by whom or where—sorry.

Unfortunately since this has been how it works for a while I don't think we can change it without providing some kind of fallback, certainly not in 4.x and possibly not in 5 either due to the b/c promise and the fact that this could break some templates or layout overrides pretty substantially. :(

JSON referenced here: https://magazine.joomla.org/all-issues/october-2021/custom-fields-episode-7-part-1-one-custom-field-to-rule-them-all

In that example used foreach($items as $item):, if your code use the same approach then you in safe.

In that example used foreach($items as $item):, if your code use the same approach then you in safe.

Yes, that's why I'm looking... I see that direct accessing the values can be a problem. That can be overcome by either have the values twice or change the layout itself, so overrides are marked as outdated.

Overrides would only be marked as outdated if it was an override of the default files though, right? So if someone creates alternative layouts (for example for an article), and assigned that layout to articles in a category, it wouldn't show as outdated. (Correct me if I'm wrong!)

Is it possible to have the values twice and flag it as deprecated, so that people can ensure they're accessing the values correctly before the old way gets removed?

Either way, I don't think that anything should be removed in 4.x....and maybe not in 5.0, either, unless we do a big awareness push as part of the update to 5. :/

Overrides would only be marked as outdated if it was an override of the default files though, right? So if someone creates alternative layouts (for example for an article), and assigned that layout to articles in a category, it wouldn't show as outdated. (Correct me if I'm wrong!)

you are correct

Can you please update your PR.
Also I think this should be remove too:

We should not rename child fields, it may broke a loot of linked JS and etc. As it happen with Showon already.

This pull request has been automatically rebased to 4.4-dev.