MultiSite Externalizer

[justinedelson]

Although it is possible to create a large externalizer configuration for multi-site installations so that each site's links can be externalized with a different domain name, it is kind of a PITA because your code needs to know how to get the right domain, i.e.

externalizer.absoluteLink(resourceResolver, "siteA", "/page.html");

vs.

externalizer.absoluteLink(resourceResolver, "siteB", "/page.html");

What I'd like to do is something like a factory component per site and then a "MultiSiteExternalizer" which looks up the right factory component based on the content path.

[davidjgonzalez]

+1! I could use this on my current project.

One thing i'd find handy is being able to attach "transform rules" to links based on the path.

Ex - well need to write links to /content/alpha URLs with the standard .html extension, but /content/beta links wont have an extension (since the legacy system doesnt use extensions).

[justinedelson]

Hmmm. My gut is that that is a separate concern. But you do raise an interesting point that links passed through the current Externalizer don't get rewritten through the normal rewriter pipeline.

Is what you're describing really about the Externalizer (which should only be used in RSS, Email, external service pings, etc.) or is it about a rewriter pipeline component?

[domirs]

Hi, are there any news on this feature? Regards

[jedatu]

+1 for any work to help with multi-tenancy. Having a factory style configuration and supporting classes would really help deploying multiple solutions in the same instance.

[jayproulx]

+1, this would be wonderful

[cwoeltge]

Not sure I understand the issue yet. @justinedelson the regular externalizer would take care of that already if you give it a slingRequest rather than a resolver. If you have a /path/to/page you'd use externalizer.absoluteLink(request, /path/to/page + ".html")` . I'm sure I'm missing something - if I know what I might be able to put it into code :)

[cwoeltge]

I was looking at this function: https://docs.adobe.com/docs/en/aem/6-1/ref/javadoc/com/day/cq/commons/Externalizer.html#absoluteLink(org.apache.sling.api.SlingHttpServletRequest,%20java.lang.String,%20java.lang.String) So it requires the scheme as well. externalizer.absoluteLink(request, scheme , /path/to/page + ".html")

[jayproulx]

@cwoeltge I think the primary challenge here is that externalizer configuration is centralized. we will be running a large number of sites from a single farm of publish servers, some sites may get their own publish servers, some sites may be created using blueprints, and coding around site names adds unnecessary configuration and boiler plating.

To a large degree, we know that sites living under /content/siteName will be accessed via specific dispatcher configuration and get their own virtual hosts. A multisite externalizer would be able to infer host, port and contextroot for a given content node.

Theoretically, we shouldn't need more than externalizer.absoluteLink("/content/siteName/page" + ".html") (maybe optionally a scheme, though the current scheme more than likely will be what we want).

Storing externalizer configuration for each domain separately would be very nice, rather than an array of every possible virtualhost served up by the server. That would let us install externalizer configuration for each virtual host automatically for the current environment (dev, int, staging, prod) for each project individually.

[jefftran-pds]

@cwoeltge I'm working on a multi-tenancy site as well and having the option in the configuration to generate paths with the current domain as the hostname would be great. In other words, if i use "_self" as the externalizer domain, then https://docs.adobe.com/docs/en/aem/6-1/ref/javadoc/com/day/cq/commons/Externalizer.html#relativeLink(org.apache.sling.api.SlingHttpServletRequest,%20java.lang.String) should be used.

[jayproulx]

I feel like the primary issue (for me at least) is the way we maintain, deploy and store externalizer configuration. Ideally the Externalizer config should work almost identically to a cloudservice config.

I can package up and deploy an arbitrary number of cloudservice configs with my site and deploy them, and associate those configs with any content root that I please, all pages in that content root get that inherited configuration.

However, the current Externalizer configuration is monolithic and only has a single config instance. Many sites and content roots may need to share that exact same node to configure themselves, which isn't feasible and requires manipulation by hand.

We already have 30+ domains on our publish farm and expect to add a few more over the next year, so we're always looking for opportunities to work around Externalizer rather than with it.

[joemaffia]

old topic but... how about using the new /conf folder for managing this? https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html

It will means a little rewrite of a custom externaliser to read from that.

[davidjgonzalez]

Closing; also updates to OOTB externalizer API supports better multi-mapping.

[jayproulx]

@davidjgonzalez was there an update to the externalizer API? This is still an issue for us, I don't think there's a lack of interest here, this is still the weakest link in the externalizer/sling mapping/dispatcher/vhost chain

[davidjgonzalez]

@jayproulx https://docs.adobe.com/docs/en/aem/6-3/develop/ref/javadoc/com/day/cq/commons/Externalizer.html

Doesn't the "custom configured domain" cover this use case?

We can reopen anything; tbh if you're interested enough to reply on closing that signifies interest :)

[henrykuijpers]

Some use cases:

1. We want to send an e-mail from the author environment, containing a link to a page on the publisher
2. We want i.e. social sharing to use the publish links, also from the author environment

There must be many more.

We use this article to set up the mappings: http://www.cognifide.com/our-blogs/cq/multidomain-cq-mappings-and-apache-configuration/

In our projects, we most of the times have the JcrResourceResolverFactoryImpl (resource.resolver.map.location) point to /etc/map.publish.acc - We do this only on the publisher, otherwise the links on the author will be rewritten too.

This does mean that even if we don't link to /etc/map.publish.acc on the author system (by not having the JcrResourceResolverFactoryImpl configuration), the nodes are still there, just unused.

What I propose from this: Why don't we use this mapping config, with a custom ResourceResolverFactory that we call MultiSiteExternalizer (that can inherit everything from the normal one, but just use those additional mappings via a similar configuration like we have on JcrResourceResolverFactoryImpl)?

[henrykuijpers]

WDYT @justinedelson @davidjgonzalez ?

I wouldn't mind investing some time in creating a good solution.

[justinedelson]

It looks to me like http://wcm.io/handler/url/ can satisfy the use cases identified in this issue. I don't think it makes sense to reproduce that functionality here.

[justinedelson]

@stefanseifert is the above true?

[stefanseifert]

yes - wcm.io URL handler uses (since version 1.0) Sling Context-Aware Configuration to store the externalization configuration (domain names). it thus supports multi-site externalization in a declarative way.

but i would love to see a "standard" mechanism for this that is not only used by wcm.io-based applications but also by others e.g. the new AEM WCM Core Components. but this then would be a topic for either Sling or the AEM product itself.

[justinedelson]

bq. but i would love to see a "standard" mechanism for this that is not only used by wcm.io-based applications but also by others

For sure, but in the meantime I don't think it is a good idea to have duplicate functionality between ACS AEM Commons and wcm.io.

[henrykuijpers]

So let's invest some time and improve the OOTB Externalizer to have multi domain support in a more configuration-friendly way? :) (Can we submit a request like that through Daycare?)

[justinedelson]

@henrykuijpers neither ACS AEM Commons nor wcm.io are projects to improve OOTB behavior. They are intended to augment OOTB capabilities. If you want to see productized improvements, please work with product support.