On Sale Layered Navigation Filter for Magento 2

What you get

Key Features

Storefront

• Shop By → Sale Status option in layered navigation on category AND search-result pages
• "On Sale" and "Regular" options with configurable labels per store view
• Real counts next to each option (On Sale (12)) that exactly match the grid total post-click — scoped to the current category + visibility, never a global store-wide tally
• Stock-aware counts — when Display Out of Stock Products is No (Magento default), the (N) excludes OOS rows; when Yes, it includes them. Works identically in both modes.
• Cross-filter accurate — when Brand = Nike, Pattern, Color, Size, or Price range is already active, the "On Sale" count shows the intersection, not the category-wide total. Super-attribute filters on configurables (color / pattern / size on variants) resolve via catalog_product_index_eav + catalog_product_super_link so configurable parents matching at least one on-attribute child are counted.
• Accurate pager totals — Items 1-12 of 24 reflects the post-filter result even under the Elasticsearch-backed Fulltext\Collection
• Sort-aware — price asc/desc, name asc/desc, position — all honoured while the filter is active
• "Now Shopping by" chip with a one-click clear, integrated with Magento's standard active-filter UI
• Pagination-safe — filter state is preserved across ?p=2, ?product_list_limit=24, and any sort dropdown; sidebar count is invariant across pages

Discount detection

• Catalog price rules — all operators (by_percent, by_fixed, to_percent, to_fixed), dated rules, priority order
• Per-product special prices — with special_from_date and special_to_date awareness
• Tier prices that fall below the regular price
• Customer-group-specific pricing — NOT LOGGED IN, General, Wholesale, Retailer, or any custom group
• Parent aggregation — a configurable, grouped, or bundle is On Sale as soon as any eligible child is
• All product types — simple, configurable, grouped, bundle, virtual, downloadable

Indexer

• Dedicated indexer panth_salefilter_product appearing in System → Tools → Index Management
• MView subscriptions on catalog_product_entity_decimal, catalog_product_entity_datetime, catalogrule_product_price, catalog_product_relation, catalog_product_super_link, catalog_product_bundle_selection
• Two index modes — Update by Schedule (default, cron-driven, recommended for production) and Update on Save (synchronous, great for staging and debugging)
• Dated-discount aware — flips automatically at discount start/end time via Magento's nightly catalogrule_apply_all cron, no custom cron needed

Admin & Ops

• Admin index grid at System → Panth Infotech → Sale Filter Index (UI component, filters, column chooser, export)
• Columns: product id, SKU, type, website, customer group, regular price, special price, is-on-sale, updated-at, rule price, discount %, active catalog rules, match source (Catalog Rule / Special Price / Both)
• CLI helpers — bin/magento panth_salefilter:reindex and panth_salefilter:status
• Cache-friendly — invalidates panth_salefilter, block_html, and full_page tags on every change

Quality & Compliance

• MEQP-compliant — passes Adobe's Magento Extension Quality Program with zero severity-10 violations
• Declarative schema (db_schema.xml + whitelist)
• Zero third-party PHP dependencies — uses only Magento framework classes
• PHPDoc + strict types throughout

How It Works

1. Indexer Panth\SaleFilter\Model\Indexer\ProductIndexer walks every product × customer-group × website, resolves the effective "is on sale" flag (catalog-rule price vs special price vs regular), and writes a row into panth_salefilter_product_index.
2. MView subscriptions on the relevant upstream tables keep the index fresh without a cron run — product saves, rule re-applies, price changes all propagate through the changelog.
3. Layered-navigation plugin runs afterGetProductCollection on Catalog\Model\Layer\Category and Catalog\Model\Layer\Search. It intersects the index with the current category + visibility, stashes the ordered id list on the collection, and swaps Magento's SearchResultApplier for a filter-aware variant so the ES page slice is taken from the filtered list rather than narrowed by it after the fact.
4. getSize() plugin returns the pre-computed post-filter count so the toolbar pager shows N of true-total, not N of unfiltered.

Caching — Per Customer Group, Per Category, Per Filter State

The "On Sale" filter shows different counts to different customer groups (a Wholesale customer's discount is not a Retailer's discount). Cached naively, the first visitor's view would be served to everyone — wrong counts, missing options. This module solves it with two well-known Magento hooks plus a multi-frontend tag invalidator.

The smart label — Block/LayeredNavigation/FilterRenderer.php

FilterRenderer extends Template and implements IdentityInterface. Two methods do all the work:

• getCacheKeyInfo() — returns an array Magento hashes into the block-cache key. We mix in store id, website id, customer group, currency, current category id, and the active sale_filter URL param. Each unique combination gets its own cached HTML fragment, so a Guest never sees a Wholesale-warmed render.
• getIdentities() — returns the cache tags stamped on every cached entry: cat_p (catalog product) and panth_salefilter (our own). Whenever a product or catalog rule changes, we clean by these tags and only matching entries are evicted — surrounding pages stay warm.

Critical: customer group is read from HttpContext, not CustomerSession. Magento's DepersonalizePlugin wipes the session to guest before cacheable blocks render, so the session would always lie. HttpContext is the only safe source.

The trigger — Observer/CatalogRuleSaveAfter.php

Wired in etc/events.xml to four events:

• catalogrule_rule_save_commit_after / catalogrule_rule_delete_commit_after
• catalog_product_save_after / catalog_product_delete_after

We listen on _save_commit_after (not _save_after) for rules because Magento's catalog-rule save runs a commit callback that rebuilds catalogrule_product_price after the transaction. Listening earlier would race the rebuild and reindex against stale data.

The observer reindexes (in realtime mode only — schedule mode lets cron catch up) and then calls the cache invalidator unconditionally.

The cleaner — Model/Cache/TagInvalidator.php

Why a dedicated class instead of CacheInterface::clean()? Because some installs put the default and page_cache (FPC) frontends on different Redis databases. CacheInterface::clean() only touches the default frontend → FPC stays stale. Cleaning by cache type (full_page) is the opposite mistake — it nukes every FPC entry in the store and tanks hit rate.

TagInvalidator::invalidate() iterates Cache\Frontend\Pool (which enumerates every configured frontend) and calls clean(MATCHING_ANY_TAG, [cat_p, panth_salefilter]) on each. Surgical, safe across split Redis setups, and defensive — a single backend failure never stops the others.

The Magento 2.4.7 FPC fix — Plugin/Framework/App/PageCache/IdentifierGroupAwarePlugin.php

Magento 2.4.7 moved FPC identifier logic to IdentifierForSave, which keys only on $context->getVaryString(). That string is empty at LOAD time because the customer ContextPlugin runs on beforeExecute (during dispatch) while FPC load happens earlier in aroundDispatch. Net effect: whichever user warms the cache for a URL dictates what every other user sees on the built-in FPC. A guest-warmed category page hides the "Yes" option for logged-in General / Wholesale / Retailer shoppers.

This plugin's aroundGetValue() reads X-Magento-Vary straight off the incoming request cookie (the pre-2.4.7 behavior) and mixes it into the cache key, so each group ends up with its own FPC entry. The cookie is stable from request arrival to response dispatch, so LOAD and SAVE produce the same key within a single request.

Wired in etc/di.xml against both Identifier and IdentifierForSave because Magento injects them separately for load vs save — patching only one gives mismatched keys and zero cache hits.

Reading order

Admin Index Grid

System → Panth Infotech → Sale Filter Index — a UI-component grid over panth_salefilter_product_index. Useful for debugging a specific product or diffing the catalog after a rule change.

Grid filters include on-sale only, match source, and an applicable rules text filter.

Indexing

panth_salefilter_product appears in System → Tools → Index Management:

Modes

• Update by Schedule (default) — MView changelog captures changed product ids, Magento's indexer_update_all_views cron (runs every 1 minute by default) processes them. Recommended for production.
• Update on Save — observers fire reindexRow inline on every relevant save. More DB writes during imports, but the storefront reflects changes instantly. Great for staging and debugging.

Switch modes from the Index Management grid (Actions → Update Mode) or via CLI:

bin/magento indexer:set-mode schedule panth_salefilter_product
bin/magento indexer:set-mode realtime panth_salefilter_product

Dated Discounts — When Does the Index Refresh?

Our indexer is event-driven, not polling. Three triggers keep it fresh:

1. Immediate — save observers

When you save a product or a catalog rule, CatalogRuleSaveAfter fires:

• Update on Save → calls $indexer->reindexRow($productId) synchronously in the same request
• Update by Schedule → the MView framework writes the changed ids into panth_salefilter_product_cl

2. MView changelog + Magento's indexer cron

The mview.xml subscription tracks:

• catalog_product_entity_decimal (special_price, price)
• catalog_product_entity_datetime (special_from_date, special_to_date)
• catalogrule_product_price (rule-computed per-product prices)
• catalog_product_relation + catalog_product_super_link + catalog_product_bundle_selection (child/parent links)

Magento's indexer_update_all_views cron runs every 1 minute. In Update by Schedule mode, our indexer catches up to any change within ~60 seconds.

3. The critical piece — daily catalog-rule refresh

This is what handles dated discounts. Magento ships a cron job catalogrule_apply_all (from Magento\CatalogRule\Cron\DailyCatalogUpdate) configured to run every day at midnight:

<!-- vendor/magento/module-catalog-rule/etc/crontab.xml -->
<job name="catalogrule_apply_all" method="execute"
 instance="Magento\CatalogRule\Cron\DailyCatalogUpdate">
 <schedule>0 0 * * *</schedule>
</job>

It:

1. Recomputes catalogrule_product_price for the current date — rules whose window starts today come online, rules whose window ended yesterday drop out.
2. Fires catalogrule_after_apply — our observer catches this (realtime) or the mview changelog captures the catalogrule_product_price inserts (schedule).

The same mechanism handles dated special_price via Magento's catalog_product_price indexer, which is invalidated nightly and rebuilds against today's date.

Concrete timeline example

Create rule "Summer Sale — 25% off" with from_date = 2026-06-01, to_date = 2026-06-30, saved on 2026-04-20.

Worst-case lag for a discount starting/ending at a specific time: ~1 minute after midnight, bounded by the index cron group's schedule.

Prerequisites

# Magento's own cron must be running
bin/magento cron:install # once, at setup
# OS cron then invokes bin/magento cron:run every minute

If bin/magento cron:run is not firing, nothing time-gated works — not just our module, but all Magento price/rule scheduling. This is a baseline Magento requirement, not something our module adds.

Force an immediate re-check

bin/magento catalog:rule:apply-all # behave as if it's midnight right now
bin/magento indexer:reindex panth_salefilter_product
bin/magento cache:flush

URL Parameters

• ?sale_filter=1 — on-sale only
• ?sale_filter=0 — regular-price only (honoured only while Show Not On Sale Option is enabled)

Parameters are preserved across pagination (&p=2), per-page override (&product_list_limit=24), and sort (&product_list_order=price&product_list_dir=desc).

Changelog

1.0.14

• Fix: sidebar "On Sale (N)" now mirrors every grid-applied constraint so the number always equals the post-click grid total. Covers: stock filter (Display Out of Stock Products Yes/No), every other active layered-nav filter (Brand, Color, Pattern, Size, Price range, category drill-down), and super-attribute filters on configurable products (resolved via catalog_product_index_eav expanded through catalog_product_super_link).
• Fix: ?pattern=X&sale_filter=1 no longer broadens the grid. The plugin's afterGetProductCollection hook runs BEFORE the layered-navigation block populates Layer::getState(), so state-based filter mirroring silently missed every sibling filter and the module's custom SearchResultApplier (which bypasses ES when ITEMS_FLAG is set) then rendered the full category-wide on-sale set. Plugin now reads active filters from $request->getParams() and resolves each non-reserved key via EavConfig.
• Safety: if a mirrored filter would zero the count (EAV super-attribute values tied to children outside the current category), skip the mirror rather than hide the sidebar option — wider approximate count is strictly better than a missing filter.
• Verified: 56/56 PASS across indexer mode (realtime / schedule) × show_out_of_stock (0 / 1) × theme (Hyvä / Luma) × 3 categories × 4 cross-filter combinations (none, color=49, pattern=196, color+pattern) × pagination.

1.0.13

• Fix: stock filter is now honoured in the sidebar count and in the Plugin's COUNT_FLAG/ITEMS_FLAG. Previously a category with 48 in-stock on-sale items displayed "On Sale (69)" because the count collection included OOS products Magento core had already removed from the grid.

1.0.5

• Docs: complete README rewrite with screenshots, animated admin-configuration GIF, full compatibility matrix, FAQ, and indexer-timing deep dive.

1.0.4

• Fix: Update on Save mode now actually reindexes on product save (previously only flagged the index as stale, so changes weren't visible until someone ran indexer:reindex manually).

1.0.3

• Fix: honour storefront sort (position / price asc-desc / name asc-desc) while the sale filter is active. Previously all sort directions returned the same slice in category position order.

1.0.2

• Fix: correct grid + pager total under the ES-backed Fulltext\Collection. Replaces the default SearchResultApplier with a filter-aware variant; plugs getSize() to return the post-filter count.

1.0.1

• Fix: count the full category, not just the visible page (toolbar pagination was leaking into the count query).

1.0.0

• Initial release.

Troubleshooting

Enable bin/magento deploy:mode:set developer and tail var/log/system.log for diagnostic output.

Compatibility

Tested on:

• Magento 2.4.8-p4 with PHP 8.4 and Elasticsearch 8
• Magento 2.4.7 with PHP 8.3 and OpenSearch 2
• Magento 2.4.6 with PHP 8.2 and Elasticsearch 7

Installation

Composer (Recommended)

composer require mage2kishan/module-sale-filter
bin/magento module:enable Panth_SaleFilter
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento indexer:reindex panth_salefilter_product
bin/magento cache:flush

Hyvä storefronts

Also install the companion module — it ships the Alpine.js / Tailwind template and the Hyvä Appearance admin group:

composer require mage2kishan/module-sale-filter-hyva
bin/magento module:enable Panth_SaleFilterHyva
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush

Manual installation via ZIP

1. Download the latest release ZIP from Packagist or GitHub Releases
2. Extract to app/code/Panth/SaleFilter/ in your Magento installation
3. Run the same commands starting from bin/magento module:enable Panth_SaleFilter

Verify installation

bin/magento module:status Panth_SaleFilter
# Expected: Module is enabled

bin/magento indexer:status panth_salefilter_product
# Expected: Ready / Update by Schedule / idle

After installation, navigate to:

Admin → Stores → Configuration → Panth Extensions → Sale Filter

Configuration

Stores → Configuration → Panth Extensions → Sale Filter

All fields are store-scoped — you can set different labels per store view for multi-locale installations.

Uninstall

bin/magento module:disable Panth_SaleFilter
composer remove mage2kishan/module-sale-filter
bin/magento setup:upgrade

The panth_salefilter_product_index table and MView changelog are dropped automatically by setup:upgrade once the module is removed.

License

Proprietary. See LICENSE. Commercial licence granted per Magento installation.

CLI Reference

# Full reindex
bin/magento indexer:reindex panth_salefilter_product
# …or our dedicated command (same effect, friendlier output)
bin/magento panth_salefilter:reindex

# Health check
bin/magento panth_salefilter:status
bin/magento indexer:status panth_salefilter_product

# Switch modes
bin/magento indexer:set-mode schedule panth_salefilter_product
bin/magento indexer:set-mode realtime panth_salefilter_product

# Refresh only catalog rules (as if midnight)
bin/magento catalog:rule:apply-all

# Clear caches tagged by this module
bin/magento cache:clean panth_salefilter