Closed stephen-cox closed 2 months ago
The screenshot looks fine @stephen-cox - thanks for working on it
Don't think I've got the power to merge this PR though :)
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
Discussing in Merge Tuesday:
Q1: Should we name this "Service parent page" ?
Q2. What is the expected behaviour of setting this field?
Also noting that this is just for new installs for now, so do we need documentation on how to implement on existing sites?
See https://github.com/localgovdrupal/localgov_guides/pull/166
I think I need to read up on th original issue https://github.com/localgovdrupal/localgov/issues/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.
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.
Adds a parent page field to subsite overview pages. When this is used the subsite will appear in the services heirachy.
Fixes #148