Search form input field missing from server-rendered HTML

Important note

To avoid negative customer experience I’ve had to revert our header’s search bar from advanced woo search to default wordpress/astra theme search. So if you visit https://themirrorman.uk/ – you won’t actually be able to see the problem in action.

Summary

On desktop requests, the plugin’s search form renders its wrapper (label, clear button, loader) but never outputs the actual <input> field — not just visually, it’s missing from the raw server-rendered HTML entirely. Mobile requests render correctly, with the input present. This reproduces across every plugin version I’ve tried (3.63, 3.64, and whatever was current at 3.65/3.66), with Seamless Integration both on and off, and using the plain [aws_search_form] shortcode directly. I don’t believe this is a caching, theme, or hosting issue — details below.

Environment

• Advanced Woo Search: tested 3.63, 3.64, and the version prior to rollback (3.66)
• WooCommerce: 10.9.1
• Theme: Astra + Astra Pro
• WordPress: 7.0
• PHP: 8.2.30
• Hosting: LiteSpeed Web Server, LiteSpeed Cache plugin active

Steps to reproduce

1. Place the form via shortcode: [aws_search_form] inside a plain HTML block in the header (Seamless Integration setting: Off).
2. Load the site as a normal desktop visitor (no special cookies, fresh/incognito session).
3. View page source (not DevTools Elements — the raw HTTP response) and search for aws-search-field.

Expected: the <input type="search" name="s" ... class="aws-search-field search-field"> element is present in the response body.

Actual: only this renders inside .aws-wrapper:

<div class="aws-wrapper">
  <label class="aws-search-label" for="...">Search TheMirrorMan.uk</label>
  <div class="aws-search-clear"><span>×</span></div>
  <div class="aws-loader"></div>
</div>

No <input> at all. The parent .aws-container shows data-is-mobile="false" on every broken request. On requests where data-is-mobile="true", the same markup includes the full input correctly:

<div class="aws-wrapper">
  <label class="aws-search-label" for="...">Search TheMirrorMan.uk</label>
  <input type="search" name="s" id="..." value="" class="aws-search-field search-field" placeholder="Search TheMirrorMan.uk" autocomplete="off" />
  <input type="hidden" name="post_type" value="product">
  <input type="hidden" name="type_aws" value="true">
  <div class="aws-search-clear"><span>×</span></div>
  <div class="aws-loader"></div>
</div>

What I’ve ruled out

• Caching: reproduces on a fresh, no-cache, anonymous fetch()/curl request straight to the server, immediately after purging LiteSpeed page cache and recycling PHP/LSAPI workers.
• Client-side JS / DOM manipulation: confirmed via raw HTTP response body (not the live DOM after JS runs) — the input is absent in what the server sends, before any JS executes.
• Seamless Integration: reproduces identically with Seamless Integration off, using the plain [aws_search_form] shortcode directly in a static HTML block.
• Plugin version: reproduces on 3.63, 3.64, and 3.66 (rolled back through each via WP Rollback).
• Theme/header markup: reproduces in the exact same way regardless of whether the form is placed via Seamless Integration’s auto-replacement or a hardcoded shortcode.
• Browser/device/network: reproduces across two different machines on two different networks (local desktop + a separate VPS), in normal and Incognito sessions, and via plain curl with no browser involved at all.
• DNS/CDN/WAF in front of the origin: server-side curl from localhost on the host itself shows the same broken output.

My read

This looks like the plugin’s shared search-form-wrapper renderer has an is_mobile-gated branch that skips emitting the <input> element on “desktop” requests, likely expecting a companion JS step to inject it afterward — but I can’t find that companion step actually running (no relevant reference in common.min.js, no console errors, no matching hook in your public JS Hooks Reference). Whatever that companion mechanism is supposed to be, it isn’t firing, and the desktop search box is left completely non-functional as a result.

Happy to provide a live reproduction URL, HAR file, or any further diagnostics you need.

• This topic was modified 2 weeks, 3 days ago by zhayter88.