Best practices for multisite solution set up

Hey everyone,

We’re starting a new Umbraco Cloud project, currently v15 but will soon move to v16 when it is released.

I’m wondering if there are any best practices and recommendation for multisite solution set up when working with Umbraco?

I have worked with CMSs for a long time (I come mainly from a Sitecore background), so understand CMS concepts very well, including structuring content, root nodes, reusablity of document types and components. I’ve also read through the info on the multisite setup documentation: Multisite Setup | Umbraco CMS

I haven’t been able to any guidance on the Visual Studio solution set up though?

Are there are recommendations on separating out the code into separate projects per site, to keep the business logic, the components, controllers. views etc separate? I know you can separate out the C# Class Libraries into separate projects, and there are potential issues with multiple Web projects, but there are often workarounds.

Ideally, i would have a Common web project, and then a Web project per site (along with multiple Class projects as needed).

Also from the backend structure, it looks like it’s possible to organise Document Types in folders, but doesn’t seem like it is possible to do that so much with block list/block grid components? MVC Areas support also seems to be some what limited form what I could find out, so it didn’t seem possible to separate using Areas easily.

We’re only to have a number of sites on this project, there will be some common elements, but many components which will be very site specific and only used on specific sites. We have found that longer term, keeping the separation of projects in the solution helps maintenance and reduce overhead in the longer term.

What are some recommendations, what have you found to work well?

thanks
Kam

Sitecore templates are much more flexible compared to Umbraco document types/compositions, so keep that in mind. There is no muli-level inheritance in Umbraco, so you can’t for instance do something like this that you could do in Sitecore:

  • Website A homepage
    • Website A base
      • Generic website base
        • SEO composition
        • Base composition

I wrote a discussion about this, comparing it to Sitecore:

So you can have some base compositions, but you need to apply them to every page for every site seperately, like this:

  • Website A homepage
    • SEO composition
    • Base composition
  • Website B homepage
    • SEO composition
    • Base composition
  • Website C news overview
    • SEO composition
    • Base composition

By default all template files (Umbraco templates, not Sitecore templates, so the visualisations) will be placed direcly in the views folder, so it’s best to give them a good alias. Also read this topic for inspiration:

When it comes to code, it’s just a matter of preference. I always try to write as many generic components as possible (View Components for example) so that the pages themselves don’t have that much code (and possible duplicate code). If the sites are very similar, you might use the same code for everything and manage the differences via the Umbraco backoffice. We have some sites that are so similar that you can just enter the URL to the stylesheet and the favicon in the backoffice per site, the rest of the code is the same.

Hope this gives you an idea where to start.

Thanks, appreciate the response, this helps and at least I know I am not missing something obvious.

So far from what I am seeing I agree with your approach. Seems like your mapping of your experience is similar to what I am seeing. In some ways Umbraco is very simple in it’s approach (which is good) but that simplicity results in some lack of control, e.g. the fact that code discovery is entirely convention based rather than you specifying a path to a file.

I did find that Precompiled Views in Razor Class Libraries seemed to work, at least for Block components, so that will help keep some logical separation of code. We were planning to have as many generic components as possible (rather than logic in pages themselves) - this is more similar to the way we would approach it in Sitecore.

In terms of taking a “component based approach”, I assume you make use of Document Blueprints to “pre-compose” the pages with a default set of components for the different types, rather than leaving it to the content authors to start from completely blank pages as a starting point?

It doesn’t seem like Blueprints can be serialized as part of Umbraco Deploy though :cry:

1 Like