W opisywanym projekcie pracowałam nad sklepem opartym o WordPress (WooCommerce), w którym standardowy sposób prezentacji atrybutów okazał się niewystarczający dla rzeczywistych potrzeb biznesowych.

Domyślne rozwiązania systemu nie pozwalały na przedstawienie danych w układzie wymaganym przez klienta, co wymusiło przebudowę nie tylko logiki, ale również warstwy odpowiedzialnej za ich wyświetlanie.

Punkt wyjścia, czyli co mamy w WooCommerce na start

WooCommerce prezentuje atrybuty w formie horyzontalnej, gdzie każdy parametr jest niezależną pozycją:

Nazwa atrybutu: wartości

Taki sposób sprawdza się przy większości produktów, nawet z bardzo wieloma atrybutami, jednak w tym przypadku dane miały być prezentowane w formie tabelarycznej, gdzie każdy wiersz stanowi spójny zestaw informacji.

Wymaganie projektowe i zmiana modelu prezentacji danych

Zamiast listy atrybutów potrzebna była tabela, w której dane są prezentowane jako uporządkowane wiersze:

Kolumna | Kolumna | Kolumna
wartość | wartość | wartość
wartość | wartość | wartość

Oznaczało to odejście od klasycznego modelu WooCommerce, w którym atrybuty są niezależnymi bytami, na rzecz modelu tabelarycznego, gdzie kluczowe staje się ich wzajemne powiązanie, mimo że dla osoby obserwującej z zewnątrz nadal wygląda to jak zwyczajna tabelka z danymi technicznymi.

Kluczowy problem: sposób renderowania atrybutów

WooCommerce korzysta z domyślnego szablonu odpowiedzialnego za prezentację atrybutów produktu. W tym przypadku standardowy plik szablonu nie pozwalał na:

• kontrolę układu kolumn,
• łączenie danych w wiersze,
• synchronizację różnych typów atrybutów w jednej tabeli.

Rozwiązanie: podmiana warstwy widoku

Zamiast próbować na siłę „podkręcać” logikę do domyślnego szablonu WooCommerce, zdecydowałam się na jego nadpisanie i stworzenie własnej warstwy prezentacji danych.

W praktyce oznaczało to:

• przygotowanie własnego szablonu odpowiedzialnego za renderowanie tabeli,
• budowę mechanizmu grupowania i mapowania atrybutów przed ich wyświetleniem,
• pełną kontrolę nad strukturą HTML tabeli.

Dzięki temu mogłam odejść od standardowego układu WooCommerce.

Warstwa logiki danych

Domyślnie w WooCommerce każdy atrybut jest traktowany jako niezależna lista wartości. System nie zakłada istnienia relacji pomiędzy poszczególnymi atrybutami ani wspólnego wiersza danych. W przypadku tego projektu taki model nie sprawdzał się, ponieważ tabela miała prezentować komplet informacji o produkcie w logicznie powiązanych rekordach.

Pierwszym krokiem było więc oddzielenie warstwy prezentacji od warstwy danych. Wszystkie atrybuty musiały być najpierw normalizowane, czyli oczyszczane z formatowania HTML, dzielone na poszczególne wartości oraz zapisywane w ujednoliconej strukturze. Dzięki temu dalsza logika operowała na przewidywalnych tablicach, niezależnie od liczby wartości przypisanych do konkretnego atrybutu.

Następnie atrybuty zostały podzielone na dwie grupy. Atrybut odpowiedzialny za wariant produktu był analizowany oddzielnie i pełnił rolę elementu sterującego, natomiast wszystkie pozostałe zostały zgrupowane w serie danych. Takie podejście pozwoliło uniknąć sytuacji, w której atrybut sterujący był jednocześnie wykorzystywany do budowania struktury tabeli, co wcześniej prowadziło do przesunięć kolumn i nieprawidłowego mapowania wartości.

Sporą trudnością okazało się także to, że nie wszystkie produkty posiadały tę samą strukturę danych. Część z nich wymagała wygenerowania pełnej macierzy wszystkich kombinacji, inne miały pojedyncze wartości, które należało powielić we wszystkich wierszach, a jeszcze inne wykorzystywały liniowe powiązanie pomiędzy kolejnymi wartościami atrybutów. Próba obsłużenia wszystkich przypadków jedną pętlą prowadziła do coraz bardziej złożonej logiki i kolejnych efektów ubocznych.

Ostatecznie zamiast rozbudowywać jeden uniwersalny algorytm zdecydowałam się rozdzielić logikę renderowania na trzy niezależne ścieżki, z których każda odpowiadała innemu modelowi danych.

Pętla standardowa i produkty o klasycznej strukturze

Pierwszy mechanizm obsługuje większość produktów w sklepie. Jego zadaniem jest wygenerowanie tabeli na podstawie wszystkich dostępnych wartości atrybutów przy jednoczesnym zachowaniu poprawnego mapowania pomiędzy kolumnami.

Jeżeli dany atrybut posiada tylko jedną wartość, jest ona automatycznie powielana we wszystkich wierszach tabeli. Jeżeli natomiast atrybut zawiera wiele wartości, kolejne rekordy są budowane na podstawie ich indeksów. Dzięki temu tabela zachowuje spójność nawet wtedy, gdy poszczególne atrybuty mają różną liczbę elementów.

Pętla z mapowaniem liniowym

Drugi mechanizm został przygotowany dla produktów, w których kolejne wartości różnych atrybutów tworzą gotowe zestawy danych i nie powinny być ze sobą dowolnie łączone.

W tym przypadku każda wartość jednego atrybutu odpowiada dokładnie jednej wartości kolejnego atrybutu. Zamiast generowania wszystkich możliwych kombinacji zastosowałam liniowe mapowanie według indeksu, dzięki czemu pierwszy rekord jest tworzony z pierwszych wartości wszystkich atrybutów, drugi z drugich itd. Rozwiązanie to pozwoliło zachować poprawne relacje pomiędzy danymi bez sztucznego mnożenia liczby wierszy.

Pętla dla produktów o indywidualnej logice biznesowej

Trzecia ścieżka została przygotowana dla produktów wymagających niestandardowych reguł biznesowych. W tym przypadku część wartości była wyliczana lub podmieniana dynamicznie na podstawie określonych warunków, natomiast pozostałe dane pozostawały wspólne dla wszystkich rekordów.

Zamiast modyfikować główny algorytm i wprowadzać kolejne wyjątki, odseparowałam całkowicie logikę od pozostałych mechanizmów. Dzięki temu możliwe było dodanie indywidualnych zasad dla wybranych produktów bez ryzyka wpływu na działanie całej tabeli.

Takie podejście znacząco uprościło architekturę rozwiązania. Zamiast jednego rozbudowanego algorytmu obsługującego wszystkie możliwe przypadki powstały trzy wyspecjalizowane mechanizmy renderowania, odpowiadające trzem różnym modelom danych występującym w sklepie. Dzięki temu kod stał się bardziej przewidywalny, łatwiejszy do utrzymania i prostszy do dalszej rozbudowy.

Efekt końcowy

Wdrożenie obejmowało zarówno warstwę backendową (PHP), jak i frontendową (szablon WooCommerce).

Po zmianach:

• możliwe stało się wyświetlanie atrybutów w układzie tabelarycznym,
• zachowano pełną elastyczność struktury danych,
• usunięto ograniczenia standardowego szablonu WooCommerce,
• sposób prezentacji danych został dostosowany do realnych potrzeb produktu.

Najważniejszy wniosek

Największym wyzwaniem w tym projekcie nie była sama logika danych, ale fakt, że domyślny system WooCommerce narzuca własny sposób ich prezentacji.

Dopiero oddzielenie warstwy danych od warstwy widoku – poprzez podmianę szablonu – pozwoliło na pełną kontrolę nad sposobem wyświetlania informacji.

Nie rozumiesz, o czym jest ten wpis, ale potrzebujesz dedykowanych rozwiązań dla swojego sklepu WooCommerce? Zapraszam do kontaktu! Nie będę tłumaczyć, tylko działać!