A long-time client of mine needed a new corporate community site for which Sueetie was of course the perfect solution. The problem was that the site had to be located in a subdirectory of an existing domain, so it was time to make Sueetie “Subdirectory Friendly.” You’ll be hearing more about my client’s new Sueetie corporate community site, but the news of the day is that Sueetie now runs in a subdirectory. That’s going to make Sueetie a great community option in many more environments.
Sueetie has traditionally required being run at the site root, or http://yourdomain.com. Running Sueetie at http://yourdomain.com/sueetie was not an option, until now. You can even run MULTIPLE Sueetie Communities on a single domain, which I’m sure a lot of Sueetie devs will be jazzed about. I’ll discuss how to do that later, but right now we’ll describe the steps required to configure Sueetie to run in a subdirectory.
The Configuration Process
For purposes of demonstrating a working Sueetie subdirectory configuration we’re going to describe how a company named "Cool Company" would use Sueetie as an Enterprise Social Media Platform to communicate among employees inside the company. Cool Company’s domain is http://coolcompany.com, with the location of the eSMP at http://coolcompany.com/intranet. "/intranet" is the subdirectory where Sueetie is located.
The location of Sueetie.config file must be known to the various applications of Sueetie. The Sueetie.config was traditionally located in /util/config/sueetie.config. In Version 4.0 the Sueetie.config has been moved to the site root. This is the most obvious location for multiple applications in multiple tiers to find a shared resource. So if Sueetie is run in a subdirectory, the Sueetie.config will be located in the parent tier, or for our Cool Company eSMP scenario, at http://coolcompany.com/sueetie.config.
New Sueetie.config RootPath Property
The next step in configuring Sueetie to run in a subdirectory is to enter the site’s subdirectory name in the Sueetie.config’s new "RootPath" property. Here is what that property looks like with Sueetie at the root followed by providing the "intranet" RootPath value for our Cool Company scenario.
Modify web.config WCF SVC paths
Modifying the web.config WCF addresses to the SueetieService.SVC file is part of the standard Sueetie Site Setup. You’ll be supplying the full address here, i.e., http://coolcompany.com/intranet/
Modify /themes/Lollipop/menu.config paths
Modify the paths in your theme’s menu.config file. We’re automatically converting most process urls to accommodate both root and subdirectory configuration, but decided to not modify the menu.config urls to avoid any complications for sites using external and full http urls.
Search.Config No Longer Exists
The Search.Config has gone away and its properties added to the Sueetie.Config file. One update required for Sueetie in a Subdirectory is to modify the location of your site index directory.
Favicon.ico in Site Root
You can handle your favicon.ico any way you want. Typically all subdirectory sites share a common favicon.ico in the site root, which is the default configuration of Sueetie. So unless we were using a different favicon in our Sueetie intranet, no changes are required.
Full urls.config Paths
Full paths are used in the /util/config/urls.config paths for sites running Sueetie in a subdirectory. Like the menu.config updates, a quick search-replace on ="/ for ="/YOURROOT/ will do the job in seconds. Here’s a screenshot of a Subdirectory Sueetie urls.config.
You’ll need to change /members/login.aspx as the FORMS login url on all web.configs, again searching on ="/. Any other hard-coded web.config element property paths you find or have added will probably need updated as well.
CSS Paths, Page Hrefs
You will of course have to accommodate your site’s subdirectory in your CSS url(‘/intranet/images/pic.png’) paths and any page Href and image paths. You might want to consider using a <Base Url="/intranet/" /> with relative urls, but this and CSS path updates is pure HTML and included here only for planning purposes.
Blog Configuration Default Image Path
For the sake of completeness, if you’re using the Addon-Pack Blog Thumbnail Image displays, be sure to use the full path to the blog’s default image.
This point is primarily important for Sueetie developers, but it is important to remember that any Sueetie Permalinks are stored as absolute Urls and WITHOUT the site’s RootPath. For our scenario, there would be no appearance of "/intranet/" in any stored Sueetie Content or in Sueetie Analytics Page Urls. This enables sites to be moved and reconfigured at a root domain easily without losing any data integrity.
Flexibility in HTML paths, loading CSS and JS files
We’ve added Sueetie properties and controls to give you flexibility in entering HTML paths and when loading CSS and JS files. The screenshot below demonstrates the SueetieUrlHelper.RootPath property as well as the SueetieTheme and JQueryScript controls. Using these items enables you to relocate your site from a subdirectory to a root location or vice versa without any need for modification.
Multiple Sueetie Sites On One Domain
The part many of you have been waiting for, configuring multiple Sueetie Communities on a single domain. Woo-hoo!
First of all, we’re going to need Atomo, but don’t fear, we’re only going to change a single line of code. Remember how we talked about the all-important Sueetie.Config file and that the most obvious place for multiple applications to locate a physical file is the site root? Okay, then to run multiple Sueetie Communities we need to hard-code the location of each site’s Sueetie.Config in Sueetie.Core/SueetieConfiguration.cs. That’s it.
An even more simple approach would be store all Sueetie.configs in the site root, but change the name of the Sueetie.config to, say, Site1.config, Site2.config, etc. and hard-code that in the specific site’s SueetieConfiguration.cs.
We will in time no doubt add an out-of-the-box method of supporting multiple communities without the need to hard-code the SueetieConfiguration.cs as more users build multi-community Sueetie sites in v4.x. The initial release of Sueetie in a Subdirectory is also Phase One toward shared membership configurations, both among multiple communities and other non-Sueetie applications.