I have a project that requires multiple unique webskin sets on a single install of FarCry (v6.2.1). The webskin set would toggle based off the domain. I was hoping to do something like/project1/webskins/site1/… and /project1/webskins/site2/… The goal is to have multiple sites that share custom defined objects (and their data) in the CMS but have the ability to render them completely different. Unfortunately the grid layouts are so different that trying to do this with CSS would be a pain. Is there a way to dynamically reset the default webskin directory? Any other thoughts?
There are a number of different ways you could approach this depending on how your app works.
If you have multiple versions of a site where the structure / content is largely the same and you just want to render them with different webskins, you could do this by checking the hostname in _serverSpecificRequest.cfm and setting a value in the request scope (e.g. a “webskin prefix”) that could be used for the rest of the request. When a request runs, the front controller gets default webskin names for the client device using the device lib, so you could override the getDeviceWebskinNames method to change the default webskin names that would be used by the front controller when processing the request:
So instead of using displayPageStandard and displayBody and displayTypeBody you could set them to site-specific defaults based on a prefix that you set in your request scope for each domain… e.g. site1DisplayPageStandard, or displaySite1PageStandard, etc.
The webskin file structure needs to remain in the form of webskin/typename/webskinname so you can’t easily add an extra level of depth like you were suggesting (webskin/sitetheme/typename/webskinname), but if you want to keep a clean separation of your webskins then it can easily be achieved by putting the webskins into a plugin, e.g. /plugins/sitetheme/webskin/typename/webskinname.
So the above you could potentially do with a switch statement when the request starts as well as overriding that one device library method. Not too crazy… 
The more advanced uses cases will really depend on your app. Where this starts to get a bit more complicated is when you need to “partition” your data, so that objects from site1 cannot appear on site2 and vice versa. Or, where you need site1 and site2 to be able to use the exact same friendly URL but render completely different objects. Or, where you need different users to be able to log in to a site and manage their own data and not have access to data from other sites, etc. We do have a plugin to handle this use case but it’s a commercial one rather than open source. The one main use case it doesn’t currently handle is the ability to have independent site trees, partly due to the sheer number of nested_tree_object-related methods that would need to be overridden.
The other possibility that you have is creating completely separate projects (which may still share common functionality using plugins), and you could put your common/shared data in a different database and just query it as necessary from each of those projects. The various pros/cons really start to come down to how your app works or needs to work, and how much customisation or development time you can spend on it… There’s probably no one-size fits all approach
1 Like