2

I have the following component (only the relevant part of the component's source is shown):

<ParagraphCenter xmlns="http://www.sdl.com/web/schemas/core">
... 
    <bodyText>
        <text>
            <p xmlns="http://www.w3.org/1999/xhtml">
                <a xmlns:xlink="http://www.w3.org/1999/xlink" title="Linked component 1" xlink:href="tcm:184-112533" xlink:title="Linked component 1">Linked component 1</a>
            </p>
        </text>
    </bodyText>
    <ctaButton>
        <linkText>text</linkText>
        <internalLink xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="tcm:184-112534" xlink:title="Linked component 2"></internalLink>
        <altText>text</altText>
    </ctaButton>
... 
</ParagraphCenter>

When outputing the field using @Html.DxaRichText() the tag's href property remains unresolved, and the xlink attributes are not cleaned up: 

<a title="Linked component 1" xlink:href="tcm:184-112534"
xlink:title="Linked component 2" xmlns="http://www.w3.org/1999/xhtml"
xmlns:xlink="http://www.w3.org/1999/xlink">Linked component 1</a>

Debugging showed that issue is in the ResolveRichText() of the DefaultRichTextProcessor.cs, specifically on line

foreach (XmlElement linkElement in doc.SelectNodes("//a[@xlink:href]", nsmgr))

In the source of the component, <a> has a namespace of http://www.w3.org/1999/xhtml, so when using the following instead of the original line

foreach (XmlElement linkElement in doc.SelectNodes("//xhtml:a[@xlink:href]", nsmgr))

the <a> gets processed properly.

My question is, did anyone encounter this before? What is the source of the mismatch on the xml <-> xpath relation, CM or DXA? Any advices on how to resolve this? I can always resolve the link in the views, but I'd rather have it done the way it's supposed to be.

Important to state that the component link in the RTF is added through the ribbon RTF editor. Version of CMS is Web 8.2 coupled with Dxa v1.5

There were a couple of similar questions already, but this situation is different:

  • the linked component is published is resolved properly to a page from the internalLink field (this was the issue here)
  • the href attribute does have the xlink namespace prefix (this was the issue here)

Thank you in advance.

Improve this question

1 Answer 1

Reset to default
3

Kudos for your analysis! I agree that your modified XPath is the right one and, frankly, I don't quite understand why the current XPath also works in many situations (we do include this in our tests).

UPDATE: I dived further into this; was really curious how it could work in the first place. It turns out that the XHTML namespace is suppressed on the CM-side: in the DD4T JSON, the value of a Rich Text Field contains XHTML element, but not in the XHTML namespace.

Stripping of the XHTML namespace is done in the DXA "Resolve Rich Text" TBB: https://github.com/sdl/dxa-content-management/blob/master/Sdl.Web.Tridion.Templates/Templates/ResolveRichText.cs

I'm not sure why that apparently doesn't happen for you; do you have it in your "Default Component Template Finish Actions" TBB?

Improve this answer
4
  • Thanks Rick, the mentioned TBB is present but unfortunately the namespace is still not stripped. Your answer did point me to the right direction however: In our implementation the 'Serialization format' is set to XML (it was needed to support SI4T). By changing it back to JSON, the namespaces were stripped, so I believe I have stumbled upon a bug. Resolve Rich Text does not strip the namespaces from XML format. Any ideas on how to address this issue? Is customizing the Resolve Rich Text the correct choice keeping in mind future releases?
    – Atila Sos
    Commented Nov 17, 2016 at 11:02
  • 1
    In general, DXA is not intended to work with legacy DD4T XML (at least we don't test it nor guarantuee that it works). If you really want to stick with XML format, I would recommend to create a custom TBB instead of modifying the DXA one.
    – Rick Pannekoek
    Commented Nov 17, 2016 at 18:29
  • BTW: SI4T works perfectly well with JSON format. You will get a weird intermediate result (JSON with an XML comment preamble), but the SI4T indexer (deployer extension) strips of this XML comment, so the stored content is regular JSON. We do extensively test (and support) that combination.
    – Rick Pannekoek
    Commented Nov 17, 2016 at 18:33
  • Understood, thank you. I was told by a collage that the switch was made because of some issues with SI4T, I will be sure and forward this information.
    – Atila Sos
    Commented Nov 17, 2016 at 18:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.