I've a couple questions about mappings in sling and best practices. I have a number of 10 sites on my current Sling install, and we will be expanding to 100+ over the next few years.
I have 5 environments: dev, test, staging, preprod, prod Dev is run off of: localhost The other ends are run off: <subdomain>.<domain>.com test.siteA.com, staging.siteA.com, preprod.siteA.com, www.siteA.com Test through Prod also have certain pages that require HTTPS. Sites are setup as follows: /content/site/en/<pages> I want to serve pages such that they appear to be served from: <subdomain>.siteA.com/<pages>.html I thought it would be easy to create a simple sling:mapping node with sling:match => .+\.siteA\.com.\d* mapping /content/siteA/en/ : / Unfortunately this only allows requests for www.siteA.com/page.html to be routed in, however all the links on the page are now pointing at http://null/other-pages.html Sling docs state that using regex wildcards in sling:match in the root mapping (hostname and port) prevents outgoing mappings to work, thus the null. What is the best practice for this? Currently the only work around I can see is making sling:Mapping nodes for every subdomain www.siteA.com, preprod.siteA.com, staging.siteA.com, test.siteA.com, etc. (along with any specific mappings for corner cases like mapping <subdomain>.siteA.com/ to the home page. Trying to maintain all these subdomains separately in each environment is a pain, and likewise maintaining all variations for the site clutters the mappings very quickly. Also, this becomes even worse when dealing with 10s of sites. Thoughts on how to best handle these mappings so they can be easily/efficiently reused between environments and the number of mappings can be minimized? Thanks -- David Gonzalez Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
