Missing WordPress scripts: restore wp_head() and wp_footer() in the theme

Connect missing resources to the template displaying the page

A WordPress page displays, but several elements no longer work: the menu does not open, a component remains empty, and styles have disappeared. If these resources are missing only from one family of pages, check the template producing them. It may have omitted a point where WordPress and plugins add their code to the document.

In a classic theme, core functions trigger actions, also called hooks. The theme calls wp_head() in the document’s head section, then wp_footer() before the end of body. Components attached to these actions may print resources or other information there. If an action is missing, several apparently unrelated functions may fail together.

This guide targets the public page of a self-hosted WordPress using PHP templates, with file access for the developer or operator. An administrator with only the content editor can gather evidence without touching code. The repair must restore intended resources on the faulty template and preserve functionality on previously healthy pages.

Check whether the browser receives a loading instruction

Before opening the theme, choose a failing page and a comparable working page. The best control uses the same component under similar conditions: the same login state and component settings. A plugin loading its script only on a particular page may explain a normal difference.

The Network tab shows what the browser attempts to load. Received source shows what the server delivered, while the element inspector may already include JavaScript changes. Examine both according to the question. A file explicitly requested and then refused with 403 or missing with 404 primarily requires checking its request. An expected resource absent from both document and requests calls for tracing its generation.

1. On both pages, open browser tools, Network tab, then reload.
2. Search for the name of a script or stylesheet associated with the component and record its state.
3. Compare response source around the end of head and body.
4. Keep a control URL and a resource normally expected to load. Do not conclude from a single missing name.

Identify the file actually used for this URL

In Appearance, then Themes, record the active theme and its parent if it is a child theme. Then identify the failing page type. The homepage, a page with a chosen template, an archive, and a not-found page may use different files. A page’s editor may show its assigned template, but does not necessarily show every PHP file included in rendering.

In release sources, trace the template corresponding to the URL and calls loading its shared parts. A named get_header call may look for a variant such as header-landing.php, while an unnamed call targets header.php. The same principle applies to get_footer. Check the variant and any fallback, then whether a child override exists.

A file containing the correct call is insufficient if the page follows another route. Also look for an early return or condition preventing the footer from being reached. If only a landing page is affected, start with its variant. If several page types share the failure, look for the shared part actually used.

Prepare a correction on a representative copy

Work in theme sources controlled by the team or in a private copy reproducing the failure. Record the WordPress version, parent- and child-theme versions, and template name. A copy serving another template or lacking the same plugins is not a good control. Choose an action without external effects for browser checks, such as opening a menu.

Before editing, keep the initial file and identify the deployment or restoration mechanism. If the theme comes from a publisher, ask whether the current version already corrects the omission. Directly modifying a third-party parent theme risks being overwritten by an update and complicating support follow-up.

1. Associate each control page with the file opening or closing its document.
2. Check that the call is actually missing along this route and does not exist elsewhere in the same document.
3. Back up the files and prepare a correction limited to these points.
4. Choose the planned rollback: restore the previous file or return to the previous release.

Restore wp_head() at the end of the HTML head

In a classic template writing its head, locate the closing </head> in the active file. This may be header.php, a variant, or the standalone template itself. Add only the missing call immediately before that tag. The rest of the document, including meta tags and theme styles, must remain in place.

The excerpt shows the expected position when the file is in HTML mode at that point. The closing tag is normally already present: do not add a second one. If the file is already inside a PHP block there, insert only the wp_head(); statement before returning to HTML. Do not put the call in functions.php, a content block, or a function running too early.

Then check the page response on the copy. Expected head tags must be able to appear exactly once; choose a resource whose loading condition you know. If the template already calls wp_head() in an included part, do not call it again here: instead investigate why the resource is not registered or was removed.

<?php wp_head(); ?>
</head>

Restore wp_footer() at the end of the document body

Locate the file closing the HTML body. The visible footer is not necessarily that file: a component may display the final banner without closing body, and a template may close body without displaying a banner. Place the insertion point before the actual body closing tag, after content and parts already displayed. This restores, among other things, the ability to print footer scripts.

On the copy, add only the missing call. As with the head, do not duplicate the closing tag or PHP markers if the statement is already being inserted into PHP. If the page never reaches this point because of a conditional branch, first correct its route. Moving the call into the middle of content can mask the defect and execute the same hook in two places.

The wp_body_open() call corresponds to a third point, immediately after body opens. Check it if an integration requires it; it replaces neither wp_head() nor wp_footer(). Keep roles and locations distinct when comparing the structure with a working page.

<?php wp_footer(); ?>
</body>

Connect a standalone template to shared parts

A page may use a PHP file rewriting the entire HTML wrapper while the rest of the theme relies on correct shared parts. Compare sources before adding functions one by one. If this template was meant only to change the central area, connecting it to the existing header and footer may be more sustainable.

In the theme directory, generally under wp-content/themes, open the assigned template’s PHP file. Check that the parts to reuse already contain the necessary calls and accept your page structure. In the template’s PHP code, call get_header() before content and get_footer() after it, preserving the loop and template-specific elements. If the theme uses a variant, retain its intended name and parameters. Remove only the redundant wrapper now produced by these parts.

1. Identify which tags and areas the shared parts produce.
2. Connect the template on the copy without retaining a second document inside the first.
3. Check resources and rendering of the menu, content, and footer.
4. If the template was intended to remain minimal, return to the backed-up file and restore only the necessary insertion points.

Choose a lasting repair for a third-party theme

If a corrected version is available from the publisher, compare its file with your template and test that version on the copy. Check that a child override does not continue replacing the corrected file. A parent update does not automatically repair an old file still present in the child.

When no corrected version is available, a targeted child-theme override may suit a file loaded through the template lookup mechanism. For an existing child theme, back up its variant and apply only necessary changes. If the file is included through a fixed parent path, copying a same-named file into the child may have no effect: have that loading adapted or request a publisher fix.

Creating and activating a new child theme can change other site aspects depending on configuration. Check menus and customizations on the copy before choosing this approach. If it requires more changes than the fix, prefer a maintained theme version or rollback to an already validated release. Keep the previous file available until checks agree.

Distinguish a missing hook from a resource not registered with it

If calls are present and reached, the cause may lie elsewhere. On the public site, wp_enqueue_scripts is the action intended for registering styles and scripts. A component may limit loading to a page type, have custom code remove a file, or depend on optimization transforming output. Check the affected component’s conditions before editing the theme again.

An ordinary block theme follows another route. Its HTML template files and parts visible in the Site Editor are not the entire PHP wrapper. WordPress normally produces this wrapper and calls the functions there. Do not paste PHP into a block template or a Custom HTML block. If a plugin replaces the wrapper, have the code actually producing the page identified before any correction.

A comparative test can help when files do not settle the question: on the private copy, reproduce the same function with an already available compatible theme under comparable conditions. Then restore the initial theme. A different result narrows investigation to theme rendering or its conditions without proving by itself that an insertion point is missing.

Check syntax and apply the targeted fix

On a copy, review differences before trying the page. The fix should touch only the file that did not execute the hook, or the few files necessary for connection to shared parts. Check that you have neither moved content, left a tag open, nor added a second call in a shared part. Do not modify WordPress core.

If you already have a development terminal, check each modified PHP file using PHP compatible with hosting. Replace the fictional command path with your copy’s path. The -l option checks syntax without executing the template; it does not indicate that this file is selected or the menu works. If PHP reports an error, correct the file before deploying.

Once the copy validates the correction, use the site’s release process and keep the previous version. Perform a targeted cache update only if the public response still serves an old page copy. A general purge does not activate a file deployed to the wrong theme.

php -l "/chemin/de/la-copie/wp-content/themes/mon-theme/header.php"

Check that browsers and visitors regain expected behavior

Revisit the URL and resource recorded initially under the same login conditions. The expected result has two parts: the required resource arrives or expected code is present in the response, and observed behavior returns. A script may reappear but then be blocked; a button may seem restored thanks to a version still loaded in memory. Check both aspects.

If the correction prints the same component twice, inspect inherited calls and the page file. Two similarly named resources are insufficient to prove duplication; compare their URLs and roles. If the fix triggers a PHP error or breaks rendering on other pages, return to the saved file or release before resuming diagnosis.

1. Check the failing and control pages, then at least one other page using the same shared part.
2. Compare source and requests for the chosen resource.
3. Repeat the intended interaction without triggering a real send.
4. Check new errors and neighboring-page rendering.
5. If rolling back, repeat the same reads to confirm that the previous version is actually being served.

Prevent a new template from omitting the same points

When a developer creates a page very different from the rest of the site, encourage reuse of shared parts if they meet the need. A minimal template may retain its own document; in that case, review must check its insertion points and their positions, along with branches bypassing their execution. A check limited to the homepage will miss a rarely used variant.

For a child theme, keep a note of each template override and its justification. Compare these files after a parent update. If the maintained version incorporates the correction, check whether the now-unnecessary override can be removed without losing other customizations. Test removal on a copy like an ordinary change.

If you lack source access, give the owner the URL, page type, presumed template name, expected resource, and observed differences. This lets them check the correct file without searching blindly. No additional optimization module is needed to restore an insertion point. When resources are present but behavior remains broken, continue instead with browser errors and the responsible component.

Check syntax, execution route, and behavior separately

Fix validation consists of three pieces of evidence. php -l checks that the modified file can be parsed. The HTML response then proves that the correct template variant produces the expected resources. Finally, browser interaction confirms that the component can use them. Success at the first stage does not cover the next two.

Choose three controls: a page using the faulty variant, a healthy page sharing a common part, and a page using another template. For each, record the expected resource, its presence in the document, and network status. Check an interaction without external effects, such as opening a menu, at the same screen width.

If the resource reappears but returns 404, the omitted hook may have been repaired while exposing a second path problem. If it arrives correctly but a JavaScript error remains, continue with the component; do not add a second wp_footer() to try to restart it. Tags must not be duplicated in a shared part and its calling template.

The native repair restores the insertion point in the theme or reuses its correct shared part. A cache or snippets plugin does not replace this structural location. After deployment, check the three controls as a visitor. If a regression appears, restore only the saved file or release, then confirm that the public response actually uses that restored version.