Merge subsites and subsites_extras

[rupertj]

This issue continues the discussion from #16

@willguv:

"Is this a good time to consider pulling subsites extras into subsites?

It seems like most councils will use it, and finding out about this extra functionality/ asking for it to be installed shouldn't be additional work for them"

@msayoung:

"Well, there is an interesting conundrum...

I think the theme bits can be ported in almost as-is.

One of the features of localgov_subsites_extras is that it uses menus to create the subsite navigation. the main localgov_subsites module does not, and follows the localgovdrupal-y convention of creating heirachry through relationships.

The menu version is much more flexible and allows all sorts of content to be brought in to a subsite.

It would be / is weird to have both going on at once."

@andybroomfield:

"Given there is quite a bit of divergence between how these work I wouldn't do that in the current 2.x version.
But I would consider merging subsites and extra in 3.x and make the way extra works with the menu the default way in subsites 3. Perhaps with a fall back to entity hierarchy for backward compatibility (or upgrade existing ones with a menu)."

[rupertj]

There's a few things we'd need to decide:

1. If we make an upgrade path, what does it do? Creating menu items for existing non-extras subsites and then deleting the reference fields would make sense to me.

2. Do we keep the subsite_page included? Now any page can be in a subsite, is it still needed?

3. How long do we keep "extras" in the class name used for theming? If we're doing a major version release for this, we could take it out straight away potentially.

4. Do we need to make corresponding changes in the base theme?

[tonypaulbarker]

Hi folks

Some thoughts from me:

It feels like a big undertaking. Requires technical planning and will involve at least a slight revamp of the demo content that is currently not compatible.

My preference would be to get simple features out of the box and have the option to turn on extensions so I might prefer if they weren't merged.
Designing and developing multiple themes with background colours to be accessible can be an overhead to a project and I'm not sure where it sits within GDS - although we have used these features to create some compelling pages I don't think it is for every site.

What is the list of distinct features provided by Subsites Extras?

[rupertj]

The main features of Subsites Extras are:

• It lets you put any content type in a subsite
• It gives you a standard Drupal menu for that subsite.
• Content types that have a child/parent relationship can have their child pages in a subsite if their parent is. EG: You can put a directory in your subsite and all the directory pages will appear to be in it too.

[willguv]

Propositionally, subsite extras is a good thing to have. With subsite extras installed, councils have the choice of:

• main site for council provided services
• subsites for campaigns, partnerships etc where there's limited extra branding/ functionality or the need for a separate url
• microsites where separate urls and branding are required

[tonypaulbarker]

The case I am thinking of where I don't think the described content structure is in play is that subsite overviews are sometimes used for standalone landing pages and home pages, e.g.

https://www.westmorlandandfurness.gov.uk/
https://www.northyorks.gov.uk/
https://www.westdevon.gov.uk/
https://www.northdevon.gov.uk/
https://www.haringey.gov.uk/news
https://laois.ie/

Maybe there is a place for a standalone landing page type that has the page builder but not the content structure.

[willguv]

There's been conversations about a standalone homepage module before localgovdrupal/localgov#823

[andybroomfield]

The case here is that whilst subsites were originally built as campaigns to align with the GDS campaign pattern, it has since evolved into something unique. Originally this was the page builder format separate but part of the main website, with a defined format. Later on the requirement came to be that certain content types such as events and directories needed to be part of a subsite, which lead to the menu pattern which blended them.

Nowadays I think most councils that use subsites use it with th extra module and the menu pattern, s it makes sense that this is now default and I think it makes sense to unite them.

The upgrade path / how to deal with demo content and existing content is valid, which is why I suggested doing this in a 3.x version.

To me though I think it's going to be harder to maintain the two approaches. My understanding is that once you use extras, content editors use the menu pattern. Sounds about right to make that the default.

BHCC are also now switching to the menu pattern, albeit in different content types as part of our enhanced landing page work. It might be worth considering standardising on this.

[ekes]

The case here is that whilst subsites were originally built as campaigns to align with the GDS campaign pattern, it has since evolved into something unique.
The upgrade path / how to deal with demo content and existing content is valid, which is why I suggested doing this in a 3.x version.
To me though I think it's going to be harder to maintain the two approaches.

I think @andybroomfield is correct here.

With a 3.x version if it's not possible to actually make an upgrade path, it's maybe best to detect any sites using entity hierarchy and enable a 'localgov subsites legacy' module that gets minimal maintenance and is deprecated giving people time to manually move their structures over to menus. Though I'd guess it is actually possible to automatically move the structures over, anything else involved in presentation I've not thought deeper so don't know.

There's been conversations about a standalone homepage module before localgovdrupal/localgov#823

With a full version update, and the near on complete overlap in fields and usage of LocalGov Page and LocalGov Subsites Pages (and once you've moved to menus LocalGov Subsites Overview as well), it would seem sensible to do something about them if possible. Seems better than also making yet another version almost identical to the existing ones for just a (front) page.

[tonypaulbarker]

Seems better than also making yet another version almost identical to the existing ones for just a (front) page.

We use them for other rich standalone landing pages than the home page (see Haringey news landing page, for example).

Subsite overviews gave us the features we needed but they’re not really subsites so I’d like to discover how we could get the features we need and be logical and consistent.

The other thing that comes into it is the logic for generating the right paths. Even if content types have similar features it might make sense for creating sections and relationships for them to be distinct.

I think it’ll be handy to create a few diagrams to help tease out logical content types and flows.