I’ve seen posts throughout the years about location schemes and various ways to go about setting them up. The impression I get is that there aren’t any best practices, as such, but people seem to do whatever makes the most sense and that they can get to work. I’m just tackling the question myself. Seems to me the basic question you ask yourself is if will do some degree of sharing of contexts (and therefore location schemes) across your sites by writing clever JEXL, or to have separate contexts for each site and not share. My instinct is to go with the latter, because you won’t run the risk of breaking multiple sites when you make changes, not to mention just general maintainability and simplicity. If anyone could share their thoughts / experiences in this area, it would be much appreciated.
Always try to go with one set of Publish and Assembly location schemes across all your sites. If you don’t you’ll end up not being able to cross-site link. I’ve been there, done that, and reverted back to single location schemes.
In order to keep your location schemes simple, you can also use system variables to allow you to have different output paths for different Sites that share the same location schemes.
For example:
Content Type: Article
Template: Article_Xml
expression: ${sys.variables.MyRootPath}/articles/${sys.item.getProperty(‘rx:sys_contentid’).string}.xml
(Apparently, the form inserts spaces into the text that shouldn’t be there. please ignore them)
The best thing to do is use the $sys.site.url parameter which comes from the Site definition - Published URL. And then add that into the location scheme and, as long as its set correctly along with Published Path, just use absolute URLs everywhere (ie skip the cross site link check). This works perfectly for us and clarifies/simplifies everything in page assembly. It also means you don’t need to add so many context variables to the site.
Thanks for the info guys. We’re in the early stages of our implementation and I’ve read a bit the cross-site linking concept. A couple of of thoughts/questions came to mind. It seems like a bit of a corner case to me in that if you are going to link to another website, you just create a normal external link, which of course doesn’t go through active assembly.
With regards to training to have one set of contexts for all sites, it would seem that might break down if you share content types across sites and have different naming/location conventions depending on the site their being used on. Did you not run into that or do you not share content types across sites?
Allana, awesome tip. I’ll remember that for my own work from now on. That’s much cleaner than a variable. Although $sys.site apparently only has fields for Site Root, Folder Root, Global Template and Id (keys of “url”, “path”, “globalTemplate” and “id” respectively)
Duane, if you’ve got different paths for different sites for the same content item using the same template, you’ll want to define a new context for the second site and build out the locations schemes in the new context according to the second site’s publishing model.
In our instance yes we use the same set of content types across all sites but the naming conventions are all the same. In our case we use a set filename field so people actually define “news.html” for example, and that field is validated as being unique to a folder, but I’ve also had success using the system title or display title (again if unique), escaped and with invalid url characters removed, plus the file extension. It depends on your model, but it’s a good idea to keep cross-site linking working and available because as sure as anything someone will want to use it sometime.