Cztery atrybuty dla jednego produktu. Dziewiętnaście wartości dla pierwszego, ósmego, ósmego i trzeciego. To odpowiada 3,648 wariantom produktu i nie jest to jedynie hipoteza: sprzedawca zgłosił dokładnie to w systemie śledzenia problemów PrestaShop , dla 30 produktów i ponad 100 000 wierszy bazy danych.
Strony ich produktów uległy przedawnieniu, a w panelu administracyjnym pojawił się pusty, biały ekran.
Nic się nie zepsuło. Katalog działał dokładnie tak, jak został zaprojektowany, w skali, której nikt nie zoptymalizował.
Problem, który wielu właścicieli odkrywa, gdy jest już za późno: kombinacje produktów PrestaShop to wykładniki, a nie sumy. Dziesięć wartości w jednej grupie i dziesięć w drugiej daje sto wariantów ceny, stanu magazynowego i zdjęcia, a nie dwadzieścia. Dobre zarządzanie kombinacjami produktów PrestaShop zaczyna się właśnie tam.
1.0 Atrybuty i kombinacje PrestaShop: jaka jest różnica?
Dwa terminy są stale mylone, a różnica ta decyduje o sposobie tworzenia katalogu.
Atrybuty produktu PrestaShop to elementy wybierane przez klienta. Rozmiar, kolor, pojemność. Cecha to tekst opisowy, który znajduje się na stronie i którego nie można wybrać: waga, materiał, kraj pochodzenia. Własna dokumentacja PrestaShop jasno to ujmuje: klient może kupić wersję iPada na podstawie koloru i miejsca na dysku, ale nie na podstawie wagi.
Jeśli się pomylisz, i tak poniesiesz koszty. Potraktuj cechę jak atrybut, a wygenerujesz setki wariantów, między którymi nikt nigdy nie będzie wybierał, a każdy z nich będzie zawierał wiersze w pięciu tabelach. Odwrotna sytuacja jest jeszcze gorsza: klienci nie mogą kupić wersji, po którą przyszli.
Strukturę tworzą trzy warstwy. Grupa atrybutów, taka jak „Rozmiar”, zawiera wartości takie jak „Mały” i „Średni”, a „ kombinacja” to jedna para w każdej grupie. W zapleczu jest to wiersz w „product_attribute” , zawierający własne odniesienie, korektę ceny, wagę i stan magazynowy.
2.0 Dlaczego kombinacje produktów PrestaShop mnożą się tak szybko?
Pełny iloczyn kartezjański – każda wartość z każdej grupy łącznie z każdą wartością z każdej innej grupy – to wynik generatora kombinacji PrestaShop . Liczba wariantów produktu PrestaShop to pomnożone, a nie zsumowane liczby.
Zobacz jak szybko ci to ucieknie.
Trzy grupy, sześćdziesiąt wariantów. Czwarta grupa trzech wartości dałaby 180.
| Grupy atrybutów | Wartości w każdym | Utworzone kombinacje |
| 2 (rozmiar, kolor) | 5 i 4 | 20 |
| 3 (Rozmiar, Kolor, Materiał) | 5, 4 i 3 | 60 |
| 4 (Rozmiar, Kolor, Materiał, Wykończenie) | 5, 4, 3 i 3 | 180 |
| 4 (zgodnie ze zgłoszeniem nr 12915) | 19, 8, 8 i 3 | 3,648 |
Dodaj jeszcze jedną grupę trzech wartości, a suma się potroi. Nie plus trzy: razy trzy. Ten pojedynczy punkt wyłapuje więcej sprzedawców niż cokolwiek innego w zarządzaniu kombinacjami w PrestaShop.
Warto wiedzieć przed kliknięciem przycisku „Generuj”: platforma nie narzuca górnego limitu . Generator jest rekurencyjny, generując kombinacje pojedynczo, bez zdefiniowanego maksimum w żadnej klasie.
3.0 Co robi baza danych podczas generowania kombinacji
Pojedyncza kombinacja nigdy nie tworzy pojedynczego rzędu. Wręcz przeciwnie. To właśnie ten szczegół umyka ludziom, gdy patrzą na rozdęty katalog i zastanawiają się, skąd wziął się ten rozmiar.
Wygeneruj jedną kombinację, a PrestaShop zapisze ją w pięciu oddzielnych tabelach:
- atrybut_produktu zawiera samą kombinację, jej odniesienie i wpływ na cenę.
- Ustawienia cen i zapasów specyficzne dla danego sklepu są uwzględniane atrybut_produktu_sklep, jeden rząd na sklep.
- kombinacja_atrybutów_produktu łączy kombinację z wartościami jej atrybutów. Co najważniejsze, jest to jeden wiersz na atrybut, więc kombinacja czterech atrybutów zapisuje tutaj cztery wiersze samodzielnie.
- Zapasy mieszkają w stan magazynowy, ponownie na sklep.
- Wreszcie, język_atrybutu_produktu przechowuje etykiety dostępności, jeden wiersz na język.
Pięć tabel na kombinację, z czego dwie są skalowane w zależności od atrybutów i liczby języków.
Teraz wykonaj obliczenia na tym produkcie z 3,648 kombinacjami, zakładając cztery atrybuty, 2 języki i 1 sklep. Otrzymasz 3,648 wierszy dla atrybutu product_attribute, kolejne 3,648 dla atrybutu product_attribute_shop, 14 592 dla atrybutu product_attribute_combination, 3,648 dla atrybutu stock_available i 7,296 dla atrybutu product_attribute_lang. To daje 32 832 wiersze dla pojedynczego produktu.
Pomnóż przez 30 produktów, a dojdziesz do miliona wierszy. Sprzedawca, o którym mowa w tym numerze, zgłosił ponad 100 000, co plasuje go na ostrożnym poziomie.
Liczba języków i sklepów ponownie zwiększa tę sumę, więc trzy języki w dwóch sklepach nie zwiększają znacząco kosztów zarządzania wariantami produktów w PrestaShop . Kilka z tych liczb się mnoży.
4.0 Wydajność kombinacji PrestaShop dla dużych katalogów
Pamięć masowa jest tania, a milion wierszy to nic dla bazy danych. Dlaczego więc te strony produktów zostały przeskanowane?
Odpowiedź leży w kontrolerze front-office i jest bardziej konkretna niż ogólne spowolnienie.
Otwórz stronę produktu jako klient, a PrestaShop wywoła getAttributesGroups() bez filtra, zawężając wyszukiwanie do kombinacji na ekranie. Wyświetli się każdy wiersz kombinacji dla tego produktu. Wszystkie 3,648, przy każdym wyświetleniu strony, zanim użytkownik kliknie cokolwiek.
Potem robi się drożej. Kontroler przechodzi przez te wiersze i wywołuje Product::getPriceStatic() raz dla każdej kombinacji, aby sprawdzić, czy dana cena ma zastosowanie. Prawie cztery tysiące obliczeń cen, z których każde uruchamia własną logikę podatku i rabatu, aby wyrenderować jedną stronę.
Nic tu nie zależy od tego, co wybierze widz. Praca dzieje się tak czy inaczej.
Deweloperzy PrestaShop są tego świadomi. Bezpośrednio nad tym zapytaniem w kodzie źródłowym 8.2.6 znajduje się komentarz głównego opiekuna, który pyta, czy kod powinien pobierać tylko grupy, a nie wszystkie warianty. Pytanie to pojawia się w bazie kodu od lat.
Z tego projektu wynikają dwie praktyczne konsekwencje:
- Czas ładowania strony zależy od liczby kombinacji, a nie od tego, co klient faktycznie wybierze. Produkt z 3,600 wariantami jest powolny nawet dla osoby, która od razu go opuści.
- Konkretne reguły cenowe pogarszają sytuację, ponieważ każda z nich dodaje pracę w pętli, która już działa tysiące razy. To największa pułapka w… Zarządzanie dużymi kombinacjami katalogów PrestaShop.
Warto wiedzieć: sklep bez kombinacji całkowicie pomija zapytanie, ponieważ Combination::isFeatureActive() zwraca wartość wcześniej.
5.0 Jak zarządzać tysiącami kombinacji produktów w PrestaShop
5.1 Przed wszystkim innym usuń liczbę atrybutów
Każda usunięta grupa dzieli całkowitą kwotę, więc jest to zmiana o największym efekcie, która technicznie rzecz biorąc nie kosztuje nic.
W przypadku każdej grupy zadaj pytanie wprost: czy klient odmówi zakupu, jeśli nie będzie mógł wybrać tego? Wykończenie, rodzaj opakowania i gęstość nici zazwyczaj nie przechodzą tego testu. Przenieś ich do cech.
Usuń jedną grupę trzech wartości z tego 3,648-kombinacyjnego produktu, a otrzymasz 1,216. Jedna decyzja i dwie trzecie wierszy zniknęło.
5.2 Podział na osobne produkty, gdy wariant jest w rzeczywistości produktem
W przypadku autentycznych wariantów jednego produktu atrybuty są odpowiednie. Jeśli opcje różnią się na tyle, że klienci szukają ich osobno, lub jeśli potrzebujesz osobnych zdjęć i adresów URL, są to osobne produkty w różnych wariantach.
Oddzielne produkty również lepiej się indeksują, ponieważ każdy z nich ma własny adres URL i metaopis. Kombinacja nie ma ani jednego, ani drugiego.
5.3 Generowanie i edycja zbiorcza
W przypadku zbiorczych kombinacji produktów w PrestaShop , generator przewyższa ręczne tworzenie wariantów. Wygeneruj pełny zestaw, a następnie usuń te, których nie masz w magazynie, co stanowi praktyczne rozwiązanie w zarządzaniu zbiorczymi kombinacjami produktów w PrestaShop . Podczas generowania PrestaShop wyłącza określone reguły cenowe i stosuje je za jednym razem na końcu, dzięki czemu pierwsze uruchomienie jest szybsze, niż się wydaje.
Regeneracja istniejącego zestawu działa inaczej. Przed utworzeniem każdej kombinacji PrestaShop wysyła zapytanie do bazy danych, aby sprawdzić, czy dana para atrybutów już istnieje. Tysiące kombinacji, tysiące wyszukiwań. Dlatego drugie uruchomienie wydaje się znacznie wolniejsze niż pierwsze.
5.4 Kiedy kombinacja jest całkowicie niewłaściwym narzędziem
Usunięcie grup atrybutów rodzi oczywiste pytanie: co dzieje się z opcją, którą właśnie usunięto? Czasami staje się funkcją. Czasami żadna z nich nie pasuje.
Tekst grawerunku, monogram, data dostawy, przesłane logo. Żadne z nich nie może być kombinacją, ponieważ kombinacja wymaga skończonej listy wartości zdefiniowanych z wyprzedzeniem.
Należą one do pola produktu niestandardowego, które PrestaShop nazywa dostosowaniem:
- Kombinacja jest skończona, zdefiniowana z góry i zawiera zapasy. Każda z nich kosztuje wiersze w pięciu tabelach.
- Otwarte i wypełnione przez klienta: Pole niestandardowe nie zajmuje miejsca w magazynie, a koszt jego zakupu w przypadku produktów w 3 wariantach będzie taki sam, jak w przypadku produktów w 3000 wariantach.
Obie opcje działają razem. Koszulka może zawierać kombinacje Rozmiaru i Koloru, a nadrukowane imię i nazwisko może być polem niestandardowym, a w wierszu zamówienia widoczne są oba pola.
Warto najpierw poznać jeden haczyk. PrestaShop identyfikuje wiersz koszyka według produktu i kombinacji, więc dwóch klientów zamawiających ten sam kubek z innym grawerunkiem połączyłoby się w jeden wiersz z numerem dwa. Moduły rozwiązujące to nadpisanie , Cart::updateQty , Cart::getProducts i Cart::deleteProduct , następnie haszują przesłane wartości, aby rozdzielić wiersze.
5.5 Dwa problemy, które pojawiają się dopiero po złożeniu zamówienia
Zamówienie przechowuje kombinację w nazwie produktu. Podczas składania zamówienia PrestaShop nie przechowuje odniesienia do kombinacji i nie wyszukuje jej później. Zapisuje kombinację w nazwie i przechowuje ten ciąg znaków, więc order_detail .product_name zawiera coś takiego jak koszulka z nadrukiem kolibra (rozmiar: S – kolor: biały).
Z każdym pojedynczym atrybutem ustawionym dla pola, ciąg ten wydłuża się o jeden element, ponieważ dodawane są do niego kolejne wartości i grupy. Cztery grupy tworzą długi ogon w i tak już długiej nazwie.
Problem leży w szerokości kolumny, która różni się w zależności od wersji PrestaShop.
W PrestaShop 1.7 szerokość kolumny wynosi varchar(255). Wersje 8 i 9 używają MEDIUMTEXT. Ponadto wydaje się, że w wersji 1.7 rozmiar varchar dla tego pola nie jest zadeklarowany, a długość nie jest testowana przed wstawieniem i jest po prostu obcinana przez MySQL po 255 znakach.
Nikt nie widzi błędu. Zamówienie zostaje zapisane, a strata pojawia się później na fakturze lub na liście zamówień, gdzie dwa warianty mogą wyglądać identycznie, ponieważ częścią, która je rozróżnia, jest ta sama część, która została wycięta. Aktualizacja do wersji 1.7 usuwa sufit.
Tekst personalizacji jest przekazywany do e-maila z potwierdzeniem jako ciąg znaków, a PrestaShop dynamicznie generuje ten tekst w PHP z wymaganym znacznikiem, z etykietami umieszczonymi w środku i wpisami rozdzielonymi znacznikami <br />. Szablon e-maila następnie wyświetla wartość bez użycia znacznika "oznaczone jako bezpieczne", a ponieważ szablony wiadomości e-mail są wykonywane z włączoną funkcją ucieczki w Smarty, wszystkie te znaczniki są przekształcane w encje.
Klient odczytuje tagi zamiast widzieć pogrubioną etykietę i podział wiersza. Wyślij do siebie zamówienie testowe z produktem dostosowanym do indywidualnych potrzeb, ponieważ to samo zamówienie może wyświetlać się poprawnie na fakturze PDF, podczas gdy e-mail zawiera surowe znaczniki.
5.6 Obserwuj, co robią konkretne ceny
Każda konkretna reguła cenowa dodaje pracy w ramach pętli dla każdej kombinacji, dlatego kilka reguł nic nie kosztuje w przypadku małego katalogu, a w przypadku dużego staje się problemem. Przypomnijmy sprzedawcę z problemu nr 12915: inna cena niestandardowa dla każdego z 3,600 wariantów.
Jeśli jedna różnica cen dotyczy całej grupy, należy użyć pola „Wpływ ceny łączonej” zamiast konkretnej reguły cenowej. Znajduje się ono w samym wierszu kombinacji, a jego odczyt nie wiąże się z żadnymi dodatkowymi kosztami.
6.0 Co zmieniło się między PrestaShop 1.7 a 9?
Mnóstwo, a różnice mają znaczenie, jeśli korzystasz ze starszego samouczka.
W PrestaShop 9 nie ma już starej strony produktu. To, co ją zastąpiło – przebudowana strona wprowadzona w wersji 1.7 i udoskonalona w serii 8.x – jest teraz jedyną dostępną opcją. Notatki programistów PrestaShop 9.0 potwierdzają, że do starej strony w ogóle nie można dotrzeć. Dlatego każdy zrzut ekranu w samouczku napisanym wcześniej pokazuje interfejs, którego nie masz.
Autorzy modułów mają więcej do sprawdzenia. Każdy hak powiązany ze starą stroną produktu zniknął wraz z nią w wersji 9.0, czyli z rodziną kontrolerów actionAdminProductsController . Poleganie na jednym z nich do obsługi kombinacji? Ten moduł wymaga przerobienia.
Dwie zmiany danych również zaskakują. Z Product::getProductProperties usunięto attribute_price, a funkcje nie są już domyślnie uwzględniane w getProductsProperties. Obie zmiany powodują niepowodzenie.
Jeśli chodzi o wydajność, ostatnio pojawiły się dobre wieści. PrestaShop 9.1 wprowadził, jak to określają jego notatki dotyczące wydania, znaczną poprawę wydajności koszyka dla sklepów z wieloma kombinacjami produktów . Prowadzenie obszernego katalogu wariantów w wersji 9.0? Samo to uzasadnia aktualizację.
Jedna zmiana schematu ma znaczenie, jeśli nadal korzystasz z wersji 1.7. Kolumna order_detail.product_name miała tam typ varchar(255), a w wersjach 8 i 9 jest MEDIUMTEXT, więc aktualizacja usuwa opisane powyżej ciche obcięcie.
Podstawowe zachowanie się jednak nie zmieniło. Kombinacje pozostają iloczynem kartezjańskim, nieograniczonym, rozłożonym na tych samych pięciu tabelach, a liczenie przed wygenerowaniem ma takie samo znaczenie w wersji 9, jak i w wersji 1.7.
7.0 Praktyczna kolejność pracy
W obliczu katalogu, który stał się nieporęczny, przejrzyj je po kolei. Krótka odpowiedź na pytanie, jak obsługiwać warianty produktów na dużą skalę w PrestaShop.
- Najpierw policz. Pomnóż wartości atrybutów przez siebie, zanim klikniesz „Generuj”. Jeśli przekroczysz kilkaset dla jednego produktu, zatrzymaj się i przemyśl to jeszcze raz.
- Czy jakaś grupa atrybutów mogłaby być funkcją lub otwartym polem niestandardowym?
- Które warianty zasługują na własną stronę produktu? Wszystko, czego chcesz, znajdziesz osobno w wyszukiwarce.
- Sprawdź szczegółowe zasady dotyczące cen dla produktów o wielu wariantach, zastępując je, jeśli to możliwe, polem wpływu na cenę łączoną.
- Złóż zamówienie testowe na produkt z kilkoma atrybutami i personalizacją, a następnie przeczytaj wiersz zamówienia i e-mail z potwierdzeniem. Długie nazwy są skracane w wersji 1.7, a e-mail unika własnego znacznika.
- Korzystasz z PrestaShop 9.0 z dużym katalogiem wariantów? Zaktualizuj do wersji 9.1, aby poprawić wydajność koszyka.
8.0 Wersja skrócona
Kombinacje się mnożą, a to mnożenie trafia do bazy danych szybciej, niż większość sprzedawców się spodziewa. Pięć tabel na kombinację. Jeden produkt czteroatrybutowy z kilkoma tysiącami wariantów może pomieścić 30 000 wierszy.
Wydajność spada na stronie produktu, a nie na pamięci masowej. PrestaShop ładuje każdą kombinację i wycenia każdą z nich osobno, przy każdym wyświetleniu, niezależnie od tego, czy użytkownik otworzy menu rozwijane.
Najskuteczniejsze rozwiązanie pozostaje najprostsze. Mniej grup atrybutów oznacza wykładniczo mniej kombinacji, więc wykonaj mnożenie przed wygenerowaniem czegokolwiek.
Dziękuję za przeczytanie.
Jeśli masz pytania lub potrzebujesz pomocy w zakresie wydajności lub migracji witryny, nasi eksperci są do Twojej dyspozycji. Skontaktuj się z zespołem Knowband pod adresem [email protected] już dziś, aby uzyskać niezawodne wtyczki eCommerce dopasowane do Twoich potrzeb.
