Adobe Commerce Developer Professional: EAV Attribute Not Appearing in the Layered Navigation

EAV Attribute Not Appearing in the Layered Navigation

A merchant adds a new product attribute material (a select with global scope, Used in Layered Navigation = Filterable (with results), Used in Product Listing = Yes) via a data patch. After setup:upgrade and full reindex, the attribute appears on the product edit form and saves correctly, but the storefront layered navigation never shows it as a filter. The catalog has ~12,000 simple products; ~9,000 have a material value. The theme is stock Luma. The developer confirms the value is stored in catalog_product_entity_int. The catalog_product_index_eav table has rows for other filterable attributes but none for material.

1. Given that values are stored in `catalog_product_entity_int`, why is `catalog_product_index_eav` missing rows for `material`, and what must be true for an attribute to be indexed there?

Read the worked answer

catalog_product_index_eav is populated by the catalog_product_attribute indexer (and the price/eav indexers), but only for attributes that meet the indexer's criteria. The indexer selects attributes where:

backend_type is one of the static/indexable types (int, varchar, text, decimal, datetime) - int qualifies;
the attribute is filterable or otherwise flagged for use in layered navigation / search;
is_used_for_promo_rules or filterable flags drive inclusion.

The most common failure: the attribute was created with Used in Layered Navigation set, but the indexer metadata was cached or the attribute was added after the indexer's attribute list was built, so the catalog_product_attribute indexer never picked it up. Another cause: the attribute's frontend_input/source_model mismatch, or is_filterable stored as 0 in catalog_eav_attribute even though the admin UI showed it as filterable (data patches often set the EAV attribute but forget the catalog_eav_attribute row).

The developer should check catalog_eav_attribute.is_filterable and is_filterable_in_search for the attribute, then re-run bin/magento indexer:reindex catalog_product_attribute. If is_filterable is 0, the patch must also update catalog_eav_attribute.

2. The developer finds `catalog_eav_attribute.is_filterable = 0`. What is the correct fix, and why is editing only `eav_attribute` insufficient?

Read the worked answer

EAV attributes are split across two tables: eav_attribute holds the generic definition (code, backend_type, source_model, frontend_input, scope), while catalog_eav_attribute holds catalog-specific behavior flags - is_filterable, is_filterable_in_search, is_used_for_promo_rules, is_visible_in_advanced_search, etc. The layered navigation and the catalog_product_attribute indexer read the catalog_eav_attribute flags, not eav_attribute.

Correct fix: in the data patch, after creating the attribute, update the corresponding catalog_eav_attribute row to set is_filterable = 1 (and is_filterable_in_search if needed). Then run bin/magento indexer:reindex catalog_product_attribute and flush the config/layout cache. Editing only eav_attribute leaves the catalog flags at their defaults (0), so the attribute is never indexed into catalog_product_index_eav and never offered as a filter - exactly the observed symptom.