[#47306] - [5.4] Fix: custom field named "images" overrides core article images in API response
- Pending
- Medium
- Build: 5.4-dev
- # 47306
- Diff
- icybersanjay:fix-47301-api-images-custom-field
User tests: Successful: Unsuccessful:
Summary
Fixes #47301
When a com_content custom field has the name images, it silently overwrites the core article images property during prepareItem(). This causes the JSON:API response (GET /api/index.php/v1/content/articles/{id}) to return an empty array for images instead of the article's actual intro/fulltext image data.
The same collision could occur for any other core field name (e.g. urls, metadata) if a custom field uses the same name.
What was changed
api/components/com_content/src/View/Articles/JsonapiView.php
prepareItem(): Skip custom field hydration when the property already exists on the item object, so core article data is never overwritten by a custom field with a colliding name.displayItem()/displayList(): Guard against appending a custom field name tofieldsToRenderItem/fieldsToRenderListwhen that name is already present (prevents duplicate attribute keys in the JSON:API output).
tests/System/integration/api/com_content/Articles.cy.js
Added a Cypress system test that:
- Creates a custom field with
name = "images"scoped tocom_content.article - Creates an article with intro/fulltext images set
- Asserts that
GET /content/articles/{id}returns the core articleimages.image_introvalue (not an empty array) - Cleans up both
#__contentand#__fieldsrows after each test
Testing instructions
- Install a clean Joomla site.
- Enable the API Authentication - Token plugin and copy the token from a Super Admin user.
- Create a custom field for Articles with the name
images(any type, e.g. Media). - Create an article and set both an intro image and a full-text image.
- Call:
GET /api/index.php/v1/content/articles/{id}with the bearer token. - Before this fix:
attributes.imagesis[]and the custom field value is also absent. - After this fix:
attributes.imagescontains the correctimage_intro/image_fulltextURLs; the custom field is not duplicated.
Environment tested
- PHP 8.3
- MySQL 9.x
- Joomla 5.4-dev (bug also present in 6.0.x)
Notes
The fix is intentionally minimal: core properties defined on the item object at the time prepareItem() is called take precedence over any custom field with a matching name. Custom fields with unique names continue to work exactly as before.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | JavaScript Unit Tests |
This cannot be the correct solution as the next question would be why isnt the content of my custom field being included in the api response. All you are doing here is silently removing a valid field to solve one part of the problem.
What else should be done to fix the issue @brianteeman ? Renaming the custom field in the response?
Perhaps with a custom field prefix. Simply throwing away the field content silently is just pushing the valid bug to someone else to fix in the future
| Labels |
Added:
Unit/System Tests
PR-5.4-dev
|
||
custom field not rendered
{
"links": {
"self": "http:\/\/localhost:7060\/api\/index.php\/v1\/content\/articles"
},
"data": [
{
"type": "articles",
"id": "1",
"attributes": {
"id": 1,
"asset_id": 101,
"title": "test_imagesin_fileds",
"alias": "test-imagesin-fileds",
"state": 1,
"access": 1,
"created": "2026-03-05 10:44:12",
"created_by": 657,
"created_by_alias": "",
"modified": "2026-03-05 11:03:06",
"featured": 0,
"language": "*",
"hits": 0,
"publish_up": "2026-03-05 10:44:12",
"publish_down": null,
"note": "",
"images": {
"image_intro": "http:\/\/localhost:7060\/images\/sampledata\/fruitshop\/apple.jpg#joomlaImage:\/\/local-images\/sampledata\/fruitshop\/apple.jpg?width=375&height=281",
"image_intro_alt": "",
"float_intro": "",
"image_intro_caption": "",
"image_fulltext": "http:\/\/localhost:7060\/images\/sampledata\/fruitshop\/bananas_2.jpg#joomlaImage:\/\/local-images\/sampledata\/fruitshop\/bananas_2.jpg?width=300&height=352",
"image_fulltext_alt": "",
"float_fulltext": "",
"image_fulltext_caption": ""
},
"metakey": "",
"metadesc": "",
"metadata": {
"robots": "",
"author": "",
"rights": ""
},
"version": 3,
"featured_up": null,
"featured_down": null,
"typeAlias": "com_content.article",
"text": " ",
"tags": []
},
"relationships": {
"category": {
"data": {
"type": "categories",
"id": "2"
}
},
"created_by": {
"data": {
"type": "users",
"id": "657"
}
},
"tags": {
"data": []
}
}
}
],
"meta": {
"total-pages": 1
}
}
I have tested this item 🔴 unsuccessfully on 2e34e59
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47306.
okay @brianteeman, now I've added prefix 'cf_' in case of field names collision
Does adding a prefix such as “cf_” to custom fields create a problem with all apps that already use APIs and call custom fields by their name without a prefix?
Does such a change mean having to change the JSON management system that comes back from Joomla?
imho it's a wont fix, just choose a non conflicting name for custom fields
There is another, a little bit older PR for the same issue: #47304 .