Programista WooCommerce w Pradze

Polski zespół programistyczny, który buduje WooCommerce dla firmy w Pradze, 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 kampanię przed WebExpo albo szczyt rekrutacyjny w Q4. Ta strona opisuje dedykowane programowanie WooCommerce właśnie w tym układzie: polski delivery, kontekst Karlína, Smíchova, fintech i centrum usług wspólnych w aglomeracji praskiej, 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 Pradze. Stała opieka po wdrożeniu: opieka techniczna WordPress w Pradze. Headless storefront, gdy Woo zostaje tylko silnikiem zamówień: migracja Next.js i Astro w Pradze.

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

Dedykowany sklep WooCommerce to decyzja architektoniczna zapisana przed pierwszym commitem, nie pięć wtyczek premium wklejonych w panelu. Dla firmy w Pradze, która sprzedaje D2C obok dealera, prowadzi katalog B2B dla partnerów z Karlína albo testuje subskrypcję consumables dla klientów SSC przy Florenc, 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 Pragi, 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 Pradze

• 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

#Praga: Karlín, fintech i e-commerce w stolicy

Praga to nie Brno z większą liczbą mieszkańców. Stolica Czech ma inny kalendarz konferencyjny (WebExpo co roku ustawia deadline na landingi i formularze demo), gęstszy ekosystem międzynarodowych firm i wyższą poprzeczkę compliance niż drugi ośrodek kraju. Karlín to hub startupów i scale-upów wzdłuż řeky Vltavy, Smíchov zbiera biurowce IT i fintech, Holešovice łączy kreatywną scenę z software house’ami, a Florenc i Pankrác trzymają centra usług wspólnych grup europejskich.

Dla programisty WooCommerce w Pradze ten kontekst ustawia priorytety inaczej niż w czysto marketingowej agencji: klient bywa inżynierem z ČVUT albo product managerem z SSC, 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 Pradze 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.

#Karlín, Smíchov i spin-offy D2C

Firmy z Karlína i akceleratorów przy Rohanském nábřeží często startują z produktem hardware albo SaaS, a WooCommerce trzyma warstwę D2C: pierwsze zamówienia prototypu, subskrypcja consumables, merchandising employer brandingowy przed rundą seed. 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.

#Fintech, SSC i katalogi B2B w Pradze

W Smíchovie, przy Václavském náměstí i w biurowcach Pankráce siedzą software house’y, fintech, SSC i BPO, których sklep WooCommerce bywa witryną katalogową B2B z logowaniem partnera, zamówieniami na numer partii albo frontem D2C, 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 fintech tier-one”. Trzeba napisać wtyczkę mapującą pola na system klienta i motyw, który nie cache’uje koszyka zalogowanego wholesaler na CDN.

WebExpo w Pradze to nie tylko adres na mapie. To konferencja, która co roku zbiera frontend, product i marketing tech, i która ustawia deadline na landingi, formularze demo zbierające dane pod GDPR CZ oraz profile rekrutacyjne. Sklep WooCommerce w tym środowisku nie zastępuje platformy inwestycyjnej, ale kampania przed konferencją musi wytrzymać szczyt ruchu w piątek wieczorem, nie produkować incydentu operacyjnego w poniedziałek rano, gdy prawnik pyta o zgłoszenie do UOOU.

#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 obcą domenę. Comgate i GoPay to standardy, które software house z Pragi 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.

Porównanie warstw przy kickoffie w Pradze:

#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: UOOU w Pradze

Czechy wdrożyły rozporządzenie UE 2016/679 (GDPR) przez zákon č. 110/2019 Sb. o zpracování osobních údajů. Nadzór: Úřad pro ochranu osobních údajů (UOOU) z siedzibą przy Pplk. Sochora 27 w Pradze 7. Dla sklepu WooCommerce w Pradze to nie jest abstrakcyjny paragraf prawny. To decyzje w formularzach checkoutu, w wtyczkach consent, v zásadách ochrany osobních údajů i w logach audytowych.

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, Iubenda popularne w Czechach) musi przetrwać aktualizację motywu i cache. GTM i Meta Pixel nie mogą odpalać się przed zgodą, bo marketing w Pradze też słyszy o UOOU.

Lista podprocesorów umowie powierzenia obejmuje hosta (Wedos, 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.

Przy incydencie z danymi osobowymi art. 33 GDPR daje administratorowi 72 godziny na zgłoszenie do UOOU, o ile naruszenie może wiązać się z ryzykiem pro práva a svobody osob. Agencja WooCommerce nie składa raportu za klienta. Dostarcza oś czasu, której klient nie musi rekonstruować z pamięci i ze Slacka.

#Hosting w UE i impressum z obchodního rejstříku

Dane osobowe pod GDPR CZ ciągną pytanie: w której jurysdykcji stoi serwer i kopia. Wedos, Forpsi, Active24, Český hosting i mniejsze hostery z datacenter w Czechach albo w UE to nazwy, które klient w Pradze rozpoznaje, gdy pyta „kde leží WordPress”. Rozmowa o hostingu w onboardingu jest operatorska, nie wizerunkowa. Czy produkcja jest w UE? Czy kopia wyjeżdża nocą poza jurysdykcję, którą klient akceptuje? Czy CDN kończy TLS w Czechach, w innym kraju UE, czy w USA?

eIDAS (910/2014) i czeska bankovní identita nie są „wtyczką WooCommerce”. Są kontekstem dla logowania partnera B2B. Jeśli klient podpina OAuth u bankovní identity albo korporacyjnego IdP, w developmentcie pilnujemy redirect URI, przechowywania tokenów, timeoutów sesji i tego, żeby środowisko testowe nie wyciekał do Google przez robots.txt.

#Para CS/EN i katalog wielojęzyczny

Praga to nie tylko czeski front. B2B i D2C w stolicy często wymagają czeskiego frontu w rejestrze vykání i angielskiej wersji dla zagranicznych partnerów, inwestoró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 Karlína angielski bywa językiem dokumentacji produktowej; dla SSC przy Florenc 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 Pradze 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 Pradze

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. Freeze przed WebExpo albo kampanią korporacyjną zapisany w runbooku. 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: kampania przed WebExpo i cache checkoutu

Dostawca SaaS z Karlína, 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 WebExpo, 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 Pradze 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 z zgłoszeniem do UOOU po stronie klienta, 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 Pradze

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 Pradze wymaga tylko optymalizacji checkoutu, zostajemy przy Woo. Jeśli cała instalacja potrzebuje refaktoryzacji od motywu, odsyłamy do WordPress developera w Pradze albo łączymy oba streamy w jednym programie z jasną granicą zakresu prac.

#Jak zacząć projekt sklepu w Pradze

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 Pradze szanujemy poprzeczkę Karlína i fintech: kod, który da się utrzymać, środowisko testowe przed produkcją, płatności CZK testowane na kartach, nie na klientach, GDPR CZ pod nadzorem UOOU traktowane serio od pierwszego formularza checkoutu.