Feature review: Redirect Configuration: 'context prefix' per configuration

[senn]

As redirect rules are often created and maintained by authors, there are a lot of cases where a (big) part of the path is useless and even confusing. For example the following rules:

• /content/mysite/about/contact-us => /content/mysite/about/contact-them
• /content/mysite/blog => /content/mysite/articles

The "/content/mysite" part is often irrelevant to authors. And also tedious when they are typing out the paths instead of selecting.

The idea is to have a "context prefix" option that can be set per main configuration. This would allow all redirect rules to omit the prefix. The above redirect rules would then be

• /about/contact-us => /about/contact-them
• /blog => /articles

Which is much more readable and understandable for authors. Especially in more complex cases.

The "context prefix" is optional and when not set, the rules are evaluated as normal.

[YegorKozlov]

Thanks for the patch, but this functionality can already be achieved with Sling Mappings.

When enabled, Sling Mappings are used for two things:

1. To rewrite Location header, so that instead Location: /content/mysite/about/contact-us user will get Location: /about/contact-us

2. To match ResourceResolver#map'ed path as a second try.

RedirectFilter will first try to match the full JCR Path from the request, e.g. /content/mysite/about/contact-us and , if it didn't match, try ResourceResolver#map'ed path (/about/contact-us)

Example:

Given a Sling Mappings configuration /etc/map/https/www.mysite.com

{
  "jcr:primaryType": "sling:Folder",
  "www.mysite.com": {
    "jcr:primaryType": "sling:Mapping",
    "sling:internalRedirect": [
      "/content/mysite"
    ]
  }
}

and a redirect configuration

/about/contact-us => /about/contact-them

When evaluating http://localhost:4502/content/mysite/about/contact-us.html , RedirectFilter will try to match the full JCR path which will return null. Then it will ResourceResolver#map it and try to match /about/contact-us which will match.

See https://adobe-consulting-services.github.io/acs-aem-commons/features/redirect-manager/mappings.html

[royteeuwen]

@YegorKozlov I don't see how this would work if you have multiple domains on your AEM? They all want their own redirect manager configuration with possibly conflicting redirects, which wouldn't work if you do it like you state (unless I'm mistaken)

[YegorKozlov]

@royteeuwen I don't see a conflict here. Redirects can be separated by context.

/conf/site1/
  /about/contact-us => /about/contact-them

and the Sling Mappings for site1 are:

{
  "jcr:primaryType": "sling:Folder",
  "www.site1.com": {
    "jcr:primaryType": "sling:Mapping",
    "sling:internalRedirect": [
      "/content/site1"
    ]
  }
}

/conf/site2/
  /about/contact-us => /about/contact-them

and the Sling Mappings for site2 are:

{
  "jcr:primaryType": "sling:Folder",
  "www.site2.com": {
    "jcr:primaryType": "sling:Mapping",
    "sling:internalRedirect": [
      "/content/site2"
    ]
  }
}

this should work fine.

[senn]

That is ofcourse a technical solution while the idea for this feature was more about the fact that non-technical authors (who might not know what “/content/mysite” means) can just create the redirect rules without this prefix. A technical user can create this prefix beforehand for each configuration and authors can just create easy and small redirect rules.

Once these rules are created, there is no difference with normal redirect rules as the RedirectFilter just concatenates the prefix with the rule.

[royteeuwen]

Indeed, and also thinking about AEM Quick Site Creation, where you now don't have to do any java code changes, you don't want to do any setup of sling mappings. This feature will help for this

[senn]

Any further input on this feature request and provided solution would be appreciated.

[YegorKozlov]

@senn and @royteeuwen I see your point. You need a non-tech solution for mere content authors who aren't developers and don't want to mess with sling mappings. In this context the feature makes sense. I'll review the PR and send my feedback soon.