Własny silnik filtrowania w OpenCart 3 bez modyfikacji Core – DC Filters

Filtrowanie produktów jest jednym z tych elementów sklepu internetowego, których znaczenie rośnie razem z katalogiem. Jeżeli mamy kilkanaście produktów, klient bez większego problemu może przejrzeć je wszystkie. Przy kilkuset pozycjach zaczynają być potrzebne kategorie i sortowanie.

Przy kilku czy kilkunastu tysiącach produktów dobry system filtrów przestaje być dodatkiem do sklepu, a zaczyna być jednym z podstawowych elementów nawigacji.

Problem polega na tym, że „filtr” może oznaczać bardzo różne rzeczy. W jednym sklepie klient chce wybrać cenę i producenta, w innym rozmiar i kolor zapisane jako opcje, a w kolejnym moc, materiał, długość czy klasę energetyczną znajdujące się w atrybutach. Do tego dochodzą podkategorie, dostępność produktu, promocje, wyszukiwarka, wiele języków i walut.

Można oczywiście próbować rozwiązywać to kolejnymi modyfikacjami modelu produktu OpenCart. Tylko że im głębiej wchodzimy w catalog/model/catalog/product.php , tym większy zaczyna być później problem z kompatybilnością, aktualizacjami i innymi rozszerzeniami.

Dlatego przy DC Filters dla OpenCart 3 założyłem coś innego: chciałem mieć własny silnik filtrowania, ale nie chciałem modyfikować Core OpenCart.

Tak powstał moduł, który składa się właściwie z dwóch współpracujących ze sobą warstw. Pierwsza to widoczny dla klienta panel filtrów. Druga, znacznie ważniejsza od strony technicznej, to Filter Engine , który w odpowiednim momencie przejmuje zapytania odpowiedzialne za listę produktów i zwraca wyniki uwzględniające filtry DC.

W aktualnej wersji 0.4.0 DC Filters obsługuje filtrowanie po cenie, atrybutach, opcjach, kategoriach, producentach i dostępności. Może działać na stronach kategorii, wyszukiwania, producenta i promocji, posiada obsługę AJAX, Multistore, wielu języków i walut oraz bardzo rozbudowany panel pozwalający dopasować jego frontend praktycznie bez pisania CSS. 🧩 

Jeśli masz problem z instalacją lub modyfikacją modułu skorzystaj z naszej pomocy na: tworzenie sklepów internetowych.

 

Dlaczego właściwie napisałem kolejny filtr dla OpenCart?

OpenCart 3 ma własny mechanizm filtrów. Nie uważam, że jest on zły. Problem polega raczej na tym, że wymaga wcześniejszego utworzenia grup filtrów, przypisywania ich do produktów oraz kategorii i utrzymywania dodatkowej warstwy danych.

W wielu realnych sklepach informacje potrzebne do filtrowania już przecież istnieją.

Produkt ma producenta. Ma cenę. Ma ilość magazynową. Ma przypisane kategorie. Posiada atrybuty. Jeżeli sprzedajemy odzież, obuwie czy produkty konfigurowalne, prawdopodobnie ma również opcje i wartości tych opcji.

Nie zawsze widzę sens w przepisywaniu części tych danych jeszcze raz tylko po to, żeby stworzyć filtr.

Przykładowo produkt może już posiadać atrybut:

Materiał: Aluminium

albo opcję:

Kolor: Czarny

DC Filters może wykorzystać te informacje bezpośrednio.

To było jedno z głównych założeń projektu: korzystać z danych, które już istnieją w katalogu OpenCart .

Drugim problemem było Core. Filtrowanie w praktyce dotyka jednego z najbardziej newralgicznych fragmentów sklepu — pobierania produktów. Można zmodyfikować standardowy model, można przygotować OCMOD wstrzykujący dodatkowe warunki SQL, ale przy bardziej rozbudowanym rozwiązaniu zaczynamy być mocno zależni od konkretnej wersji pliku.

Chciałem tego uniknąć.

 

Własny Filter Engine bez modyfikowania Core

DC Filters wykorzystuje system Events OpenCart 3 .

Podczas instalacji moduł rejestruje eventy dla metod:

getProducts()

getTotalProducts()

oraz odpowiedników obsługujących stronę promocji.

Event uruchamia się przed wykonaniem standardowej metody modelu produktu. Następnie specjalna warstwa decyzyjna sprawdza, czy DC Filters powinien w danej sytuacji przejąć zapytanie.

Jeżeli nie — OpenCart działa normalnie.

Jeżeli tak — dane są przekazywane do własnego Filter Engine, który buduje i wykonuje zapytanie, a wynik zostaje podstawiony do standardowego przepływu OpenCart.

Dzięki temu nie muszę przepisywać oryginalnego pliku:

catalog/model/catalog/product.php

ani instalować patcha zmieniającego jego zawartość.

To dla mnie jedna z ważniejszych cech DC Filters. Moduł ingeruje w bardzo ważny proces sklepu, ale stara się robić to poprzez mechanizm przewidziany przez sam OpenCart.

 

Panel filtrów i silnik to dwie osobne rzeczy

Warto zrozumieć tę architekturę, ponieważ na początku może nie być oczywista.

Panel filtrów jest klasycznym modułem OpenCart, który można umieścić np. w Column Left odpowiedniego layoutu. To właśnie on wyświetla slider ceny, checkboxy, selecty, liczniki i przyciski.

Filter Engine działa niezależnie od samego widoku modułu. Jego zadaniem jest przechwycenie głównego zapytania listingu i zastosowanie wybranych przez klienta warunków.

Dzięki temu frontend nie zawiera własnej, odseparowanej listy produktów. Nadal pracujemy z normalnym listingiem kategorii, wyszukiwarki czy producenta, a DC Filters zmienia zestaw produktów zwracanych przez model.

Sortowanie oraz paginacja pozostają częścią tego samego przepływu.

 

Gdzie DC Filters może działać?

Aktualny silnik obsługuje cztery podstawowe konteksty OpenCart:

Strona	Obsługa
Kategoria	Tak
Wyniki wyszukiwania	Tak
Strona producenta	Tak
Produkty promocyjne	Tak

Każdy z tych kontekstów można niezależnie aktywować w panelu.

Domyślnie po instalacji aktywne jest wykorzystanie silnika na stronie kategorii. Pozostałe miejsca można włączyć wtedy, kiedy faktycznie są potrzebne.

Nie chciałem wymuszać przejęcia wszystkich listingów od pierwszej sekundy po instalacji.

 

Marker Mode i Always Mode – dwa sposoby pracy silnika

To kolejny element, który wprowadziłem przede wszystkim ze względu na bezpieczeństwo i możliwość kontrolowanego wdrożenia.

DC Filters posiada dwa tryby silnika.

 

Tryb A – tylko gdy URL zawiera marker DC Filters

Jest to domyślny i bardziej zachowawczy wariant.

Pierwsze wejście na zwykłą kategorię może korzystać z natywnego mechanizmu OpenCart. Gdy użytkownik użyje DC Filters, formularz dodaje do adresu marker:

dcf=1

i wtedy główny listing zostaje przejęty przez Filter Engine.

Pozwala to ograniczyć ingerencję DC Filters tylko do sytuacji, kiedy rzeczywiście jest potrzebny.

 

Tryb B – zawsze

W tym trybie Filter Engine może obsługiwać główny listing od razu, również zanim klient wybierze pierwszy filtr, oczywiście tylko dla typów stron włączonych w konfiguracji.

To rozwiązanie może być przydatne wtedy, kiedy chcemy, aby cała lista produktów na danej stronie zawsze przechodziła przez ten sam silnik.

 

Własna przestrzeń parametrów URL

Parametry DC Filters mają własny prefix:

dcf_

Przykładowo zakres ceny korzysta z:

dcf_pmin

i:

dcf_pmax

Wartości opcji, atrybutów, kategorii, producentów i stanów posiadają własne parametry należące do tej samej przestrzeni.

Chciałem w ten sposób ograniczyć ryzyko kolizji ze standardowymi parametrami OpenCart albo filtrami dodanymi przez inne rozszerzenia.

Filtry są przekazywane przez GET, dlatego ich stan może zostać zapisany bezpośrednio w URL. Przy pracy AJAX adres w przeglądarce również jest aktualizowany przez History API.

 

Jak działa logika filtrowania?

Nie wszystkie rodzaje filtrów można potraktować tak samo.

W przypadku opcji zastosowałem logikę:

OR w obrębie jednej opcji, AND pomiędzy różnymi opcjami.

Załóżmy, że mamy:

Kolor: czarny lub biały

oraz:

Rozmiar: XL

Klient otrzyma produkty posiadające kolor czarny lub biały, ale równocześnie spełniające warunek rozmiaru XL.

Podobna zasada działa przy atrybutach. Kilka wartości tego samego atrybutu może tworzyć alternatywę, natomiast kolejne atrybuty zawężają wynik.

To znacznie bardziej naturalne dla użytkownika niż traktowanie każdego zaznaczonego checkboxa jako niezależnego wymogu AND.

 

Cena uwzględniająca realną cenę produktu

Filtrowanie ceny jest trochę bardziej skomplikowane, niż mogłoby się wydawać.

Jeżeli produkt kosztuje standardowo 500 zł, ale aktualnie ma aktywną promocję 399 zł, klient oczekuje, że filtr ceny będzie pracował na 399 zł.

DC Filters przy ustalaniu efektywnej ceny bierze pod uwagę aktywną cenę specjalną dla aktualnej grupy klientów, następnie odpowiedni rabat ilościowy dla jednej sztuki, a dopiero później podstawową cenę produktu.

Ten sam mechanizm wykorzystywany jest również podczas sortowania po cenie przez własny silnik.

Dodatkowo zakres widoczny dla klienta jest przeliczany na aktualnie używaną przez niego walutę. Przy wysłaniu formularza wartość wraca do waluty katalogowej przed wykonaniem zapytania SQL.

Dzięki temu klient korzystający np. z EUR nie musi widzieć zakresu obliczonego w bazowej PLN tylko dlatego, że taka waluta została ustawiona w sklepie.

 

Facety i liczniki produktów

DC Filters buduje również facety , czyli zestawy możliwych wartości dla aktualnego kontekstu listingu.

Jeżeli w kategorii znajdują się produkty posiadające opcję „Kolor”, moduł może utworzyć odpowiednią grupę z występującymi wartościami.

Analogicznie powstają grupy atrybutów, producentów, kategorii i dostępności.

Do wartości mogą być wyświetlane liczniki produktów, np.:

Czarny (18)

Biały (7)

Aluminium (24)

W aktualnej architekturze liczniki opisują bazowy zakres danego listingu. Nie próbuję więc przedstawiać ich jako skomplikowanego, wieloetapowego systemu dynamicznego przeliczania każdego facetu po każdym zaznaczeniu.

Ich zadaniem jest przede wszystkim pokazanie klientowi, jakie dane występują w aktualnym katalogu i jaka jest ich skala.

Ważna uwaga: liczniki produktów to kolejne zapytania do bazy danych. Jedną z moich metod optymalizacji sklepów z dużą liczba produktów jest ich wyłączanie.

 

Instalacja DC Filters w OpenCart 3

Moduł jest dostępny na stronie Opencart Marketplace

Moduł jest przygotowany jako standardowa paczka instalacyjna OpenCart:

dc-filters.ocmod.zip

Proces instalacji wygląda następująco:

1. W panelu OpenCart przechodzimy do Extensions → Installer i przesyłamy paczkę dc-filters.ocmod.zip .

2. Następnie otwieramy Extensions → Extensions , wybieramy typ Modules i instalujemy Design Cart Filters .

3. Po instalacji otwieramy ustawienia modułu i konfigurujemy go dla wybranego sklepu.

4. W Design → Layouts dodajemy DC Filters do odpowiedniej pozycji, np. Column Left layoutu kategorii.

5. Jeżeli chcemy używać filtra również w wyszukiwarce, na stronach producentów albo promocjach, aktywujemy odpowiednie konteksty w ustawieniach i umieszczamy moduł w odpowiadających im layoutach.

6. Zapisujemy ustawienia i testujemy filtrowanie na frontendzie.

Samo uruchomienie Filter Engine i wyświetlenie panelu to dwie osobne kwestie. Jeżeli nie umieścimy modułu w layoucie, klient nie zobaczy interfejsu filtrów, nawet jeżeli jego silnik jest aktywny.

 

Multistore – osobna konfiguracja dla każdego sklepu

Po wejściu do DC Filters nie trafiam od razu do formularza ustawień. Najpierw pojawia się ekran sklepów.

Każdy storefront może otrzymać własną konfigurację.

Na kafelkach widoczny jest adres sklepu, status konfiguracji i informacja, czy moduł jest aktywny.

Dodałem również funkcję kopiowania ustawień pomiędzy sklepami . Przy większym Multistore nie trzeba więc od początku ustawiać kilkudziesięciu parametrów wyglądu dla każdej domeny. Można skonfigurować jeden sklep, skopiować jego ustawienia i później zmienić tylko różnice.

Jeżeli dodatkowy sklep nie posiada jeszcze osobnego zestawu ustawień, panel wykorzystuje wartości sklepu domyślnego jako punkt wyjścia.

 

Panel administracyjny DC Filters

Konfigurację podzieliłem na jedenaście zakładek:

Ogólne, Filtry, Teksty, Wygląd, Typografia, Cena, Atrybuty, Opcje, Kategorie, Wydajność oraz Indeks.

Panel jest dość rozbudowany, ponieważ zależało mi na tym, aby po instalacji można było dostosować nie tylko logikę filtrowania, ale również frontend bez otwierania arkusza CSS.

 

Zakładka „Ogólne”

Pierwsza zakładka odpowiada za podstawowe działanie modułu oraz Filter Engine.

Opcja	Działanie
Status	Włącza lub wyłącza DC Filters dla aktualnego sklepu.
Nazwa wewnętrzna	Administracyjna nazwa modułu.
Log diagnostyczny	Włącza informacje diagnostyczne przeznaczone głównie dla developera.
Tryb silnika	Pozwala wybrać tryb Marker albo Always.
Zoptymalizowane zapytanie – Kategoria	Pozwala Filter Engine obsługiwać listing kategorii.
Zoptymalizowane zapytanie – Szukaj	Włącza silnik na stronie wyników wyszukiwania.
Zoptymalizowane zapytanie – Producent	Włącza go na stronie producenta.
Zoptymalizowane zapytanie – Promocje	Włącza obsługę listingu produktów promocyjnych.

Użyłem określenia „zoptymalizowane zapytanie”, ale nie oznacza ono obietnicy, że każdy katalog po zaznaczeniu przełącznika automatycznie zacznie działać szybciej. Chodzi o wykorzystanie własnego zapytania DC Filters zamiast standardowego przepływu modelu dla danego listingu.

Rzeczywista wydajność zawsze zależy od wielkości katalogu, struktury danych, serwera i konfiguracji bazy.

 

Zakładka „Filtry”

Tutaj wybieramy, jakie rodzaje filtrów mają w ogóle istnieć.

Opcja	Działanie
Filtrowanie ceny	Włącza grupę ceny.
Filtrowanie atrybutów	Buduje filtry na podstawie atrybutów produktów.
Filtrowanie opcji	Buduje je z wartości opcji OpenCart.
Filtrowanie kategorii	Pozwala zawężać listing według kategorii.
Filtrowanie producenta	Dodaje wybór producentów.
Filtrowanie dostępności / stanu	Pozwala wybrać produkty dostępne albo niedostępne.
Pokazuj liczniki produktów	Kontroluje widoczność liczby produktów przy wartościach.
Wartości z zerem produktów	Określa, czy takie wartości mają być ukryte, nieaktywne czy pokazane, jeżeli pojawią się w danym typie facetu.
Kolejność grup filtrów	Pozwala ustalić kolejność sekcji.
Zwijane grupy	Pozwala otwierać i zamykać sekcje filtrów.
Domyślnie zwinięte	Określa początkowy stan grup.
Zwiń cały filtr na mobile	Na małych ekranach cały moduł może startować jako zwinięty.

Kolejność grup zapisujemy prostą listą oddzieloną przecinkami:

category,price,attribute,option,manufacturer,stock

Nie trzeba więc zmieniać Twig tylko po to, żeby cena znalazła się nad kategoriami albo opcje nad atrybutami.

 

Zakładka „Teksty”

DC Filters jest przygotowany pod sklepy wielojęzyczne.

Dla każdego aktywnego języka możemy zdefiniować własne teksty interfejsu.

Tekst	Przykład
Nagłówek modułu	Filtruj produkty
Przycisk Filtruj	Filtruj
Przycisk Wyczyść	Wyczyść
Wyczyść wszystko	Wyczyść wszystko
Nagłówek ceny	Cena
Nagłówek kategorii	Kategorie
Nagłówek atrybutów	Atrybuty
Nagłówek opcji	Opcje
Od	Od
Do	Do
Pokaż więcej	Pokaż więcej
Pokaż mniej	Pokaż mniej
Brak wyników	Brak produktów dla wybranych filtrów
Etykieta produktów	produkty

Jeżeli pole pozostawimy puste, moduł posiada własne teksty fallback dla obsługiwanej wersji językowej.

Nazwy samych atrybutów, opcji, kategorii i producentów są oczywiście pobierane z danych OpenCart dla aktualnego języka.

 

Zakładka „Cena”

Filtr ceny może być bardzo prosty albo bardziej rozbudowany.

Opcja	Działanie
Pokaż slider	Wyświetla graficzny suwak zakresu.
Pokaż pola min / max	Pozwala ręcznie wpisać wartości.
Pokaż aktualne wartości	Wyświetla bieżący zakres nad sliderem.
Automatyczne filtrowanie po zmianie	Może uruchamiać filtrowanie po zmianie zakresu.
Pokaż symbol waluty	Dodaje np. zł, €, $ zależnie od aktualnej waluty.
Krok slidera	Określa skok zmiany wartości, np. 1 albo 0.50.
Źródło zakresu	Automatyczny albo ręczny.
Ręczne minimum	Dolny limit przy trybie manualnym.
Ręczne maksimum	Górny limit przy trybie manualnym.

W trybie automatycznym DC Filters analizuje ceny produktów znajdujących się w aktualnym zakresie listingu i na tej podstawie ustala minimum i maksimum.

W trybie ręcznym możemy wymusić np. zakres 0–5000 niezależnie od aktualnego katalogu.

Slider obsługuje również klawiaturę. Uchwyty można zmieniać strzałkami, a klawisze Home i End pozwalają szybko przejść do granicznych wartości.

 

Zakładka „Atrybuty”

Atrybuty są szczególnie użyteczne w sklepach technicznych, meblowych, budowlanych czy elektronicznych, gdzie duża część specyfikacji produktu już znajduje się właśnie w systemie atrybutów OpenCart.

Opcja	Działanie
Prezentacja	Checkbox, radio albo select.
Maks. wartości przed „Pokaż więcej”	Ogranicza wysokość bardzo długiej listy.
Sortowanie wartości	Według nazwy, liczby produktów albo kolejności własnej.
Pokazuj liczniki	Włącza liczby przy wartościach atrybutu.
Zwijane	Pozwala zamknąć grupę danego atrybutu.
Domyślnie zwinięte	Ustala jej stan początkowy.

Jeżeli atrybut „Materiał” zawiera wartości Aluminium, Drewno oraz Stal, DC Filters może zbudować z nich gotowy filtr bez tworzenia dodatkowej grupy filtrów OpenCart.

Wartość atrybutu jest analizowana w aktualnym języku sklepu.

 

Zakładka „Opcje”

Opcje są traktowane niezależnie od atrybutów.

Ma to znaczenie zwłaszcza przy takich danych jak rozmiary, warianty czy kolory faktycznie przypisane do produktu jako opcje zakupowe.

Opcja	Działanie
Prezentacja	Checkbox, radio albo select.
Maks. wartości przed „Pokaż więcej”	Określa liczbę wartości widocznych od razu.
Sortowanie	Nazwa, liczba produktów albo kolejność własna.
Pokazuj liczniki	Wyświetla liczby produktów.
Zwijane	Pozwala zamknąć daną grupę opcji.
Domyślnie zwinięte	Określa stan początkowy.
Uwzględniaj wartości opcji ze stanem 0	Decyduje, czy warianty bez dostępnej ilości mają brać udział w facetach i filtrowaniu opcji.

Domyślnie DC Filters nie traktuje wartości opcji z ilością 0 jako dostępnego wariantu.

To ma znaczenie np. przy rozmiarze buta, który istnieje w konfiguracji produktu, ale w danym momencie nie ma już żadnej sztuki w magazynie.

 

Zakładka „Kategorie”

Kategoria może być nie tylko miejscem startowym listingu, ale również jednym z jego filtrów.

Opcja	Działanie
Zakres kategorii	Tylko dzieci aktualnej kategorii albo cała gałąź.
Maks. poziomów	Określa głębokość drzewa.
Pokazuj liczniki	Wyświetla liczbę produktów.
Zwijane	Pozwala zamykać sekcję kategorii.
Domyślnie zwinięte	Określa jej początkowy stan.

Przy trybie Tylko dzieci interfejs pozostaje prostszy i skupia się na bezpośrednich podkategoriach.

Tryb Cała gałąź może zejść głębiej w strukturę.

Na frontendzie kolejne poziomy mogą otrzymać odpowiednie wcięcie, dzięki czemu nadal widać hierarchię kategorii.

 

Producent

Producent jest prostszym typem filtra i dlatego nie posiada osobnej rozbudowanej zakładki ustawień.

Po jego włączeniu Facet Engine pobiera producentów występujących w aktualnym zbiorze produktów i może pokazać ich jako listę checkboxów wraz z licznikami.

Na samej stronie konkretnego producenta grupa producentów nie jest oczywiście tworzona — nie miałoby sensu filtrować strony „Samsung” ponownie według „Samsung”.

 

Dostępność

Filtr stanu rozróżnia dwa podstawowe warianty:

Dostępny – quantity > 0

oraz:

Niedostępny – quantity <= 0 .

Jeżeli klient zaznaczy oba warianty jednocześnie, filtr stanu nie ogranicza listingu.

To celowe zachowanie — „dostępny lub niedostępny” oznacza w praktyce wszystkie produkty.

 

Zakładka „Wydajność”

Filtrowanie potrafi generować dodatkowe zapytania potrzebne do policzenia zakresu ceny i zbudowania facetów. Dlatego dodałem osobną sekcję odpowiedzialną za cache.

Opcja	Działanie
Cache facetów	Zapisuje wyniki budowania grup i liczników.
Cache zakresów ceny	Przechowuje obliczone minimum i maksimum.
TTL cache	Określa czas życia danych w sekundach.
Filtrowanie AJAX	Włącza warstwę AJAX interfejsu.

Domyślny TTL wynosi 3600 sekund , czyli godzinę.

Klucz cache bierze pod uwagę m.in. sklep, język, grupę klienta, kontekst listingu i ustawienia wpływające na budowę facetów, więc nie jest to jedna globalna wartość dla całego sklepu.

 

Jak działa AJAX?

Przy wyłączonym AJAX formularz działa klasycznie. Parametry filtrów trafiają do URL i przeglądarka ładuje stronę ponownie.

Przy włączonym AJAX DC Filters pobiera przefiltrowaną stronę w tle, odczytuje nowy element #content i zastępuje nim aktualną zawartość. Jednocześnie aktualizowany jest tytuł dokumentu oraz URL w historii przeglądarki.

Jeżeli JavaScript nie znajdzie struktury, której potrzebuje do bezpiecznej podmiany, moduł wykonuje zwykłe przejście pod nowy URL.

Celowo zostawiłem więc fallback do klasycznego działania .

AJAX jest tutaj warstwą UX, a nie warunkiem działania samego Filter Engine.

 

Zakładka „Wygląd”

Ta część panelu jest rozbudowana, ponieważ zależało mi na możliwości dopasowania filtrów do różnych motywów bez tworzenia kolejnej wersji CSS.

Na początku znajduje się podgląd na żywo . Zmiana wielu parametrów od razu aktualizuje przykładowy filtr w panelu. Dopiero użycie przycisku Zapisz utrwala ustawienia.

Dostępny jest również przycisk Resetuj wygląd do domyślnych .

Główny kontener

Opcja	Zakres
Tło	Kolor kontenera.
Kolor obramowania	Kolor ramki.
Grubość obramowania	0–8 px.
Zaokrąglenie	0–40 px.
Padding	0–48 px.
Cień	Włączenie lub wyłączenie cienia.
Akcent	Główny kolor akcentujący interfejs.

 

Nagłówek modułu

Możemy ustawić kolor tła, kolor tekstu, zaokrąglenie oraz padding nagłówka „Filtruj produkty”.

 

Nagłówki grup

Osobne ustawienia posiadają sekcje takie jak Cena, Kolor, Materiał czy Kategorie. Dostępne są tło, kolor tekstu, kolor obramowania oraz jego grubość.

 

Wartości i liczniki

Można określić podstawowy kolor wartości, kolor hover, kolor liczników oraz ich przezroczystość.

 

Checkboxy i radio

Konfigurujemy kolor obramowania, kolor aktywny, kolor znacznika, wielkość kontrolki oraz zaokrąglenie.

 

Slider ceny

Slider posiada własne ustawienia toru, aktywnej części toru, uchwytów, ich obramowania, wielkości oraz tekstu wartości.

 

Przyciski „Filtruj” i „Wyczyść”

Oba przyciski posiadają niezależne zestawy ustawień.

Dla każdego możemy kontrolować tło, tło hover, kolor tekstu, kolor tekstu hover, ramkę, ramkę hover, grubość obramowania, zaokrąglenie oraz padding poziomy i pionowy.

Nie musimy więc robić z „Wyczyść” wizualnej kopii głównego CTA. Może pozostać delikatnym przyciskiem drugorzędnym.

 

Zakładka „Typografia”

Typografia również nie jest jednym globalnym ustawieniem.

Osobne grupy otrzymały:

nagłówek modułu, nagłówki grup, wartości filtrów, liczniki, cena, przycisk Filtruj oraz przycisk Wyczyść.

Każda grupa posiada ten sam zestaw parametrów:

Opcja	Działanie
Rozmiar czcionki	10–72 px.
Grubość	100–900.
Kolor	Niezależny kolor tekstu.
Rodzina czcionki	Domyślnie inherit , ale można podać własny font stack.
Wielkie litery	Opcjonalny uppercase.

Domyślne inherit jest celowe. W większości przypadków filtr powinien korzystać z tego samego fontu co reszta motywu, a nie ładować własną rodzinę czcionek.

 

Responsywność i zwijanie na urządzeniach mobilnych

Na desktopie filtr może zajmować stałą kolumnę boczną. Na telefonie ta sama lista potrafiłaby jednak zająć większość pierwszego ekranu.

Dlatego można aktywować funkcję Zwiń cały filtr na mobile .

Nagłówek modułu staje się wtedy przełącznikiem pozwalającym rozwinąć i schować całą zawartość filtrów.

Niezależnie od tego poszczególne grupy mogą posiadać własny mechanizm zwijania.

 

„Pokaż więcej” przy długich listach

Niektóre atrybuty potrafią mieć kilkadziesiąt wartości. Wyświetlenie wszystkich od razu sprawiłoby, że filtr byłby bardzo długi.

Dlatego dla atrybutów i opcji można ustalić maksymalną liczbę wartości widocznych od razu.

Pozostałe są ukryte pod:

Pokaż więcej

a po rozwinięciu przycisk zmienia się na:

Pokaż mniej .

Oba teksty można przetłumaczyć w zakładce Teksty.

 

Sortowanie wartości

Opcje i atrybuty można sortować na trzy sposoby.

Według nazwy jest najbardziej przewidywalne dla użytkownika.

Według liczby produktów może eksponować najpopularniejsze wartości.

Kolejność własna korzysta z kolejności zapisanej przy odpowiednich danych OpenCart tam, gdzie jest ona dostępna.

 

Zakładka „Indeks”

W panelu znajduje się również sekcja Indeks produktów .

W wersji 0.4.0 Filter Engine działa bez własnych tabel indeksowych, dlatego zakładka ma obecnie charakter informacyjny i pokazuje stan:

Indeks nie zbudowany .

Nie jest to błąd instalacji i nie oznacza, że filtr nie może działać.

Aktualny silnik korzysta bezpośrednio z danych katalogu OpenCart oraz z cache facetów i zakresów ceny. Warstwa osobnego indeksu została pozostawiona jako przestrzeń pod ewentualną dalszą optymalizację większych katalogów.

Nie przypisuję więc obecnej wersji funkcji indeksowania, której jeszcze faktycznie nie wykorzystuje.

 

Zachowanie sortowania i paginacji OpenCart

Budując własny silnik, nie chciałem jednocześnie wymyślać drugiego systemu sortowania produktów.

DC Filters obsługuje standardowe kryteria wykorzystywane przez OpenCart, między innymi nazwę, model, ilość, cenę, ocenę, kolejność sortowania i datę dodania.

Obsługiwane są również start oraz limit , dzięki czemu wynik nadal współpracuje z normalną paginacją listingu.

Filtr nie jest więc drugim katalogiem produktów umieszczonym obok OpenCart. Jest warstwą zawężającą istniejący listing.

 

Co z natywnym filtrem OpenCart?

Własny Filter Engine nie musi oznaczać całkowitego zerwania z natywnym filtrem.

Zapytanie zachowuje obsługę standardowego filter_filter OpenCart w kontekście kategorii.

To istotne, jeżeli sklep ma już część istniejącej konfiguracji i chcemy stopniowo przejść na DC Filters albo wykorzystać obydwa mechanizmy w bardziej niestandardowym wdrożeniu.

Oczywiście im bardziej nietypowa jest instalacja i im więcej rozszerzeń ingeruje w getProducts() , tym dokładniej warto przetestować współpracę.

 

Debug dla developera

W ustawieniach ogólnych znajduje się opcjonalny tryb diagnostyczny.

Filter Engine potrafi zapisać informacje o przejęciu getProducts() albo getTotalProducts() , liczbie wyników i czasie wykonania własnego zapytania.

Nie jest to funkcja potrzebna klientowi sklepu.

Dodałem ją przede wszystkim po to, żeby podczas wdrażania łatwiej było ustalić, czy w danym miejscu naprawdę działa DC Filters i ile czasu zajmuje konkretne zapytanie.

 

Dlaczego nie modyfikuję Core?

W tym module ma to dla mnie szczególne znaczenie.

Filtr dotyka funkcji, przez którą przechodzi praktycznie każdy listing produktów.

Jeżeli zrobiłbym duży OCMOD modyfikujący model katalogu, każda aktualizacja OpenCart albo rozszerzenie zmieniające te same linie zwiększałoby ryzyko konfliktu.

Events pozwalają mi podejść do tego inaczej.

DC Filters pyta najpierw: czy to jest obsługiwany listing i czy mam go przejąć?

Jeżeli odpowiedź brzmi „nie”, niczego nie zmienia.

Jeżeli „tak”, uruchamia własny silnik.

Nie twierdzę, że Events automatycznie rozwiązują wszystkie problemy kompatybilności. Inny moduł również może przecież ingerować w te same zapytania. Jest to jednak dla mnie znacznie czystszy punkt integracji niż ręczne przepisywanie Core.

 

Przykład praktyczny – sklep z obuwiem

Załóżmy, że w kategorii znajduje się 800 modeli butów.

Produkty mają producenta, cenę i ilość magazynową. Jako opcje posiadają rozmiary i kolory, a w atrybutach zapisany jest materiał, przeznaczenie i rodzaj podeszwy.

DC Filters może na podstawie tych danych zbudować panel pozwalający klientowi wybrać kategorię, zakres ceny, producenta, dostępność, kolor, rozmiar, materiał i przeznaczenie.

Nie trzeba do każdego z 800 produktów ręcznie przypisywać drugiego kompletu tych samych danych tylko dlatego, że mają być używane w filtrze.

To właśnie taki przypadek miałem na myśli podczas projektowania modułu.

 

Przykład – katalog techniczny

W sklepie z częściami albo wyposażeniem sytuacja może wyglądać jeszcze ciekawiej.

Atrybutami mogą być napięcie, moc, średnica, długość, materiał, norma czy klasa szczelności.

Dobrze uzupełnione dane produktowe zaczynają wtedy pełnić podwójną rolę: tworzą specyfikację na karcie produktu, ale jednocześnie stają się źródłem nawigacji po katalogu.

Moim zdaniem właśnie wtedy filtrowanie po atrybutach ma największy sens.

 

Czy DC Filters przyspieszy duży sklep?

Nie chciałbym obiecywać czegoś, czego nie można uczciwie obiecać bez zobaczenia konkretnej bazy danych.

Moduł posiada cache facetów i zakresów ceny, własne zapytania oraz możliwość ograniczenia silnika tylko do potrzebnych listingów. To daje narzędzia do rozsądnego zarządzania wydajnością.

Jednocześnie filtrowanie atrybutów, opcji czy głębokiego drzewa kategorii zawsze kosztuje bazę danych pewną pracę.

Sklep mający 300 produktów i sklep mający 300 000 produktów to dwa różne problemy.

Dlatego w dużych wdrożeniach nadal warto analizować rzeczywiste zapytania, indeksy MariaDB/MySQL, sposób zbudowania katalogu i charakter ruchu.

Tryb diagnostyczny został dodany między innymi właśnie po to, żeby zamiast zgadywać można było mierzyć.

 

Podsumowanie

DC Filters zacząłem pisać nie dlatego, że OpenCart nie potrafi filtrować produktów. Bardziej przeszkadzało mi to, że w wielu sklepach dane potrzebne do dobrego filtrowania już istnieją, a mimo to trzeba budować wokół nich kolejny, odrębny system.

Cena jest już w produkcie. Producent również. Kategorie, stan magazynowy, atrybuty i opcje także.

Chciałem wykorzystać właśnie te dane.

Drugim celem było uniknięcie modyfikowania Core w miejscu tak ważnym jak getProducts() i getTotalProducts() . Zamiast patchować standardowy model, DC Filters korzysta z Events i uruchamia własny Filter Engine tylko wtedy, kiedy warunki tego wymagają.

Do tego dołożyłem możliwość wyboru kontekstów, Marker Mode, Multistore, cache, AJAX, obsługę walut, wielojęzyczne teksty oraz rozbudowany cockpit wyglądu i typografii.

W rezultacie powstał moduł, który z jednej strony daje klientowi zwykły, czytelny panel filtrów, a z drugiej ma pod spodem własną warstwę odpowiedzialną za rzeczywiste zawężanie katalogu.

I chyba właśnie tak najlepiej opisałbym DC Filters 0.4.0 : nie jako kolejny zestaw checkboxów doklejonych do kategorii, tylko jako osobny silnik filtrowania produktów dla OpenCart 3, który stara się współpracować z platformą zamiast ją przepisywać . 🔎🛒