Konfiguracja modułów PrestaShop: zakres, wartości domyślne i sekrety
Poznaj przechowywanie ustawień modułów, zakres multistore, wartości domyślne, tłumaczenia, pola sekretów i kontrolę poprawnego zapisu konfiguracji.
Konfiguracja ma warstwę przechowywania i warstwę aplikacji. Zanim zmienisz ustawienie lub zaczniesz diagnozować wartość, która pozornie się resetuje, sprawdź używane przez nie reguły sklepu, języka i wartości domyślnych.
Co byśmy zrobili
Zanim zmienilibyśmy cokolwiek innego, zapisalibyśmy wybrany sklep, język, próbę wprowadzenia wartości z usuniętymi sekretami i wynik po przeładowaniu. Wybór ścieżki zależy od zainstalowanych wersji modułu i pakietu, integracji, motywu, zapisanych danych, rynków oraz osoby w zespole odpowiedzialnej za ustawienie.
Do napraw kodu lub warstwy przechowywania używaj kopii testowej odizolowanej od produkcyjnej poczty i zapisów przez integracje. Przećwicz zmianę, zachowaj poprzedni pakiet i konfigurację, a następnie uzgodnij przełączenie produkcyjne i plan wycofania. Sprawdź zarówno objęty zmianą scenariusz klienta lub pracownika, jak i sam formularz.
W przypadku niestandardowego działania konfiguracji PrestaShop Custom Module Development Service opiera się na uzgodnionej specyfikacji i testach odbiorczych.
Ustal, gdzie przechowywane są ustawienia
Wbudowane API Configuration PrestaShop obsługuje zakres sklepu i wartości językowe oraz proste odczyty klucz/wartość. Jego tabele używają prefiksu bazy danych instalacji.
Wspólny system konfiguracji mypresta.rocks używa tabel mpr_config i mpr_config_lang z tym prefiksem. Wersje pakietu z zapisami koordynowanymi przez rewizje korzystają też z mpr_config_revision. Nazwy modułów oddzielają klucze różnych modułów. Wspólne przechowywanie to infrastruktura dla uczestniczących modułów, a nie zastępstwo każdego ustawienia rdzenia.
Twórz kopie tych wspólnych tabel razem z bazą sklepu. Usunięcie jednego modułu nie może usuwać ustawień używanych przez inne.
Odróżnij brakujące wartości od domyślnych i błędów odczytu
Bezpośredni odczyt ConfigTable::get() odwołuje się do globalnego magazynu i zwraca null, gdy klucz nie istnieje. Obsługa błędów odczytu zależy od dołączonej wersji pakietu. Starsze kopie mogą też zwracać null po nieudanym odczycie bazy. Nowsza implementacja zgłasza ConfigReadException, gdy błąd odczytu pozostawia wartość nieznaną, ale potwierdzony brak tabeli bazowej traktuje jako brak magazynu. Korzystaj z API uwzględniającego status, gdy kod wymaga jawnego wyniku odczytu.
tryGet() zwraca logiczny status odczytu i przekazuje wartość przez argument wyjściowy. Brakujący klucz to udany odczyt z wartością null; błąd odczytu bazy zwraca false. Nieoczekiwane wyjątki nadal mogą być przekazywane dalej. readStatus() rozróżnia znalezienie, brak i błąd dla jednego jawnego zakresu.
Warstwa pośrednia modułu może stosować zadeklarowane wartości domyślne i konwersję typów. Wartość widoczna w formularzu może więc być domyślna, a nie pochodzić z już zapisanego wiersza bazy. Sprawdź reguły tej warstwy, zanim uznasz brak wiersza za błąd.
| Co widzisz | Co sprawdzić dalej |
|---|---|
| Sugerowana wartość pojawia się przed pierwszym zapisem. | Zapytaj, czy jest to zadeklarowana wartość domyślna i czy to ustawienie wymaga jawnie zapisanej wartości. |
| Formularz zgłasza błąd pola. | Popraw odrzucone dane przed diagnozowaniem przechowywania; zachowaj dokładny komunikat walidacji. |
| Zapis zgłasza powodzenie, ale po przeładowaniu wartość znika. | Poproś programistę o prześledzenie przesłanego pola, wyniku metody ustawiającej i kolejnego odczytu w tym samym zakresie. |
Jawnie wybieraj zakres sklepu i języka
Niskopoziomowe API obsługuje typ i identyfikator kontekstu. Jego globalne metody pomocnicze używają globalnego kontekstu z identyfikatorem zero; nie podążają automatycznie za sklepem wybranym w panelu administracyjnym.
Dla wartości właściwych sklepowi używaj obsługiwanego przez moduł API i formularza uwzględniających kontekst. Niskopoziomowe odczyty kontekstu pobierają wiersze tego zakresu bez automatycznego dziedziczenia innego zakresu i stosowania wartości domyślnych. Warstwy wyższego poziomu mogą określać reguły wartości zastępczych.
Tłumaczone wartości mają powiązania językowe w tabeli towarzyszącej. Sprawdź żądany język i politykę zastępczego języka modułu. Zapis zestawu tłumaczeń może zastąpić zestaw przekazany dla ustawienia, więc zachowuj języki, które chcesz utrzymać.
- Wybierz docelowy kontekst wszystkich sklepów, grupy sklepów lub sklepu.
- Zmień jedno ustawienie i zapisz.
- Przeładuj stronę w tym samym kontekście.
- Sprawdź inny sklep i język, aby potwierdzić zamierzony zakres.
Na przykład zmieniasz tekst dostawy w angielskim formularzu sklepu A, a następnie widzisz stare brzmienie we francuskiej wersji sklepu B. Najpierw powtórz kontrolę w sklepie A i po angielsku. Jeśli ten widok jest poprawny, zbadaj inny zakres i tłumaczenie, zamiast wielokrotnie zapisywać we wszystkich sklepach. Jeśli jest błędny, prześledź opisaną powyżej ścieżkę zapisu i odczytu.
Obsługuj formularze i sekrety oddzielnie
Formularze potrzebują walidacji, kontroli uprawnień i mapowania zadeklarowanych pól na zapisywane klucze. Potwierdź, że zapis do bazy się powiódł, zanim pokażesz komunikat o zapisaniu ustawień.
Kontrakt pola sekretu w zestawie narzędzi administracyjnych obsługuje zachowanie, zastąpienie i, gdy dozwolone, usunięcie zapisanego sekretu. Pominięte lub puste pole może oznaczać zachowanie istniejącej wartości. Używaj jawnej kontrolki usunięcia, zamiast zakładać, że puste pole usuwa sekret.
Prezentacja sekretu i ochrona przechowywania to osobne kwestie. Zamaskowane pole lub formularz pozwalający tylko na zapis nie oznacza szyfrowania danych w spoczynku. Ogranicz dostęp do bazy, kopii i logów oraz nie ujawniaj danych dostępowych w eksportach ani diagnostyce.
Na kopii testowej używaj testowych danych dostępowych obsługiwanych przez dostawcę. Jeśli naprawa wymaga zastąpienia produkcyjnego sekretu, użyj obsługiwanego formularza i zweryfikuj połączenie przed unieważnieniem starych danych dostępowych, jeśli dostawca pozwala na ich równoczesne użycie. Zaplanuj odzyskiwanie danych dostępowych: przywrócenie pakietu nie przywróci unieważnionych danych.
Sprawdzaj trwałość zapisu i ostrożnie przywracaj ustawienia
Obsługiwane metody ustawiania zwracają wynik powodzenia i po udanym zapisie unieważniają odpowiednie cache. Sprawdzaj ten wynik w kodzie i obsługuj niepowodzenie. Gdy kilka zależnych zmian wymaga skoordynowanego utrwalenia, korzystaj z mechanizmów zakresu zapisu pakietu.
Jeśli ustawienie się nie zachowuje, potwierdź przestrzeń nazw modułu, kontekst, język, walidację pola i uprawnienia bazy. Przed bezpośrednią edycją wierszy bazy ponownie odczytaj dane przez zwykłe API.
Rozróżniaj pojęciowo wartości domyślne, ustawienia sprzedawcy i tymczasowy stan wykonania. Proces naprawczy powinien identyfikować brakujące wymagane ustawienia bez wymyślania danych dostępowych API i nadpisywania świadomie wybranej wartości.
O co zapytać programistę lub agencję
- Które wersje modułu i pakietu, klucz pola, sklep i język pozwalają odtworzyć błąd?
- Czy wyświetlana wartość jest zapisana, dziedziczona czy domyślna i co potwierdza powodzenie walidacji, zapisu i odczytu?
- Jaki błąd z usuniętymi danymi poufnymi i znacznik czasu identyfikują nieudane żądanie oraz jakie dowody z testów i kroki odzyskiwania potwierdzają naprawę?
Pytania właścicieli sklepów
Czy zresetować lub ponownie zainstalować moduł?
Najpierw sprawdź, co usuwa jego procedura resetowania lub odinstalowania. Zachowaj konfigurację i odtwarzalny przypadek, zanim wykonasz działanie, które może usunąć dowody.
Czy wyczyszczenie pamięci podręcznej naprawi problem?
Może odświeżyć nieaktualny widok, ale nie zapisze wartości, której nigdy nie utrwalono. Porównaj odczyt przez obsługiwane API z wyświetlanym wynikiem, zanim uznasz czyszczenie pamięci podręcznej za naprawę.
Czy mogę odtworzyć całą kopię zapasową bazy danych?
Pełne odtworzenie może też usunąć zamówienia i inne zmiany dokonane od utworzenia kopii. Poproś o plan odzyskiwania objętych problemem ustawień, który zachowa późniejsze dane biznesowe.