Hi @whitelamp!
I understand the issue you’re reporting. When searching orders, the initial request includes the _wp_http_referer and _wpnonce parameters, returns the full Orders page, and then performs a 302 redirect to remove those parameters. This results in the order search request effectively being processed twice and can add unnecessary load and delay.
The redirect in PageController.php is intended to clean up the URL and prevent the _wp_http_referer and _wpnonce parameters from accumulating in the URL over time. These parameters are related to WordPress request/security handling rather than tracking how users interact with the Orders page.
I tested this behavior on my side and found that the same _wp_http_referer and _wpnonce parameters, followed by a 302 redirect to remove them, also occur when performing searches on other WordPress admin pages outside of WooCommerce.
The strip_http_referer() code you found is actually WooCommerce’s fix for the side effect of this — it redirects to a clean URL afterward (mirroring what WordPress core itself does on wp-admin/edit.php), so the nonce/referer don’t keep accumulating in bookmarked or shared links over time.
The practical impact is a single extra redirect per search submission not an ongoing performance cost. Once you land on the clean URL, further actions on that page (pagination, sorting, etc.) won’t trigger it again.
Since this comes from how WordPress core builds admin list-table forms, there isn’t a supported way to remove the nonce field from the search submission without custom code (e.g., JS to strip the field before the form submits), which isn’t something we can implement or recommend as part of core support it would also affect the security of the bulk actions on that same form.
I hope this helps.
“it redirects to a clean URL afterward”. Why not *before*? What is the point of the nonce and referrer if the user then loads a page without them? Anyway, I have added a few lines of code to the /wp-admin/admin.php to intercept searches on “page=wc-orders” and generate the 302 URL myself and redirect immediately.
Hi @whitelamp!
Thanks for the follow-up and for sharing the workaround you’ve implemented.
The behavior you’re asking about is controlled by WordPress core’s admin request and list-table handling rather than WooCommerce itself. WooCommerce follows the same general pattern used by WordPress for admin list-table forms, including the handling of the nonce and referrer parameters.
Since your question is specifically about why WordPress processes these parameters and performs the redirect after the initial request, I’d recommend reaching out to the WordPress support team for further clarification on the core behavior.
Regarding the changes you’ve made directly in /wp-admin/admin.php, please keep in mind that modifying WordPress core files is not recommended, as those changes can be overwritten during WordPress updates and may have unintended effects on other admin functionality.
From the WooCommerce side, we can certainly help investigate any WooCommerce-specific performance issue or unexpected behavior resulting from the standard request flow.
Thank you for your cooperation and understanding.
I am aware of the issues with modifying core files – if there’s a template I could override or a hook available to add some javascript to remove these hidden inputs client-side I would go down that route – can you tell me where to find such a thing? In the meantime I will just re-apply these mods as required.
I have found another inefficiency in the search. My slow query logs show a query beginning with “SELECT wp_wc_orders.id FROM wp_wc_orders LEFT JOIN wp_woocommerce_order_items AS search_query_items ON search_query_items.order_id = wp_wc_orders.id WHERE” and ending in “LIMIT 0,50” as I am doing 50 items per page. This can take over five seconds. This is followed by the same query but beginning with “SELECT COUNT(DISTINCT wp_wc_orders.id) FROM wp_wc_orders” and without the limit. This appears to be so that the results page can show the total number if more than 50 and provide pagination. But if the first query returns less than 50 results the second is utterly pointless! Is this also part of core WordPress?
Hi @whitelamp!
Thanks for your cooperation and understanding.
For the JavaScript customization, you can try conditionally enqueueing your script using the standard WordPress admin_enqueue_scripts hook. This can allow you to load your custom JavaScript only on the relevant admin screen and remove the hidden inputs client-side.
Since implementing and troubleshooting custom JavaScript or modifying the WooCommerce admin interface falls outside the scope of our support, we’re unable to provide detailed guidance or custom code for this. If you need assistance implementing this safely, you can consider hiring a WooCommerce developer through Codeable, which specializes in WordPress and WooCommerce development.
Regarding the additional COUNT(DISTINCT) query, based on the details you’ve provided, this appears to be related to WooCommerce’s HPOS order querying logic, specifically the OrdersTableQuery found-rows/count handling we discussed.
If you’d like to have this investigated by the WooCommerce development team, you can submit a report through the official WooCommerce GitHub Issues. Please include the relevant slow queries, WooCommerce version, HPOS status, and steps to reproduce the behavior.
Thank you.
