I have confirmed that the issue has been resolved, and the changes are functioning correctly when a GUID is returned for the ID field after saving. However, it appears that the tests are currently failing, so they may need to be reviewed and updated.
I realized that the generic mapper is more efficient for both posting and retrieving data in the file module. Instead of modifying the file URL mapper, I will use the generic mapper, as it already maps the ID to its corresponding array effectively.
The URI mapping works by associating the URI with a label, which can create issues when dealing with multiple files. In this case, an array of URIs would be required, but this doesn't map well to the expected string format for the URI field. While this setup works fine for viewing, it causes problems when saving, as shown in my code.
My questions are, why is it necessary to map to a field that corresponds to a JSON property? Why not allow the file field to directly map to a property that can hold either a single URI or an array of URIs? Is there a specific use case where mapping to a label is beneficial? Additionally, is it possible to modify the approach so that the file field has its own property for direct mapping?
Furthermore, I have this parent::addFieldValuesToRawData($field_values,$raw_data,$context); commented out, as I was pretty sure it does nothing for the file field. Is that fine? or should I include it?
I created Feature Request ✨ Allow mapping of file URI to a field Active for adding to the URI field on creation and modification of files.
sugen → created an issue.
It worked! Thank you.