Level: 200

Building multisite solutions in Sitecore


It is possible to have multiple sites in the same solution in Sitecore, but there are a few pitfalls and issues which need to be taken into account, when developing the solution. This article will go through the steps and considerations to take, when designing and building solutions containing multiple sites. Starting out with a simple walk through and then talking about the pitfalls and drawbacks.

Written by: Jens Mikkelsen
Tue, Oct 13 2009


Building large multisite solutions can be very complex, setting great requirements to architecture and code quality in form of reusability, extendibility and maintainability. As Sitecore has acknowledged this is a difficult task, they developed a product for this: Sitecore Foundry. This product accommodates the requirements to large multisite solutions, so you should consider this product, if your solution should hold a lot of sites or if it is very complex – why develop something which has already developed as a product?


This article addresses the more simple solutions, where a few corporate sites need to be incorporated in the same solution. It helps you set it up; goes through things you should consider and what pitfalls there are. The article will start out with the most simple solutions and then move on to the more complex considerations you will need to handle.


Setting multiple sites up

This section will describe how to set up a simple multisite possible.


Multiple sites are pretty easy to set up in Sitecore. As clients and end users tend to say: “Can’t we just copy the Home node?” And yes, in theory it is that easy; just copy the node, publish it and point the web.config to it and then you’re good to go. (In real life there are a lot more to it than that, which we will described later).



In this example I have a site with a home node based on the “Sample Item” template. I then duplicate it to a node named Home2 and then just need to set it up in the web.config. The site is set up within the /configuration/sitecore/sites section. Here you will see there are a several sites, even though you just have one site running. Most of them are system sites used by Sitecore’s internal tasks. A site node looks something like this:



< site name = "website" virtualFolder="/" physicalFolder="/" rootPath="/sitecore/content" startItem="/home" database="web" domain="extranet" allowDebug="true" cacheHtml="true" htmlCacheSize="10MB" registryCacheSize="0" viewStateCacheSize="0" xslCacheSize="5MB" filteredItemsCacheSize="2MB" enablePreview="true" enableWebEdit="true" enableDebugger="true" enableAnalytics="true" disableClientData="false" />



Whenever a page is shown, it is shown in a context. You have probably noticed this, if you have used the Sitecore.Context in your code. A lot of the properties of the context are determined from whatever you have specified in the above site setting. For instance the site node specifies which database to use; what the root path to the site is etc.

When a page is requested by a visitor, a site is resolved from this section in the web.config. Which site to use, is determined by the processor Sitecore.Pipelines.HttpRequest.SiteResolver. The site is identified using a type of pattern matching. The resolver runs sequentially through the sites and identifies which site should be used depending on the following conditions in prioritized order:

  1. If the querystring sc_site is used and points to a valid name of a site; that site is used. For instance sc_site=website will ensure the site named website is used.
  2. In the site setting you can specify a parameter named virtualFolder e.g. /sitecore/shell. If the URL used to access a page includes this path, the site which has specified the path will be used. For instance the site “shell” will be used if you access the path http://mydomain/sitecore/shell/whatever.aspx.
  3. The last way the site resolver identifies the site, is based on the hostname – which is the most important for multisite solutions. If you specify a hostname using the parameter hostName (remember the capital N), you can control which site is used depending on the entered domain. For instance you can have a site, which matches URLs with the domain www.domain1.com and another site which matches www.domain2.com.

If none of your sites matches the querystring, path or domain, it uses the first site specified, which haven’t specified any of these values. In the default installation this is the site called “website”; as it hasn’t specified a virtualPath or a hostName, it will be used if no other site matches the variables.


In our example we have the two home nodes “home” and “home2”. Now imagine that the first site is accessed via the URL www.domain1.com and the other is to be accessed via www.domain2.com. We can now distinguish which site is resolved depending on the domain by adding two new sites with the following hostName parameter set:


< site name = "website1" hostName="www.domain1.com" rootPath="/sitecore/content" startItem="/home" [snip]

< site name = "website2" hostName="www.domain2.com" rootPath="/sitecore/content" startItem="/home2"[snip]


Now all requests to www.domain1.com will resolve items in the website1 context with the prefix /sitecore/content/home and requests to www.domain2.com will resolve items in the website2 context with the prefix /sitecore/content/home2.


This will work fine but there are a few more settings you need to set up. Cache is set for each individual site, so you will need to set this up as well (read more about Sitecore cache here). Cache for each site can either be set up in the site element by specifying the parameters htmlCacheSize, registryCacheSize, viewStateCacheSite and xslCacheSize like this:


< site name = "website1" hostName="www.domain1.com" rootPath="/sitecore/content" startItem="/home" cacheHtml="true" htmlCacheSize="10MB" registryCacheSize="0" viewStateCacheSize="0" xslCacheSize="5MB" [snip]


Or by specifying it in the /configuration/sitecore/cacheSizes/sites section of the web.config like this:



< sites >

  < website1 >

    < html > 10MB</html>

    < registry > 0</registry>

    < viewState > 0</viewState>

    < xsl > 5MB</xsl>

  </ website1 >

</ sites >


This enables cache which also means you should clear the cache, whenever you publish, otherwise the publish may not take effect. You do this in the publish:end event in the web.config. Here all the sites, which should clear the cache after publish, is specified. You need to add your sites in the cache clear handler like this:


< event name = "publish:end">

  < handler type = "Sitecore.Publishing.HtmlCacheClearer, Sitecore.Kernel" method="ClearCache">

    < sites hint = "list">

      < site > website</site>

      < site > website1</site>

      < site > website2</site>

    </ sites >

  </ handler >

</ event >


When you have added this, you have set up our multisite solution. When you hit www.domain1.com the node “home” will be the starting node of your site and when you hit www.domain2.com the node “home2” will be the starting node. When you publish both site caches are cleared… So you are now running a working multisite solution in Sitecore.


Wow! That was easy, right? Well the following chapters highlight some of the issues you will have to consider, if you want to have a stable and maintainable solution running.


Global vs. Site global

Now that you have your second site, you will probably find that you are having some issues with global items in form of settings, dictionaries and content. If you have a multisite solution you probably want to be able to differentiate these global values for each site; hence you need another content level. This means that the home node shouldn’t reside directly under the /sitecore/content node, but have a parent called “site” or something like that. This site node resembles the root of a site, and site global configuration can be inserted under that node. This should give a content structure looking something like this: 



Multisite content structure



As you can see in this image, there is now an extra level defining the site. Under this node there is the possibility to add site specific content, settings, dictionaries or whatever you want to add as a site global setting.
The site node has a specific template, which makes it possible to resolve - in a hierarchical matter - which site a given item is placed under and thereby what site a content item belongs to. This is powerful when you need site specific settings or content.


For instance imagine you have a global folder for content, which you can pull on different pages with a multiselect field. This is the common idea for content spots and shared content as described here. A multiselect field and similar fields uses the source to determine which items are presented in the selection box. Normally you would specify this by entering a direct path to the root of the items, which can be selected. This won’t work in a multisite setup, as the root is unique for each site. So how do you ensure that the site specific values are shown for each site?


You can solve the issue by using the template of the site node and Sitecore Query. In the source field you can use Sitecore Query to look for the first ancestor inheriting from the ‘site’ template and then set the site specific global folder to the source.

DAtasource multisite 




This will fill the select box with items placed under the SiteGlobalContent folder under the first ancestor based on the template named Site.


If you want to see the full list of possible Sitecore query syntax, check out this link: http://sdn.sitecore.net/Reference/Using%20Sitecore%20Query/Sitecore%20Query%20Syntax.aspx.
In this way you can specify site specific values in selection fields.


In the same way as fields using the source attribute in relation to the specific site; every other path needs to be relative. This means hardcoding paths and similar is a big “no no”. The typical way of referencing the home node or anything else, by using a direct path, can’t be used in this setup; so you will have to refer everything in relation to the specific site looking for the first ancestor deriving from the site template.

Creating a site from a branch 

If you want to allow easy creation of new sites, you can create a branch holding all the nodes needed by a site including the siteroot, the home node, the dictionary etc. A branch lets you create a set of items and you specify them in the /sitecore/template/branches. You add a new branch by standing on the folder under branches where you want to add your branch; click the new branch button and then specify which template the root of the branch should be based on. In our example that is the Site template:


Creating a branch

You can now add the nodes under the site node making up the site (dictionary, settings, home and globalfolder). If you now add this branch to the insert options on the /sitecore/Content node it is now easy to add a new site: 


Creating a site



You still have to do the config changes and setup the DNS though, so the authors can’t do it completely on their own.


Sharing templates

One of the real powerful things about having a multiple sites in the same solution is that they can share functionality and templates. Thereby you get double use of the functionality you developed for the original site. This is really great, but there are some pitfalls.


To my experience two sites are very rare completely the same. There may be small varies in functionality or the processes involved in content authoring - such as the workflows associated with writing content. If you need to change just the smallest thing in a template or in the standard value of the template, you will have to create a separate template, which does exactly the same as the original except the small change you need. Now that you have a new template, you would also have to change the insert options on all templates, which can create the template you have changed. The result being that you often end up having a complete duplicate of the original templates just for a small change.


As you add more and more sites, you will end up having a lot of similar templates and it will probably result in you losing the overview and make it really difficult to add new functionality.


For instance imagine you want to add functionality which requires you to add a sublayout to a given pagetype. This pagetype are based on a lot of different template, depending on which site it is used on. Which means you must keep track of all duplicate templates and add the sublayout to all of them. As you might see, this will become harder and harder to maintain as you get more and more sites. Therefore my advice to you is, that if you are looking for a multisite solution, ensure that the functionality is the same on all sites, so you don’t have to create a duplicate set of templates.


Most of the time your main site is special and you have a lot of similar small sites. A good way of accommodating this need is by having the concept of microsites. You can create a set of templates and functionality for these simple sites and then keep that static, allowing you to have a more dynamic main site, where you can add all the special functionality you like.

Media library

Sitecore is in many ways a type-centric system, where things are grouped together depending on what type it is. This also goes for media. All images, movies etc. is by default placed under /sitecore/media library. This means that the media files associated with a site will not be placed under the site node you created (e.g. /sitecore/content/mysite1), but in the global media library folder.


If you want to ensure that media files don’t get mixed up between the different sites, you should create a similar site structure under the media library node. You can thereby set security on the folders so that authors for mysite1 only have access to their own media files.

Pitfalls and drawbacks

There are a few pitfalls and drawbacks when developing multisite solution in Sitecore. In this section I will try and highlight some of the most common and most severe pitfalls.


  • Backend functionality and securit: Sitecores backend and the hierarchy in the content editor is not always designed for multisite solutions, where the different sites are suppose to be completely independent of each other, as if they were in two different solutions. Everything under the system node is global, so it is shared between the sites. For instance take aliases. They are created under /sitecore/system/aliases and are thereby global. You cannot create the same alias for two different sites. There are several things like this, so don’t expect that you can create sites and have functionality like it was in two different installations.
  • Modules: A lot of modules – both in shared source and the Sitecore released - are not built for multisite solutions. They are often based on global functionality and settings. For instance the mailinglist module is not multisite compatible in any way. The functionality where you send mails and create different lists are global, meaning that if an author from one site has access to the module, he has access to all mailinglists from all sites and can send out mails to them
  • Backend not scalable: The current version of Sitecore doesn’t allow the backend to be distributed over several servers due to caching issues. Therefore the backend doesn’t scale, which may be a problem if you have a lot of sites with a lot of active authors, making the backend perform badly. This is normally not an issue, but if you have enough sites, you will eventually run into performance issues.
  • Performance issues on one site will hurt all sites: All sites are running on the same machine in the same IIS site. This means that if one site has performance issues, the issues will affect all sites in the solution.
  • Publish queue: The publishing task is global for the solution. This means that if an author from one site performs a full publish, he will publish changes on other sites as well and block the process in the mean time. Authors may experience long waiting times while other publishes, seeing their own publishes to be queued.

A lot of these issues can be handled or worked around, but they are still issues you will need to handle and you may end up “hacking” Sitecore, which isn’t a preferable solution.


Single versus multiple installations

We have seen that it is possible to add several sites in the same Sitecore installation, but what is the difference from this to having separate installations with a site each running on the same code and templates? When should you use one installation and when should you use multiple installations?


Unfortunately there are no simple answers to this one. It really depends on your requirements and the future need of your site. For most cases the following is true: If you have a corporate site with a few microsites sharing content or similar; use one installation. If you have many very different sites (functionality-wise) use different installations. This statement should be seen in general, as your requirements may differ from the standard. I have written up some of the pros for each setup and you can match your requirements up against them:

 Topic Single installation  Multiple instances 
Content sharing between sites Possible. You can use normal Sitecore functionality to achieve this. Not possible by default. You will need to share content via RSS or similar and it won’t be as easy for content authors to use the functionality.
Backend security. Disallowing authors of site1 to see and change content and settings for site2  Can be problematic. Complex to setup and maintain security. Some modules presume you don’t want to differentiate security for each site.
However a pro is that editors altering content on both solutions will have a single sign on process and can alter content in the same solution.

Great. As the sites are completely separate, there is nothing to be setup or maintain other than logins to each site.
However authors on multiple sites needs to login to different installations, if they need to change content on more than one site.

Separate functionality The more the functionality varies the harder it will be to maintain the solution. For instance imagine you want to have different insert options for each site. This requires you to create two different templates.
As the solutions are separate you won’t have to have duplicated templates or similar. However as functionality gets more and more differentiated, it will be harder to add new functionality, build for the different solutions.
Pretty simple and easy. You only have one solution and deployment is almost as easy as just having one site.
May be time consuming if you haven’t build deployment scripts, as you have to deploy to each installation.
Performance and availability  The more sites you have the more performance heavy the complete installation is, meaning that one site could cause all sites to slow down. If one site crashes the .net process, all sites will be affected. Each installation is separate so if one site crashes or consumes all resources, the other sites won’t be affected. 
Publishing and caching
As publishing is a global process, an author publishing one site, may block other users from publishing.
As the publishing clears all HTML cache, site1’s cache will be cleared when site2 publishes, even though nothing has changed in site1.

Works as normal and only the site publishing is affected by the process.
License and costs
As everything runs on a single installation and on the same server(s), the cost for this solution is normally lower, than having multiple installations. (depending on your license agreement)
License is more expensive and if your installations don’t run on the same server(s), the cost of that increases too.
Site specific setup
You cannot alter IIS and .Net setup for each site. For instance you won’t be able to have different impersonation setup for each site.
As a normal single site solution.

Besides the simple pros and cons, there are several other things which need to be considered. When running multisite solution you will find that the more sites you have, the complexity, maintainability and time involved in developing new functionality will change the more sites you get. Over time it will be harder to maintain the solution as it gets more complex. Especially if the different sites develop in different directions, where one site holds functionality another site doesn’t. The separate functionality may influence general functionality, which makes it even harder to maintain. This of cause is especially relevant for the single installation scenario. Therefore multisite solutions in a single installation tend to be more problematic if you have a larger amount of sites. This is shown in the following graph:


One or multiple installation graph


Here you can see, that if you have a fewer amount of site, the single installation scenario is the best for maintainability, as it is simpler just having one installation. Updates and new development can be applied to this installation only and it is therefore not so time consuming as having two installations. However as you get more and more sites into the solution and the functionality for separate sites vary, you will find that having them in separate solutions will make the process easier, as you won’t have to take every type of site and multisite functionality into account every time you develop or deploy functionality to a solution.


It is not set in stone when it is better having one installation and when it is better having multiple installations. This varies depending on the how different the functionality in each site are, how tight security needs to be, what modules you have installed etc. For instances if you have a solution where the different sites will always have the exact same functionality and it won’t change very often; this will push the red curve right and make it more feasible to have the sites in a single solution. If the opposite is true, you will find that the red curve will move left, making it a better solution to have separate installations. 



This article has hopefully helped you setting up a multisite solution and enlightened you on some of the concerns, architectural decisions and given you an idea of what pitfalls and drawbacks there are. The article is based on our experiences in Pentia and is therefore biased, so if you disagree or have something to add, please feel free to add a comment.



Please rate this article

9 rates / 4,56 avg.

  • About the author:

    Jens Mikkelsen

    Jens Mikkelsen is a partner at Inmento Solutions a Sitecore consulting firm. He works as a Sitecore specialist and consulting helping clients architect and build quality Sitecore solutions using the newest modules and tools. 

    Further he has been deeply envolved in various complex solutions and has built up a strong knowledge of Sitecore architecture and best practices. He has especially focused on and is specialized in debugging and analyzing Sitecore solutions.


    Jens is very interested in the technical mechanisms in the new marketing products such as Sitecore DMS and Sitecore ECM.

    My Sitecore Freelance CV

28 responses to "Building multisite solutions in Sitecore"

There is one more thing to consider when setting up multiple sites. It is possible to access content from www.site1.net in www.site2.net. Simply by entering the full content path e.g. www.site2.net/sitecore/content/home1.aspx
Posted: Wednesday, October 14, 2009 11:33 AM
Your absolutely right Larre. I though i'd added that. I'll update the article later. Thanks for the feedback
Posted: Wednesday, October 14, 2009 11:39 AM
Rather than adding sites to the web.config why not also use /App_Config/Include/website1.config, that way you can specify various parameters for caching, publishing and the website configuration in one succint unit.
Posted: Wednesday, October 14, 2009 5:43 PM
Do you have an opinion on the best way to set up the project in Visual Studio? We have an issue where we have multiple sites under one Sitecore instance and any fix to one site requires pushing all the files on all of the sites.
Posted: Wednesday, October 14, 2009 5:46 PM
Hi Kris,

I would have a solution for the shared code. This would be your framework.

If you are only talking about site specific add-ons and not changes, I would have a seperate solution for each site holding the additions. Then you can deploy site specific code to only one server.

If one site requires changes to the framework, I would create a complete separate branch of the complete framework for that site only. This will require any changes in the framework to be merged into the site specific branch, but it is the best way of keeping track of site specific changes and the sideeffects it may have on new developed framework code.

I hope that helps. If not; let me know.

Posted: Sunday, October 18, 2009 7:54 PM
Thanks for the article. We are doing a lot of the same things.

I'm having trouble with this Sitecore Query and wondering if you can see what I'm doing wrong.

When I run it in Developer Center (without the query:) it works great.

When I add "query:" in front and place it in the source for a multi-list field, I get no results:


Node Structure for context item:


Folder of items I want retrieved:


Thanks for your time (don't spend too much of it!)
Posted: Tuesday, November 03, 2009 6:44 PM
Thanks for the article. We are doing a lot of the same things.

I'm having trouble with this Sitecore Query and wondering if you can see what I'm doing wrong.

When I run it in Developer Center (without the query:) it works great.

When I add "query:" in front and place it in the source for a multi-list field, I get no results:


Node Structure for context item:


Folder of items I want retrieved:


Thanks for your time (don't spend too much of it!)
Posted: Tuesday, November 03, 2009 7:12 PM
Hi Donna

Thanks for reading and posting on learnsitecore :)

I think your query look just fine. So the problem must be somewhere else.

Which Sitecore version are you running?

From Sitecore's change log for the Sitecore CMS 6.0.1 rev.090212 (also known as "Service Release-1") release, under Miscellaneous it says:

Using query in field sources did not work.

So if you are using a version of Sitecore 6 prior to 6.0.1 rev.090212 I think you have to upgrade :(

Posted: Tuesday, November 03, 2009 10:12 PM
Arrg... we are on Sitecore 6.0.0 (rev 090120)

Thanks for your help!!

Posted: Tuesday, November 03, 2009 10:28 PM
Hi Jens,
Thanks for this Post. Very informational.
Can you elaborate this post with additional inputs including security(in Part2). (Content of domain1 should not be visible/accessible to domain2 like independent websites but in one installation as you mentioned)?
Posted: Thursday, November 05, 2009 6:24 AM
Hi Jens,

Can we schedule the Indexing Jobs? Dowe need to do custom coding for this? Please clarify me on this point and it will be very much grateful if you can provide any solution.
Posted: Tuesday, March 16, 2010 5:43 AM
To Jens and Larre:
it's possible to prevent Site1 seeing Site2's node or the other way around by:
1, make sure you have a field in “Site” node for the domain or hostname.
2, In your code, make sure if Site2 is accessing Site1 (www.site2.net/sitecore/content/Site1/home1.aspx) that domain/hostname (www.site2.net) is the same as the field in “Site” node. If not then redirect to www.site2.net

Posted: Thursday, July 22, 2010 3:57 PM
Jens, when I configure my content structure like in your example above I then have the issue of the extra node in the items url path.

For example a a piece of content displays a link to another piece of content. This link is editable via the CMS. The user clicks the internal link option and navigates to the item. This works fine but the web dialog adds the root node into the path and therefore we end up with hostname/root/home but we want it to display hostname/home.

Any ideas?
Posted: Tuesday, November 30, 2010 4:19 PM
make sure that you use LinkManager to get your target item

public string Url
return LinkManager.GetItemUrl(_linkField.TargetItem);


in the link field you see the path kind of like this /SiteName/home/item.aspx but the LinkManager will make sure that it's resolved like this hostname/item.aspx

Posted: Tuesday, November 30, 2010 6:38 PM
Hi Jens,

Thanks for the great article. Which field types support sitecore Query Syntax ?

Grouped Droplink
Grouped Droplist
Droptree ?
Posted: Tuesday, December 21, 2010 8:04 PM
Hi Lello,

All the fields that needs to be populated with one or more items. For instance the multilist field, which is populated with items.

Fields that holds actual values doesn't allow datasources. For instance the check box field.

Posted: Wednesday, December 29, 2010 5:29 PM
Can we add somthing like *.domain.com
Posted: Saturday, January 15, 2011 10:51 AM
Hello Jens,
We are working on multiple sites in one intstallation. We use a shared master page and in the code behind of the master page we want to get data for the site being accessed by a user. We use Sitecore.Context.Items["sc_CurrentItem"] to get the current item from the context, but in some cases this returns the top item of another site (using the same templates) in this installation. Also when using Sitecore.Links.UrlOptions() I see the site name of the other site.
Might this have something to do with 'A lot of modules – both in shared source and the Sitecore released - are not built for multisite solutions'.

Posted: Tuesday, August 02, 2011 5:20 PM

I think you guys are accessing Site1 through Site2 that's why it returns items from Site2.

always use Item item = Sitecore.Context.Item; for current item.

Which version of Sitecore are you using?


Posted: Tuesday, August 02, 2011 6:09 PM
Hi Iede,

Mortaza is right. You should use Sitecore.Context.Item instead. In regards to the URL this more sounds like you are using Sitecore wrong.

Maybe you haven't configured the Site section correctly. You should ensure the right site is resolved.

If you need any more help with it, I am probably going to need a little more information.

Posted: Tuesday, August 02, 2011 6:27 PM
Hello Jens and Mortaza,

Thanks for the reply.
We are using SiteCore 6.4. We have multiple sites in one installation.

We found our bug: wrong key generation for cache.

And yes, I had a better look at some other issues (mainly to do with how to use SiteCore, still need to learn a lot about that) and changed some settings for the link manager.

After changing from debugging using the internal web server of VS2010 to using IIS I could not reproduce the error with the switch of context anymore.


Posted: Thursday, August 04, 2011 10:40 AM
Hi Jens,

I am currently trying to learn sitecore and just have a quick question. I am not entirely sure if it is related to this thread, but here goes.

When you are creating multiple sites, how do you 'hide' the sitecore/content/ part of the url?

For example at the moment I have created a page and the url displayed is:


But ultimately I would like it to be:


How can I achieve this?

Best Regards,

Posted: Thursday, August 18, 2011 2:36 PM
Any way to write a Sitecore query to get to the corresponding node in the Media Library from the Site Configuration? I.E. my configuration which will be an item under /sitecore/content/[website]/SiteConfiguration needs to build a multi-list from images in /sitecore/media library/[website]/images.

If not, what is the best way to handle this?
Posted: Monday, November 14, 2011 9:16 PM
Hi Jens,

Does this type of configuration works on Windows Server R2, that means users can access domain1.com and domain2.com from worldwide and sitecore should be able to handle the requests.
Is there any specific settings, that should be done on windows server.
Posted: Thursday, August 09, 2012 8:21 AM
While talking about multiple intances: Do you mean more than one instances / installations on one physical server or each instance on it's own Hardware?
Would multiple instances on one and the same hardware server mean additional license Feed?
Thanks in advanve
Posted: Tuesday, March 24, 2015 7:58 PM
While talking about multiple intances: Do you mean more than one instances / installations on one physical server or each instance on it's own Hardware?
Would multiple instances on one and the same hardware server mean additional license Feed?
Thanks in advanve

We are talking about Multi-Site under the same installation/instance. This has nothing to do with licensing because you only have one instance. Sitecore by default comes Multi-Site, /Sitecore/Login is in fact a “Site”.
So basically you have more than one “Home” Node under Content Tree.


Posted: Sunday, March 29, 2015 4:56 PM
From your code above....
< event name = "publish:end">
< handler type = "Sitecore.Publishing.HtmlCacheClearer, Sitecore.Kernel" method="ClearCache">
< sites hint = "list">
< site > website</site>
< site > website1</site>
< site > website2</site>
</ sites >
</ handler >
</ event >
I am trying to do this using an EventHandler.config file that is in the app_config/include folder.
All I keep getting is the last site that is referenced when showconfig is used.
Any idea how to write this so it add the additional sites and not just overwrites?
Posted: Friday, December 04, 2015 8:55 PM
Very nice article ,very informative.
Thanks a lot.
Posted: Sunday, January 01, 2017 8:36 AM

Leave a reply

Notify me of follow-up comments via email.