Storefront Header Not Showing: Ten Hooked Functions and the One That Went Missing

Gone, thinned out or split in two

A Storefront header rarely disappears whole. More often one strip of it goes, or it reappears in the wrong place, and the exact shape of the damage points at the callback responsible. Look at a product page, a plain page and the homepage, on a desktop and a phone, logged out, and match what you see to this list.

• No header at all, and the page stops early. A PHP fatal error inside a header callback halted output. The error log names the file.
• Logo present, menu bar gone. storefront_primary_navigation or its wrapper was removed, or replaced by a function that prints nothing.
• Search box and cart gone on every screen. WooCommerce is inactive, or a child theme removed priorities 40 and 60.
• Search box and cart gone only on phones. That is Storefront's design below 768 pixels; the bottom bar carries them instead.
• Menu bar pushed below the content or stretched oddly. A wrapper div was opened without being closed, or closed without being opened.
• Header present but blank. Text color matches the background, or a header image sits behind text of the same shade.

The storefront_header queue in version 4.6.2

Open header.php and one line does the work: do_action( 'storefront_header' ), inside the header element with the id masthead. Everything visible up there comes from callbacks attached in inc/storefront-template-hooks.php and, for the shop parts, inc/woocommerce/storefront-woocommerce-template-hooks.php. Storefront's functions.php loads that second file only when WooCommerce is active, which matters more than it sounds.

One oddity is worth knowing. The comment block in header.php also lists storefront_social_icons at priority 10, but 4.6.2 never hooks it; the function only serves the old Subscribe and Connect plugin. A snippet that removes it removes nothing. That is harmless, but it tells you the snippet was written from the comment rather than the code, so check its other numbers too.

Child theme edits that take the masthead apart

remove_action that runs before Storefront arrives

WordPress loads a child theme's functions.php before the parent's. A remove_action written at the top level of the child file runs before Storefront has attached anything, finds nothing to remove and fails silently. Put removals inside a function hooked to init, which fires after both files have loaded. Owners who miss that step sometimes escalate to remove_all_actions( 'storefront_header' ), which clears the logo, the menus and every wrapper in a single line.

The priority does not match

remove_action only succeeds with the exact priority the callback was added at. The cart sits at 60, the product search at 40, the primary menu at 50. Leave the number out and WordPress assumes 10, so a removal of storefront_header_cart without 60 does nothing at all. When a blog snippet and the hooks file disagree about a number, believe the hooks file for the version you run.

Half of a wrapper pair

Priorities 0 and 41 open and close one div; 42 and 68 open and close two more. Remove an opener and its closer prints stray closing tags, which the browser matches against whatever happens to be open, sometimes the page container itself. Remove a closer and everything after it nests inside the header. Either way the menu bar shifts, content slides beneath it or the footer lands somewhere strange. Move or remove wrappers in pairs, or leave them alone.

A pluggable function overridden from an old copy

Each header function sits inside a function_exists check, so a child theme may define its own storefront_site_branding or storefront_primary_navigation. That is legitimate, and it is also how old code lingers for years. A copy from an early Storefront release may call a function the theme has since dropped, which is a fatal error, or print markup the current stylesheet no longer styles. Compare the child's version with inc/storefront-template-functions.php from the release you run.

Causes that live outside the child theme

• WooCommerce is off. Because the shop hooks load only with WooCommerce active, deactivating it for a test, or a WooCommerce update that failed halfway, removes the search at 40 and the cart at 60 without a single error message.
• A plugin printing into storefront_header failed. Some plugins add banners or notices to the same action. A fatal error inside one cuts the page off at that point. Turn on WP_DEBUG_LOG and read wp-content/debug.log.
• Colors that hide the header. Customizer, Header holds the header image plus Background color, Text color and Link color. The image is applied as an inline background through storefront_header_styles, so a pale photo under white text reads as an empty bar.
• Phones, by design. Below 768 pixels Storefront hides the header search and cart with CSS and the handheld footer bar takes over. If that bar was removed as well, see Storefront mobile menu not working.
• A builder's blank layout. Page builders that offer blank or canvas page layouts replace the theme's page template, so Storefront never runs its header queue on that page.

One complaint is not about absence at all: the cart at priority 60 shows a stale count or an empty dropdown. That is the cart fragments script and a page cache disagreeing, which the Storefront speed guide covers in depth. If the cart page itself refuses orders, go to WooCommerce checkout not working.

Rebuilding the masthead in seven checks

1. 1

   Read the source, not the screen

   View the page source logged out and search for masthead, site-branding, site-navigation and site-header-cart. Markup present means a styling problem; markup absent means nothing printed it.

2. 2

   Confirm WooCommerce is active

   Check the Plugins screen. If WooCommerce was just updated, look for an update notice or a database update prompt waiting in the dashboard.

3. 3

   Read the error log

   Set WP_DEBUG and WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false, reload the page, then read debug.log for a fatal error naming a header callback. A blank page is covered in white screen of death.

4. 4

   Preview the parent theme

   On a staging copy, activate plain Storefront. If the header returns, the cause is the child theme or a customization plugin.

5. 5

   Audit every storefront_header call

   Search the child theme and customization plugins for storefront_header. Check that removals run on init, carry the right priority and come in opener and closer pairs.

6. 6

   Check Customizer, Header

   Compare the background, text and link colors, and preview without the header image to rule out text hidden against it.

7. 7

   Purge and compare

   Clear the page cache, the host cache and the CDN, then compare the logged-out view on a desktop and a phone.

Header edits that survive the next update

WooCommerce's own child theme documentation recommends keeping snippets in a customization plugin rather than editing theme files, and Storefront's functions.php ends with the same advice. Whichever home you choose, keep every header change in one function hooked to init, with a comment beside each removal naming its priority and the reason it exists. The next developer will thank you, and so will the one after that.

• Move items as a pair of calls in one place: remove the cart at 60, then add it back at its new priority in the same function.
• Prefer filters such as storefront_menu_toggle_text and storefront_header_styles over redefining whole functions.
• After each Storefront update, open header.php and the two hooks files and compare the priorities with your notes. In 4.6.2 they match the table above.
• Test header changes on staging once with WooCommerce active and once without it, so the shop-only parts never surprise you.

Our theme repair team untangles child themes like this on a copy of the store, and WooCommerce website repair handles faults that reach past the header into orders. If style edits refuse to appear after the fix, Storefront CSS not updating is the companion checklist, and shop pages that came apart at the same time belong to Storefront WooCommerce layout broken.

When every header change needs a PHP developer

Storefront's hook queue is a fine design for a developer and an opaque one for everyone else. Moving a search box means PHP; hiding a cart means knowing it lives at 60. The Storefront review credits that flexibility, and the general WordPress header not showing guide shows how other themes hand the same job to builders and template parts, with their own ways of failing. More guides sit in the troubleshooting section.

In a Next.js build the header is one layout component, and a change to it is reviewed and tested before release. Staff editing in Athena CMS change menu items and banners in plain fields without touching the layout. That costs more to build and needs a developer for structural changes. Storefront vs Next.js sets out when it pays, and Storefront to Next.js maps the move.