Feature request: URL-functions that can point to other layers

Features
1

:bangbang: This is my #1 API-feature-request in XP!

Problem

I use layers in my application(s) to provide content in multiple languages. I always need to create URLs to the same content in another language – and as far as I can see, there is no API that can help me with this.

pageUrl() only works in the context of the page we are currently on.

I have created a library that helps me build URLs by cutting-and-pasting strings together myself, but this doesn’t feel robust at all.

Another usecase here is that we need to provide some meta-data for the other language versions of a given content by using element:

<link rel="alternate" hreflang="${langCode}" href="${url}" />

Solution (maybe?)

Since pageUrl() only works in the context of the current page, could it be possible to provide it the context we want it to operate on instead?

E.g could it be possible to pass in a entry from libVhost.list() as an agument to pageUrl()?

– Tom Arild

1 Like
2

Hi Tom! Have you tried to call pageUrl() inside of contextLib.run() call?

3

Yes, that is part of the solution I’m currently using. But it’s not enough by itself to get a functioning URL.

4

Hi Tom Arild, the solution is not that complex. Simply run a multirepo query against your desired layers to get the instances of the content ID you are on.

Then, using a custom configfile that contains a map over layer + deployment I.e. homepage-en → company.com/en and concatenate this in your frontend. You cannot “automatically” use vhosts here, as multiple vhosts may point to the same sites etc. If you still want to lookup via vhosts, you would need atleast a config mapping of which projects/layers are linked to which vhosts (by vhost id).

This is what is done in the language selector on Collicare for instance: Professional

5

Also, this could ofc be lazy loaded via a service rather than with every page generation.

6

Hi Thomas (@tsi),

Your suggested solution sounds simpler then what I came up with in my lib-xp-translations. :slight_smile: I will probably swith to using your solution in the future.

But my problem wasn’t that I was unable to solve this… I already had a working solution.

The problem is that this use case – that is fundamental to every projects using layers – is non-trivial to solve. And it feels like this should be part of the Core API. Maybe not in pageUrl if it’s too invasive, but how about in project-lib or vhost-lib, or a completely new lib?

– Tom Arild

7

Imho, there is no obvious solution to this, every project/front-end might have a different requirement/setup. Also consider headless setups where there is no vhost in XP at all.

If you know the vhost, I guess there might be an option where you provide the vhost id as a parameter to the portal functions, rather than setting up the full context?