WooCommerce 11.2 introduces faster range-based product reordering for large catalogs and starts deprecating older ordering hooks. According to the developer advisory, use of deprecated hooks can trigger the legacy algorithm, which reindexes the complete catalog and can multiply queries, cache churn, and downstream callback work.
Use this for stores with manual product sorting, category merchandising, feed generation, search indexing, custom order columns, large catalogs, or extensions attached to WooCommerce ordering hooks.
Quick answer
Scan custom code for woocommerce_after_single_product_ordering and woocommerce_after_product_ordering. Record what each callback actually needs, then benchmark moving one product near the start, middle, and end of a realistic staging catalog. Compare optimized and fallback paths for affected IDs, SQL count, duration, locks, cache deletes, callback count, search and feed jobs, and public order. Replace deprecated behavior with the new moved-products or reindexed-products hooks only after the side effects match.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Move one product | 10,000-item catalog | Range update only |
| Deprecated hook | Legacy callback active | Fallback measured |
| Concurrent sort | Two administrators | Consistent final order |
| Interrupted request | Timeout after write | Recoverable sequence |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Find deprecated ordering hooks | Inventory deprecated and new ordering callbacks, priorities, arguments, catalog scopes, downstream jobs, cache keys, and whether the callback needs moved or fully reindexed products. | The intended products move and every untouched product retains a consistent relative order. |
| Classify moved versus reindexed needs | Clone a realistic catalog size and record product IDs, menu_order values, category membership, visibility, translations, variations, and current public sequence. | Deprecated callbacks no longer force the legacy algorithm after their side effects are migrated. |
| Benchmark both algorithms | Move products near the start, middle, and end, reorder across category views, and force the deprecated-hook fallback for a measured comparison. | Search, feeds, caches, and storefront sorting reflect one completed reorder event. |
| Migrate callback side effects | Capture request duration, SQL count, updated rows, locks, cache invalidations, callback counts, queue jobs, search index updates, feed output, and storefront order. | Interrupted or concurrent requests recover without duplicate positions, missing products, or repeated jobs. |
What to check first
- Inventory deprecated and new ordering callbacks, priorities, arguments, catalog scopes, downstream jobs, cache keys, and whether the callback needs moved or fully reindexed products.
- Clone a realistic catalog size and record product IDs, menu_order values, category membership, visibility, translations, variations, and current public sequence.
- Move products near the start, middle, and end, reorder across category views, and force the deprecated-hook fallback for a measured comparison.
- Capture request duration, SQL count, updated rows, locks, cache invalidations, callback counts, queue jobs, search index updates, feed output, and storefront order.
- Test interruption, browser retry, two administrators, a long callback, and rollback so partial ordering cannot leave duplicate or missing positions.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
rg -n "woocommerce_after_(single_)?product_ordering" wp-content/plugins wp-content/mu-plugins wp-content/themes
# Capture query count and callback IDs while moving one marked product.
# Compare the optimized and intentional fallback paths.
Why this usually happens
- A legacy hook fires once per product and requires the complete catalog to be reindexed.
- A callback assumes every product appears even though it only needs the moved IDs.
- Search and feed jobs are queued for each touched row instead of one reorder event.
- A timeout occurs after database writes but before the browser receives the final result.
Decision rule
Use the optimized reorder path when moved IDs, public order, and required side effects match the legacy result while query count, cache churn, and job volume stay within the written budget.
Production verification checklist
- The intended products move and every untouched product retains a consistent relative order.
- Deprecated callbacks no longer force the legacy algorithm after their side effects are migrated.
- Search, feeds, caches, and storefront sorting reflect one completed reorder event.
- Interrupted or concurrent requests recover without duplicate positions, missing products, or repeated jobs.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Find deprecated ordering hooks
- Classify moved versus reindexed needs
- Benchmark both algorithms
- Migrate callback side effects
- Test interruption and retry
Mistakes to avoid
- Changing production before recording exact versions, UTC time, the affected fixture, current behavior, and a tested rollback point.
- Accepting one successful admin screen while the stored record, API response, queue, email, browser, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, locale, network state, catalog size, and failure path a real user reaches.
- Leaving broad credentials, debug logs, temporary filters, synthetic records, or recovery code active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with current data, extensions, cache, browser mix, and integration settings. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I rule out a cache artifact?
Record the origin response, purge only affected paths, and repeat in private and normal sessions. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version and settings it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When is the test complete?
Close it when the main path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP benchmark catalog sorting.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references