Site header ability reference
Reference for the GoBuildWP Free 1.18.6 source. Installed schemas and policy remain authoritative.
The site header ability reference explains how to inspect a site's existing branding, validate a proposed header and save it across supported languages. The caller supplies the design; GoBuildWP does not choose a finished template.
Read-only, write and destructive groups describe the source annotations. They do not establish a minimum safety profile, human approval or undo support. Those controls are separate: check the installed ability, the connected user and the active site policy before calling it. A read can still return sensitive data. These pages are not evidence that every operation passed an end-to-end runtime test.
What Site header needs before these load
Included in GoBuildWP Free; GoBuildWP Pro is not needed. Use an active block theme, or Elementor together with Elementor Pro, Elementor's own paid add-on, whose Theme Builder holds the header. The connected WordPress user needs permission to edit the site's appearance. Language-specific output depends on the site's language configuration.
Inspect, validate, then save
Start with dry_run and no design to retrieve site facts and supported building blocks. Send the proposed Elementor elements or block markup with dry_run again to inspect validation findings. Saving requires confirm because a site-wide header affects visitors across pages.
Check the rendered result at three widths
After saving, the ability reads the served pages and reports problems such as missing accessible names, broken images and navigation issues. Open the returned probe URLs at desktop, tablet and phone widths to inspect wrapping, overflow and menu interaction. Server checks alone cannot establish that the layout works.
On a reported error the operation restores the previous header unless keep_on_fail was explicitly requested. Undo restores the previous header state; independently inspect the served page after recovery.
Representative call sequence
This sequence describes the documented calls and checks to perform. It is not a recorded result from an installed WordPress site. Inspect returned errors and partial results, then verify the saved values and affected output before proceeding.
Replace a site's header while preserving its existing menu and language links.
- 01
wppilot/build-site-headerRead facts with dry_run, validate your proposed design, then save with confirm only after reviewing the findings. Use check_only to recheck the served header without another write.
Destructive Site header calls
| Ability | What it does |
|---|---|
wppilot/build-site-headerBuild Site Header | Saves the site-wide header YOU design and checks it. You are the designer, as for the rest of the website: there is no template. 1) Call with dry_run: true and no design: it returns the site's facts (title, tagline, logo, colours and fonts from the Elementor kit or theme.json and the logo, the home page hero, each language's menu, whether there is a shop) and building_blocks: settings for the menu, the language switcher and the cart that are known to render well. 2) Design a header that fits this brand - its colours, type and tone - and pass it as elementor.elements (Elementor Pro: Elementor elements, in the format Elementor stores them) or block_markup (block themes: the header template part's blocks), with dry_run: true: it is checked before anything is saved. Use the tokens {{menu}} (each language's menu), {{language_switcher}} (a styled language dropdown, never a bare list), {{navigation_ref}} (block themes), {{home_url}}, {{site_title}} and {{label:key}} (per-language text from labels); one design then serves every language, or pass elements_by_language for a language that needs its own. 3) Build with confirm: true. Elementor Pro: one Theme Builder header per language on every page (swapped in by language), the headers that had display conditions kept with their conditions removed. Block themes: the header template part, with one translated part per Polylang language and a navigation per language. It then reads each language's home page as a visitor and reports objective problems - raw language list, a menu with no menu button for phones, cart without its icon, text below WCAG AA, missing accessible names, broken images and links - each with the element id and what to change; on a failed served-page check it attempts to restore the previous header unless keep_on_fail is true. Check recovery and served pages; a storage restore can fail. It returns probe URLs: open them in a browser at 1440, 768 and 390 px and read window.siteHeaderProbe for what only a layout shows (menu rows, wrapping labels, overlaps, horizontal scroll, header height, the menu button opening, computed contrast). Fix your design from the findings and build again; check_only: true re-checks the served header without writing. A retained supported before-image can restore the captured header state; inspect the recovery result and served header. |