Skip to content

Add services parent to subsite overviews #148 #151

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jun 18, 2024

Conversation

stephen-cox
Copy link
Member

Adds a parent page field to subsite overview pages. When this is used the subsite will appear in the services heirachy.

image

Fixes #148

@stephen-cox stephen-cox force-pushed the feature/2.x/148-subsite-parent branch from 6aa05ea to 1259eb9 Compare May 31, 2024 09:11
@stephen-cox stephen-cox changed the title Add services parent to subsite views #148 Add services parent to subsite overviews #148 May 31, 2024
@willguv
Copy link
Member

willguv commented Jun 3, 2024

The screenshot looks fine @stephen-cox - thanks for working on it

Don't think I've got the power to merge this PR though :)

@stephen-cox
Copy link
Member Author

Don't think I've got the power to merge this PR though :)

Thanks for checking @willguv - we'll merge and release later at Merge Tuesday

@finnlewis
Copy link
Member

finnlewis commented Jun 4, 2024

Discussing in Merge Tuesday:

  • Ekes points out that we have other fields that could be parent pages, and we might want to mention that this is a services parent page. For example, if posting into directories a directory might be a parent.
  • Ru concurs. Working in subsites, people refer to parent pages to mean the subsite overview, but also the services parent page.

Q1: Should we name this "Service parent page" ?

Q2. What is the expected behaviour of setting this field?

  • By selecting a parent service landing page or service sub-landing page:
      1. it sets the url alias to be child of the parent, which in turn sets the breadcrumb.
      1. It then gets listed as a potential child in service landing pages.

Also noting that this is just for new installs for now, so do we need documentation on how to implement on existing sites?

See localgovdrupal/localgov_guides#166

I think I need to read up on th original issue localgovdrupal/localgov#487

I'll do that this week.

Note: everyone is in agreement that consistency is important, just co-ordinating on the various parent fields on names is key.

@finnlewis finnlewis self-assigned this Jun 4, 2024
@willguv
Copy link
Member

willguv commented Jun 5, 2024

Thanks for these questions @finnlewis

Q1

I discussed naming of parent fields with content designers when we were rationalising them a while ago. "Parent page" was decided upon.

Presumably a content designer would only set a parent page that would make sense, and we only allow parent fields to be set that make sense. So does this field name need to be anything other than "Parent page"?

Sorry if I'm missing something here.

Q2

The expected behavior is as you describe. It's valid that subsite overview pages are listed in service landing pages as potential children, and I've seen content designers try to do this.

Is there a risk in adding this to all new sites, not just new installs? Most councils are likely to use it and can ignore if not. If there's a risk, agree a doc is the right way to go.

@stephen-cox stephen-cox requested a review from ekes June 18, 2024 09:46
@finnlewis finnlewis merged commit e1da568 into 2.x Jun 18, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Subsite overview page needs a parent field
4 participants