Implement global header/footer design across w.org network

[iandunn]

After it's implemented for News in WordPress/wporg-news-2021#6, we'll need to roll the new header/footer out to all sites in the network. That can/should probably happen before News launches.

There are a lot of potential improvements we can make under the hood, to make the header easier to maintain across the various systems that implement it. It'd be nice to do at least some of that here, but we'll have to weigh the time/benefit tradeoffs for each one.

Pain Points

This file is used by wordpress.org static files including index-wporg.php. It is also used by the codex [and GlotPress, Trac, etc], based on a cron job set up to fetch header.php?wpcodex=1.

And, a lot of WordPress and bbPress themes include it.

Changes require global testing!

• It’s a pain to include the header in local environments, since you have to curl w.org/header.php instead of having a dynamic file. It's easier to fork it, but those quickly become out of date.
• Changes have to be manually copied to the hardcoded Genshi templates for Trac
• It’s hard to test updates to Trac and the Codex before deploying.
• Testing the changes across all sites is tedious, and it’s easy to miss something
• wp4.css is massive, and changes have unintended consequences
• footer strings have to be copied to pub/wporg/footer.php for localization

Potential solutions

We could:

• Open source the files. We should do this if nothing else. Maybe make the global header a separate repo with completely self-contained styles, or just commit to meta.svn
• I think the styles would be easier to maintain, and less fragile, if they were component-ized in the new design, rather than remaining a part of the wp4.css maze. That could still be used by the other themes/systems until they’re migrated to the new parent. We could remove the header/footer styles from wp4.css and move them to some shareable component.
• create a REST API endpoint to get the HTML for the header/footer. that seems like a more modern version of how some sites will curl https://wordpress.org/header.php to import it.
• To make global testing easier and more reliable, we could setup e2e screenshot comparisons or something. They might have to be post-deploy given the lack of dev environments for Trac etc, though.
• Is there a reason Trac doesn’t <iframe> it, or curl-and-cache it like the Codex? Could the Codex <iframe> it for simplicity? probably because submenus/modals can't expand beyond fixed height of the iframe

Refine existing code

• Fix minor style conflicts with header/footer in Classic themes #44 - high
• VoiceOver gets stuck in header #29 - high
• internationalize new header/footer #46 - high
• Assign active-menu-item dynamically #35 - high
• Footer should link to Rosetta pages when available #52 - high
• Port old header.php features etc #42 - medium
• Keyboard navigation jumps around through header  #22 - medium
• Mobile menu and search: inconsistent behaviour and visual refinement #57 - medium
• port any needed features from old footer.php - medium
• test bbpress. need to call bb_head(), footer etc like is done for GlotPress?
• Profiles header/footer missing styles, footer laid out in sidebar #81
• update hardcoded strings in Learn footer, or make it so that they're not necessary. at the very least, make them DRY across sites. this may be unnecessary after internationalize new header/footer #46, or may be a post-launch thing

Add new features

• add feature flag on production so can commit progress but not have it loaded
• output wp_head() in classic themes, but not FSE themes
• Include global FSE styles in classic themes  #19
• Use Rosetta header menu items instead of global #49
• migrate /mobile/index.php content to WP page and delete #47
• migrate /hosting/index.php content to WP page and delete #48
• migrate /search/index.php content to WP page and delete
• Delete static homepage #37 - high
• Make header stick to top on all sites #67 - high
• Add Rosetta locale header #50 - medium
• setup REST API endpoints for sites outside the network #45 - medium
• Integrate new header/footer into Trac #53 - medium
• Hide Rosetta header search for initial launch #58 - low

Launch day

Tracked in #100

Post-launch iteration:

Tracked in #55

[iandunn]

Now that WordPress/wporg-news-2021#6 is done, it'd be a good time to start thinking about this. It's a big chunk of work that's essential to the launch.

@dd32, do you have any thoughts on any of it? Are there any parts you'd like to do?

[dd32]

Is there a reason Trac doesn’t <iframe> it, or curl-and-cache it like the Codex? Could the Codex <iframe> it for simplicity? probably because submenus/modals can't expand beyond fixed height of the iframe

I noted this is mentioned in https://github.com/WordPress/wporg-mu-plugins/blob/trunk/mu-plugins/blocks/global-header-footer/README.md too. It's not possible to iframe it and have a expanding menu that floats over existing content, without using some complicated JS to move the menu from within the iframe to the parent document.

Trac doesn't curl it as there's some complications in the way that Trac Genshi templates work, It's not a straight HTML include but rather a dynamic template language. We could build an endpoint that output the new header in a format that can be included via a curl, that generated something like wporg-head.html & wporg-header.php though.

It might be possible to simply have a JS embed though? So that the "header" is always built on the site via an inline <script src="//wordpress.org/header.php?js_embed=1"></script> that adds required elements to <head> and outputs the <div> directly?

create a REST API endpoint to get the HTML for the header/footer. that seems like a more modern version of how some sites will curl https://wordpress.org/header.php to import it.

This already exists, kind of, for rosetta localised sub-sites. https://de.wordpress.org/?fetch-custom-header=%2Fplugins%2F the Menu is generated on the "main localised site" and that menu (and therefor, all menu items) are then output on the sub-site. There's memcache involved in all that of course. The menu on Rosetta can't be built on a not-main/root-site as Nav Menu's (as used on Rosetta, rather than hard-coded links) can't be generated with a simple switch_to_site() correctly.

[zackkrida]

Hi folks, chiming in to note that Openverse would also ideally use w.org/header.php and w.org/footer.php once they are updated. Inlined styles and scripts for these parts would be ideal for our use case. I'll keep an eye on things here and if details about our implementation would be useful just let me know.

[ryelle]

These items are unchecked and don't have corresponding issues:

To make global testing easier and more reliable, we could setup e2e screenshot comparisons or something. They might have to be post-deploy given the lack of dev environments for Trac etc, though.

port any needed features from old footer.php - medium

update hardcoded strings in Learn footer, or make it so that they're not necessary. at the very least, make them DRY across sites. this may be unnecessary after internationalize new header/footer #46, or may be a post-launch thing

Are they still relevant? Are they needed for launch?

[iandunn]

I just checked off the last two after closing #46. The first was an aspirational thing, but I don't think it's worth it right now.

[fierevere]

thank you for completely breaking the UX for forums and translation system.
Very appreciated for making them unusable. Now i can see the global menu, everytime, instead of the content of the forum posts and translation strings. This is really important for all the contributors on the forums and the translators - PERMANENT ON SCREEN MENU!

Also on rosetta sites locale managers are unable to define custom menus, can only add extra items after global menus,
NO LINKS CHANGING, NO SORTING.
Decisions, not options! Truly WordPress way.

[Otshelnik-Fm]

I have been translating Gutenberg into Russian for several years. Now you have killed the interface. I quit using this service and being active until you remove the huge menu and return the styling of the service interface.

[tellyworth]

Thanks for the feedback, and sorry this has caused issues for Translate! Do you mind posting some screenshots demonstrating the problems you're seeing? It seems that some of them are specific to particular screens and/or window sizes, and the more info we have the better we can fix it.

[zackkrida]

When viewing a list of translation strings like https://translate.wordpress.org/projects/wp/dev/dsb/default/?page=4, each translation has its own sticky header and menu:

These can be obscured by the sticky header, which is particularly frustrating on short (namely small laptop and ultrabook) displays:

before

after

[iandunn]

I created #124 for the sticky element bug.

Closing this since the work that it tracked is done.

[iandunn]

Some other Translate bugs were fixed in https://meta.trac.wordpress.org/ticket/6037 and https://meta.trac.wordpress.org/ticket/6046