3

The official documentation explains the link resolving algorithm quite detaily, however our testing showed that the proximity resolving doesn’t work like described. Instead, we see the resolving starts at the Root SG instead of the SG where the source Page is located. We have used the same CT (same priority) on all the potential link “destination” pages.

We observe the following behavior:

  • if there is a Page which fulfils the criteria in the Root, it will be resolved (no matter if there is another candidate Page right next to the source Page).

  • if not, the link resolving will continue in the 1st level of the Root’s child SG-s, again having higher priority than the candidate page right next to the source page and so on.

The incorrectly resolved URLs are already present in the PageModelData received from the Model Service (extension). We’re using the various GraphQL providers (Content, ModelService, etc.) .

This was already reported as a defect here and was supposedly fixed in DXA 2.2 which we are on, but it’s still not working. Does this only apply to 2.2 in combination with Sites 9.1 (note that we’re on 9.0) or are we missing something? A setting perhaps to force the Model Service Extension to take into account the context Page, or is there a hotifx?

One more thing, if we manually use the GraphQLLinkResolver’s ResolveLink method from the ILinkResolverExt interface which has a parameter for the context Page, then we get the correct Page resolved (see the screenshot at the end). This tells me that the mechanism is there to do the proper resolving, but how do I make the Model Service’s link resolving behave that way by default?

And one bonus question, disabling the RTF link resolving is described here, but can I turn off link resolving altogether (in the Model service’s response)?

enter image description here

  • Do you use the DXA Model Extension that comes with DXA 2.2? – Rick Pannekoek May 13 at 17:16
  • Not sure, I wasn't the one who set up the environment, but give me some time and I will verify whether everything was set up properly. I will leave a comment once I do. It's the extension for sure, not the standalone service. I wasn't aware there are multiple variations of it – Atila Sos May 13 at 21:24
  • @RickPannekoek Bingo! The wrong version of the model extension was installed. After taking the correct one from the DXA (2.2 release) installation zip, the link resolving started working as expected. In my defense I will quote myself once again: "I wasn't the one who set up the environment". Thanks for the hint, care to post it as an answer so I can accept it? – Atila Sos May 14 at 13:04
  • Regarding your bonus question: why would you want to disable link resolving altogether in the DXA Model Service/Extension? Doing link resolving there saves significantly on server roundtrips. – Rick Pannekoek May 14 at 20:00
  • Partially out of curiosity (to find out whether its even possible), but also I thought it would be beneficial if the OOTB model extension link resolving was not working properly (to have the IDs of the linked components within my models in a string property, so without the need to use an Entity Model property instead of the string just to take its ID). So? Is it possible? :-) – Atila Sos May 14 at 21:55
1

Link resolving using proximity logic was indeed implemented in DXA 2.2.

In particular: it was implemented in the DXA 2.2 Model Service and the DXA Model Extension for the GraphQL Content Service.

If you’re using the 9.0 GraphQL Content Service, you have to ensure you deploy the DXA Model Extension which ships with the DXA 2.2 distribution.

If you’re using the 9.1 GraphQL Content Service, you should use the DXA add-on which ships with 9.1.

See https://docs.sdl.com/LiveContent/content/en-US/SDL%20DXA-v12/GUID-2B7F9E94-11C3-47A9-B3A9-0B7B2465A242

UPDATE

Regarding the bonus question: The link resolving in the DXA Model Service/Extension only adds information (LinkUrl property), so you will also still have the original Component ID. Except for links in RTF, which are replaced with the resolved URL.

This is why the latter can be disabled. AFAIK, it is not possible to disable link resolving altogether. It is definitely not recommended from a performance perspective.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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