Configuration of Multiple Sites/Domains

[dnelson42]

I need some help with determining best practice solutions for site specific configuration of shared, or server-wide, items in our CQ installation that will soon have multiple sites / domains. The affected items in our server are first the error pages (404/500 pages), second the domain name mappings, third the Sling Resource Resolver mappings (also “URL redirects” and/or vanity urls), and lastly the robots.txt.

1. For error pages I need a good way to give each site a custom 404 and 500 error page. I can not find any documentation on this subject at all.
2. I want to be able to map the root of each domain, e.g. www.mydomain.com/ => /content/mydomain/en, so that the home page of the site is en.html and all children of en.html are treated as being in the root of the website.
   I have tried the solution proposed by this document about multiple domains, http://helpx.adobe.com/cq/kb/HowToMapDomains.html, but that appears to break the server. The best I could ever do with that solution was that the child pages worked but the home page would not come up at all.
3. I need to separate the sling resource resolver mappings in /etc/map/ for each domain so that I can have distinct mappings for each, but despite the instructions here at http://sling.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html I cannot make nested mappings work properly.
4. Also I want to be able to set a separate robots.txt file for each domain. What is the best way to accomplish this? A solution that can be kept within the CQ repository would be ideal since that would make maintenance of these files simpler.

I am fairly new to both Java and Adobe CQ5. Any help you could provide would be greatly appreciated.

[Paul_McMahon · Accepted solution]

My personal recommendation would be to look to your web server tier to solve most of the questions you listed above, assuming you are using dispatcher for caching. 

Using mod-rewrite to handle your incoming mappings will allow you much finer grained control over them, but more significantly in my opinion you get better results for dispatcher caching. I will admit that is personal preference, but I have found it to be much more effective in production situations.  You get much simplified sling mappings (because all you are concerned about is rewriting the outgoing links and those rules are based entirely on the repository paths and not on the domain name). It splits the configurations into two - the outgoing being handled by Sling and the incoming by Apache, but I think the benefits are generally worthwhile. Generally you will want some level of mod_rewrite configurations anyway to redirect any requests that contain the full paths to the short paths (to avoid SEO issues) so you aren't adding massively to you Apache configurations. There is a blog article here that discusses this approach - http://www.cognifide.com/blogs/cq/multidomain-cq-mappings-and-apache-configuration/. 

For the robots.txt file one approach I have used in the past is to manage the robots.txt files in the DAM, and then use mod_rewrite to point DAM URL. 

For you custom error pages the only solution I am aware of is to build the logic into you custom error page - checking the domain name and then including the correct sub-JSP based on the domain name. Another alternative is to leverage Apache to return your custom error document - the DispatcherPassError setting in dispatcher to allow Apache to handle error codes. 

[Scott_Brodersen]

This page might provide you with some help...it is about using dispatcher with multiple domains, and has an example of sling url mapping:  http://dev.day.com/docs/en/cq/current/deploying/dispatcher/disp_domains.html

Regarding the custom error messages, is this what you are looking for? http://dev.day.com/docs/en/cq/current/developing/customizing_error_handler_pages.html

hth,

scott

[dnelson42]

Thanks for the solutions. The solution that I ended up with for the error pages is to take the base error pages and add a few lines of code to parse out the site path from the url then check for a couple of pages in the root of the site, eg /page-not-found.html and /page-error.html. If found then I include the page using sling:include:

String pageUri404 = null; String pageUri500 = null; if (!isAuthorMode || mode == WCMMode.PREVIEW) { Pattern p = Pattern.compile("^(/content/[^/]+/[^/]+)/.*"); Matcher m = p.matcher(requestPath); if (m.matches() && m.groupCount() == 1) { String rootPath = m.group(1); if (rootPath != null && !rootPath.isEmpty()) { pageUri404 = rootPath + "/page-not-found"; pageUri500 = rootPath + "/page-error"; } } //check 404 and 500 page urls to see if they are valid if (pageUri404 != null) { Page page404 = pageManager.getPage(pageUri404); if (page404 == null) { pageUri404 = null; } else { pageUri404 += ".html"; } } if (pageUri500 != null) { Page page500 = pageManager.getPage(pageUri500); if (page500 == null) { pageUri500 = null; }  else { pageUri500 += ".html"; } } } if (pageUri404 != null && (statusCode == HttpServletResponse.SC_NOT_FOUND || statusCode == HttpServletResponse.SC_FORBIDDEN)) { %><sling:include path = "<%= pageUri404 %>" /><% } else if (pageUri500 != null) { %><sling:include path = "<%= pageUri500 %>" /><% } else { //fallback for any non-existent error page. The original error page html markup/jsp code goes here }

[Yogesh_Upadhyay]

Note that custom 404 / 403 can cause performance issue on your site. You can handle multi domain 404 through dispatcher as well by having different Error code under each virtual host. Something like http://www.wemblog.com/2013/03/how-to-cache-error-page-in-cq.html

Yogesh