Mixing
Is using Hub sites the new way of having sub-sites
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty{ margin-bottom:0;
}
up vote
4
down vote
favorite
I am working on a new sharepoint online project. and we need to build the following:
- Have a main intranet site where users can publish news, events and general documents and templates.
- To have separate sites or sub-sites for each department. Such as HR, IT, Finance, etc.
Now I was planning to follow the traditional way of doing things, mainly by:
Create a new classic team site (mainly to use the built-in root site collection).
To create separate classic team sub-sites for our departments.
But recently I read about Hub sites, and it is been mentioned that using hub sites should be the new/modern way of having sub-sites.
So I am not sure if for my above case I should follow having classic team site and classic sub-sites? OR I should use Hub sites and have departments' site collections that are linked to the hub site?
second point. one of the main benefits i usually get from using site collection and sub-sites, is that columns and content types created at the root site (site collection) will be available to all the sub-sites without having to set content type hubs or any things else, also i have the ability to have a sub-site which inherit from its root site, finally i also have the ability to have sub-sites of each sub-site. so i am not sure if these features/capabilities are offered for us when we use site collections linked to Hub Sites?
sharepoint-online team-sites community-site modern-team-site hub-site
asked yesterday
SharePoint TestDev
998
add a comment |
up vote
4
down vote
favorite
I am working on a new sharepoint online project. and we need to build the following:
- Have a main intranet site where users can publish news, events and general documents and templates.
- To have separate sites or sub-sites for each department. Such as HR, IT, Finance, etc.
Now I was planning to follow the traditional way of doing things, mainly by:
Create a new classic team site (mainly to use the built-in root site collection).
To create separate classic team sub-sites for our departments.
But recently I read about Hub sites, and it is been mentioned that using hub sites should be the new/modern way of having sub-sites.
So I am not sure if for my above case I should follow having classic team site and classic sub-sites? OR I should use Hub sites and have departments' site collections that are linked to the hub site?
second point. one of the main benefits i usually get from using site collection and sub-sites, is that columns and content types created at the root site (site collection) will be available to all the sub-sites without having to set content type hubs or any things else, also i have the ability to have a sub-site which inherit from its root site, finally i also have the ability to have sub-sites of each sub-site. so i am not sure if these features/capabilities are offered for us when we use site collections linked to Hub Sites?
sharepoint-online team-sites community-site modern-team-site hub-site
asked yesterday
SharePoint TestDev
998
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I am working on a new sharepoint online project. and we need to build the following:
- Have a main intranet site where users can publish news, events and general documents and templates.
- To have separate sites or sub-sites for each department. Such as HR, IT, Finance, etc.
Now I was planning to follow the traditional way of doing things, mainly by:
Create a new classic team site (mainly to use the built-in root site collection).
To create separate classic team sub-sites for our departments.
But recently I read about Hub sites, and it is been mentioned that using hub sites should be the new/modern way of having sub-sites.
So I am not sure if for my above case I should follow having classic team site and classic sub-sites? OR I should use Hub sites and have departments' site collections that are linked to the hub site?
second point. one of the main benefits i usually get from using site collection and sub-sites, is that columns and content types created at the root site (site collection) will be available to all the sub-sites without having to set content type hubs or any things else, also i have the ability to have a sub-site which inherit from its root site, finally i also have the ability to have sub-sites of each sub-site. so i am not sure if these features/capabilities are offered for us when we use site collections linked to Hub Sites?
sharepoint-online team-sites community-site modern-team-site hub-site
asked yesterday
SharePoint TestDev
998
I am working on a new sharepoint online project. and we need to build the following:
- Have a main intranet site where users can publish news, events and general documents and templates.
- To have separate sites or sub-sites for each department. Such as HR, IT, Finance, etc.
Now I was planning to follow the traditional way of doing things, mainly by:
Create a new classic team site (mainly to use the built-in root site collection).
To create separate classic team sub-sites for our departments.
But recently I read about Hub sites, and it is been mentioned that using hub sites should be the new/modern way of having sub-sites.
So I am not sure if for my above case I should follow having classic team site and classic sub-sites? OR I should use Hub sites and have departments' site collections that are linked to the hub site?
second point. one of the main benefits i usually get from using site collection and sub-sites, is that columns and content types created at the root site (site collection) will be available to all the sub-sites without having to set content type hubs or any things else, also i have the ability to have a sub-site which inherit from its root site, finally i also have the ability to have sub-sites of each sub-site. so i am not sure if these features/capabilities are offered for us when we use site collections linked to Hub Sites?
sharepoint-online team-sites community-site modern-team-site hub-site
sharepoint-online team-sites community-site modern-team-site hub-site
asked yesterday
SharePoint TestDev
998
asked yesterday
SharePoint TestDev
998
edited yesterday
asked yesterday
SharePoint TestDev
998
asked yesterday
SharePoint TestDev
998
asked yesterday
SharePoint TestDev
998
998
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
5
down vote
Certainly, the standard recommendation moving forward would be to use modern sites and a flat structure, rather than subsites and/or classic sites. You're right, this changes how we approach things like content types.
The content type story is an interesting one these days:
- Content type hubs haven't been updated recently, nor have they been talked about at any recent conference, that I'm aware of
- MS seems to have decided that they like developers to be involved for these scenarios, as guidance points to resources such as the PNP dev tools, which certainly provide simple mechanisms to deploy virtually any sharepoint asset to site collections, including site columns and content types
- Site scripts allow us to deploy content types and site columns when the site is created, no hub site needed. (site scripts involve JSON and powershell, so again, some developer skill is needed here)
That said, there are some interesting benefits of flat structures, including permissions. Subsites per department often means breaking permission inheritance, which many users find confusing to administer. Flat structures mean that each site simply has permissions applied directly, without dealing with the mess of breaking inheritance.
answered yesterday
Mike2500
4,57131328
1
Correct! The use of a hub site does not automatically cause site content types to be published - a hub site is not a content type publishing hub site. If you use a hub site, and want to use consistent content types throughout, you need to use another mechanism, such as a content type hub, site script, powershell, or 3rd party tool.
– Mike2500
yesterday
1
ShareGate is a great option for this, but yes, ultimately with any of these tools, the content types are separate: they are copied to each site, but each is a separate copy.
– Mike2500
yesterday
1
My corporation is in the middle of a large SPO deployment and we've been assigned some Microsoft engineers as resources. I asked this question of them back when we were in the initial planning stages and this answer mirrors the response they provided me. The future of the Microsoft environment is groups (office unified groups) for every possible collection of users, site collections for every workspace, and hub sites tying them together.
– Brian R
yesterday
1
That was last year's answer. Today, the answer is Teams for collaboration and communication sites for ... communication. ;)
– Mike2500
yesterday
1
I understand your scenario, and that's what my answer addresses
– Mike2500
yesterday
|
show 11 more comments
up vote
2
down vote
Another way to approach this is: how much risk is acceptable in my project ?
The flat model and hub sites gives us a lot out of the box, however once we hit the boundries, we hit them at full speed, and only a very limited number of the old tricks we know is available in Modern SharePoint.
One thing is for sure, we'll be writing a lot of PowerShell in the next few years in order to update all those disjoined site collections
answered yesterday
Kasper Bo Larsen
1,51621017
i know it is a grey area... and we are not at the best period to take decisions... but when we read about the benefits which are offered by modern sites and flat structures, we can not eliminate them and just go with the standard site collection/sub-suite,, i think we need to go for the modern Flatt structure and pay the price/effort (which seems it is a mandatory price/effort at this stage).. what do you think ?
– SharePoint TestDev
yesterday
second point,can you please give us some examples of the boundaries we might face when using modern team sites ?
– SharePoint TestDev
yesterday
1
This article sums it up nicely: digital.withum.com/blog/…
– Kasper Bo Larsen
yesterday
thanks for the reply. now from the link you provide seems the main limitation of using modern sites is that we can not have modern sub-sites.. But regarding the limitations on the UI, i think these limitations are also valid when using classic team sites, because in sharepoint online classic sites it is not recommended to provide custom master pages (although we can) , as customizing the master pages (for example customizing a copy of the seatle.html) might break in the future if SharePoint provides an update which is not compatible with our custom master page...
– SharePoint TestDev
yesterday
From my point of view the primary shortcomings are that you can no longer can inject js snipperts on the pages/lists without involving a developer to create a SPfx component and the fact that you will have to revert to classic if you are using any search based solutions as Modern does not cater for Search as we know it today
– Kasper Bo Larsen
yesterday
|
show 2 more comments
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
Certainly, the standard recommendation moving forward would be to use modern sites and a flat structure, rather than subsites and/or classic sites. You're right, this changes how we approach things like content types.
The content type story is an interesting one these days:
- Content type hubs haven't been updated recently, nor have they been talked about at any recent conference, that I'm aware of
- MS seems to have decided that they like developers to be involved for these scenarios, as guidance points to resources such as the PNP dev tools, which certainly provide simple mechanisms to deploy virtually any sharepoint asset to site collections, including site columns and content types
- Site scripts allow us to deploy content types and site columns when the site is created, no hub site needed. (site scripts involve JSON and powershell, so again, some developer skill is needed here)
That said, there are some interesting benefits of flat structures, including permissions. Subsites per department often means breaking permission inheritance, which many users find confusing to administer. Flat structures mean that each site simply has permissions applied directly, without dealing with the mess of breaking inheritance.
answered yesterday
Mike2500
4,57131328
1
Correct! The use of a hub site does not automatically cause site content types to be published - a hub site is not a content type publishing hub site. If you use a hub site, and want to use consistent content types throughout, you need to use another mechanism, such as a content type hub, site script, powershell, or 3rd party tool.
– Mike2500
yesterday
1
ShareGate is a great option for this, but yes, ultimately with any of these tools, the content types are separate: they are copied to each site, but each is a separate copy.
– Mike2500
yesterday
1
My corporation is in the middle of a large SPO deployment and we've been assigned some Microsoft engineers as resources. I asked this question of them back when we were in the initial planning stages and this answer mirrors the response they provided me. The future of the Microsoft environment is groups (office unified groups) for every possible collection of users, site collections for every workspace, and hub sites tying them together.
– Brian R
yesterday
1
That was last year's answer. Today, the answer is Teams for collaboration and communication sites for ... communication. ;)
– Mike2500
yesterday
1
I understand your scenario, and that's what my answer addresses
– Mike2500
yesterday
|
show 11 more comments
up vote
5
down vote
Certainly, the standard recommendation moving forward would be to use modern sites and a flat structure, rather than subsites and/or classic sites. You're right, this changes how we approach things like content types.
The content type story is an interesting one these days:
- Content type hubs haven't been updated recently, nor have they been talked about at any recent conference, that I'm aware of
- MS seems to have decided that they like developers to be involved for these scenarios, as guidance points to resources such as the PNP dev tools, which certainly provide simple mechanisms to deploy virtually any sharepoint asset to site collections, including site columns and content types
- Site scripts allow us to deploy content types and site columns when the site is created, no hub site needed. (site scripts involve JSON and powershell, so again, some developer skill is needed here)
That said, there are some interesting benefits of flat structures, including permissions. Subsites per department often means breaking permission inheritance, which many users find confusing to administer. Flat structures mean that each site simply has permissions applied directly, without dealing with the mess of breaking inheritance.
answered yesterday
Mike2500
4,57131328
1
Correct! The use of a hub site does not automatically cause site content types to be published - a hub site is not a content type publishing hub site. If you use a hub site, and want to use consistent content types throughout, you need to use another mechanism, such as a content type hub, site script, powershell, or 3rd party tool.
– Mike2500
yesterday
1
ShareGate is a great option for this, but yes, ultimately with any of these tools, the content types are separate: they are copied to each site, but each is a separate copy.
– Mike2500
yesterday
1
My corporation is in the middle of a large SPO deployment and we've been assigned some Microsoft engineers as resources. I asked this question of them back when we were in the initial planning stages and this answer mirrors the response they provided me. The future of the Microsoft environment is groups (office unified groups) for every possible collection of users, site collections for every workspace, and hub sites tying them together.
– Brian R
yesterday
1
That was last year's answer. Today, the answer is Teams for collaboration and communication sites for ... communication. ;)
– Mike2500
yesterday
1
I understand your scenario, and that's what my answer addresses
– Mike2500
yesterday
|
show 11 more comments
up vote
5
down vote
up vote
5
down vote
Certainly, the standard recommendation moving forward would be to use modern sites and a flat structure, rather than subsites and/or classic sites. You're right, this changes how we approach things like content types.
The content type story is an interesting one these days:
- Content type hubs haven't been updated recently, nor have they been talked about at any recent conference, that I'm aware of
- MS seems to have decided that they like developers to be involved for these scenarios, as guidance points to resources such as the PNP dev tools, which certainly provide simple mechanisms to deploy virtually any sharepoint asset to site collections, including site columns and content types
- Site scripts allow us to deploy content types and site columns when the site is created, no hub site needed. (site scripts involve JSON and powershell, so again, some developer skill is needed here)
That said, there are some interesting benefits of flat structures, including permissions. Subsites per department often means breaking permission inheritance, which many users find confusing to administer. Flat structures mean that each site simply has permissions applied directly, without dealing with the mess of breaking inheritance.
answered yesterday
Mike2500
4,57131328
Certainly, the standard recommendation moving forward would be to use modern sites and a flat structure, rather than subsites and/or classic sites. You're right, this changes how we approach things like content types.
The content type story is an interesting one these days:
- Content type hubs haven't been updated recently, nor have they been talked about at any recent conference, that I'm aware of
- MS seems to have decided that they like developers to be involved for these scenarios, as guidance points to resources such as the PNP dev tools, which certainly provide simple mechanisms to deploy virtually any sharepoint asset to site collections, including site columns and content types
- Site scripts allow us to deploy content types and site columns when the site is created, no hub site needed. (site scripts involve JSON and powershell, so again, some developer skill is needed here)
That said, there are some interesting benefits of flat structures, including permissions. Subsites per department often means breaking permission inheritance, which many users find confusing to administer. Flat structures mean that each site simply has permissions applied directly, without dealing with the mess of breaking inheritance.
answered yesterday
Mike2500
4,57131328
answered yesterday
Mike2500
4,57131328
answered yesterday
Mike2500
4,57131328
answered yesterday
Mike2500
4,57131328
4,57131328
1
Correct! The use of a hub site does not automatically cause site content types to be published - a hub site is not a content type publishing hub site. If you use a hub site, and want to use consistent content types throughout, you need to use another mechanism, such as a content type hub, site script, powershell, or 3rd party tool.
– Mike2500
yesterday
1
ShareGate is a great option for this, but yes, ultimately with any of these tools, the content types are separate: they are copied to each site, but each is a separate copy.
– Mike2500
yesterday
1
My corporation is in the middle of a large SPO deployment and we've been assigned some Microsoft engineers as resources. I asked this question of them back when we were in the initial planning stages and this answer mirrors the response they provided me. The future of the Microsoft environment is groups (office unified groups) for every possible collection of users, site collections for every workspace, and hub sites tying them together.
– Brian R
yesterday
1
That was last year's answer. Today, the answer is Teams for collaboration and communication sites for ... communication. ;)
– Mike2500
yesterday
1
I understand your scenario, and that's what my answer addresses
– Mike2500
yesterday
|
show 11 more comments
1
Correct! The use of a hub site does not automatically cause site content types to be published - a hub site is not a content type publishing hub site. If you use a hub site, and want to use consistent content types throughout, you need to use another mechanism, such as a content type hub, site script, powershell, or 3rd party tool.
– Mike2500
yesterday
1
ShareGate is a great option for this, but yes, ultimately with any of these tools, the content types are separate: they are copied to each site, but each is a separate copy.
– Mike2500
yesterday
1
My corporation is in the middle of a large SPO deployment and we've been assigned some Microsoft engineers as resources. I asked this question of them back when we were in the initial planning stages and this answer mirrors the response they provided me. The future of the Microsoft environment is groups (office unified groups) for every possible collection of users, site collections for every workspace, and hub sites tying them together.
– Brian R
yesterday
1
That was last year's answer. Today, the answer is Teams for collaboration and communication sites for ... communication. ;)
– Mike2500
yesterday
1
I understand your scenario, and that's what my answer addresses
– Mike2500
yesterday
1
1
Correct! The use of a hub site does not automatically cause site content types to be published - a hub site is not a content type publishing hub site. If you use a hub site, and want to use consistent content types throughout, you need to use another mechanism, such as a content type hub, site script, powershell, or 3rd party tool.
– Mike2500
yesterday
Correct! The use of a hub site does not automatically cause site content types to be published - a hub site is not a content type publishing hub site. If you use a hub site, and want to use consistent content types throughout, you need to use another mechanism, such as a content type hub, site script, powershell, or 3rd party tool.
– Mike2500
yesterday
1
1
ShareGate is a great option for this, but yes, ultimately with any of these tools, the content types are separate: they are copied to each site, but each is a separate copy.
– Mike2500
yesterday
ShareGate is a great option for this, but yes, ultimately with any of these tools, the content types are separate: they are copied to each site, but each is a separate copy.
– Mike2500
yesterday
1
1
My corporation is in the middle of a large SPO deployment and we've been assigned some Microsoft engineers as resources. I asked this question of them back when we were in the initial planning stages and this answer mirrors the response they provided me. The future of the Microsoft environment is groups (office unified groups) for every possible collection of users, site collections for every workspace, and hub sites tying them together.
– Brian R
yesterday
My corporation is in the middle of a large SPO deployment and we've been assigned some Microsoft engineers as resources. I asked this question of them back when we were in the initial planning stages and this answer mirrors the response they provided me. The future of the Microsoft environment is groups (office unified groups) for every possible collection of users, site collections for every workspace, and hub sites tying them together.
– Brian R
yesterday
1
1
That was last year's answer. Today, the answer is Teams for collaboration and communication sites for ... communication. ;)
– Mike2500
yesterday
That was last year's answer. Today, the answer is Teams for collaboration and communication sites for ... communication. ;)
– Mike2500
yesterday
1
1
I understand your scenario, and that's what my answer addresses
– Mike2500
yesterday
I understand your scenario, and that's what my answer addresses
– Mike2500
yesterday
|
show 11 more comments
up vote
2
down vote
Another way to approach this is: how much risk is acceptable in my project ?
The flat model and hub sites gives us a lot out of the box, however once we hit the boundries, we hit them at full speed, and only a very limited number of the old tricks we know is available in Modern SharePoint.
One thing is for sure, we'll be writing a lot of PowerShell in the next few years in order to update all those disjoined site collections
answered yesterday
Kasper Bo Larsen
1,51621017
i know it is a grey area... and we are not at the best period to take decisions... but when we read about the benefits which are offered by modern sites and flat structures, we can not eliminate them and just go with the standard site collection/sub-suite,, i think we need to go for the modern Flatt structure and pay the price/effort (which seems it is a mandatory price/effort at this stage).. what do you think ?
– SharePoint TestDev
yesterday
second point,can you please give us some examples of the boundaries we might face when using modern team sites ?
– SharePoint TestDev
yesterday
1
This article sums it up nicely: digital.withum.com/blog/…
– Kasper Bo Larsen
yesterday
thanks for the reply. now from the link you provide seems the main limitation of using modern sites is that we can not have modern sub-sites.. But regarding the limitations on the UI, i think these limitations are also valid when using classic team sites, because in sharepoint online classic sites it is not recommended to provide custom master pages (although we can) , as customizing the master pages (for example customizing a copy of the seatle.html) might break in the future if SharePoint provides an update which is not compatible with our custom master page...
– SharePoint TestDev
yesterday
From my point of view the primary shortcomings are that you can no longer can inject js snipperts on the pages/lists without involving a developer to create a SPfx component and the fact that you will have to revert to classic if you are using any search based solutions as Modern does not cater for Search as we know it today
– Kasper Bo Larsen
yesterday
|
show 2 more comments
up vote
2
down vote
Another way to approach this is: how much risk is acceptable in my project ?
The flat model and hub sites gives us a lot out of the box, however once we hit the boundries, we hit them at full speed, and only a very limited number of the old tricks we know is available in Modern SharePoint.
One thing is for sure, we'll be writing a lot of PowerShell in the next few years in order to update all those disjoined site collections
answered yesterday
Kasper Bo Larsen
1,51621017
i know it is a grey area... and we are not at the best period to take decisions... but when we read about the benefits which are offered by modern sites and flat structures, we can not eliminate them and just go with the standard site collection/sub-suite,, i think we need to go for the modern Flatt structure and pay the price/effort (which seems it is a mandatory price/effort at this stage).. what do you think ?
– SharePoint TestDev
yesterday
second point,can you please give us some examples of the boundaries we might face when using modern team sites ?
– SharePoint TestDev
yesterday
1
This article sums it up nicely: digital.withum.com/blog/…
– Kasper Bo Larsen
yesterday
thanks for the reply. now from the link you provide seems the main limitation of using modern sites is that we can not have modern sub-sites.. But regarding the limitations on the UI, i think these limitations are also valid when using classic team sites, because in sharepoint online classic sites it is not recommended to provide custom master pages (although we can) , as customizing the master pages (for example customizing a copy of the seatle.html) might break in the future if SharePoint provides an update which is not compatible with our custom master page...
– SharePoint TestDev
yesterday
From my point of view the primary shortcomings are that you can no longer can inject js snipperts on the pages/lists without involving a developer to create a SPfx component and the fact that you will have to revert to classic if you are using any search based solutions as Modern does not cater for Search as we know it today
– Kasper Bo Larsen
yesterday
|
show 2 more comments
up vote
2
down vote
up vote
2
down vote
Another way to approach this is: how much risk is acceptable in my project ?
The flat model and hub sites gives us a lot out of the box, however once we hit the boundries, we hit them at full speed, and only a very limited number of the old tricks we know is available in Modern SharePoint.
One thing is for sure, we'll be writing a lot of PowerShell in the next few years in order to update all those disjoined site collections
answered yesterday
Kasper Bo Larsen
1,51621017
Another way to approach this is: how much risk is acceptable in my project ?
The flat model and hub sites gives us a lot out of the box, however once we hit the boundries, we hit them at full speed, and only a very limited number of the old tricks we know is available in Modern SharePoint.
One thing is for sure, we'll be writing a lot of PowerShell in the next few years in order to update all those disjoined site collections
answered yesterday
Kasper Bo Larsen
1,51621017
answered yesterday
Kasper Bo Larsen
1,51621017
answered yesterday
Kasper Bo Larsen
1,51621017
answered yesterday
Kasper Bo Larsen
1,51621017
1,51621017
i know it is a grey area... and we are not at the best period to take decisions... but when we read about the benefits which are offered by modern sites and flat structures, we can not eliminate them and just go with the standard site collection/sub-suite,, i think we need to go for the modern Flatt structure and pay the price/effort (which seems it is a mandatory price/effort at this stage).. what do you think ?
– SharePoint TestDev
yesterday
second point,can you please give us some examples of the boundaries we might face when using modern team sites ?
– SharePoint TestDev
yesterday
1
This article sums it up nicely: digital.withum.com/blog/…
– Kasper Bo Larsen
yesterday
thanks for the reply. now from the link you provide seems the main limitation of using modern sites is that we can not have modern sub-sites.. But regarding the limitations on the UI, i think these limitations are also valid when using classic team sites, because in sharepoint online classic sites it is not recommended to provide custom master pages (although we can) , as customizing the master pages (for example customizing a copy of the seatle.html) might break in the future if SharePoint provides an update which is not compatible with our custom master page...
– SharePoint TestDev
yesterday
From my point of view the primary shortcomings are that you can no longer can inject js snipperts on the pages/lists without involving a developer to create a SPfx component and the fact that you will have to revert to classic if you are using any search based solutions as Modern does not cater for Search as we know it today
– Kasper Bo Larsen
yesterday
|
show 2 more comments
i know it is a grey area... and we are not at the best period to take decisions... but when we read about the benefits which are offered by modern sites and flat structures, we can not eliminate them and just go with the standard site collection/sub-suite,, i think we need to go for the modern Flatt structure and pay the price/effort (which seems it is a mandatory price/effort at this stage).. what do you think ?
– SharePoint TestDev
yesterday
second point,can you please give us some examples of the boundaries we might face when using modern team sites ?
– SharePoint TestDev
yesterday
1
This article sums it up nicely: digital.withum.com/blog/…
– Kasper Bo Larsen
yesterday
thanks for the reply. now from the link you provide seems the main limitation of using modern sites is that we can not have modern sub-sites.. But regarding the limitations on the UI, i think these limitations are also valid when using classic team sites, because in sharepoint online classic sites it is not recommended to provide custom master pages (although we can) , as customizing the master pages (for example customizing a copy of the seatle.html) might break in the future if SharePoint provides an update which is not compatible with our custom master page...
– SharePoint TestDev
yesterday
From my point of view the primary shortcomings are that you can no longer can inject js snipperts on the pages/lists without involving a developer to create a SPfx component and the fact that you will have to revert to classic if you are using any search based solutions as Modern does not cater for Search as we know it today
– Kasper Bo Larsen
yesterday
i know it is a grey area... and we are not at the best period to take decisions... but when we read about the benefits which are offered by modern sites and flat structures, we can not eliminate them and just go with the standard site collection/sub-suite,, i think we need to go for the modern Flatt structure and pay the price/effort (which seems it is a mandatory price/effort at this stage).. what do you think ?
– SharePoint TestDev
yesterday
i know it is a grey area... and we are not at the best period to take decisions... but when we read about the benefits which are offered by modern sites and flat structures, we can not eliminate them and just go with the standard site collection/sub-suite,, i think we need to go for the modern Flatt structure and pay the price/effort (which seems it is a mandatory price/effort at this stage).. what do you think ?
– SharePoint TestDev
yesterday
second point,can you please give us some examples of the boundaries we might face when using modern team sites ?
– SharePoint TestDev
yesterday
second point,can you please give us some examples of the boundaries we might face when using modern team sites ?
– SharePoint TestDev
yesterday
1
1
This article sums it up nicely: digital.withum.com/blog/…
– Kasper Bo Larsen
yesterday
This article sums it up nicely: digital.withum.com/blog/…
– Kasper Bo Larsen
yesterday
thanks for the reply. now from the link you provide seems the main limitation of using modern sites is that we can not have modern sub-sites.. But regarding the limitations on the UI, i think these limitations are also valid when using classic team sites, because in sharepoint online classic sites it is not recommended to provide custom master pages (although we can) , as customizing the master pages (for example customizing a copy of the seatle.html) might break in the future if SharePoint provides an update which is not compatible with our custom master page...
– SharePoint TestDev
yesterday
thanks for the reply. now from the link you provide seems the main limitation of using modern sites is that we can not have modern sub-sites.. But regarding the limitations on the UI, i think these limitations are also valid when using classic team sites, because in sharepoint online classic sites it is not recommended to provide custom master pages (although we can) , as customizing the master pages (for example customizing a copy of the seatle.html) might break in the future if SharePoint provides an update which is not compatible with our custom master page...
– SharePoint TestDev
yesterday
From my point of view the primary shortcomings are that you can no longer can inject js snipperts on the pages/lists without involving a developer to create a SPfx component and the fact that you will have to revert to classic if you are using any search based solutions as Modern does not cater for Search as we know it today
– Kasper Bo Larsen
yesterday
From my point of view the primary shortcomings are that you can no longer can inject js snipperts on the pages/lists without involving a developer to create a SPfx component and the fact that you will have to revert to classic if you are using any search based solutions as Modern does not cater for Search as we know it today
– Kasper Bo Larsen
yesterday
|
show 2 more comments
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsharepoint.stackexchange.com%2fquestions%2f252914%2fis-using-hub-sites-the-new-way-of-having-sub-sites%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
