If a custom customer label disappears while testing WooCommerce 11.3, inspect callbacks attached to woocommerce_json_search_found_customers. The selected registered customer on an order-edit screen is keyed by user ID, not necessarily numeric key zero. A callback that reads only element zero can miss a valid customer.
This is beta compatibility guidance checked October 28, 2026. Test on synthetic orders. A blank display is not permission to reassign a customer's order or overwrite billing information.
Find the callback before changing the order
Search your custom plugin, active theme and must-use plugins for the filter name. If terminal access is available from the WordPress project directory, a read-only search is enough:
rg -n 'woocommerce_json_search_found_customers' wp-content/plugins wp-content/mu-plugins wp-content/themes
Inspect what each matching callback expects and returns. Look for direct access to [0], array reindexing, and code that assumes every result is a registered customer. A search result map can contain several customers; a selected-customer map may contain only one, but its key still has meaning.
The upstream compatibility change brings the selected registered-customer shape into line with AJAX search. Guest handling remains a separate case. Do not replace the map with a flat string simply because one label is visible.
Read values without destroying identity
For a display-only calculation, current() can retrieve the first value without requiring a particular numeric key. Handle false or an empty label before calling string functions. If the integration needs identity, use the actual map key and validate it for the current case.
When transforming every label, preserve each key. Rebuilding the result with array_values() can discard the customer IDs the consumer needs. A callback that makes the label prettier but changes the map's identity contract is not a safe fix.
| Callback purpose |
Requirement |
| Read one display label |
Do not assume key zero; handle empty results |
| Decorate search labels |
Preserve all original keys |
| Retrieve customer identity |
Validate the returned key, not label text |
| Process guest order |
Do not interpret the guest placeholder as a registered user |
Illustrative payload shapes explain why preserving array keys matters independently of the displayed label.
Test search and selected state separately
Create an artificial registered customer and assign one sandbox order to that customer. Create a second guest order. Open the registered order, search for the same customer, save without changing ownership, and reopen. Confirm the selected label and persisted customer ID agree throughout.
Repeat with the guest order. An empty guest label can be expected; a PHP warning or an automatic assignment to the first search result is not. Do not use real customer names or email addresses in debug screenshots.
For multisite integrations, add a fixture for a network user who is not a member of the current site. Record the site's identity and expected unavailable-user behavior. Do not expand memberships merely to make the label look normal.
Isolate a renderer failure from a permission failure
A blank label with otherwise functioning administration differs from an entire screen failing. If PHP reports a fatal error, follow its file and stack before applying an array-key patch. The PublishPress Future Scheduled Actions failure is an example of a different update issue that needs a different repair.
Keep diagnostics limited to array keys, types and synthetic labels. Logging the full customer search response can expose personal data. Remove temporary logging after the fixture passes.
For approval, compare stored order customer IDs before and after, not just the screenshot. Send a developer the callback, installed build and failing fixture. A focused WooCommerce compatibility review should preserve ownership while correcting the display contract.
Sources checked October 28, 2026. Synthetic fixtures and diagrams illustrate the proposed checks; they are not claims of customer testing.