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 Place the form via shortcode: [aws_search_form] inside a plain HTML block in the header (Seamless Integration setting: Off). Load the site as a normal desktop visitor (no special cookies, fresh/incognito session). 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 3 days, 18 hours ago by zhayter88 . Hi, Thanks for detailed overview of this issue. I was able to reproduce the same error. What I found is that when adding search form as Widget block that problem not appears. So for you to quickly fix this issue it is the best solution. Also I was thinking to add AWS search bar as additional widget for Astra header builder – perhaps this will be the best solution. Regards Hi Mihail I am glad you were able to reproduce the issue and thanks so much for looking into this so quickly. I have now added AWS search as a widget block there instead as a temporary fix and it works. Adding AWS search bar as additional widget for Astra header builder sounds awesome! If you release this feature I will test it and let you know how it goes. Would be great if the shortcode version could also be fixed as I imagine many other sites are having the same issue, and my current setup is all geared to using the shortcode. Thank you so much. Yes, I will think about fixing that html issue too but thinking that having built-in Astra header widget will solve that problem alone.