Forum Discussion
Modern subsites?
i would say that from a performance viewpoint, resolving sub-sites has always been an overhead as it reduces the amount of work that can be delegated to SQL by the need to translate internal sharepoint only meta-structures. Now that the old limitations around site collections and database sizes have gone, it makes sense to evolve the granularity and use site collections as the atomic site so that performance can be accelerated. it is only because we have got in the habit of subsites that we are nervous about moving away from them. The advantages they gave in inheritance are much outweighed by the problems of broken inheritance. The inability to separate them in SQL can become a problem as a site grows and then forces a restructuring.
For small segregations then List/ Library structures can be used instead of subsites to partition data physically for security purposes.
The https://www.unily.com/insights/blogs/microsoft-ignite-2017-announcements-you-need-to-knowarchitecture looks like a more formalised evolution of cross-site publishing which delivers a very robust and flexible system where I have used it before. excellent pattern that really leverages search.
perhaps those with a love for subsites could bullet point their advantages to see if we can suggest how that functionality would be designed into a site collection approach.
One strong argument for the classic sub-site Information Architecture is that important Web Designer Galleries -- the Web Parts gallery, the List templates gallery and the Style Library -- all live in the Site Collection, not in the sub-sites. We maintain important assets in these galleries and in the Style Library: in one place, where a change automatically applies to all the subsites within that site collection.
In a new Information Architecture where all sites are site collections -- and we have 1000s of these site collections -- where do we deploy a common, custom JavaScript that we would traditionally keep in the Style Library? Same question for custom list templates, web parts, themes, solutions and composed looks?
- Ian MoranJan 09, 2018Iron Contributor
Related to this - if I wish to make a custom list accessible to a number of sub-sites then it must live in the root site of the site collection. I don't see how I can provide this functionality if I adopt the "new" flat infrastructure where subsites are not used
- Chad_V_KealeyFeb 12, 2018Iron Contributor
I know that in our on-prem 2010 environment, subsites were over-used and often created real tangles of permissions and navigation, so we're trying to get people on board with a flatter structure. However, we have a number of cases where that really wouldn't work or make sense. For example, we have a department that handles "Student Conduct Hearings". Each "case" they handle has a unique set of users (viewers) and needs its own site provisioned using a customized site template (with IRM enabled on the doc library). I'm sure we could create our own site collection template, but we want the end users ("owners" of the site) to be able to provision those case sites without our intervention (and we have self-service site creation disabled).
For this purpose, the classic layout of the subsites isn't really a problem, but it's visually jarring to go from a modern site to a classic one.
- Mary F HarveyFeb 15, 2018Iron Contributor
Yes, that's what I'm finding as well. I try to use as flat a structure as possible, but there are certain types of business processes I want to support in SharePoint Online that just work better with a subsite structure in order to be able organize the content and then also bubble up content from all the sites. Hub sites will help as well Site Designs (the ability to "templatize" modern sites), but not in all cases.