Katalog produktów w Drupalu bez Commerce: najpierw dane

Nie każdy producent potrzebuje sklepu internetowego. Gdy sprzedaż odbywa się przez dystrybutorów albo handlowców, strona powinna przede wszystkim przedstawiać ofertę, ułatwiać porównywanie specyfikacji i kierować zainteresowanych kupujących do działu sprzedaży. Katalog produktów w Drupalu może spełniać tę funkcję bez modułu Drupal Commerce, czyli bez koszyka, składania zamówień i płatności online.

Punktem wyjścia są dane produktowe. Specyfikacje, wymiary, materiały, rodziny produktów, warianty, zdjęcia i dokumenty powinny być zapisane w ustrukturyzowanych rekordach, które Drupal może wykorzystywać na wielu stronach i w różnych kanałach. Pliki PDF nadal mogą być przydatne dla kupujących, ale nie powinny być jedynym miejscem, w którym zapisano informacje z katalogu.

To rozróżnienie ma znaczenie także w kontekście AI. Zarówno kupujący, jak i asystenci AI muszą znaleźć właściwy produkt, zrozumieć jego atrybuty i odróżnić poszczególne warianty.

W tym artykule:

• Projektowanie katalogu zaczyna się od potrzeb kupującego, a nie od koszyka
• Produkty jako rekordy z jasno określonymi powiązaniami
• Wspólne słownictwo dla atrybutów, rodzin i wariantów
• Komponenty powinny prezentować dane, a nie je powielać
• Listy produktów i filtry oparte na rzeczywistych kryteriach wyboru
• Dokumenty produktowe generowane z tych samych rekordów
• Informacje produktowe dostępne dla asystentów AI
• Kiedy katalog potrzebuje Drupal Commerce?
• Jak zaplanować katalog, który zespół utrzyma w aktualności?

Projektowanie katalogu zaczyna się od potrzeb kupującego, a nie od koszyka

Wyobraźmy sobie producenta pomp przemysłowych, który sprzedaje przez dystrybutorów. Jego klienci muszą znaleźć pompy odpowiednie do określonej cieczy, sprawdzić ich wymiary i dopuszczalne parametry pracy, pobrać dokumentację techniczną oraz zapytać o dostępność.

Najważniejszym przyciskiem na stronie może być „Poproś o wycenę” albo „Znajdź dystrybutora”. Żadne z tych działań nie wymaga systemu zamówień.

Przydatna strona produktu powinna zawierać:

• stały identyfikator produktu i nazwę modelu,
• opis przeznaczenia,
• specyfikację techniczną z jednostkami,
• dostępne warianty i różnice między nimi,
• zdjęcia, rysunki techniczne, instrukcje i certyfikaty,
• formularz kontaktowy, który przekazuje do zapytania identyfikator produktu albo wariantu.

Taka strona służy przede wszystkim do prezentowania informacji i ułatwia wybór odpowiedniego produktu. Potraktowanie jej jak sklepu internetowego wprowadza funkcje, z których zespół może nigdy nie skorzystać, a jednocześnie zwiększa zakres konfiguracji, testów i utrzymania.

Prace warto zacząć od katalogu. Decyzję o obsłudze transakcji można podjąć później, na podstawie rzeczywistego procesu sprzedaży.

Zarządzanie produktami na stronie producenta opisujemy także w artykule Jak efektywnie zarządzać produktami na stronie firmy produkcyjnej na Drupalu?.

Produkty jako rekordy z jasno określonymi powiązaniami

Ustrukturyzowane rekordy ograniczają konieczność aktualizowania tych samych informacji w wielu miejscach. Gdy zmienia się wymiar, wystarczy zaktualizować pole źródłowe, zamiast szukać wszystkich stron, tabel porównawczych i dokumentów, do których skopiowano tę wartość.

W Drupalu wykorzystanie encji (entity) nie oznacza automatycznie konieczności prowadzenia niestandardowych prac developerskich. Węzeł (node) jest już encją treści. Typ treści „Produkt”, zawierający pola o odpowiednio dobranych typach danych, może stanowić praktyczną podstawę katalogu.

Początkowy model dla producenta pomp może wyglądać tak:

Do wspólnych klasyfikacji, takich jak materiał czy zastosowanie, warto użyć terminów taksonomii. Encje Media mogą przechowywać dokumenty i zdjęcia wraz z metadanymi. Dzięki temu redaktorzy wykorzystują ten sam plik na wielu stronach, zamiast wgrywać osobne kopie.

Rodzinę produktów można odwzorować jako termin taksonomii, jeśli służy ona głównie do grupowania produktów. Jeśli wymaga rozbudowanej treści redakcyjnej, etapów akceptacji albo odrębnej struktury strony, lepiej sprawdzi się osobny typ treści.

Niestandardowe encje treści (custom content entities) warto stosować wtedy, gdy uzasadniają to specyfika danych produktowych i wymagania biznesowe. Takie encje zapewniają większą kontrolę nad logiką produktową, ale wymagają samodzielnego przygotowania i utrzymywania interfejsów redakcyjnych oraz funkcji związanych z cyklem życia danych.

W wielu katalogach typy treści, odwołania do encji (Entity Reference), taksonomia i Media zapewniają wystarczającą strukturę.

Wydzielanie porównywalnych wartości do pól opisujemy w artykule Modelowanie treści w Drupalu pod odpowiedzi kupujących: pola zamiast prozy.

Nadrzędne źródło danych dla każdego pola

Jeśli specyfikacjami technicznymi zarządza już system PIM, Drupal może publikować te wartości, a redaktorzy mogą rozwijać opisy i treści uzupełniające przeznaczone na stronę.

Tę granicę należy określić na wczesnym etapie. W przeciwnym razie redaktor może poprawić specyfikację w Drupalu, a kolejny import nadpisze tę zmianę.

Importowanie danych i łączenie rekordów powinno opierać się na stałych identyfikatorach zewnętrznych. Nazwy produktów się zmieniają, dlatego integracja potrzebuje trwalszego sposobu rozpoznawania tego samego rekordu.

Podział odpowiedzialności między Drupalem a systemami PIM i ERP opisujemy w artykule Integracja Drupala z PIM i ERP: specyfikacje dla kupujących.

Wspólne słownictwo dla atrybutów, rodzin i wariantów

Spójnie zdefiniowane atrybuty sprawiają, że porównania produktów są wiarygodne. Zapobiegają też typowemu problemowi w filtrach, gdy „stal nierdzewna”, „Nierdzewna” i „INOX” pojawiają się jako osobne opcje, choć oznaczają to samo.

Dla każdego atrybutu trzeba określić:

• znaczenie i zakres,
• typ danych,
• jednostkę, jeśli ma zastosowanie,
• dozwolone wartości albo słownik, do którego się odwołuje,
• rodziny produktów, w których atrybut występuje,
• reguły walidacji i wyświetlania.

Wymiar powinien być zapisany jako wartość liczbowa z określoną jednostką, a nie jako dowolny tekst, na przykład „około 12 cm”. Wartość można przechowywać w polu liczbowym, a jednostkę określać w konfiguracji pola albo w osobnym polu.

Niektóre specyfikacje wymagają bardziej rozbudowanej struktury. Minimalna i maksymalna temperatura pracy powinny być osobnymi wartościami, a deklarowane natężenie przepływu może wymagać odwołania do warunków testu. Wartość podana bez warunków pomiaru może wprowadzić kupującego w błąd.

Brak wartości należy zapisywać tak, aby dało się go odróżnić od innych stanów. Puste pole określające graniczny parametr pracy nie oznacza wartości zero. Status „nie dotyczy” również nie oznacza tego samego co „jeszcze nie uzupełniono”.

Atrybuty przypisane do rodzin produktów

Rodziny pomp mogą mieć część atrybutów wspólnych, a część różnych. Pompa odśrodkowa i pompa dozująca nie muszą korzystać z identycznego zestawu pól specyfikacji.

Drupal nie rozpozna automatycznie tych różnic na podstawie samej nazwy rodziny. Trzeba je odwzorować w typach treści, konfiguracji pól, walidacji albo w niestandardowej logice formularza.

Przy niewielkiej liczbie stabilnych typów produktów pola zdefiniowane bezpośrednio w modelu treści są często łatwiejsze w utrzymaniu i obsłudze zapytań niż ogólny model atrybut-wartość. W katalogach obejmujących wiele zmieniających się zestawów atrybutów bardziej elastyczny model albo integracja z PIM mogą być uzasadnione.

O wyborze powinna decydować rzeczywista złożoność katalogu, a nie założenie, że kiedyś może on obejmować wszystko.

Osobny rekord dla wariantów, które kupujący rozróżniają

Wariant powinien mieć osobny rekord, gdy kupujący muszą go samodzielnie zidentyfikować, wskazać w zapytaniu albo porównać z innymi.

W ofercie producenta pomp poszczególne modele mogą różnić się napięciem i rozmiarem przyłącza. Każdy wariant może mieć własny identyfikator, specyfikację, rysunek oraz informacje przekazywane w zapytaniu ofertowym, nawet jeśli strona nie obsługuje zamówień.

Trzeba ustalić, gdzie zapisana jest każda wartość. Na przykład:

• rekord produktu zawiera wspólny opis i materiał obudowy,
• rekord wariantu zawiera napięcie, rozmiar przyłącza i wymiary zależne od konfiguracji,
• reguły wyświetlania określają, które wspólne wartości są prezentowane razem z wartościami przypisanymi do wariantu.

Dziedziczenie i nadpisywanie wartości wymaga w Drupalu wyraźnie zdefiniowanej logiki. Same odwołania do encji nie ustalają takich reguł.

W niewielkim katalogu zapisanie każdego oferowanego modelu jako osobnego, kompletnego rekordu produktu może być prostsze niż wprowadzanie mechanizmu dziedziczenia wartości. Właściwy model to taki, który redaktorzy mogą utrzymywać bez tworzenia sprzecznych informacji.

Komponenty powinny prezentować dane, a nie je powielać

Zespół marketingu potrzebuje swobody w opisywaniu produktów. Na jednej stronie może chcieć umieścić opis zastosowania, zdjęcie z montażu, panel specyfikacji i blok zapytania ofertowego.

Biblioteka komponentów zapewnia taką swobodę, podczas gdy dane produktowe pozostają przechowywane i edytowane w odpowiednich polach.

Zasada jest prosta: pola przechowują informacje produktowe, a komponenty je układają i wyświetlają.

Komponent specyfikacji powinien odczytywać pola produktu. Nie powinien udostępniać redaktorom kolejnego pola tekstowego, w którym wpiszą te same wymiary. Porównanie wariantów powinno wczytywać powiązane warianty, a nie wymagać utrzymywania osobnej tabeli przygotowanej ręcznie.

Drupal udostępnia kilka narzędzi, które pełnią tu różne funkcje:

• Tryby wyświetlania (view modes) i formatowanie pól (field formatters) określają, jak wyświetlane są dane encji.
• Layout Builder może zapewnić redaktorom kontrolę nad układem strony.
• Single Directory Components (SDC) pozwalają zebrać w jednym miejscu szablony, style i skrypty komponentów wielokrotnego użytku.
• Paragraphs, tam gdzie ma to uzasadnienie, mogą służyć do budowania ustrukturyzowanych sekcji redakcyjnych.

Sama biblioteka komponentów nie łączy automatycznie szablonów z polami produktu ani nie narzuca zasad edycji. Developerzy muszą przygotować te powiązania i skonfigurować dozwolone układy i bloki.

W katalogu pomp redaktorzy mogą układać wprowadzenie do produktu, tabelę specyfikacji, listę dokumentów, sekcję o zastosowaniach i blok zapytania. Wartości techniczne nadal pochodzą z rekordów produktu i wariantu.

W modelu treści powinno również pozostać miejsce na tekst ciągły, potrzebny między innymi do publikowania wskazówek montażowych i opisów zastosowań. Informacje wykorzystywane w filtrach, porównaniach i automatycznym pobieraniu danych powinny jednak pozostać w ustrukturyzowanych polach.

Podejście do pracy z komponentami wspólnie z klientem opisujemy w artykule Mindset komponentowy: jak nauczyć klientów myślenia komponentami.

Listy produktów i filtry oparte na rzeczywistych kryteriach wyboru

Dobrze zaprojektowane filtry ograniczają konieczność przeglądania wielu stron produktów, które nie spełniają wymagań kupującego.

Filtry warto projektować na podstawie tego, jak klienci wybierają urządzenia. W katalogu producenta pomp przydatne mogą być filtry według zastosowania, odporności na pompowaną ciecz, zakresu natężenia przepływu, materiału obudowy i rozmiaru przyłącza.

Moduł Views w Drupalu pozwala przygotować listy produktów oraz podstawowe filtry udostępnione użytkownikom (exposed filters). W przypadku bardziej wymagającego wyszukiwania można wykorzystać moduły z ekosystemu Search API, odpowiedni serwer wyszukiwania, na przykład Apache Solr, oraz zgodne moduły wyszukiwania fasetowego. Taki zestaw pozwala rozbudować indeksowanie i nawigację po katalogu.

Wybór architektury wyszukiwania zależy od wielkości katalogu i rodzaju zapytań. Mały katalog może nie potrzebować osobnej usługi wyszukiwania.

Przykład wyszukiwarki produktów opartej na Apache Solr opisujemy w artykule Zaawansowana wyszukiwarka produktów w Drupalu z integracją Apache Solr – przewodnik.

Czy wyniki pokazują produkty, czy warianty?

Wybór między produktami a wariantami wpływa zarówno na filtrowanie, jak i na poprawność wyników.

Załóżmy, że jeden wariant pompy jest dostępny w wybranym napięciu, a inny ma wybrany rozmiar przyłącza. Wyszukiwanie na poziomie produktu, które łączy atrybuty wszystkich wariantów, może zwrócić produkt nadrzędny, mimo że żaden pojedynczy wariant nie spełnia obu wymagań.

Aby uniknąć tej niejednoznaczności, warianty można indeksować osobno albo projektować zapytania, które zachowują powiązanie między atrybutami tego samego wariantu. Jeśli wyniki grupują pasujące warianty pod produktem nadrzędnym, strona powinna wyraźnie wskazywać, które warianty spełniają wybrane kryteria.

Trzeba również precyzyjnie określić zasady filtrowania zakresów wartości. Wyszukanie produktów, których maksymalne natężenie przepływu przekracza daną wartość, to inne zapytanie niż wyszukanie produktów, których zakres pracy obejmuje tę wartość.

W indeksie należy stosować spójne jednostki albo wartości przeliczone do wspólnej jednostki bazowej. Reguły filtrowania warto sprawdzić na rzeczywistych scenariuszach wyboru produktu, a przy każdym wyniku wyświetlić tyle kontekstu, aby kupujący rozumiał, dlaczego produkt spełnia kryteria.

Należy też zadbać o aktualność wyników wyszukiwania. Opublikowanie zmienionej specyfikacji powinno uruchamiać aktualizację indeksu i unieważnienie odpowiednich wpisów cache. W przeciwnym razie strona produktu i wyniki filtrowania mogą pokazywać różne wartości.

Dokumenty produktowe generowane z tych samych rekordów

Kupujący nadal potrzebują dokumentów. Wysyłają karty techniczne współpracownikom, dołączają je do wniosków zakupowych i zabierają na miejsce montażu.

Celem nie jest rezygnacja z plików PDF, lecz wyeliminowanie konieczności ręcznego utrzymywania tych samych specyfikacji w kilku miejscach.

Generator dokumentów może łączyć pola produktu, powiązane pliki i kontrolowany szablon, tworząc na ich podstawie kartę techniczną. Strona produktu i wygenerowany dokument korzystają wtedy z tego samego rekordu.

Proces generowania powinien:

1. wybierać właściwą opublikowaną rewizję produktu albo wariantu oraz język,
2. ustalać obowiązujące specyfikacje i zdjęcia,
3. tworzyć dokument na podstawie utrzymywanego szablonu,
4. zapisywać rewizję źródłową i datę wygenerowania,
5. ponownie generować dokument albo oznaczać dotychczasową kopię jako nieaktualną po zmianie rekordu źródłowego.

Taki proces wymaga w Drupalu integracji albo implementacji niestandardowej, ponieważ samo utworzenie pól produktu nie generuje plików PDF. W dużych katalogach wykorzystanie kolejki (queue) pozwala generować dokumenty w tle, niezależnie od żądania, w ramach którego użytkownik otwiera stronę.

Data dokumentu powinna być jednoznaczna. Data wygenerowania informuje, kiedy powstał plik, ale niekoniecznie, kiedy inżynier zweryfikował specyfikacje.

Niektóre dokumenty powinny pozostać plikami wgrywanymi ręcznie i objętymi osobną kontrolą. Podpisane certyfikaty, raporty z badań wydane przez podmioty zewnętrzne i zatwierdzone rysunki mają własne procesy zmiany wersji. Rekord produktu powinien odwoływać się do tych dokumentów, zamiast generować ich nowe wersje.

W przypadku dokumentów z ograniczonym dostępem reguły dostępu trzeba zastosować nie tylko do linku na stronie, ale też do adresu pobierania i miejsca przechowywania plików.

Generowanie plików PDF z encji opisujemy w artykule Utwórz plik PDF z dowolnej encji w Drupalu - Przegląd modułu Entity Print. Odwrotny kierunek, czyli przenoszenie danych z plików PDF do Drupala, opisujemy w artykule Pipeline w Drupalu: jak zamienić pliki PDF w treści strukturalne.

Informacje produktowe dostępne dla asystentów AI

Asystenci AI mogą uzyskiwać informacje z katalogu za pośrednictwem wyników wyszukiwania, treści stron, danych strukturalnych albo bezpośrednich integracji. Ustrukturyzowane rekordy produktów pomagają zachować spójność informacji udostępnianych we wszystkich tych kanałach.

Samo zastosowanie ustrukturyzowanych rekordów nie gwarantuje, że asystent znajdzie produkt lub uwzględni go w odpowiedzi. Zwiększa jednak szansę, że asystent poprawnie zinterpretuje informacje.

W przypadku katalogu producenta pomp asystent musi odróżnić rodzinę od modelu, rozpoznać wybrany wariant i powiązać specyfikację z jednostką i warunkami pracy. Folder plików PDF o niespójnych nazwach utrudnia każde z tych zadań.

Praktyczne podejście do publikacji obejmuje:

• Czytelny HTML: publiczne specyfikacje powinny być treścią strony z etykietami, dostępną dla odwiedzających i robotów wyszukiwarek.
• Stałe adresy URL i identyfikatory: produkty i warianty prezentowane jako osobne rekordy powinny mieć trwałe adresy i identyfikatory.
• JSON-LD: odpowiednie pola można zmapować na właściwości typu Product ze Schema.org i w razie potrzeby dodać kolejne właściwości.
• API albo kanały danych: zatwierdzone dane z pól mogą być udostępniane integracjom, które potrzebują ustrukturyzowanych rekordów.
• Spójna obsługa rewizji: zmiana rekordu źródłowego powinna prowadzić do aktualizacji wszystkich publikowanych na jego podstawie danych.

Znaczniki Schema.org powinny wiernie odzwierciedlać produkt widoczny na stronie. Nie należy dodawać fikcyjnych cen, dostępności, opinii ani ofert tylko po to, żeby wypełnić szablon. Poprawne znaczniki nie gwarantują też, że wyszukiwarka wyświetli produkt w wynikach rozszerzonych.

Moduł JSON:API z rdzenia Drupala może udostępniać dane encji, zależnie od konfiguracji i kontroli dostępu. Zakres danych publicznie udostępnianych przez API powinien wynikać ze świadomej decyzji dotyczącej publikacji. Trzeba przejrzeć włączone zasoby, dostęp do pól, nieopublikowane treści i powiązane pliki.

Eksport do formatu Markdown albo integracja z wykorzystaniem MCP (Model Context Protocol) mogą być przydatne w konkretnych procesach obsługiwanych przez agentów AI. Żadna z tych metod nie zastępuje dostępnych stron produktów i nie każdy katalog ich potrzebuje. Jeśli projekt obejmuje narzędzia dla agentów AI, trzeba określić, jakie dane mogą odczytywać i jakie działania wykonywać, a następnie zweryfikować skuteczność tych ograniczeń.

Najważniejsza jest spójność informacji. Dodanie kolejnego formatu danych do odczytu maszynowego nie rozwiąże problemu sprzecznych specyfikacji.

Generowanie JSON-LD z pól opisujemy w artykule JSON-LD w Drupalu: jak generować dane strukturalne z pól za pomocą Schema.org Metatag.

Kiedy katalog potrzebuje Drupal Commerce?

Drupal Commerce warto rozważyć, gdy strona ma obsługiwać procesy transakcyjne, a nie tylko prezentować produkty.

Samo pole z ceną ani identyfikator wariantu nie zmieniają strony w sklep internetowy.

Commerce wprowadza mechanizmy typowe dla sprzedaży online, takie jak warianty produktów przeznaczone do zakupu (purchasable variations), koszyk, zamówienia, proces składania zamówienia oraz integracje z bramkami płatności. Elementy te są potrzebne wtedy, gdy wynikają z rzeczywistych procesów sprzedażowych firmy.

Jeśli sprzedaż online jest już planowana, docelową architekturę warto uwzględnić przed budową katalogu. Stałe identyfikatory i jasno określone powiązania ułatwią późniejszą migrację. Przejście do Commerce nadal będzie jednak wymagało mapowania danych, zaprojektowania procesów transakcyjnych i przeprowadzenia testów.

Funkcje platformy opisujemy w artykule Przewodnik po platformie Drupal Commerce. Jakie są funkcje Drupal Commerce?.

Jak zaplanować katalog, który zespół utrzyma w aktualności?

Prace warto zacząć od reprezentatywnej rodziny produktów, łącznie z trudnymi przypadkami: brakującymi specyfikacjami, kilkoma wersjami językowymi, rysunkami przypisanymi do konkretnych wariantów i dokumentami wspólnymi dla wielu produktów.

Następnie warto przygotować jeden kompletny proces, od edycji danych po ich publikację, i sprawdzić stronę produktu, listę produktów, filtry, zapytanie ofertowe, dane do odczytu maszynowego oraz wygenerowaną kartę techniczną.

Na koniec warto zmienić jedną specyfikację i sprawdzić skutki tej zmiany w całym procesie. Czy dane zostały prawidłowo zaktualizowane we wszystkich kanałach? Czy redaktor widzi, których wartości brakuje? Czy zapytanie zawiera dokładnie ten wariant, który wybrał kupujący?

Takie testy pozwalają ocenić działanie katalogu lepiej niż sama dopracowana makieta strony.

Drupal dobrze sprawdza się wtedy, gdy katalog wymaga danych wykorzystywanych w wielu miejscach, powiązań między rekordami, procesów redakcyjnych, publikacji wielojęzycznej i udostępniania danych w kilku formatach. Mały, rzadko aktualizowany katalog z ograniczonym filtrowaniem może być łatwiejszy w utrzymaniu na prostszej platformie. Producent z rozbudowanymi procesami zarządzania danymi produktowymi może potrzebować systemu PIM działającego obok Drupala.

Najważniejsze rozróżnienie nie dotyczy wyboru między katalogiem a sklepem, lecz między ustrukturyzowanym katalogiem a informacjami powielanymi ręcznie w wielu miejscach. Model danych warto zaprojektować na podstawie informacji potrzebnych kupującym, a następnie wykorzystywać te same dane na stronach, w dokumentach i integracjach.

Planowanie katalogu produktów w Drupalu bez Commerce warto rozpocząć od analizy konkretnych materiałów. Na rozmowę wystarczy przykładowa rodzina produktów, kilka kart technicznych i pytania, które kupujący zadają najczęściej. Porozmawiajmy o modelu danych, filtrach i procesie publikacji oraz sprawdźmy, czy którakolwiek część procesu sprzedażowego rzeczywiście wymaga Drupal Commerce. Więcej o naszej pracy można przeczytać na stronie poświęconej wdrożeniom Drupala.