[5.4] Prevent custom fields from overriding article properties in com_content API (#47301)

[narang24]

Pull Request resolves #47301

• I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.

Summary of Changes

Custom fields are dynamically attached to the article object in the Content API view using $item->{$field->name}.

If a custom field has the same name as an existing article property (for instance, images in this case), the custom field value overwrites the core article property. This results in incorrect API responses where core article data is replaced by custom field values.

This patch prevents overriding existing properties by checking whether the property already exists before assigning the custom field value.

Testing Instructions

1. Create an article and set Intro Image and/or Full Article Image.
2. Create a custom field for articles with the name images.
3. Request the article via the API , for example,

curl.exe -X GET "http://localhost/test-api/api/index.php/v1/content/articles/1" \
-H "Authorization: Bearer xxxxxxx" \
-H "Accept: application/vnd.api+json"

where 1 is the article ID and xxxxxxx is the API token of a super-admin user.

Actual result BEFORE applying this Pull Request

If a custom field named images exists, the core images attribute in the API response is overwritten and returned as an empty array.

Expected result AFTER applying this Pull Request

The core article images attribute is returned correctly and is not overridden by a custom field with the same name.

Link to documentations

Please select:

• Documentation link for guide.joomla.org:

• No documentation changes for guide.joomla.org needed

• Pull Request link for manual.joomla.org:

• No documentation changes for manual.joomla.org needed

[alikon]

but in this way the custom field is not rendered

[narang24]

Thank you for the feedback @alikon

This change was implemented to address the behavior reported in #47301, where the core images property is overwritten when a custom field with the same name exists. The goal of this patch is to preserve the original article property in the API response.

Rendering the custom field with the same name alongside the core property would require introducing a separate attribute or structure to avoid name collisions. Since the issue specifically concerns the loss of the core images data, this patch focuses on preventing that overwrite.

If there is a preferred approach for exposing both the core property and the custom field in the API response, I would be happy to update the implementation accordingly.

[richard67]

There is another, newer PR for the same issue: #47306 .

[brianteeman]

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.

[narang24]

Thank you for the feedback @brianteeman

I have pushed an update to the PR. The implementation now prefixes custom fields with custom_field_ when their name conflicts with an existing article property. This prevents the core property (such as images) from being overridden while still ensuring that the custom field value is included in the API response.

[alikon]

I have tested this item 🔴 unsuccessfully on 67f8b3e

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47304.}

[alikon]

still custom fields 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
    }
}

[narang24]

@alikon I checked the test and noticed it was using the /articles endpoint. The prefixed custom field was not being added to the render list for that endpoint. This has now been updated so the custom field is properly returned in the response.

[alikon]

consider also that custom fields are used not only by com_content