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.
Hello,
I have a classic site with 2000 subsites in it. If i convert it to a Hub site and link all subsites to the hub site; is it possible to do?
- Vinita, no. Modern team sites and modern communication sites link to hub sites. I have not heard any simple answer to what do you do with thousands of classic sub-sites.
Thanks Martin for your quick response.
If I change this main site from classic to Modern experience can then it be converted to a hub site?
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?
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
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.
I'd rather not have to sacrifice information architecture and usability for the sake of performance, especially in an Intranet as its main function is to provide information. So my concern is more whether we are losing an aspect of information architecture that can be beneficial for certain types of users, those that prefer browsing to searching.
At least one scenario we use is a site collection of clients. Each client is a subsite which in turn has subsites for those projects. We could have a hub that surfaced the site collections of clients, but then what about the projects and searching across all of that structure?
I'm glad you qualified the multiple List/Library approach for small segregations. I've seen the opposite, and the job of trying to split that information apart into separate sites is quite a bit more difficult than moving a subsite into its own site collection.
But that said, we haven't had a lot of people "with a love of subsites" chiming in :-). And maybe I just need to get my head to think a different way.
Mary,
We currently have the same information architecture on premises. One site collection per client (> 150,000) and one subsite per project (2-50 per client). We could use a hub per client but then we loose the «all clients» scope.
If we stay with the subsites, it prevent us from using Teams and Planner for the projects.
We have to make on decision on our 2.0 architecture for the cloud and I think we will have to leave the subsites strategy.
As you probably have seen there will be 2 navigation bars one for the the hub and it linked sites and one on top which lets you navigate to other hub sites. As it is not Live at this moment i do not have exact specs.
Yes, I did see that. But I do know that in the current Hub specs (or in the talk), they said you cannot make a hub part of another hub. Certainly, you can link to another hub, but searching and rolling up across two hubs might not work.
I can see making a site directory with a list and Site Designs that use a flow to post to the list which could provide category and sub-category information for sites in the list. But I've often longed to be able to assign metadata to sites using the UI (rather than programmatically using the property bag) If we could do that, we could more easily provide some kind of automatic navigation between site collections based on categories.
