Extra Properties w PrestaShop 9.2: wybór właściwego modelu danych

Dodatkowe pole łatwo zamówić, ale zaskakująco trudno dobrze zdefiniować. Sprzedawca prosi o „referencję dostawcy”, lecz agencja nadal musi wiedzieć, czy należy ona do produktu, kombinacji, zamówienia czy relacji z dostawcą. Błędna odpowiedź powoduje niejednoznaczność wszędzie tam, gdzie wartość jest ponownie używana.

PrestaShop 9.2 wprowadza Extra Properties jako natywny mechanizm rozszerzania. Oficjalne wyjaśnienie opisuje definicje pól z przestrzeniami nazw, typami, wartościami domyślnymi, walidacją i ustawieniami widoczności. Wskazuje encje obejmujące Product, Combination, Customer i Order. Wprowadzenie do Extra Properties.

W przypadku RC1 dostępnej 26 września 2026 r. traktuj wdrożenie jako ćwiczenie projektowe na środowisku staging. Poniższe przykłady wyjaśniają, jak zdecydować, co należy do właściwości; nie twierdzą, że przykładowy sklep został już zmigrowany.

Gdy odpowiedzialność i zakres pola są jasno określone, użyj procesu integracji modułu Extra Properties, aby prześledzić wartość przez rejestrację, formularze, trwały zapis i dostęp API.

Zacznij od faktu, nie od pola formularza

Przydatna właściwość zapisuje jeden fakt o jednej identyfikowalnej encji. Przed wyborem widżetu napisz zdanie opisujące ten fakt: „Ten produkt ma tę wewnętrzną klasę obsługi” lub „To zamówienie ma tę zewnętrzną referencję uzgodnienia”.

Następnie zapytaj, kiedy fakt się zmienia. Klasa obsługi w katalogu może zmienić się wraz z opakowaniem produktu. Referencja zamówienia może zostać raz nadana przez system zewnętrzny i pozostać stała. Preferencja klienta może zmieniać się często. Różne cykle życia oznaczają różnych właścicieli i reguły walidacji.

Unikaj niejasnych nazw takich jak extra_info. Zachęcają do umieszczania kilku niepowiązanych znaczeń w jednej wartości. Właściwość o nazwie packing_instruction daje opiekunom jaśniejszy kontrakt, choć nadal trzeba określić jej dokładny format i dozwoloną zawartość.

Przestrzenie nazw mają też znaczenie operacyjne. Dwa moduły mogą mówić o „referencji”, lecz mieć na myśli różne identyfikatory. Zachowaj widoczność właściciela biznesowego i technicznego. Jeśli moduł zostanie zastąpiony, zespół powinien wiedzieć, które wartości przenieść, a które są nieaktualne.

Natywny mechanizm rozszerzania może ograniczyć powtarzaną pracę infrastrukturalną. Nie może zdecydować, co znaczą dane sprzedawcy.

Wybierz encję pozostającą właściwą w czasie

Rozważ sklep sprzedający produkt w kilku rozmiarach. Instrukcja obsługi wspólna dla wszystkich rozmiarów może należeć do produktu. Kod identyfikujący konkretny rozmiar danego dostawcy może należeć do kombinacji lub osobnego modelu relacji. Umieszczenie obu na produkcie może dawać pozornie poprawne eksporty aż do wprowadzenia drugiego rozmiaru.

Zamówienia wprowadzają pytanie o czas. Jeśli wartość opisuje, co sprzedano w chwili zakupu, odczyt obecnej właściwości produktu po miesiącach może dać błędną odpowiedź historyczną. Zdecyduj, czy zamówienie potrzebuje migawki, referencji do trwałego rekordu zewnętrznego, czy żadnej kopii.

Nie używaj właściwości na poziomie klienta tylko dlatego, że wartość zebrano od klienta. Instrukcja dostawy dla jednego zakupu może zamiast tego należeć do adresu lub zamówienia. W przeciwnym razie kolejny zakup może odziedziczyć wartość, której klient nie zamierzał używać ponownie.

Użyj tego krótkiego wywiadu modelującego:

Wywiad powinien odbyć się przed programowaniem. Pole szybkie do dodania nadal może być później kosztowne w interpretacji.

Zakres sklepu i języka odpowiadają na różne pytania

Przetłumaczona etykieta to nie to samo co przetłumaczona wartość. Etykieta pola może być potrzebna w kilku językach pracowników, podczas gdy zapisana wartość jest pojedynczym kodem wewnętrznym. Z kolei instrukcja dla klienta może wymagać osobnej wartości dla każdego języka witryny.

Zakres sklepu opisuje, gdzie wartości różnią się handlowo lub operacyjnie. Dwa sklepy mogą współdzielić produkt, lecz używać różnych instrukcji realizacji. Nie jest to problem tłumaczenia. Nadanie sklepom różnych języków wyłącznie w celu odróżnienia wartości ukrywałoby rzeczywisty model danych.

Oddziel też dostępność pola od zmienności wartości. Właściwość może być istotna tylko dla wybranych sklepów. W ich obrębie wartość nadal może być wspólna lub specyficzna dla sklepu zgodnie z obsługiwaną definicją. Prace nad 9.2 obejmują możliwość ograniczania definicji właściwości do listy sklepów; to odrębna kwestia od ustalania, jak zmienia się wartość. Definicje ograniczone do sklepów.

Nie zakładaj, że wszystkie kombinacje zakresu są obsługiwane identycznie dla każdej encji i powierzchni integracji. Sprawdź aktualną implementację encji, którą planujesz rozszerzyć. Ogólny opis funkcji nie zastąpi niewielkiego dowodu działania dokładnego modelu.

Podczas oceny zakresu używaj celowo różnych wartości testowych. Jeśli oba sklepy zawierają „Standard”, przypadkowo współdzielona wartość może pozostać niewidoczna. Odmienne wartości pokazują, czy zapis, odczyt lub eksport użył zamierzonego kontekstu.

Widoczność to decyzja o danych, nie o stylu

Sprzedawca może chcieć pola w formularzu administracyjnym, ale nie w witrynie sklepu. Integracja może potrzebować wartości, która nigdy nie powinna pojawić się w szablonie produktu. Podejmuj te decyzje osobno.

Oficjalne wprowadzenie wyjaśnia, że Extra Properties w API są grupowane w przestrzeni nazw swojego modułu i dziedziczą uprawnienia encji nadrzędnej. Oznacza to, że możliwości API nie należy traktować jako niezależnej granicy poufności na poziomie pola. Zachowanie API w wyjaśnieniu funkcji.

Dla instrukcji wewnętrznej sprawdź wszystkich zamierzonych i niezamierzonych odbiorców: formularz, siatkę, odpowiedź API, dane witryny i moduły eksportu. Ukrycie kolumny siatki nie dowodzi, że wartości nie da się odczytać gdzie indziej.

Zachowaj szczególną ostrożność wobec wartości zawierających wrażliwe notatki biznesowe lub dane osobowe. Poprawną odpowiedzią może być bardziej wyspecjalizowany projekt przechowywania i autoryzacji. Ogólny mechanizm pól niestandardowych nie powinien automatycznie stawać się repozytorium informacji wymagających bardziej restrykcyjnego dostępu niż encja nadrzędna.

Dla wartości publicznych zdecyduj, czy są zwykłym tekstem, ograniczonym wyborem, adresem URL czy treścią formatowaną. Obsługa wyjścia powinna odpowiadać typowi. Wartość edytowalna w Back Office nadal może wymagać escapowania przy wyświetlaniu w witrynie.

Wartości domyślne, puste i unikalność wymagają jawnego znaczenia

Często istnieją co najmniej trzy stany: nieznany, celowo pusty i znacząca wartość. Wartość domyślna może je przypadkowo zlać. Jeśli każdy importowany produkt otrzymuje „Standard”, ponieważ dostawca pominął pole, personel może pomylić brak informacji ze zweryfikowaną klasyfikacją.

Zapisz zamierzone zachowanie dla starych rekordów, nowych rekordów i wyczyszczonych wartości. Wymagane pole potrzebuje także planu dla istniejących encji sprzed wprowadzenia wymogu. Bez niego zwykła edycja może zostać zablokowana przez nowo dodane ograniczenie.

Unikalność musi odpowiadać domenie biznesowej. Zewnętrzny identyfikator może być unikalny w obrębie jednego dostawcy lub sklepu, a nie całej instalacji. Założenie globalnej unikalności może odrzucać prawidłowe rekordy lub skłaniać personel do zmieniania identyfikatorów tylko po to, by zapisać formularz.

Wartości domyślne i ograniczenia powinny wspierać kontrakt danych, a nie rekompensować jego niejasność. Testuj je przez wszystkie obsługiwane ścieżki zapisu, w tym API, jeśli jest udostępnione. Widżet formularza nie jest jedynym miejscem wprowadzania wartości do systemu.

Niektóre dane należą do osobnego modelu

Extra Properties jest dobrym kandydatem dla niewielkiej liczby jasno zdefiniowanych atrybutów przypisanych do istniejących rekordów. Gorzej nadaje się jako cały model sekwencji zdarzeń, relacji wiele-do-wielu lub przepływu pracy wymagającego własnych uprawnień i transakcji.

Kategoria przechowywania produktu jest sensownym atrybutem. Rejestr każdego ruchu magazynowego jest historią zdarzeń. Zewnętrzna referencja zamówienia jest sensownym atrybutem. Pełny proces uzgadniania z próbami, błędami i zatwierdzeniami jest przepływem pracy.

Unikaj umieszczania dużych nieprzejrzystych dokumentów JSON we właściwości wyłącznie po to, by nie projektować relacji. Wartość strukturalna może pasować do ograniczonego celu, lecz nieograniczony dokument utrudnia wyszukiwanie, walidację i migrację. Zapytaj, jak operator zbadałby i naprawił jeden błędny element.

Podobnie odróżniaj faktyczne dane źródłowe od wartości pochodnych. Jeśli wartość można wiarygodnie obliczyć z istniejących rekordów, przechowywanie kolejnej kopii tworzy obowiązek synchronizacji. Może być uzasadniony, ale powinien być świadomy.

Dla propozycji pola wymagaj konkretnego przykładu i kontrprzykładu. „Referencja uzgodnienia zamówienia” to przykład; „pełna historia prób uzgodnienia” to kontrprzykład. To małe rozróżnienie pomaga przyszłym opiekunom zachować pierwotną granicę, gdy pojawią się nowe prośby.

Uzgodnij odpowiedzialność przed zapisaniem pierwszej rzeczywistej wartości

Utwórz krótką specyfikację pola z encją, przestrzenią nazw, typem, zakresem, wartością domyślną, zapisującym, odczytującymi i polityką usuwania. Dodaj zdanie opisujące, do czego pola nigdy nie wolno używać.

Na przykład wewnętrzna klasa obsługi może należeć do zespołu katalogu, być zapisywana przez kontrolowany import i odczytywana przy realizacji. Ręczne zmiany mogą być dozwolone tylko wtedy, gdy kolejny import je zachowuje. Jeśli wyjątek nie zostanie określony, integracja i personel będą wzajemnie nadpisywać swoje zmiany.

Zaplanuj także zachowanie przy wymianie i odinstalowaniu. Wyłączenie modułu, usunięcie jego definicji i usunięcie zapisanych danych to różne operacje. Oficjalny moduł przykładowy pokazuje destrukcyjne opcje usuwania, których nie należy bezmyślnie kopiować do biznesowej polityki przechowywania danych. Oficjalny moduł przykładowy.

Dobry projekt Extra Properties zaczyna się od małego, precyzyjnego faktu i śledzi go przez cały cykl życia. Gdy odpowiedzialność, zakres i widoczność są jasne, programista może wdrożyć pole bez podejmowania tych decyzji biznesowych niejawnie w kodzie.

Kontekst platformy znajdziesz w naszym przewodniku po tworzeniu modułów PrestaShop 9 i zastosuj powyższe kontrole specyficzne dla wersji do ocenianej instalacji.