Programista WooCommerce w Brnie

Polski zespół programistyczny, który buduje WooCommerce dla firmy w Brnie, nie dokłada „gotowego motywu sklepowego z marketplace”. Pisze checkout, który ma obsłużyć płatność w koronach, webhook Comgate o trzeciej w nocy, integrację z Pohoda i pytanie księgowego o DPH w tym samym tygodniu, w którym marketing chce nową kampanię pod Targi Brno. Ta strona opisuje dedykowane programowanie WooCommerce właśnie w tym układzie: polski delivery, kontekst Technologického parku Brno, ekosystemu Škoda i software house’ów z Jihomoravského kraje, bez cennika na stronie i bez obietnicy, że „motyw premium wystarczy”.

Szerszy opis roli programisty WooCommerce, niezależny od miasta, jest na stronie programista WooCommerce. Warstwa WordPress pod sklepem (motyw, wtyczki, portale B2B): programista WordPress w Brnie. Stała opieka po wdrożeniu: opieka techniczna WordPress w Brnie. Headless storefront, gdy Woo zostaje tylko silnikiem zamówień: migracja Next.js i Astro w Brnie.

#Co oznacza dedykowany WooCommerce w Brnie, a nie szablon sklepu

Dedykowany sklep WooCommerce to decyzja architektoniczna zapisana przed pierwszym commitem, nie pięć wtyczek premium wklejonych w panelu. Dla firmy w Brnie, która sprzedaje części do łańcucha Škoda, prowadzi D2C obok dealera albo testuje subskrypcję consumables dla klientów B2B, motyw sklepowy z marketplace kończy się w momencie, gdy trzeba podpiąć stany magazynowe z Pohoda, wymusić fakturę z IČO na checkoutie albo dodać Zásilkovna z mapą punktów odbioru bez psucia Core Web Vitals.

Granica między motywem a wtyczką jest wtedy operacyjna. Prezentacja katalogu, szablony produktu, archiwum kategorii i checkout block idą do motywu albo child theme. Integracje bramek, logika DPH, synchronizacja ERP, custom order statuses, endpointy REST i narzędzia administracyjne idą do wtyczki, żeby przetrwały wymianę motywu za dwa lata. Jeśli reguła cenowa B2B jest „tylko widoczna w koszyku”, nadal sprawdzam, czy nie powinna żyć w wtyczce, bo inaczej aktualizacja WooCommerce psuje rabat dla roli wholesaler.

WordPress Coding Standards, PHPCS w CI, gałęzie feature z przegląd kodu i środowisko testowe identyczny ze stosem produkcji to warunek, żeby za rok inny programista, czy to z Brna, czy z Polski, mógł wgrać łatkę bezpieczeństwa bez czytania trzech lat historii Slacka. Modyfikacje plików rdzenia WooCommerce odrzucamy na etapie audytu. Vendor lock-in przez wtyczkę „mostek do ERP” bez dokumentacji też.

#Co dostarczamy w projektach WooCommerce w Brnie

• Checkout CZK z bramkami Comgate, GoPay, Stripe i Apple Pay tam, gdzie bramka to wspiera; webhooki z idempotencją i runbookiem testów kart
• Integracja Zásilkovna, PPL, Česká pošta ze strefami dostaw, wagą, wymiarami i mapą punktów odbioru w checkout block
• Logika DPH CZ, faktury z polami IČO/DIČ, obsługa reverse charge dla B2B UE tam, gdzie scope tego wymaga
• Katalogi B2B: ceny według ról, minimalne wielkości zamówienia, rejestracja partnera z walidacją IČO z obchodního rejstříku
• Synchronizacja produktów i stanów z Pohoda, Money S3 albo magazynem klienta przez REST, webhook albo zaplanowany import z rozwiązywaniem konfliktów
• WooCommerce Subscriptions i billing cykliczny z testami na stagingu przed pierwszą produkcyjną opłatą
• Rozszerzenia REST API i headless storefront (Astro, Next.js) tam, gdzie front musi być aplikacją, a Woo zostaje silnikiem zamówień
• Para CS/EN z WPML albo Polylang: hreflang, osobne slugi, checklista regresji checkoutu w obu językach po każdym release

#Brno: tech park, automotive i e-commerce

Brno to drugi ośrodek technologiczny Czech po Pradze. Technologický park Brno (TPB) przy Udolní, JIC (Jihomoravské inovační centrum), VUT (Vysoké učení technické v Brně) wypuszczające spin-offy, a obok nich Red Hat, Honeywell, Siemens i software house’y budujące produkty B2B. Dla programisty WooCommerce w Brnie ten kontekst ustawia priorytety inaczej niż w czysto marketingowej agencji: klient bywa inżynierem, który rozróżnia wtyczkę od motywu i wie, że „szybki motyw sklepowy” z trzydziestoma wtyczkami third-party to dług, nie oszczędność.

Sklep w Brnie często nie jest jedynym kanałem sprzedaży. Bywa obok dealera, marketplace B2B, intranetu zamówień i Excela, który księgowość traktuje jak ERP. WooCommerce ma połączyć te światy albo chociaż nie udawać, że jest jedynym źródłem prawdy o stanie magazynowym, jeśli Pohoda już tę rolę pełni.

#Technologický park Brno i spin-offy D2C

Firmy z TPB i akceleratorów JIC często startują z produktem hardware albo SaaS, a WooCommerce trzyma warstwę D2C: pierwsze zamówienia prototypu, subskrypcja consumables, merchandising employer brandingowy. Wzorce się powtarzają: szybki sklep na motywie premium, potem żądanie integracji z Comgate, potem Zásilkovna, potem para CS/EN, gdy pierwszy kontrakt wychodzi poza Czechy.

W takim cyklu refaktoryzacja checkoutu z wycięciem ciężkiego page buildera bywa tańsza niż rok utrzymywania instalacji, która przy każdym patchu Woo psuje sekcję upsell w koszyku. Budujemy checkout block i szablony produktu, które redakcja konfiguruje, ale kod integracji idzie do wtyczki w Git.

#Ekosystem Škoda i katalogi B2B

Škoda Auto ma siedzibę w Mladá Boleslav, ale Jihomoravský kraj i okolice Brna są pełne dostawców komponentów, integratorów produkcji i firm logistycznych. Ich WooCommerce bywa witryną katalogową B2B z logowaniem partnera, zamówieniami na numer partii albo frontem D2C dla części zamiennych, gdzie klient końcowy płaci kartą w koronach, a faktura musi przejść audyt u odbiorcy tier-one.

Typowe wymagania: walidacja IČO partnera przy rejestracji, strefa zalogowanego dostawcy z cenami netto, brak indeksowania strefy B2B, PDF specyfikacji do zamówienia, integracja stanów z magazynem klienta. Motyw sklepowy premium nie ma wtyczki „dostawca automotive tier-one”. Trzeba napisać wtyczkę mapującą pola na system klienta i motyw, który nie cache’uje koszyka zalogowanego wholesaler na CDN.

#Płatności CZK i checkout pod rynek czeski

Czeski klient B2C oczekuje płatności kartą, Apple Pay albo Google Pay tam, gdzie bank to wspiera, oraz przelewu online przez bramkę, która nie wyrzuca go z checkoutu na obcy domen. Comgate i GoPay to standardy, które software house z Brna rozpoznaje; Stripe bywa wyborem, gdy produkt idzie poza Czechy od pierwszego dnia. PayPal bywa drugorzędny na rynku CZ, ale w scope B2B eksportowym nadal się pojawia.

Dla każdej bramki dokumentuję obsługiwane flow: jednorazowa płatność, subskrypcja, zwrot pełny, zwrot częściowy, 3DS, timeout webhooka. Matryca kart testowych leży w runbooku, nie w głowie jednego developera. Webhook, który dwa razy dostarczy to samo zdarzenie payment.captured, nie może utworzyć drugiego zamówienia. Idempotencja to kod w wtyczce, nie obietnica w PDF od bramki.

Checkout block WooCommerce (bloki serwerowe) bywa lepszym wyborem niż legacy shortcode [woocommerce_checkout], bo łatwiej kontrolować pola IČO, Zásilkovna picker i walidację po stronie serwera. Nie wdrażamy checkout block „bo modny”. Wdrażamy go, gdy testy regresji na stagingu pokazują, że utrzymanie shortcode po aktualizacji Woo kosztuje więcej niż migracja.

#DPH, faktury i compliance handlowe CZ

Sklep w Czechach musi mówić językiem księgowości klienta, nie tylko marketingu. DPH (daně z přidané hodnoty), faktura s IČO a DIČ, správné sazby podle typu zboží i místa dodání to elementy checkoutu i panelu zamówień, nie PDF wysyłany ręcznie po tygodniu. WooCommerce Tax albo wtyczka dedykowana musi być skonfigurowana z runbookiem, który księgowy klienta rozumie.

Dla B2B w UE reverse charge i walidace DIČ přes VIES bywają w scope. Dla D2C transgranicznego OSS to osobna decyzja biznesowa; programista implementuje to, co prawnik i księgowy zatwierdzą na piśmie, nie zgaduje stawki z bloga SEO. Generowanie faktury PDF po opłaceniu zamówienia wymaga szablonu zgodnego z praxí klienta, nie polskiego wzoru skopiowanego z innego projektu.

Obchodní rejstřík i impressum to element frontu sklepu, nie przypis w stopce. IČO, DIČ, právní forma s.r.o. albo a.s., sídlo zgodne z výpisem z OR muszą być w szablonie jako pola edytowalne. Po migracji na nowy motyw sklepowy to bywa pierwszy błąd, który právní oddělení widzi przed programistą.

#GDPR CZ w sklepie WooCommerce, nie tylko w polityce prywatności

Czechy wdrożyły GDPR przez zákon č. 110/2019 Sb. Nadzór: Úřad pro ochranu osobních údajů (UOOU). Sklep WooCommerce przetwarza dane osobowe od pierwszego kliknięcia „Přidat do košíku”: konto, adresy, historia zamówień, IP w logach bramki, marketing po zgodzie.

Formularze checkoutu projektujemy z minimalizacją pól. Checkboxy zgód nie mogą być pre-zaznaczone. Log zgód z wtyczki cookie (Complianz, Cookiebot) musi przetrwać aktualizację motywu i cache. GTM i Meta Pixel nie mogą odpalać się przed zgodą, bo marketing w Brnie też słyszy o UOOU.

Lista podprocesorów umowie powierzenia obejmuje hosta (Wedos ma korzenie w Brnie, Forpsi, Active24, Hetzner w DE), CDN, bramkę płatniczą, pocztę transakcyjną, backup, analitykę. Programista nie zastępuje DPO. Dostarcza konfigurację i opis, co gdzie trafia, żeby klient mógł uzupełnić zpracování osobních údajů. Transfer poza UE wymaga osobnej oceny; backup na S3 w Ohio „bo taniej” kończy rozmowę na onboardingowym callu.

#Para CS/EN i katalog wielojęzyczny

Brno nie jest Pragą, ale B2B i D2C w regionie często wymagają czeskiego frontu w rejestrze vykání i angielskiej wersji dla zagranicznych partnerów albo matki w Niemczech. WPML WooCommerce Multilingual albo Polylang rozwiązują hreflang i duplikację produktów. Nie rozwiązują procesu: kdo schvaluje český popis produktu, kdo angielski, než to jde na produkci.

W każdym release sprawdzamy: czy CS i EN mają właściwe URL produktów, czy hreflang nie wskazuje 404, czy zásady ochrany osobních údajů i obchodní podmínky istnieją w obu wersjach, czy checkout zwraca błędy walidacji w obu językach, czy diakritika v češtině nie została zepsuta po imporcie z polskiego panelu tłumaczeń. Sklep, który serwuje angielski tytuł produktu z czeskim opisem z fallbacku, psuje konwersję szybciej niż słaby LCP.

Dla firm z TPB angielski bywa językiem dokumentacji produktowej; dla dostawcy automotive niemiecki bywa trzecim językiem w roadmapie. Architekturę i18n planujemy na etapie audytu, nie po wdrożeniu pierwszego języka „bo WPML da radę”.

#Architektura: wtyczka, motyw, headless

Dla nowych sklepów Brnie domyślnym wyborem jest motyw blokowy z szablonami produktu i checkout block, bo tam zmierza WooCommerce i bo utrzymanie shortcode legacy bywa droższe po dwunastej aktualizacji Woo w roku. Headless ma sens, gdy front musi być aplikacją: konfigurator z tysiącami wariantów SKU, PWA dla techników terenie, marketplace z osobnym frontendem. Wtedy Woo zostaje silnikiem zamówień i REST API, a front idzie do Astro albo Next.js. Decyzję zapisuję jako pisemny kompromis techniczny z kosztem pięcioletnim.

REST API WooCommerce i custom endpointy w wtyczce dokumentujemy w runbooku, z wersjonowaniem i rate limitingiem. Synchronizacja katalogu z ERP bywa jednokierunkowa (ERP → Woo) albo dwukierunkowa z kolejką i dead letter; w obu przypadkach Action Scheduler albo WP Cron musi mieć monitoring, bo cichy fail synchronizacji to sprzedaż na minusie, której nikt nie widzi przez tydzień.

Redis object cache, Elasticsearch albo FacetWP do wyszukiwania produktów, Cloudflare na CDN i WAF to warstwa infrastruktury uzgadniana z hostingiem klienta (Wedos, Forpsi, dedykowany VPS w UE). Nie sprzedajemy hostingu jako obowiązku. Konfigurujemy sklep pod hosting, który klient już ma albo wybierze po audycie.

#Proces realizacji w Brnie

Każdy projekt idzie przez ten sam szkielet. Szczegóły w howTo w frontmatter; tu w skrócie operacyjnie.

Odkrywanie i audyt. Przegląd katalogu, checkoutu, bramek, dostaw, integracji ERP, pary CS/EN, impressum, cookie bannera i budżetu wydajności na trzech realnych URL-ach (kategoria, produkt, checkout). Wynik to lista ryzyk z priorytetem i propozycja kształtu dostarczenia.

Specyfikacja techniczna. Decyzje: refaktoryzacja vs nowy motyw sklepowy, granica wtyczka/motyw, wybór bramek, endpointy integracji, kryteria odbioru, harmonogram w sprintach. Zatwierdzasz plan przed pierwszą linią kodu produkcyjnego.

Implementacja w sprintach. Demo na koniec sprintu na stagingu. przegląd kodu na każdej gałęzi. Testy płatności kartami testowymi na każdej bramce. Zmiana priorytetu między sprintami jest możliwa, ale wpływ na harmonogram idzie na piśmie.

QA i wdrożenie. Regresja CS/EN, koszyk, checkout, webhooki, maile transakcyjne, faktury PDF, Lighthouse na uzgodnionych URL-ach. Deploy z rollbackiem. 72 godziny gotowości po starcie na incydenty launchowe.

Przekazanie. Dokumentacja dla managerów sklepu (jak edytować produkt, jak obsłużyć zwrot) i dla programistów (jak uruchomić lokalnie, jak deployować, runbook bramek). Sesja przekazania na żywo. Opcja stałej opieki.

#Przypadek: promocja przed Targi Brno i cache checkoutu

Dostawca komponentów z okolic Technologického parku, WooCommerce B2B z warstwą D2C, około trzech tysięcy SKU, Comgate i GoPay, Zásilkovna, para CS/EN. Poprzedni wykonawca włączył full-page cache na całą domenę „dla szybkości”. Marketing chciał kod rabatowy na targi branżowe w Brnie, start w piątek rano.

Na stagingu przed wdrożeniem wyszło trzy rzeczy naraz. Koszyk zalogowanego wholesaler dostał cenę detaliczną z cache CDN, bo URL koszyka nie był wykluczony. Webhook GoPay przy opóźnieniu retry utworzył duplikat zamówienia, bo brak idempotencji w wtyczce. Wersja angielska checkoutu serwowała czeski tekst pola IČO po imporcie tłumaczeń WPML.

Promocja na produkcję w piątek skończyłaby się fakturą z błędną stawką DPH i duplikatami w Pohoda. Na stagingu wykluczyliśmy /kosik, /checkout, /muj-ucet z cache, dodaliśmy idempotencję webhooków, poprawiliśmy mapę tłumaczeń pól checkoutu. Checklista CS/EN i test płatności na obu bramkach przeszły, dopiero potem produkcja. Nie ma tu nazwy firmy; to kształt zdarzenia, który w Brnie wraca przy każdej większej kampanii u klienta z integracją ERP.

#Wydajność i Core Web Vitals w sklepie

Wolny sklep kosztuje: klient porzuca koszyk, partner B2B nie dociera do PDF cennika, Google obniża widoczność kategorii. Core Web Vitals traktujemy jako budżet uzgodniony na starcie, mierzony na realnych URL-ach produktu, kategorii i checkoutu w CS i EN, weryfikowany na CrUX tam, gdzie ruch na to pozwala.

LCP obniżamy przez AVIF/WebP na zdjęciach produktów, preload hero na landingach kampanijnych, edge cache dla publicznych kategorii i brak slidera 400 kB na stronie głównej sklepu. INP psuje się od live chatu dodanego poza ticketingiem, od tag managera przed zgodą cookie i od hydracji całego checkoutu w kliencie; checkout block i minimalny JS tam, gdzie to możliwe. CLS: wymiary obrazów produktów, rezerwacja miejsca na banner cookie, brak wstrzykiwania upselli nad przyciskiem „Zaplatit” bez slotu.

Katalog z tysiącami SKU wymaga paginacji, lazy load albo faceted search z indeksem, nie WP_Query na każdym filtrze bez cache. Po wdrożeniu regresję wydajności łapie Lighthouse CI na stagingu; więcej w przyspieszeniu WordPress.

#Bezpieczeństwo jako lista decyzji

HTTPS z HSTS tam, gdzie infrastruktura pozwala. Content Security Policy ograniczająca inline XSS. Wyłączenie XML-RPC, jeśli nie jest używany. 2FA na kontach administracyjnych sklepu. Minimum kont z rolą administrator. Zakaz wtyczek nulled. Wyłączenie edytora plików wp-admin na produkcji. Nonce na formularzach checkoutu i rejestracji B2B.

Przy danych osobowych kupujących: umowa powierzenia, procedura naruszenia pod GDPR CZ, jasny podział administrator vs processor. WAF (Cloudflare, reguły u hostera) kupuje czas, nie zastępuje aktualizacji Woo. Kopie testowane odtwarzaniem zamówienia testowego, nie tylko zielonym jobem w panelu.

Sklep po incydencie z wtyczką płatności, która logowała pełne numery kart w plain text w wp-content, uczy tego samego: środowisko testowe, review, wycofanie zmian, audyt logów. Bezpieczeństwo to dyscyplina release, nie plakietka PCI w stopce bez scope.

#Powiązane usługi: filary i strony w Brnie

Ta strona dotyczy programowania WooCommerce. Sąsiednie ścieżki:

Nie sprzedajemy wszystkiego naraz. Audyt mówi, która ścieżka ma sens. Jeśli sklep w Brnie wymaga tylko optymalizacji checkoutu, zostajemy przy Woo. Jeśli cała instalacja potrzebuje refaktoryzacji od motywu, odsyłamy do WordPress developera w Brnie albo łączymy oba streamy w jednym programie z jasną granicą zakresu prac.

#Jak zacząć projekt sklepu w Brnie

Wyślij krótki opis: co sprzedajesz (B2C, B2B, oba), ile SKU, jakie bramki i dostawcy są dziś albo mają być, czy jest CS/EN, gdzie stoi hosting, czy jest środowisko testowe, czy integracja z Pohoda albo innym ERP jest w scope. Z tego przygotujemy propozycję audytu albo fixed-scope na pierwszy sprint, z harmonogramem i wyceną indywidualną w umowie, bez cennika na stronie.

Budujemy WooCommerce od lat obok WordPressa ogólnego od 2007 roku. Wiemy, gdzie Woo wystarczy jako monolit, a gdzie checkout block i REST to dopiero początek headless. W Brnie szanujemy poprzeczkę tech parku i łańcucha automotive: kod, który da się utrzymać, środowisko testowe przed produkcją, płatności CZK testowane na kartach, nie na klientach, GDPR CZ traktowane serio od pierwszego formularza checkoutu.