child pages of "Giving" don't show their own title

[Pomax]

STR:

• Go to https://foundation.mozilla.org/cms/pages/1437/edit/
• See the title and header text in the CMS
• See the title on the live page https://foundation.mozilla.org/en/giving/happy-holidays-mozilla/ that says "Giving"
• It should say "Happy Holidays from Mozilla"

Jesse W is trying to create a new page under /giving and is having this same issue. Page is launching next week.

[jamilasnell]

Pomax can help out on this ticket!

[richbrennan]

Have requested access to Wagtail to view example page

[Pomax]

let's do an audit before we decide how to move forward: let's understand the difference between title and header, so we can figure out the best way to show "the correct one" based on whether something is a singleton page, a root of a tree of pages, or a child in a tree of pages.

As I recall, the title is a "wagtail" requirement, principally responsible for the page slug (and yes, it can be used in templates, but that's not "what it does", that's only "what you could do" =) whereas we use the header as string that "wins" in a template that has to choose between whether to show the header or title as main on-page content identifier for users.

However, we should verify that's (a) what we actually do right now, and (b) whether we need to keep doing that.

For menu navigation, we also have get_context values that we set that muddy the waters here, so we should set aside some time to figure out how these three aspects (title, header, context) work together and how we want them to work together going forward, so that we do a comprehensive rewrite that fixes both this issue, and any other edge cases that we might as of yet be unaware of.

[richbrennan]

Confirmed with Pomax, I'll make a list of the affected page types and the logic involved, then arrange a call with Pomax and Kristina.

[richbrennan]

Page/template investigation

This investigation covers what is diplayed in the H1 element on applicable pages as per the original issue. I haven't looked at the menus that use the header field as that's a different component, do we need to investigate these too, if so would a separate issue be less likely to cause confusion?

The title/heading logic that displays the H1 is contained in the primary_heroguts.html template. This is used by the following pages:

• Banner Page (BanneredCampaignPage model): bannered_campaign_page.html
• Homepage: homepage.html
• Primary Page: primary_page.html
• MozFest Homepage: mozfest_homepage.html
• MozFest Primary page: mozfest-base.html

The H1 is populated by these variables in the following priority order:

1. root title
2. page header
3. page title

root is a custom variable (an instance of a page) who's value is set depending on the page's parent type, see individual descriptions below.

Individual page logic

Homepage The root/header logic of the primary_heroguts.html template is not used on the homepage.

Banner Page If an ancestor page (i.e. a page above this one in the page tree) is also a Banner page, the root variable is set to be the highest ancestor banner page up the page tree. This ancestor's title will be shown in the H1: https://foundation.mofostaging.net/en/what-we-fund/fellowships/senior-fellows/ If there are no other Banner pages as ancestors then the root is set to the page itself, so the pages' own title is shown in the H1. I don't believe that header will ever be shown in the H1 on a Banner page, because its always overridden by the root variable (ancestor page or the actual page).

Primary Page The Primary page uses the same logic as the Banner Page for determining the root variable and what to output in the H1. Example Primary page with a Primary page ancestor, so root is set to the ancestor whos title is displayed in the H1: https://foundation.mofostaging.net/en/internet-health/trustworthy-artificial-intelligence/ Example Primary page without a Primary page ancestor, so root is set to itself: https://foundation.mofostaging.net/en/press-center/

MozFest Homepage The root/header logic of the primary_heroguts.html template is not used on the MozFest homepage.

MozFest Primary Page The MozFest Primary page uses the same logic as the Banner Page for determining the root variable and what to output in the H1. Example MozFest Primary page with a MozFest Primary page ancestor, so root is set to the ancestor whos title is displayed in the H1: https://mozillafestival.mofostaging.net/en/on-demand/virtual-dialogue-and-debates/big-tech-and-germanys-election/ Example MozFest Primary page without a MozFest Primary page ancestor, so root is set to itself: https://mozillafestival.mofostaging.net/en/technologists/ai-irl-hackathon-building-trustworthy-ai/

Questions/issues

Thank you for the list Rich. So this update won't change anything on /campaigns pages? The original issue isn't happening on those pages so they don't need any update. I'm just checking because they are our most used pages. E.g. https://foundation.mofostaging.net/en/campaigns/election-integrity-and-platform-accountability/ https://foundation.mofostaging.net/en/campaigns/tell-amazon-connected-devices-must-have-privacy-policies/

The first link is a Banner page with a Campaign Index page ancestor (parent), so root will be the page itself and its own title will show in H1. The second link is a Campaign page which is not affected.

With regard to the last three comments related to staging, none of my changes are on staging and these seem to related to the menu rather than the H1, so maybe we discuss and spin off into a separate issue? https://github.com/mozilla/foundation.mozilla.org/pull/7637#issuecomment-947888039 https://github.com/mozilla/foundation.mozilla.org/pull/7637#issuecomment-947893781 https://github.com/mozilla/foundation.mozilla.org/pull/7637#issuecomment-947897649

Phew

@kristinashu @Pomax Are you happy to have a call based on the above?

[richbrennan]

@jamilasnell @Pomax @kristinashu

Can we close this one if the page has been recreated using a different type?

[kristinashu]

Curious what @Pomax thinks? We solved for the original problem with a quick fix but do you think this will be a reoccurring issue we should fix - does this help clean up or complicate our code?

[Pomax]

I'd like to mull this over for a bit to see what work (if any) Rich's findings suggest might be worth doing.

[kristinashu]

@mtdenton there is valuable info in this ticket but the original request is no longer needed. Is it ok close?

[mtdenton]

Apologies, this comment fell through the cracks. Closing now.