Open stefanseifert opened 6 years ago
+1 this has been added to our roadmap
I assume you are trying to use the externalizer for foreign services, not AEM itself? Note that the externalizer is not designed for that. It's meant for externalizing AEM URLs = taking an "internal" JCR path and make it reachable from an external location (so to speak). Some methods use the sling reverse mapping which doesn't make sense for 3rd party services.
With an AEM deployment, you usually have a fixed set of environments, say the live site (publish
), the authoring (author
) (default domains), and maybe some custom production
environment that one might want to link to. In that case components might only be configured to what domain string (e.g. author
or publish
) to use when calling Externalizer.externalLink()
using e.g. Sling CA configuration, but not to an arbitrary number.
@alexkli I don't think that's the use case. The specific use case in the core components is that the og:url
meta tag used by the social sharing component is required to be an absolute URL back to the current page (not unlike the canonical
link tag). So this is a (at least IMO) reasonable use for the Externalizer
. The problem highlighted by @stefanseifert is that with the Externalizer
, the caller (i.e. the social sharing component) needs to know which domain argument to pass in and in a multi-domain environment this has to be configured somewhere. Agree that using CAConfig to define this domain argument would be a viable solution.
bq. With an AEM deployment, you usually have a fixed set of environments, say the live site (publish), the authoring (author) (default domains), and maybe some custom production environment that one might want to link to. usually you have not only 1 site in an AEM instance, but multiple (dozens, hundreds, thousands of sites for the big customers). you need different Site URL configurations for each of them. this is not maintainable using the AEM built-in externalizer. this affects not only the core components, but all AEM applications.
use cases for externalizing links within AEM applications beyond the core components are for example:
@stefanseifert I see, makes sense. The impact of MSM and hosting many sites with completely different hostnames didn't reach the externalizer so far 😄
I believe a simple extension might be to have an externalize()
method that can take a URI (as string) instead of a domain, e.g. https://siteA.com
or https://siteB.com
or even https://siteC.com/path
.
It would still leave the configuration aspect (e.g. Sling CA) to the client of the API, but at least one doesn't have to reimplement the externalize logic (which is actually quite tricky with certain encodings and proper URI parsing).
(CQ-4221425)
Using the CQ Externalizer for externalizing links is very inconvenient. By default it supports only one Author and one Publish URL. It is possible to provide further URLs by providing a third argument to the externalizer method, but this requires hard-coding this argument in the code (or making it configurable on some custom location in the site).
The core components make use of the Externalizer without passing a third argument, making the affected components unusable of more than one site is used on the AEM instance. Currently this affects directly only the social sharing component.
What would be required would be a possibility to configure the link externalizing per site (ideally using Sling Context-Aware Configuration), or to be able to plugin you own externalizing logic via an OSGi service. An example for a much more sophisticated solution is the wcm.io URL Handler, which is using Author/Site URLs configured via Sling Context-Aware Configuration under the Hood.