No error code 500 for me.

Before PR:
"text": "<p>Wrapper Component</p>\r\n<p></p>\r\n<p></p>\r\n<p></p> "

After PR;
"text": "<p>Wrapper Component</p>\r\n<p>{loadmodule mod_login Login 2}</p>\r\n<p>{loadmoduleid 134}</p>\r\n<p>{loadposition test}</p> "

Is this the expected result?

This pull request has been automatically rebased to 5.4-dev.

please don't use fastrope syntax vor better readability

is this a behavior change? I added the b/c break label because I'm not sure.

I tested this fix across different Joomla versions with the following results:

✅ Joomla 5.4.1 (without patch)

Status: Working correctly

Request:

POST /api/index.php/v1/content/articles

{
    "title": "Swiper Slider - No settings",
    "alias": "swiper-slider-no-settings",
    "articletext": "<p>Example of Swiper Slider module without any settings (only images folder)</p><p>{loadmoduleid 111}</p>",
    "catid": "8",
    "state": 1,
    "access": 1,
    "language": "*",
    "featured": 0
}

Response: 200 OK (169.64 ms)

{
    "data": {
        "type": "articles",
        "id": "1",
        "attributes": {
            "title": "Swiper Slider - No settings",
            "alias": "swiper-slider-no-settings",
            "state": 1,
            ...
        }
    }
}

❌ Joomla 6.0.1 (without patch)

Status: Fails with 500 error

Request: Same as above

Response: 500 Internal Server Error (137.78 ms)

{
    "errors": [
        {
            "code": 500,
            "title": "Internal server error"
        }
    ]
}

⚠️ Important Note: Despite the 500 error response, the articles are still created in the database. This makes it difficult to detect failures in automated workflows, as the API reports an error even though the operation partially succeeds.

✅ Joomla 6.0.1 (with patch applied)

Status: Fixed!

Request: Same as above

Response: 200 OK (143.4 ms)

{
    "data": {
        "type": "articles",
        "id": "1",
        "attributes": {
            "title": "Swiper Slider - No settings",
            "alias": "swiper-slider-no-settings",
            "state": 1,
            ...
        }
    }
}

Conclusion

I know this patch targets Joomla 5.4, but I'm experiencing this issue specifically on Joomla 6.0.1 (not on 5.4.1), and this PR successfully resolves it. The fix allows POST requests with {loadmoduleid} placeholders in article content to work correctly on Joomla 6, preventing the 500 error.

The issue is particularly problematic because:

• The API returns a 500 error, suggesting complete failure
• However, the article is actually created in the database
• This inconsistency makes error handling in automated scripts unreliable

It appears the issue might have been introduced in the Joomla 6.0 branch

@Razzo1987 Could you also test if 5.4.1 still work with the patch? And after that, could you please mark your test result in the issue tracker here https://issues.joomla.org/tracker/joomla-cms/45357 by using the blue "Test this" button at the top left corner?

If the fix would be accepted for 5.4-dev, it would also be merged up into 6.0-dev and 6.1-dev and so also go into 6.

However, it might come too late for the upcoming 5.4.2 and 6.0.2 and 6.1.0-alpha2 releases as we will prepare these releases soon, so it would have to wait until 5.4.3 and 6.0.3 and 6.1.0-beta1 in February.

I have tested this item ✅ successfully on b707ef5

Also tested on Joomla 5.4.1 (with patch).

It continues to work as before.

I have tested this item 🔴 unsuccessfully on b707ef5

I have tested this unsuccessfully but I think the test results might help:

Under 5.4.2, WITHOUT PR Patch - no 500 error code but, getting these results in Postman:
"text": <p>This is text above the Custom HTML module...<br><br><br><br>This is text below the Custom HTML module...</p> ,

Under 5.4.2, WITH PR Patch - no 500 error code but, getting these results in Postman:
"text": <p>This is text above the Custom HTML module...<br><br>{loadmoduleid 129}<br><br>This is text below the Custom HTML module...</p> ,

I am not matching the BEFORE condition of: error code 500 under 5.4.x
since a previous tester talked about 6.x, I also tried testing that and found this:

Under 6.1.0-alpha3-dev, WITHOUT PR Patch - 500 error code.
Under 6.1.0-alpha3-dev, WITH PR Patch, getting these results in Postman:
"text": <p>TEXT above call for module 132<br><br>{loadmoduleid 132}<br><br>TEXT before call for module 132</p>,

(I changed the text in 5.4.2 vs 6.1.0-alpha3-dev to make sure I would not confuse myself - the text is correct.

@alikon Is the commit a response to @exlemor failed test? Could you comment on this, and is this PR ready for testing again?

@muhme the pr is ready to test , i have just made the code simple.

to answer @exlemor on testing the before condition that get 500 on 5.4 it depends from some 3rd part module, and not from custom HTML with just html alone, but since have passed quite a year when this pr has been opened i forget the condition on 5.4

i can move on branch 6.x

I have tested this item ✅ successfully on 09a0f7e

Tested with JBT on current 5.4-dev

• Before PR, created 'Custom' site module, and inserted in article content '{loadmoduleid 111}'
• curl -k -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -X GET 'https://localhost:7154/api/index.php/v1/content/articles/1' | jq
  • Results in 500 'Internal server error'
• Applied PR with Patch Tester
• Article is delivered with field text containing the unreplaced '{loadmoduleid 111}'
• Installed Blog Sample Data
  • Tested getting article with API w/ and w/o PR resulting in same content
  • Scrolled trough home w/ and w/o PR looks identical
  • Compared three articles view w/ and w/o PR looks identical
• No unusual Joomla log messages

I tried to test this PR, but I didn't get the error 500 (without the patch applied).
I have to admit that I've never used the API and have no experience at all regarding Postman (used from VSC).

I have tested this item ✅ successfully on 09a0f7e

The reported problem did not occur in version 5.4.
I also tested version 6 and without applying the patch, error 500 occurred, but with the patch applied, the problem did not occur.

The reported problem did not occur in version 5.4.
I also tested version 6 and without applying the patch, error 500 occurred, but with the patch applied, the problem did not occur.

is this a behavior change? I added the b/c break label because I'm not sure.

@HLeithner As for the b/c break, yes, the imported module is not being rendered, but was it ever rendered? The 500 exception is a clear bug and this PR fixes it. Can you please check this yourself? If we have still doubts, should we rebranch it for 6.1?

This PR completely changed and doesn't fit the title? or did I miss something? At the moment it simply don't render on api.

This PR completely changed and doesn't fit the title? or did I miss something? At the moment it simply don't render on api.

@HLeithner In rendering the placeholder only and not importing the content, it prevents the current 500 'Internal server error'.

i can move on branch 6.x

@alikon Yes, please move it to 6.1-dev, Thank you

@muhme in 6.0 there is a bug without this pr so should be in 6.0