Dopasowanie do motywu PrestaShop: wykrywanie, nadpisania i wartości zastępcze

Co byśmy zrobili

Przed zmianą motywu prześledzilibyśmy widoczną niespójność. Wybór ścieżki zależy od obecnego motywu i motywu potomnego, modułów, integracji procesu składania zamówienia, danych katalogowych, rynków i zespołu odpowiedzialnego za ich utrzymanie. Uzgodnij, które komponenty muszą pasować do motywu, a które wymagają osobnych prac nad układem.

Przećwicz zmianę motywu lub wspólnych stylów na kopii testowej, odizolowanej od produkcyjnej poczty, płatności i eksportów integracji. Zapisz poprzednie ustawienia i zasoby, przetestuj objęte zmianą scenariusze, a następnie zaplanuj przełączenie produkcyjne z wyznaczoną osobą odpowiedzialną i sposobem przywrócenia poprzedniej konfiguracji i plików.

Jeśli chcesz ocenić zgodność proponowanego motywu przed wyborem, PrestaShop Theme Selection & Fit Assessment sprawdza go pod kątem wymagań Twojego sklepu.

Co może zapewnić wykrywanie motywu

Pakiet Theme Detector zbiera określony zestaw wartości stylów. Obejmuje on kolory główne i dodatkowe, kolory tekstu i linków, tła stron i komponentów, kolory statusów, kolory i szerokości obramowań, promienie zaokrągleń, cienie, odstępy wewnętrzne przycisków i pól oraz typografię. Typografia obejmuje tekst podstawowy, nagłówki, tekst wprowadzający, etykiety, podpisy, drobny tekst, tekst o stałej szerokości znaków i przyciski.

To wybrane tokeny projektowe. Moduł nadal potrzebuje odpowiednich znaczników, układów i stylów komponentów. Osobno sprawdzaj zgodność z motywem okien modalnych, elementów finalizacji zakupu i widżetów zewnętrznych.

Detektor odczytuje właściwości niestandardowe CSS i znane selektory. Obsługuje też deklaratywny kontrakt motywu i sondę przeglądarkową do stylów obliczonych. Statyczne parsowanie CSS nie odtwarza każdej kaskady przeglądarki, stanu responsywnego ani dynamicznie ładowanego arkusza.

Classic i Hummingbird mają wbudowaną obsługę wykrywania. Parser obsługuje też popularne kolory frameworków, w tym kolory Warehouse/IQIT. Testuj dokładne wydanie motywu i komponenty używane przez Twój moduł.

Sprawdź wynik w swoim sklepie

1. Potwierdź aktywny sklep, katalog motywu i rodzica. Sprawdź motyw potomny oraz nadrzędny.
2. Otwórz ustawienia wyglądu uczestniczącego modułu. Zapisz zachowane nadpisania, wybór adaptera i stan włączenia własnych zasobów, jeśli takie kontrolki są dostępne. Etykiety i dostępność kontrolek zależą od modułu i wydania.
3. Sprawdź główne przyciski, linki, pola, stany fokusu, okna modalne, obramowania i typografię w uczestniczącym module.
4. Sprawdź układ na komputerze i urządzeniach mobilnych, fokus klawiatury, kontrast tekstu oraz każdy oferowany tryb ciemny lub alternatywny motywu. Używaj rzeczywistych nazw produktów i przetłumaczonych etykiet dla obsługiwanych rynków.
5. Na kopii testowej tymczasowo zmień jeden token i sprawdź, czy zmieniają się tylko elementy, które powinny z niego korzystać.
6. Usuń testowe nadpisanie, odśwież wspólne style zgodnie z procedurą udokumentowaną dla Twojego wydania modułu i potwierdź powrót wartości wykrytej lub domyślnej wartości motywu.
7. Powtórz po aktualizacji motywu, przebudowie zasobów lub aktualizacji pakietu. W multistore testuj każdy sklep osobno.

Jeśli moduł ignoruje tokeny, potrzebuje zmiany integracji. Żaden detektor nie zmieni stylu komponentu, który nigdy nie korzysta z jego wyniku. Ustawienia wyglądu danego modułu opisuje jego strona pomocy.

Dobierz kolejną kontrolę do objawu

Przykład: przycisk modułu zachowuje poprzedni kolor

Załóżmy, że nowy motyw używa zielonych przycisków głównych, ale uczestniczący moduł nadal pokazuje niebieskie. Na kopii testowej wykryty kolor główny jest zielony, a moduł ma zapisane niebieskie nadpisanie. Zapisz to nadpisanie, usuń je i odśwież wspólne style. Jeśli przycisk zmieni kolor na zielony, zapisane ustawienie wyjaśnia niespójność.

Jeśli pozostanie niebieski, poproś programistę o wskazanie dokładnej zmiennej i deklaracji CSS mającej pierwszeństwo na tym przycisku. Zanim zmienisz kolejne ustawienie, sprawdź, czy niebieska wartość pochodzi z domyślnego tokenu zdefiniowanego przez motyw, pozostałego wspólnego nadpisania, prywatnego ustawienia czy reguły komponentu wpisanej na stałe.

Jak działa wykrywanie, zapisywanie i odświeżanie

Proces wykrywania zaczyna się od wartości zastępczych, odczytuje dostępny CSS motywu i ustala obsługiwane właściwości. Pakiet ustala katalog aktywnego motywu i jego zadeklarowanego rodzica. Jeśli nie znajdzie odpowiedniego arkusza motywu, wyszukiwanie CSS może użyć dostępnego arkusza Hummingbird lub Classic albo wykrywanie może zachować domyślne wartości pakietu. Wartość zastępcza nie dowodzi, że aktywny motyw jej używa. Wyniki są ponownie używane w ramach żądania PHP i zapisywane do późniejszego wykorzystania. Generowane pliki CSS dostarczają wspólne zmienne i aliasy zarejestrowane przez uczestniczące moduły.

Potwierdzenie przeglądarkowe jest powiązane ze sklepem i bieżącym odciskiem motywu. Traci aktualność po siedmiu dniach. Zmiana motywu lub wymuszone odświeżenie również może wymagać ponownego wykrywania. To wewnętrzna zasada świeżości, a nie harmonogram odświeżania konfigurowany przez sprzedawcę.

Punkt końcowy na działającej witrynie przyjmuje dane sondy tylko wtedy, gdy trwa oczekiwanie na wynik wykrywania. Waliduje wartości przed zapisaniem. Odrzucona sonda może uruchomić sześciogodzinny okres wstrzymania ponowień. Jeśli potwierdzenie nie następuje, sprawdź skrypt sklepu, żądanie sieciowe i odpowiedź zamiast zakładać, że otwarcie strony administracyjnej kończy wykrywanie.

Po zmianie zasobów motywu odśwież współdzielone style za pomocą ustawień udostępnionych przez uczestniczący moduł. Sprawdź wygenerowany arkusz i sklep. CDN lub pamięć podręczna połączonych zasobów mogą nadal serwować stary plik po zmianie zapisanych wartości.

Zapisane nadpisania i kolejność wartości zastępczych

Dla wspólnego tokenu zapisane nadpisanie sprzedawcy ma pierwszeństwo przed wykrytą wartością. Brakujące wykryte wartości są zastępowane wspieranymi starszymi wartościami lub domyślnymi pakietu. Tokeny zależne mogą dziedziczyć inną wartość, np. tło okna modalnego może odpowiadać głównej powierzchni komponentu. Niepoprawne wartości CSS są odrzucane lub zastępowane bezpieczną wartością domyślną.

Generowany arkusz używa trzech poziomów specyficzności: wartości wykrytych/domyślnych na html, wartości domyślnych autora motywu na :root lub html:root oraz jawnych zapisanych ustawień na html:root:root. W tym kontrakcie wartości domyślne motywu nadpisują wykrywanie, a zapisane ustawienia nadpisują wartości domyślne motywu. Lokalny CSS komponentu nadal podlega zwykłej kaskadzie.

Możesz mieć wspólne nadpisania sklepu oraz aliasy właściwe dla modułu lub ustawienia prywatne. Moduł musi zarejestrować alias i korzystać z niego, zanim wpłynie on na interfejs. Wyczyszczenie ustawienia jednego modułu może odsłonić wspólne nadpisanie pod nim.

1. Sprawdź surową wykrytą wartość i efektywną zapisaną wartość.
2. Sprawdź, czy różnicę wyjaśnia ustawienie wspólne lub właściwe dla modułu.
3. Wyczyść odpowiednie nadpisanie, jeśli chcesz wrócić do wykrywania.
4. Odśwież arkusz, a potem sprawdź obliczony styl danego komponentu.

Nie naprawiaj błędnie wykrytego koloru przez zmianę niepowiązanych ustawień motywu. Ustal rzeczywisty token i regułę CSS mającą pierwszeństwo.

Adaptery motywów i własne zasoby

Wykrywanie motywu i adaptery rozwiązują różne problemy. Tokeny dostarczają wartości stylów. Adapter dostarcza CSS lub JavaScript modułu dla konkretnego motywu. Pakiet front wybiera i rejestruje adaptery; pakiet admin dostarcza wspólny interfejs ustawień tam, gdzie moduł go włącza.

Automatyczny wybór adaptera sprawdza aktywny motyw, a następnie jego rodzica. Można jawnie wybrać dostarczony adapter, a none wyłącza adaptery. Dany moduł obsługuje motyw tylko w takim zakresie, jaki zapewniają dostarczony adapter i rzeczywiste działanie sklepu.

Własne zasoby sprzedawcy są opcjonalne i domyślnie wyłączone. Należy je umieszczać w lokalizacjach nadpisań modułu w motywie sklepu. Aktualizacja modułu powinna zachować te pliki motywu, ale nadal trzeba je ponownie testować po aktualizacji motywu lub modułu.

Utrzymuj spójne wersje pakietów detector, front i admin we wdrożonych modułach. Przy diagnozowaniu różnic między instalacjami sprawdź, którą wersję pakietu ładuje sklep.

O co zapytać programistę lub agencję

Przekaż URL objętej problemem strony, kontekst sklepu, wersje motywu i rodzica, wersję modułu, zrzuty ekranu przy rozmiarze obszaru wyświetlania, w którym występuje błąd, oraz kroki odtworzenia. Dołącz odpowiednie zapisane ustawienia i, jeśli są dostępne, wykrytą wartość, URL wczytanego CSS i deklarację mającą pierwszeństwo.

• Czy ten komponent korzysta ze wspólnego tokenu, zarejestrowanego aliasu czy prywatnego stylu?
• Które wersje ładowanego pakietu i adaptera sprawdzono?
• Które ustawienie lub plik się zmieni i jak je przywrócimy?

Pytania właścicieli sklepów

Czy ustawienie czcionki spowoduje jej wczytanie?

Sama wartość font-family nie wczytuje pliku czcionki. Jeśli typografia się różni, sprawdź żądania czcionek i czcionkę faktycznie renderowaną przez przeglądarkę, a także wykrytą rodzinę.

Czy dopasowany wygląd finalizacji zakupu dowodzi jej działania?

Uwzględnij w odbiorze zakończony zakup testowy i oczekiwane przekazania danych do integracji. Zgodność wizualna nie weryfikuje tworzenia zamówień, płatności ani działania dostawy.

Czy mogę zatwierdzić motyw na podstawie jego wersji demo?

Użyj wersji demo do wstępnego wyboru. Zatwierdzenie wymaga dowodów z Twojego katalogu, modyfikacji i kluczowych scenariuszy modułów na kopii sklepu.