Basically if the field is on the page when it loads then the modal works. If not then it is empty

That was the reason I kept saying that all fields need to be implemented as custom elements (or web components). Custom elements have lifecycle events, so if you create (as it happens with subform) a new field by copying the html then the field initialises automatically (the lifecycle event for this is connectedCallback)

Can it be done without custom elements? Yes but you need to set up event listeners and it would get messy. Not to mention that having multiple ways for the same task is extremely confusing for devs (when should I use this method over the other, etc)

Unfortunately the last 1-2 years nothing happen to bring the remaining fields to parity with the existing ones and on top of that people added interactivity (or new fields) that are totally incompatible with subforms (the color slider, the text count characters, etc). I had a list #19427 which apparently was never implemented although the code was written...

Here multiple issues:

• initialization (easy)
• hardcoded IDs (hard)
• bunch of callbacks (eg window.processModalX(), ) with hardcoded ID parameters (much hard)
• bootstrap modal (hard)

Custom elements can help only with initialization.
The problem much bigger than that.

@brianteeman unfortunately it cannot be fixed, without a loot of rewriting.
For now I can suggest a work around:

• Add row with a field
• Save
• Select value

This somehow related to what I tries to explain in #32473 discussion.

Sorry I dont understand your work around.

For my own component I am just forking the users webcomponent

I will try differently:
The site User (eg:Admin, Manager) should add a new row in the subform field, without selecting anything,
Then save the content item,
And only then select the value for this added field.

I realised what you meant as soon as I hit comment ;)

bunch of callbacks (eg window.processModalX(), ) with hardcoded ID parameters (much hard)

@Fedik this is the worse part and unfortunately cannot be done in any B/C way. But B/C might be ignored here (the modal fields or whatever the name) is an internal thing. There was a PR that was solving aspects of this but not the callbacks

Just tried to do exactly what is mentioned by @brianteeman in my custom component, and I confirm that it still doesn't work, in Joomla 4.3.4. Same for modal_menu as well. The suggested workaround by @Fedik: adding the row, saving and re-loading the page does not work in my case, because I have to differentiate between empty rows (with no article selected) and valid rows (with article selected). Otherwise you don't really need subforms, if you think about it. The only work around I can think of is adding another field, out of the subform, so that you have the proper initialization, and then trying to fix the wrong row IDs, when a new row is added.

	<fieldset name="testing" addfieldprefix="Joomla\Component\Content\Administrator\Field">
		<field name="field-name" type="subform" label="SUBFORM" multiple="true">
			<form>
				<field name="name" type="modal_article" label="ARTICLE"/>
			</form>
		</field>
		<field name="name" type="modal_article" label="ARTICLE" showon="something_else:-999999"/>
	</fieldset>

Would that make sense?

This will be fixed in Joomla 5, in

• #40462

For now only for modal_article, the rest of modal fields still need to be converted.
You can test after beta1 release, or on current 5.0-dev branch.

Most of the fields is fixed:

• #40462
• #41629
• #41632
• #41680
• #42293
• #42326
• #42327
• #42288

Some still need to be tested.
If anything is missing then please open new issue.