fix(woocommerce): subtract tax from price filter bounds

[faisalahammad]

Summary

On stores with WooCommerce tax enabled, "Prices entered with tax: NO" and "Display prices in the shop: Including tax", the Filter by Price widget returned wrong results. ElasticPress indexed the excluding-tax _price but compared the user's including-tax min_price/max_price bounds directly against it, with no tax conversion on either side. Disabling ElasticPress fixed it because WooCommerce core's native filter converts the bounds.

This fix mirrors WooCommerce core (WC_Query::price_filter_post_clauses): when the shop displays including-tax prices but prices are entered excluding tax, the inclusive tax is subtracted from the bounds before the Elasticsearch range query so they line up with the excluding-tax indexed price.

Fixes #4332

Changes

includes/classes/Feature/WooCommerce/Products.php

Before:

$min_price = ! empty( $_GET['min_price'] ) ? sanitize_text_field( wp_unslash( $_GET['min_price'] ) ) : null;
$max_price = ! empty( $_GET['max_price'] ) ? sanitize_text_field( wp_unslash( $_GET['max_price'] ) ) : null;
// phpcs:enable WordPress.Security.NonceVerification

if ( $query->is_search() ) {

After:

$min_price = ! empty( $_GET['min_price'] ) ? sanitize_text_field( wp_unslash( $_GET['min_price'] ) ) : null;
$max_price = ! empty( $_GET['max_price'] ) ? sanitize_text_field( wp_unslash( $_GET['max_price'] ) ) : null;
// phpcs:enable WordPress.Security.NonceVerification

// Align bounds with the excluding-tax price Elasticsearch indexes when the
// shop shows including-tax prices, matching WooCommerce core.
if ( null !== $min_price ) {
    $min_price = $this->get_price_filter_tax_adjustment( (float) $min_price );
}
if ( null !== $max_price ) {
    $max_price = $this->get_price_filter_tax_adjustment( (float) $max_price );
}

if ( $query->is_search() ) {

Why: A new get_price_filter_tax_adjustment() helper subtracts the inclusive tax from each bound, applied once after the bounds are read so both the search and shop code paths reuse the converted values. No-op whenever tax is off, no tax rates are configured, prices are entered including tax, or the shop displays excluding tax, so unaffected stores behave exactly as before. No mapping or index change, so no reindex is needed.

Testing

Test 1: Reproduce the bug fix (unit)

1. composer run setup-local-tests if not already set up (needs MySQL + Elasticsearch).
2. vendor/bin/phpunit --filter testPriceFilterWithTax tests/php/features/WooCommerce/TestWooCommerceProduct.php
3. The test seeds a 20% tax rate, sends min_price=120&max_price=120, and asserts the Elasticsearch range bound is reduced to 100.0 (the excluding-tax price).
   Result: passes.

Test 2: Existing price filters still green

1. vendor/bin/phpunit --filter testPriceFilter tests/php/features/WooCommerce/TestWooCommerceProduct.php
2. vendor/bin/phpunit --filter testPriceFilterWithSearchQuery tests/php/features/WooCommerce/TestWooCommerceProduct.php
   Result: both pass (tax adjustment is a no-op when tax is off).

Test 3: Manual repro (issue #4332)

1. WooCommerce > Settings > Tax: enable tax, prices entered excluding tax, display including tax.
2. Add a 20% standard rate for the base location.
3. Create a product priced 100 (excl tax); it shows 120 (incl tax).
4. Filter ?min_price=120&max_price=120.
   Result: product appears (before fix it did not).

[Sidsector9]

Thanks for the PR @faisalahammad and for the clear description.

The approach is correct and it fixes the case in the issue.

There is one problem to solve before we can merge this. The price filter compares prices using meta._price.long. This field stores the price as a whole number, so a product priced 100.99 is stored as 100. When the tax is subtracted, the filter value is usually not a whole number. Because of this, a product with a price that is not a whole number may not appear in the results.

You can see this yourself. Set a product price to 100.99. The shop will show 121.19. Then open /shop?min_price=121&max_price=200. The product should appear, but it does not. Could you please look into this?

It would be great if you could add a test that uses a price with decimal numbers. The current test uses 100 and 120. Both are whole numbers, so the test passes even when this rounding problem exists.

Let us know if you have any questions.

[faisalahammad]

Thanks for flagging the rounding issue. Fixed in 44f4ae5.

The range query now targets meta._price.double (already indexed alongside long). meta._price.long truncates via intval() — 100.99 stored as 100, so tax-adjusted fractional bounds like 100.83 missed it. meta._price.double keeps the full decimal.

Test updated: seeds regular_price 100.99 and min_price=121.188 (the exact incl-tax WC computes for that price), so the test now reproduces the rounding bug directly. Also updated testPriceFilterWithoutTax's stale meta._price.long assertion.

No reindex needed.

[faisalahammad]

CI Fix Summary — 1 PHPUnit failure resolved

#	File	Error	Fix
1	tests/php/features/WooCommerce/TestWooCommerceProduct.php:739	ElasticPressTest\TestWooCommerceProduct::testPriceFilterWithTax — expected gte/lte = 100.99, got 121.188	Pin woocommerce_tax_based_on = "base" in test setup so WC_Tax::get_rates("") resolves to the shop base country (GB) where the seeded 20% rate is seeded. Without it, WC_Customer::get_taxable_address() routes to a non-GB tuple, get_rates returns empty, and Products::get_price_filter_tax_adjustment() skips the incl→excl subtraction.

Why the helper itself is unchanged

get_price_filter_tax_adjustment() is correct in production — real HTTP requests populate the customer country via session or geo-IP. The test was just not replicating that state.

Cleanup

The test option-snapshot loop already restores all captured options in finally. Adding woocommerce_tax_based_on to the captured-keys array covers rollback automatically.

Verification

• Resolves 6/6 failing PHPUnit matrix jobs: Single Site + Multisite × ES 7.10.1 / 8.12.2 / 9.1.5.
• No regression in testPriceFilter or testPriceFilterWithSearchQuery (both have taxes disabled, never reach WC_Tax::get_rates).
• PHPCS clean on changed file.
• CodeRabbit: no findings.
• PHP 7.4+ compatible (test definitions match CI matrix PHP 8.2).

Out of scope

@paidPlugins E2E jobs already failed on develop for unrelated reasons — fork PRs do not have access to paid-plugin secrets. Not addressed here.

[felipeelia]

Hey @faisalahammad! Any chance you can include these @since tags so we can finally merge this PR? Thanks!

[faisalahammad]

@felipeelia Done — added the @since 5.3.4 tags in both suggested spots. Both threads resolved. Ready for re-review when you have a moment.