Kontekst: po co w ogóle „inteligentna” stopka

W klasycznym OpenCart 3 układ stopki wynika z pliku common/footer w motywie oraz z modułów przypiętych do pozycji layoutu. To podejście działa, dopóki marketing i obsługa sklepu nie proszą o częste zmiany: nową kolumnę z linkami do kategorii, inny zestaw ikon social, osobny blok tekstowy na promocję sezonową albo chwilowe wyciszenie jednego wiersza bez grzebania w kodzie FTP. Każda taka prośba w tradycyjnym modelu oznacza albo edycję Twigów, albo kombinację z modułami HTML — oba warianty szybko stają się kosztowne w utrzymaniu i podatne na błędy przy aktualizacjach motywu.

Moduł Design Cart Footer odpowiada na ten ból, traktując stopkę jak mały system layoutu: definiujesz wiersze, w każdym wierszu do czterech kolumn, a w kolumnach umieszczasz kafle (bloki) wybierane z palety — kategorie, produkty, podstrony informacyjne, predefiniowane linki systemowe, nagłówki, tekst, obraz z linkiem, a także gotowe „moduły” zbiorcze dla danych kontaktowych i social media skonfigurowanych w osobnych ekranach panelu. Dzięki temu osoba bez dostępu do repozytorium kodu może realnie zarządzać treścią strefy pod produktami, a programista zostawia w repozytorium jedynie spójny pakiet plików i ewentualnie dopasowuje style do identyfikacji wizualnej marki.

Z perspektywy użytkownika końcowego dobrze zaprojektowana stopka skraca ścieżkę do kontaktu, do regulaminów i do social proof — czyli elementów, które w sklepach niszowych często decydują o konwersji przy porównywalnej ofercie cenowej. Z perspektywy właściciela sklepu moduł ten jest więc nie tylko „ozdobnikiem”, lecz narzędziem operacyjnym: szybka zmiana bez deployu, powtarzalny układ dla wielu wierszy, możliwość klonowania wiersza gdy sekcja ma się powtórzyć z drobną modyfikacją.

Demo: nasz sklep internetowy na którym właśnie przebywasz ma stopkę zbudowaną właśnie za pomocą modułu DC Footer.

Zobacz wideo prezentujące DC Footer w akcji:

Czym jest moduł i dla kogo

Design Cart Footer to rozszerzenie dla OpenCart 3 od Design Cart, które składa się z kilku warstw: kontrolera i modelu po stronie administracji, modelu po stronie katalogu (witryny), pakietu szablonów Twig dla panelu, modyfikacji OCMOD podmieniającej zachowanie kontrolera catalog/controller/common/footer, oraz biblioteki PHP w system/library/dc_footer/catalog_mixin.php, która wstrzykuje dane i rejestruje style oraz skrypty tuż przed wyrenderowaniem alternatywnego widoku stopki.

Docelowi odbiorcy to właściciele i agencje utrzymujące sklepy na OC3, które potrzebują elastycznej stopki bez przechodzenia na ciężkie page buildery ani na pełną przebudowę motywu. Moduł zakłada znajomość podstaw OpenCarta: instalacja rozszerzeń, odświeżanie modyfikacji, uprawnienia grup użytkowników oraz świadomość, że podmiana widoku common/footer jest inwazyjna — musi współgrać z motywem i innymi OCMOD-ami dotykającymi tej samej linii kodu.

Architektura: OCMOD, mixin i szablon zastępczy

Serce integracji z rdzeniem sklepu stanowi plik modyfikacji (w dystrybucji modułu często nazwany unstall.xml lub analogicznie — ważna jest treść, nie tylko nazwa pliku). Modyfikacja wyszukuje w catalog/controller/common/footer.php fragment zwracający widok domyślnej stopki i — warunkowo, gdy w ustawieniach włączony jest status module_dc_footer_status — wykonuje trzy kroki: ładuje bibliotekę mixin, wywołuje funkcję dc_footer_catalog_mixin($this, $data), a następnie zwraca widok extension/module/dc_footer/footer zamiast common/footer.

Funkcja mixin w pliku catalog_mixin.php pełni rolę mostu między kontrolerem stopki a modelem ModelExtensionModuleDcFooter. Ładuje skompilowany zestaw danych (getCompiled): ustawienia globalne (szerokość kontenera), wiersze z bazy, kontakty i social media. Następnie dla każdego wiersza dekoduje JSON layoutu (z obsługą typowych problemów importu: BOM UTF‑8, encje HTML, podwójne escapowanie), normalizuje liczbę kolumn do maksymalnie czterech oraz buduje HTML poszczególnych bloków funkcją dc_footer_render_block. Dzięki temu szablon Twig widoku stopki pozostaje cienki: iteruje po wierszach, kolumnach i gotowych fragmentach HTML, zamiast zawierać skomplikowaną logikę warunkową.

Warstwa administracyjna to klasyczny kontroler admin/controller/extension/module/dc_footer.php z wieloma akcjami: pulpitu (index), edycji wiersza (row), ekranów kontaktów i social, ustawień globalnych oraz endpointów AJAX do sortowania, kopiowania, usuwania wierszy i autouzupełniania palety kategorii, produktów i stron informacyjnych. Zasoby JS/CSS panelu są dokładane przez Document::addStyle i addScript ze ścieżek względnych do katalogu admin/view/template/extension/module/dc_footer/..., co ułatwia utrzymanie paczki w jednym drzewie szablonów modułu.

Instalacja, pliki i zależności

Instalacja typowa dla OC3 wymaga skopiowania zawartości katalogu upload/ do odpowiadających ścieżek na serwerze (admin, catalog, system), następnie zainstalowania lub odświeżenia modyfikacji w Rozszerzenia → Modyfikacje oraz wyczyszczenia cache modyfikacji i cache szablonów (Twig). W panelu modułów należy włączyć Design Cart Footer i nadać uprawnienia grupie administratorów do trasy extension/module/dc_footer.

Po stronie serwera moduł zakłada dostęp do MySQL z uprawnieniami tworzenia tabel (przy pierwszej instalacji modelu) oraz standardowe mechanizmy OpenCarta: biblioteka obrazka (tool/image) do miniaturek kontaktów i ikon social, konfiguracja języka i sklepu. Nie jest wymagany Composer ani zewnętrzne pakiety PHP — logika jest samowystarczalna, z wyjątkiem jQuery UI używanego w panelu do sortowania i przeciągania kafli (ładowane z zasobów admina lub CDN w zależności od akcji kontrolera).

Lista plików krytycznych dla działania ścieżki sklepowej obejmuje m.in.: system/library/dc_footer/catalog_mixin.php, catalog/model/extension/module/dc_footer.php, catalog/view/theme/default/template/extension/module/dc_footer/footer.twig oraz pliki CSS/JS wskazywane w mixin — domyślnie catalog/view/theme/default/template/extension/module/dc_footer/css/dc-footer.css i .../js/dc-footer.js. Każda zmiana motywu z inną nazwą katalogu motywu wymaga dostosowania ścieżek w mixin lub nadpisania plików w motywie potomnym.

Panel administracyjny — przewodnik po funkcjach

Pulpit i lista wierszy

Po wejściu w moduł administrator widzi pulpit z kafelkami skrótów: dodanie nowego wiersza, przejście do danych kontaktowych, social oraz ustawień globalnych. Poniżej znajduje się lista zdefiniowanych wierszy stopki z możliwością zmiany kolejności przez przeciąganie (sortowanie zapisuje się przez żądanie AJAX). Przy każdym wierszu dostępne są akcje edycji, kopiowania i usuwania — klonowanie jest szczególnie przydatne, gdy tworzysz serię podobnych sekcji różniących się tylko treścią kafli.

Edycja wiersza: układ i paleta

Edycja wiersza to dwuwidokowa forma: zakładka ogólna (nazwa, liczba kolumn od jednej do czterech, layout przechowywany jako JSON) oraz zakładka wyglądu, gdzie definiujesz tło wiersza, paddingi, kolory treści i nagłówków, typografię, linki, a także separator pionowy między kolumnami. W części layoutu wybierasz aktywną kolumnę i przeciągasz elementy z palety: kategorie, produkty, podstrony CMS, linki systemowe (np. koszyk, logowanie, kontakt), bloki niestandardowe (nagłówek, tekst z zachowaniem łamów linii, obraz z opcjonalnym URL, dowolny link) oraz moduły zbiorcze kontaktu i social.

Paleta wyszukiwania kategorii, produktów i informacji korzysta z endpointów API modułu filtrujących wyniki po frazie — dzięki temu nie musisz znać identyfikatorów z pamięci. Dla linków systemowych etykiety pochodzą ze słownika językowego modułu (np. „Koszyk”, „Rejestracja”), co utrzymuje spójność tłumaczeń między panelem a witryną tam, gdzie etykiety są budowane z danych panelowych.

Kontakty i social media

Osobne ekrany pozwalają zarządzać listą wpisów kontaktowych (etykieta, treść, opcjonalny obrazek z biblioteki obrazów) oraz wpisów social (tytuł, URL, ikona/obraz). Te zbiory są niezależne od konkretnego wiersza — w layoutcie dodajesz je jako pojedynczy kafel „moduł”, który przy renderze sklepu expanduje się do listy linii kontaktu lub siatki linków social z atrybutami rel="nofollow noopener noreferrer" tam, gdzie mixin to przewiduje.

Screen: edycja danych kontaktowych

Screen: edycja danych socialmedia

Ustawienia globalne i status modułu

W ustawieniach definiujesz maksymalną szerokość kontenera treści stopki w pikselach lub procentach oraz status włączenia modułu zapisywany w standardowej tabeli ustawień OpenCarta pod kluczem modułu. Szerokość jest przekładana na inline style max-width z wyśrodkowaniem marginesami automatycznymi, co sprawdza się w motywach opartych na kontenerze Bootstrapa, ale wymaga kontroli, czy nadrzędny layout nie narzuca własnych ograniczeń szerokości.

Warstwa danych: tabele i format JSON

Instalator modelu administracyjnego tworzy cztery tabele z prefiksem bazy sklepu: dc_footer_settings (pary klucz–wartość per store_id, m.in. global, appearance, misc), dc_footer_row (wiersze z polami layout_json i appearance_json), dc_footer_contacts oraz dc_footer_socials. Usunięcie modułu przez standardowy uninstall może skasować te tabele — przed eksperymentami na produkcji warto wykonać kopię zapasową bazy lub wyeksportować same tablice modułu.

Model katalogu duplikuje część logiki odczytu z myślą o wydajności witryny: pobiera skompilowany zestaw danych jednym przebiegiem pod render strony. Zawiera też metody pomocnicze do rozwiązywania ścieżek kategorii (getCategoryPathString), nazw encji w bieżącym języku oraz list kontaktów i social z filtrem status = 1, dzięki czemu w panelu możesz przygotować wpisy „w szufladzie” i publikować je dopiero po ustawieniu statusu (o ile taka kolumna jest wykorzystywana w danych — w praktyce warto to zweryfikować w swojej wersji tabel).

JSON layoutu przechowuje strukturę kolumn jako tablice bloków; każdy blok ma przynajmniej pole type i parametry specyficzne dla typu (identyfikatory, tekst, URL, poziom nagłówka). Mixin przy renderze sanituruje dane wyjściowe: tekst jest escapowany encjami HTML, atrybuty href podlegają dekodowaniu encji i ponownemu escapowaniu z korektą ampersandów tam, gdzie to potrzebne, co ogranicza ryzyko typowych błędów przy linkach generowanych przez Url::link.

Witryna sklepu: renderowanie bloków i bezpieczeństwo

Na froncie sklep nie wykonuje skomplikowanego JavaScriptu do budowy DOM — HTML powstaje po stronie PHP. Kategorie, produkty i strony informacyjne są mapowane na linki przez oficjalne API adresów OpenCarta, z fallbackiem nazwy zapisanej w bloku, jeśli tłumaczenie w bazie zniknęło. Obrazy niestandardowe są wczytywane z katalogu image/ z odrzuceniem ścieżek z .., a następnie skalowane przez model_tool_image::resize z rozsądnym limitem wymiarów, aby nie zalać strony megapikselową grafiką przypadkowo wgraną przez redakcję.

Dla typu „system” mixin filtruje trasę do bezpiecznego zbioru znaków i rozwiązuje etykietę: dla information/information próbuje pobrać tytuł strony z bazy, dla pozostałych tras korzysta ze statycznej mapy na klucze językowe nagłówka i stopki rdzenia (common/header, common/footer), ładowanych jednorazowo przy pierwszym użyciu — dzięki temu etykiety typu „Koszyk” są spójne z tłumaczeniem motywu, o ile dane klucze istnieją w aktywnym pakiecie językowym.

Wiersze bez żadnego bloku są pomijane, co zapobiega renderowaniu pustych pasów tła. Separator kolumn ostatniej kolumny jest usuwany (same paddingi i flex), żeby układ wyglądał naturalnie na szerokich i wąskich ekranach — detale te są ważne przy ocenie „jakości pixel‑perfect” po stronie CSS motywu nadrzędnego.

Motyw, CSS, JavaScript i nadpisywanie

Mixin rejestruje arkusz dc-footer.css oraz skrypt dc-footer.js względem domyślnego motywu default. W praktyce agencja często kopiuje te pliki do motywu niestandardowego i zmienia ścieżki w mixin albo dodaje własne reguły nadpisujące zmienne CSS ustawiane inline w dc_footer_row_wrapper_style — zmienne typu --dcf-hc (kolor nagłówków), --dcf-lc (kolor linków) itd. pozwalają stylować wiersz bez rozcinania logiki PHP.

W paczce modułu mogą istnieć dodatkowe arkusze w katalogu catalog/view/theme/default/stylesheet/ służące jako materiały pomocnicze lub starsze warianty — decydujące są ścieżki użyte w mixin. Przy wdrożeniu warto trzymać się jednej kanonicznej ścieżki i dokumentować ją w README projektu sklepu, by kolejne aktualizacje modułu nie nadpisały przypadkiem lokalnych poprawek bez merge’a.

Wielosklepowość, języki i typowe pułapki

OpenCart pozwala prowadzić wiele sklepów z jednego panelu. Moduł operuje na store_id w tabeli wierszy i ustawieniach — jeśli w konfiguracji adresu admina pracujesz na innym sklepie niż domyślny front, upewnij się, że edytujesz właściwy kontekst sklepu w URL panelu. Model katalogu zawiera logikę fallbacku: gdy dla danego sklepu brak wierszy lub globalnych ustawień, może odczytać dane ze sklepu o identyfikatorze zero lub jedynego sklepu, z którego pochodzą rekordy — zachowanie to ratuje jednosklepowe instalacje, w których pierwszy zapis poszedł pod „obcym” identyfikatorem sklepu, ale bywa mylące przy świadomym rozdzieleniu treści per sklep; warto to przetestować na stagingu.

Wielojęzyczność treści katalogowych (nazwy kategorii, produktów, stron) jest rozwiązywana przez identyfikator języka wynikający z sesji lub konfiguracji, z zapasowym odczytem z tabeli language. Treści wpisywane ręcznie w blokach niestandardowych są wspólne — jeśli potrzebujesz osobnych wersji językowych tego samego wiersza, naturalnym obejściem jest zduplikowanie wiersza i przypisanie go do innego układu layoutu per język albo rozszerzenie modułu o pola wielojęzyczne (wymaga pracy programistycznej poza standardem).

Utrzymanie, kopie zapasowe i rozszerzenia

Moduł ingeruje w globalny punkt wyjścia stopki — przy aktualizacji OpenCarta lub motymu warto ponownie zweryfikować, czy wzorzec wyszukiwania w OCMOD nadal pasuje do pliku common/footer.php w danej wersji rdzenia. Konflikt z inną modyfikacją podmieniającą tę samą linię objawia się brakiem działania jednego z rozszerzeń lub podwójnym zamknięciem HTML; narzędzie logów modyfikacji i ręczny podgląd skompilowanego pliku w system/storage/modification/ są tu najlepszymi przyjaciółmi administratora.

Kopie zapasowe powinny obejmować zarówno pliki (szczególnie własne poprawki w mixin i CSS), jak i tabele modułu. Przed migracją na nowy serwer warto wyeksportować ustawienia modułu i zawartość czterech tabel, a po imporcie odświeżyć cache i sprawdzić ścieżki do obrazów w image/. Jeśli integrujesz analitykę lub chat w oryginalnej stopce, upewnij się, że po przejściu na widok modułu nadal ładują się one z nagłówka lub z innego hooka — moduł nie zastępuje nagłówka, ale zastępuje całą stopkę jako widok.

W panelu mogą pozostawać pliki historyczne (np. alternatywny szablon formularza modułu lub dodatkowe arkusze admina) niewykorzystywane przez aktualny kontroler — nie szkodzą, dopóki nie wprowadzają chaosu w dokumentacji wdrożeniowej; przy porządkowaniu repozytorium warto je oznaczyć jako „legacy” albo usunąć po potwierdzeniu braku referencji.

Podsumowanie

Design Cart Footer dla OpenCart 3 to kompletne narzędzie do budowy wielowarstwowej stopki opartej na wierszach, kolumnach i kafelach z palety, z osobną konfiguracją danych kontaktowych i mediów społecznościowych. Technicznie opiera się na modyfikacji OCMOD, bibliotece catalog_mixin.php i cienkim szablonie Twig, który korzysta z wcześniej zbudowanego HTML i list zasobów dokumentu. Dobre wdrożenie to nie tylko instalacja plików, lecz także świadomy wybór motywu, test wielosklepowy, weryfikacja konfliktów OCMOD oraz utrzymanie spójnej ścieżki do CSS/JS po stronie sklepu.

Jeśli traktujesz stopkę jak produkt — czytelny, spójny z marką i łatwy do zmiany — moduł ten znacząco skraca dystans między pomysłem marketingowym a wdrożeniem na żywym sklepie, zostawiając programiście przestrzeń na dopracowanie detali wizualnych zamiast na powtarzalne grzebanie w szablonach rdzenia przy każdej akcji sezonowej.