Issue
-
When creating a Fragment with an itemSelector field configured to select a Journal Article, the displayed content includes unexpected characters, such as "]]>" at the end. This issue does not occur when the itemSelector is configured to select a Blogs Entry.
- Here is some of the content of the fragment:
<div class="fragment_name">
[#if configuration.itemSelector1.content??]
${itemSelector1Object.getContent()}
[/#if]
</div>
Environment
- 2023.Q3+
Resolution
- When reading a web content (journal article) object associated to the item selector, the content is retrieved and then serialized to JSON within the FragmentEntryConfigurationParserImpl.java file.
-
As such, the object that is returned to the fragment is a JSON representation of the entity, which means that this behavior is expected as all fields should have the values returned as they are stored.
- In the case of content in Web Content, it’s stored as XML, not HTML (unlike a Blogs entry).
-
For other kinds of custom entities, we cannot expect that it will always be HTML (as it could be stored as XML, HTML, JSON, etc.), so it also isn't converted to HTML to ensure that the fragment can be parsed correctly depending on the use case.
Additional Information
- One option to work around this is to use Templates for this scenario instead of custom fragments with an itemSelector field, as Templates offer a simpler setup with content insertion through pre-built Content Display fragments.
-
A feature request has also been created to explore introducing a new property similar to
.getContent()that directly returns pure HTML for selected Journal Articles, to simplify content retrieval from Journal Articles within fragments. Its progress and potential implementation can be tracked at LPD-28524. - See more related information in the following articles: