Pull Request for Issue #36734 .

Summary of Changes

Addresses the data format discrepancy between what Joomla\CMS\Form\Field\AccessiblemediaField expects and what a non-repeatable subform custom field provides.

Testing Instructions

Per issue #36734:

1. Create a media custom field. Configuration doesn't matter.
2. Create another custom field, any type but media. Configuration doesn't matter.
3. Create a subform with those two fields. Set the "Repeatable" toggle to no. (This is important!)
4. Open an article with the subform field. Fill out the fields, or don't. It doesn't matter.
5. Save the article.

Actual result BEFORE applying this Pull Request

The media field disappears every other save. Any images you set in the field is ignored; the field appears in its default (empty) state when it reappears.

Expected result AFTER applying this Pull Request

The media field still displays in the subform, and if any value was added to the media field, it remains.

Documentation Changes Required

None

Technical information

This problem happens because Joomla is playing fast and loose with data types.

The subform custom field stores its value as a JSON document. This includes the values of each and every subfield contained in it. It is always decoded to an associative array, including the subfields' data.

The Media custom field's value is meant to be either an object or a string (which can be a JSON-serialised object or a legacy image file path without alt text). That's how the setup() method of the AccessiblemediaField class expects its values.

When combining the two you create the observed problem.

When you load a custom field it decodes the JSON value into an associative array. This means that the internal data of the Media custom field is also decoded as an array. Since the AccessiblemediaField does not accept an array it considers the data invalid, setup() returns false and the field is removed from the form. Therefore its data is removed when you save the content (e.g. article) again. The next page load has no value for this field stored so the field falls back to its default empty state due to the fall-through of the setup() method's opening if-block and displays, albeit empty.

The dead simple solution is to check if the incoming value is an array and type cast it to an object. This satisfies the if-block's conditions and the field displays correctly.