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)?
