Filter values are generated only from products on the current pagination page

Available filter values are collected only from products displayed on the current pagination page instead of all products assigned to the selected category or tag. Consequently, many valid filter values are missing.

Renaming a filter group or filter value removes product associations

Changing the name of a filter group or filter value causes products to lose their existing filter associations. Names should be treated only as editable labels, while associations should rely on permanent database IDs.

My store contains many thousands of products. Renaming a filter can therefore cause a serious data-loss incident: an administrator may unknowingly remove filter associations from the entire catalogue. Without a backup, this could mean losing everything.

At the moment, I consider this the most serious flaw in the store system.

Product filtering uses incorrect OR logic

Filters selected from different groups are combined using OR instead of AND. For example, selecting “ring”, “silver” and “topaz” should return products matching all three conditions.

Available filter values are not recalculated after filtering

After selecting a filter, incompatible values from other groups remain visible. Customers can therefore select impossible combinations and receive an empty product list. Available values should be recalculated after every selection.

The filter form uses POST and breaks browser history

Sorting and filtering are handled using POST. When the customer uses the browser’s Back button, the browser displays a form resubmission warning or an ERR_CACHE_MISS error. Product lists should use GET parameters or update the URL and browser history using history.pushState().

Hiding the product filter sidebar breaks the product list

Disabling or hiding the filter sidebar affects sorting and pagination. In some layouts, it causes all products to be displayed. The visibility of the filtering interface should not affect the query used to retrieve products.

-----------------------------------

I do not require support, as I solved the problem myself by creating a custom product display template plugin. However, I noticed that the issue also occurs in the default J2Commerce templates, so I thought it was worth reporting.

kind regards,
KK

 

Thanks for the quick reply.

One small enhancement request: could you consider adding a filter_input_type field to #__j2commerce_filtergroups and exposing it in the filter-group edit form?

Possible values could be checkbox, select, radio, and multiselect, with checkbox kept as the default for backward compatibility.

Rendering every group as a checkbox list does not scale well. When a single filter group contains dozens or even a hundred values, the filtering interface becomes unnecessarily long and difficult to use. Giving administrators control over the input type would make the system more flexible without affecting existing stores.

 

KK

Adam,

I noticed David’s comment that J2Commerce is not yet a five-star review candidate. I respectfully see it differently.

Of course, the component is still developing and there are areas that need work. However, I think it already deserves five stars for the direction you are taking: bringing this store back to life, listening to users who run real shops, and treating reported problems and suggestions seriously.

What I appreciate most is that you do not dismiss feedback or treat it as criticism. You investigate issues, explain the reasoning, and are willing to improve the component where it makes practical sense.

For me, this approach matters as much as the current feature set. It gives me confidence that J2Commerce is being built for the people who actually use it.

KK