User tests: Successful: Unsuccessful:
When a custom field has the same name as a core article property (e.g. "images"),
the custom field value overwrites the core value in the API response, causing
core article images to return empty and the custom field to also go missing.
In prepareItem(), the code blindly assigned $item->{$field->name} without
checking if that property already existed as a core article property.
property_exists($item, $field->name)cf_displayList(), displayItem() and prepareItem()fieldsToRenderItem and fieldsToRenderListimages property is preserved as-isimages appears as cf_images in the response/content/articles/{id}) and list (/content/articles) endpoints are fixedAdded Cypress test: keeps core article images when a custom field is named images
Fixes #47301
| Status | New | ⇒ | Pending |
| Category | ⇒ | JavaScript Unit Tests |
Thanks for pointing that out.
you are right currently my fix only handles the issue in com_content I was mainly focused on the article endpoints and didn't think about the fact that custom fields are used in other components as well ... so it probably makes more sense to handle this at a more central level so every component using custom fields gets the fix.
Would it be better to move this logic somewhere like libraries/src/MVC/View/JsonApiView.php, or should it be handled through com_fields (maybe FieldsHelper)?
Happy to refactor the PR and make the solution global. Just wanted to know the preferred place for it.
| Labels |
Added:
Unit/System Tests
PR-5.4-dev
|
||
custom fields are also available in many other components. this only addresses com_content