Repository navigation
fix(docs): put the language and search controls in the header - #544
Merged
Merged
Conversation
They were a pair of floating buttons at the bottom of the viewport. They belong where a reader looks for them: in the header, beside the theme switcher. Both now wait for the help application to draw the header, then insert themselves into `.wh-header__switchers` ahead of the theme button, wearing that button's own classes so they are its siblings rather than something pasted on top. The language menu is positioned from the button it hangs under, wherever that button ended up, and a page whose header never arrives keeps the floating pair, so nothing is lost on an older layout. This also undoes what the wrong diagnosis produced. The build profile is applied after all — the pages I read were from a deploy that predated the documentation reaching main — so the solution-level profile, the per-instance copy of every variable, and the injection of the head, the canonical link, the og:image and a second AI notice into every built page are all removed. The notice the footer already carries stays the only one. What remains from that work is the check: the assembled site is verified to carry the canonical link, the structured data and both controls, because losing them silently is exactly what happened. Refs #539
The correction in the previous commit was wrong. The pages that looked complete were served by the deploy that ran two seconds after #541 merged, so what I read as proof that the builder applies the profile was my own injection coming back at me. The assembled job on this branch, with the injections removed, came out red on every marker: the builder emits none of it. So `finalize-site.mjs` keeps writing them in — the structured data, the canonical link, the og:image address, the two controls and the notice at the end of each article. What stays removed is what genuinely changed nothing: the solution-level profile and the per-instance copy of every variable. Refs #539
fix(docs): put the language and search controls in the header
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The language switcher and the search were a pair of floating buttons at the bottom of the viewport. They now sit in the header, beside the theme switcher.
Both wait for the help application to draw the header, then insert themselves into
.wh-header__switchersahead of[data-test="theme-switcher"], wearing that button's own classes so they read as its siblings rather than something pasted over the page. The menu is positioned from the button it hangs under, and a page whose header never arrives keeps the floating pair, so nothing is lost on another layout. The placement was tried against the live site before it was written: the controls land at the theme button's height and the menu opens under them, inside the viewport.It also removes what two CI runs proved changed nothing: the solution-level build profile and the per-instance copy of every variable.
finalize-site.mjskeeps writing in what the builder does not emit — the structured data, the canonical link, theog:imageaddress, both controls and the notice at the end of each article — because that is the only mechanism that actually delivers them on this builder.How to test
assembledis green on this branch: it assembles the five builds the way the deploy does and checks three pages for the canonical link, the structured data, both controls and a non-emptyog:image.After the deploy, the header should carry
🌐 Englishand the search button next to the theme switcher, with nothing floating at the bottom.Related issues
refs #539
🤖 Generated with Claude Code