Programista WooCommerce w Turynie

Sklep WooCommerce w Turynie stoi obok katalogu części Tier 1 z okolic Mirafiori z checkoutem B2B, sklepu spin-offu z I3P z subskrypcją boxa technologicznego, hurtowni z cenami według ról i fakturą z P.IVA albo sklepu merchowego przy Lingotto, który w tygodniu premiery modelu musi przeżyć skok ruchu bez gubienia callbacków Nexi. To nie jest powód, żeby Woo udawało ERP ani platformę PLM Stellantis. To powód, żeby checkout, bramki, IVA, dostawa i integracje magazynowe były napisane tak, jak oczekuje włoski dział compliance, magazyn w Piemoncie i zespół finansowy, który czyta wytyczne Garante Privacy, a nie tylko wynik Lighthouse na stronie kategorii.

WPPoland realizuje programowanie WooCommerce z polskiego zespołu seniorów dla firm w Turynie i w szerszym Piemoncie, które mają siedzibę, magazyn albo klientów we Włoszech. Zakres to checkout, Nexi, Satispay, strefy dostaw, logika podatkowa, hooki zamiast modyfikacji rdzenia i QA end-to-end na ścieżkach zamówień. Motyw WordPress, abonament opieki i kontakt są osobnymi tematami, z linkami na końcu.

#Programowanie WooCommerce dla sklepów Turynie

Turyn nie jest Mediolanem i nie jest Bolonią. Stolica Piemontu ma inny kalendarz, inny profil klienta i inny ekosystem vendorów niż fashion week w Porta Nuova albo Motor Valley wzdłuż A14. Tu liczy się Stellantis w Mirafiori, Lingotto z charakterystyczną rampą testową na dachu, Politecnico di Torino z jednym z najsilniejszych wydziałów inżynierii w Europie Południowej, inkubator I3P przy kampusie, OGR Torino (Officine Grandi Riparazioni) oraz setki dostawców Tier 1 w całym regionie. Brief od klienta w Turynie często brzmi: mamy Elementor i trzydzieści wtyczek, checkout trwa wieczność, Satispay działa losowo, a po aktualizacji Woo zamówienia wiszą na oczekującym. To jest problem architektury checkoutu i webhooków, nie problem szablonu z marketplace.

Typowy projekt, który trafia do seniorów Turynie, nie brzmi zróbcie sklep. Brzmi: odziedziczony Woo z page builderem, Nexi skonfigurowany przez agencję trzy lata temu, magazyn klei statusy ręcznie po Black Friday albo w tygodniu premiery produktu automotive, a dział prawny pyta, czy checkbox zgody w checkout i informativa privacy da się obronić przed Garante Privacy. To jest dług integracyjny, który wychodzi w piątek wieczorem przed otwarciem kampanii premiery, nie w audycie SEO.

WordPress Torino Meetup spotyka się w ekosystemie piemontskim. To nie jest kanał sprzedaży. To sygnał, że lokalna społeczność zna WordPress Coding Standards i widzi różnicę między checkoutem z WooCommerce Blocks a page builderem generującym shortcode’y w treści. Sklepy, które tu stawiamy albo naprawiamy, zwykle łączą dwa rytmy: codzienną sprzedaż B2C z dostawą BRT do aglomeracji turynskiej oraz skoki katalogu przed premierą modelu, kampanią rekrutacyjną Politecnico albo eventem branżowym w OGR Torino, gdy magazyn w Mirafiori albo fulfilment w okolicach Grugliasco musi wyjechać paletami GLS, a nie listem poleconym.

Prace trzymają się WooCommerce. Customizacje idą przez hooki action i filter oraz własną wtyczkę, nigdy przez edycję plików rdzenia. Granica między rdzeniem Woo, kodem wtyczki i motywem zapada na audycie i trafia do runbooka.

#Checkout, Nexi i Satispay

Sklep piemontski zbiera Satispay, kartę przez Nexi (XPay), czasem Apple Pay albo Stripe dla klientów międzynarodowych, a w B2B przelew z odroczonym terminem płatności. Webhooki bramki i status zamówienia muszą przeżyć aktualizację WooCommerce i patch wtyczki płatności. W Turynie do Stripe dochodzi Nexi i Satispay - metody, których kupujący oczekują w kasie, nie ciekawostka z ulotki integratora.

Przykład z audytu: zamówienie opłacone przez Satispay, a w panelu WooCommerce wciąż oczekujące na płatność, bo callback nie dotarł po patchu wtyczki albo bo środowisko testowe i produkcja miały różne URL callbacków. To nie jest błąd UX. To incydent operacyjny, który w tygodniu premiery produktu kosztuje więcej niż w styczniu, bo magazyn wysyła ręcznie albo anuluje zamówienia, które klient już opłacił.

Co wpisujemy w runbook bramki:

WooCommerce Blocks Checkout ma sens, gdy checkout ma być lekki i spójny z motywem blokowym. Klasyczny shortcode checkout zostaje, gdy odziedziczona warstwa pól i integracji jest zbyt kosztowna do migracji przed premierą produktu. Decyzja trafia do pisemnego kompromisu technicznego, nie do mody na bloki.

Skrypt bramki nie może blokować LCP na stronie checkout. Ładujemy go po interakcji albo z defer, testujemy na stagingu z tym samym CDN co produkcja. Dyrektor operacyjny z biura w Mirafiori nie akceptuje argumentu strona produktu jest szybka, kiedy checkout na mobile wisi trzy sekundy przed polem karty.

Kolejność metod na checkoucie ustawiamy pod włoskie nawyki: Satispay wysoko, karta przez Nexi niżej, PayPal dla klientów zagranicznych, contrassegno tylko w ścieżce B2C z jasnym komunikatem o opłacie za pobraniem, przelew bankowy w ścieżce B2B z jasnym komunikatem o czasie księgowania. Domyślny szablon Woo z kartą na górze i bez Satispay pracuje wbrew nawykom rynku włoskiego, w tym kupującego w Turynie, który woli Satispay przy koszyku z częścią zamenną albo gadżetem z kolekcji limited edition.

#IVA, faktury i dostawa w Piemoncie

Włoski sklep WooCommerce musi umieć IVA krajową 22 procent, stawki obniżone tam gdzie asortyment wchodzi, oraz OSS dla sprzedaży transgranicznej w UE bez ręcznego klejenia stawek w Excelu. Pola P.IVA i Codice Fiscale w checkout B2B, numer faktury w eksporcie do ERP i zgodność z włoskim fakturowaniem elektronicznym to decyzje w wtyczce checkoutu i integracji, nie w motywie.

Koszyk mieszany jest codziennością przy sklepie, który sprzedaje części zamienne obok materiałów B2B dla dystrybutorów z całej Europy. Woo musi liczyć podatek per pozycja, a nie weź najwyższą stawkę koszyka. Błąd w klasie podatkowej produktu wychodzi dopiero na fakturze, a nie w koszyku.

Dostawa w Turynie to nie jedna stawka Włochy. Klienci oczekują BRT (Bartolini), GLS Italy, Poste Italiane, SDA albo odbioru w punkcie. Kalkulator wysyłki musi liczyć wagę, wymiary i strefy (Piemont, reszta Włoch, UE) bez trzydziestu ręcznych reguł w panelu, które nikt nie aktualizuje po zmianie cennika przewoźnika. Integracja API przewoźnika dostaje log błędów i test na stagingu z adresem testowym, nie tylko działa u mnie na localhost.

Wielojęzyczność IT/EN w sklepie wymaga osobnej decyzji: WPML WooCommerce Multilingual, osobne slugi, hreflang na produktach i checkout, tłumaczenia maili transakcyjnych. Kampania włoska bez angielskiego checkoutu albo odwrotnie kończy się porzuconymi koszykami, których analytics nie wyjaśni bez nagrania sesji.

#Turyn: Mirafiori, premiera produktu i sezon e-commerce

Turyn nie jest Rzymem ani Florencją. Tu liczy się Mirafiori, Lingotto, Politecnico di Torino, I3P i kalendarz premier produktów automotive, który ustawia priorytety techniczne dla sklepu, który ma działać w Turynie, a nie tylko nosić to w tytule strony usługowej.

#Mirafiori i sklepy B2B

Stellantis w Mirafiori i łańcuch dostawców Tier 1 w całym Piemoncie to jeden z najbardziej rozpoznawalnych korytarzy przemysłowych Włoch. WooCommerce trzyma sklep części zamiennych, katalog B2B dla dystrybutorów, subskrypcję serwisową albo checkout, który musi przeżyć skok ruchu po współpracy z mediami branżowymi albo po demo dla partnera z łańcucha dostaw aerospace. Awaria checkoutu po aktualizacji wtyczki cache albo regresja w tłumaczeniach IT/EN boli w tygodniu audytu dostawcy, nie w sierpniu.

Development, który testuje tylko stronę główną kategorii, tego nie widzi. Development z runbookiem z listą bramek, webhooków, ścieżki koszyk do opłacone do mail do magazyn widzi. Turyn nie wymaga DC w samym mieście. Wymaga sensownej jurysdykcji hostingu w UE, stagingu z tym samym stosem płatności i rollbacku zapisanego przed wdrożeniem.

#Premiera produktu i zamrożenie wdrożeń

Premiera modelu automotive w Lingotto albo kampania rekrutacyjna Politecnico na wrzesień to jeden z największych okresów ruchu w piemontskim e-commerce B2B i B2C. W tym oknie setki dostawców części, spin-offów z I3P i partnerów eventowych patrzą na landingi produktowe, formularze zamówień i sklepy z merchandisingiem. Awaria checkoutu w środku tygodnia premiery to utracona sprzedaż i ręczne klejenie zamówień w magazynie, nie ticket do backlogu na październik.

Runbook developmentu dla klientów Turynie ma wpisane zamrożenie wdrożeń produkcyjnych na okno premiery produktu, zwykle od tygodnia przed premierą do tygodnia po kampanii. Aktualizacje krytyczne bezpieczeństwa przechodzą przez środowisko testowe i okno nocne z pełną regresją Nexi i Satispay. Reszta czeka. Kto robi drobny patch wtyczki płatności w piątek wieczorem przed otwarciem kampanii premiery, uczy się tego na własnej skórze, kiedy callbacki nie docierają pod obciążeniem.

#OGR Torino i drugie okno freeze

Event branżowy w OGR Torino albo targi automotive w Lingotto to drugi szczyt sezonu w Turynie. Rezerwacje, kampanie partnerskie i skoki ruchu na sklepach merchowych generują kolejną falę obciążenia checkoutu. Runbook ma osobny wpis freeze na okno eventu, zwykle od tygodnia przed otwarciem do tygodnia po zamknięciu. Dwa freeze w jednym kwartale to nie wyjątek. To normalny kalendarz operacyjny piemontskiego sklepu B2B albo eventowego.

#GDPR, Garante Privacy i dane w checkout

Po stronie włoskiej klient pyta o coś innego niż polski zespół domyślnie zakłada: gdzie leżą dane zamówienia, czy serwer jest w Unii Europejskiej, jak długo trzymamy logi płatności, kto jest administratorem danych, czy mamy umowę powierzenia z bramką i z hostem. Te pytania trzeba umieć obsłużyć konfiguracją checkoutu i dokumentacją, nie sloganem o zgodności z GDPR.

Włochy stosują rozporządzenie UE 2016/679 (GDPR) wraz z krajową implementacją w D.Lgs. 196/2003 (Codice Privacy), nadzorowaną przez Garante per la protezione dei dati personali. Dla WooCommerce w Turynie wynika z tego konkretny zakres prac: lista podprocesorów (host, CDN, Nexi, Satispay, poczta transakcyjna, analityka), umowa powierzenia tam gdzie agencja przetwarza dane, procedura naruszenia w 72 godziny, minimalizacja pól w checkout, informativa privacy i cookie policy zgodne z art. 13 GDPR.

Development nie zastępuje DPO klienta. Dostarcza konfigurację techniczną, którą właściciel może opisać w dokumentacji. Nikt po stronie agencji nie podpisuje się pod sklep jest zgodny z GDPR, bo macie SSL. Garante Privacy publikuje wytyczne na garanteprivacy.it; runbook projektu powinien być z nimi zgodny co do tego, co agencja dokumentuje, a co zostaje po stronie administratora danych.

Co wpisujemy w checkout i w kod:

• Checkbox zgody marketingowej tam gdzie consent jest wymagany, osobno od regulaminu sklepu i od informativa privacy.
• Wtyczki consent (Iubenda, Cookiebot, Complianz) konfigurujemy tak, żeby skrypty analityczne i piksel nie ładowały się przed akceptacją. To decyzja w kolejności enqueue, nie ticket po pierwszym pytaniu audytora Garante.
• Informativa privacy i regulamin to szablony z polami, nie bloki, które redaktor może usunąć z drzewa produktu.
• Logi callbacków Nexi przechowujemy z retencją uzgodnioną w runbooku, bez pełnych numerów kart w plain text.

Hosting w UE (AWS eu-south-1 w Mediolanie, OVH, Hetzner, Aruba, Seeweb, Scaleway) to odpowiedź na pytanie o jurysdykcję. Origin w Mediolanie albo Frankfurt plus CDN z terminałem TLS w UE zwykle wystarcza dla użytkowników Piemoncie. Decyzję opisujemy w runbooku, nie zgadujemy w rozmowie sprzedażowej.

Dla firm z sektora automotive i aerospace w Turynie compliance często dotyka też NIS2 i wymogów łańcucha dostaw: katalog B2B z danymi dystrybutorów, formularze z numerami P.IVA i identyfikatorami firm wymagają świadomej architektury, nie domyślnej konfiguracji checkout bez logów. Nie obiecujemy certyfikatu ISO 27001, którego nie było, ale konfiguracja WooCommerce musi umożliwiać audyt i minimalizację danych zgodnie z wytycznymi Garante.

#Webhooki, rezerwacja stanu i HPOS

Najczęstsza wada sklepów, które wracają do naprawy w Turynie, nie leży w wyglądzie checkoutu. Leży w tym, co dzieje się po kliknięciu Paga con Satispay albo Effettua ordine. Sklep z magazynem w aglomeracji turynskiej, który sprzedaje równolegle przez własne Woo i przez marketplace, płaci za ten błąd dwa razy: raz zamówieniem w limbo, drugi raz nadsprzedażą SKU, który był już zarezerwowany w drugim kanale.

Status zamówienia ustala powiadomienie serwer do serwera. Powrót klienta na stronę podziękowania nie jest źródłem prawdy. O pieniądzach decyduje callback bramki. Handler po weryfikacji sygnatury wywołuje payment_complete na obiekcie zamówienia. Cięższą pracę po weryfikacji zdejmujemy do Action Scheduler, żeby odpowiedź 200 wracała szybko i Nexi albo Satispay nie zaczęły ponawiać.

Powtórzony sygnał z bramki jest normą. Identyfikator zdarzenia zapisujemy w meta zamówienia i sprawdzamy przed przetworzeniem. Zamówienie już opłacone nie zmienia statusu drugi raz.

Stan rezerwujemy w momencie rozpoczęcia płatności, nie po jej potwierdzeniu. WooCommerce zapisuje rezerwację w tabeli wp_wc_reserved_stock. Bez tego dwoje kupujących wchodzi w Satispay na ostatnią sztukę limitowanego SKU z kolekcji premiery i oboje dostają potwierdzenie.

High-Performance Order Storage jest domyślny dla nowych instalacji od WooCommerce 8.2. Zamówienia żyją w wp_wc_orders i powiązanych tabelach, a nie jako wpisy shop_order w wp_posts. Diagnostyka idzie przez wc_get_orders oraz OrderUtil, nie przez SQL w wp_posts. Oficjalne Nexi, Satispay i Stripe są na HPOS od dawna. Problemem są stare konektory magazynowe.

#Architektura: hooki, wtyczka checkoutu i motyw

Sklep musi przetrwać aktualizacje WooCommerce. Customizacje idą przez udokumentowane hooki action i filter, plus podział na własną wtyczkę checkoutu i motyw tam gdzie powinno. Modyfikacje plików rdzenia Woo nie wchodzą w grę.

Granica jest prosta i zapisana w runbooku. Motyw umie pokazać produkt i kategorię. Wtyczka checkoutu umie wiedzieć: stawki IVA, mapowanie pól P.IVA, callback Nexi, eksport CSV do magazynu, reguły B2B. Jeśli po zmianie motywu znika logika Satispay albo ceny według ról, architektura była zła.

#Wydajność checkoutu i Core Web Vitals

Core Web Vitals na stronie produktu nic nie dają, jeśli checkout ma INP powyżej progu albo CLS skacze, gdy ładuje się widget płatności. Dla sklepów Turynie budżet wydajności obejmuje checkout, koszyk i stronę produktu z galerią w AVIF.

• LCP: obraz hero produktu w WebP/AVIF, preload tylko na above-the-fold, edge cache dla kategorii bez personalizacji koszyka.
• INP: minimalna hydracja na checkout, debounce na polach CAP, brak ciężkiego page buildera na stronie płatności.
• CLS: jawne wymiary obrazów katalogu, rezerwacja miejsca na banner consent, skeleton koszyka mini.

Monitorujemy Lighthouse CI na stagingu i CrUX po wdrożeniu. Regresja checkoutu blokuje deploy. Monitoring tylko z regionu USA kłamie dla kupujących w Piemoncie. Punkt pomiaru w UE jest częścią kontraktu operatorskiego.

#Integracje ERP, magazyn i marketplace

Druga powtarzalna integracja w Turynie to magazyn albo ERP: TeamSystem, Zucchetti, własny system w Mirafiori, fulfilment zewnętrzny. Zamówienie opłacone przez Satispay musi trafić do magazynu bez ręcznego eksportu CSV o północy. Webhook Woo do magazynu dostaje idempotencję, log błędów i alert, gdy kolejka stoi dłużej niż uzgodniony próg.

Synchronizacja stanów między Woo, marketplace (Amazon IT, eBay) i POS wymaga rozwiązywania konfliktów i audytu, kto nadpisał stan. Budujemy to w wtyczce integracyjnej, nie w piętnastu snippetach w motywie. Każda integracja ma test end-to-end na stagingu przed produkcją i wpis w runbooku freeze premiery produktu.

Dla spin-offów z I3P trzecia integracja to często sklep z subskrypcją boxa technologicznego albo katalog produktów badawczych z parametrami technicznymi, wielojęzyczne treści IT/EN/DE i embed z systemem konfiguracji. Motywy WordPress, Gutenberg i refaktoryzacje opisujemy na stronie programista WordPress w Turynie.

#Git, środowisko testowe i QA ścieżek zamówień

Repozytorium trzyma własną wtyczkę checkoutu i motyw sklepu. Gałąź funkcyjna na jedną zmianę: nowa strefa dostawy, poprawka callback Nexi, blok produktu. Pull request ma opis, nagranie checkoutu na mobile i checklistę: Nexi sandbox, Satispay test, mail transakcyjny, eksport magazynu.

Środowisko testowe jest kopią produkcji z zanonimizowanymi danymi klientów. TPV w sandbox, te same wtyczki płatności, ten sam CDN. Regresja IT/EN, regresja zwrotu i regresja aktualizacja Woo plus wtyczka płatności dzieją się tutaj. Promocja na produkcję jest udokumentowanym krokiem ze ścieżką wycofania.

QA end-to-end na stagingu pokrywa: koszyk gościa, koszyk zalogowany, Satispay, karta przez Nexi, błąd 3DS, anulowanie, zwrot częściowy, mail do klienta, status w panelu, wpis w logu magazynu. Bez tej listy każda aktualizacja jest ruletką.

#Profile projektów Turynie: cele techniczne na piśmie

Nie prezentujemy anonimowych case study z okrągłymi liczbami niemożliwymi do zweryfikowania. Opisujemy trzy profile projektów, które powtarzają się na rynku turynkim, i cele techniczne uzgadniane przed pierwszą linią kodu.

#Profil 1: katalog części Tier 1 w Mirafiori

Typowy projekt: sklep B2B traci zamówienia w checkout podczas kampanii premiery produktu albo w tygodniu targów automotive.

Zakres pracy:

• WooCommerce Blocks Checkout z Nexi i Satispay.
• Optymalizacja zapytań MySQL i cache obiektowy Redis na sesjach koszyka.
• Testy obciążeniowe checkoutu przed kampanią premiery na stagingu.

Cele techniczne w umowie: checkout poniżej uzgodnionego czasu na mobile w stagingu przed wdrożeniem, stabilność callbacków pod symulowanym szczytem, monitoring porzuconych koszyków z alertem regresji.

#Profil 2: hurtownia B2B w okolicach Lingotto

Typowy projekt: ceny według ról, minimalne zamówienia, faktura z P.IVA i integracja z magazynem w Piemoncie.

Zakres pracy:

• Wtyczka checkoutu z polami B2B i eksportem zamówień do ERP.
• Strefy dostaw BRT i paletowe stawki GLS.
• GDPR: rejestr podprocesorów i informativa privacy powiązana z checkout.

Cele techniczne w umowie: brak ręcznego eksportu CSV po opłaceniu zamówienia, regresja cen ról po aktualizacji Woo, dokumentacja przepływu danych pod pytania Garante Privacy.

#Profil 3: spin-off z I3P z ruchem międzynarodowym

Typowy projekt: sklep IT/EN ze Stripe dla UE poza Włochami i Nexi dla rynku krajowego, kampania pod premierę produktu co roku.

Zakres pracy:

• Dwa TPV z routingiem kraju w checkout.
• Zamrożenie wdrożeń w oknie premiery produktu z runbookiem incydentu.
• Feed produktowy Google Merchant Center z poprawnym IVA w feedzie.

Cele techniczne w umowie: hreflang na produktach, brak deploy checkoutu w oknie freeze bez pisemnej zgody, test callbacków po każdej aktualizacji wtyczki płatności.

#Zwroty i prawo konsumenckie jako operacje sklepu

Poniższe akapity opisują skutki w sklepie. Nie są poradą prawną. Teksty condizioni di vendita, informativa privacy i polityki zwrotów zatwierdza kancelaria albo odpowiedzialny w firmie. Zadaniem Woo jest spiąć ten tekst z koszykiem, z przyciskiem, z mailem i z magazynem.

Konsument we Włoszech ma prawo odstąpienia od umowy zawartej na odległość w ciągu 14 dni. Termin zaczyna biec, gdy klient otrzymał towar. Dla magazynu w Turynie to SKU, którego nie wolno sprzedać drugi raz, bo może wrócić za trzy kwartały.

Ścieżka operacyjna, którą budujemy:

1. Klient składa zwrot z numerem zamówienia albo danymi, które pozwalają je znaleźć w wp_wc_orders.
2. Sklep ustawia status RMA, wysyła potwierdzenie i etykietę zwrotną BRT albo instrukcję nadania GLS.
3. Przyjęcie na magazynie zdejmuje blokadę SKU i dopiero wtedy idzie wc_create_refund na Nexi, Satispay albo przelew zwrotny.
4. Częściowy zwrot nie zamyka całego zamówienia i nie zwraca kosztów wysyłki w ciemno; kwoty bierze się z pozycji.
5. Towar wyłączony ze zwrotu musi mieć tę informację przy SKU przed zakupem.

Sezon po premierze produktu to test tej ścieżki. Sklep, który w październiku ręcznie klika zwroty w panelu Nexi, a stany poprawia w Excelu, rozjeżdża raport IVA i nadsprzedaje wracający towar.

#Bezpieczeństwo sklepu i PCI

WooCommerce z Nexi nie zastępuje certyfikacji PCI po stronie merchant ID klienta. Zespół nie pisze, że sklep spełnia PCI DSS Level 1 bez audytu klienta. WordPress ma dostarczyć: brak numerów kart w logach, HTTPS, nonce na checkout, limitowanie prób płatności, WAF na endpointach wp-login i xmlrpc wyłączony jeśli nieużywany.

Sekretów TPV nie ma w Git. Klucze Nexi idą przez zmienne środowiska. Konta sklepu mają role minimalne: redaktor produktu nie instaluje wtyczek na produkcji. Szerszy audyt bezpieczeństwa opisuje audyt bezpieczeństwa WordPress.

#Pytania, które zadają nam firmy w Turynie

Czy możecie przejąć istniejący sklep WooCommerce? Tak. Audyt wyłania krytyczne luki: stary PHP, wtyczki płatności bez łatek, callback Nexi wskazujący na stary URL, brak testu Satispay po ostatniej aktualizacji Woo, magazyn synchronizowany ręcznie. Lista napraw idzie przed większą przebudową checkoutu.

Czy pracujecie z firmami spoza Turynu? Tak. Znamy kontekst Stellantis, Mirafiori, Politecnico, I3P, Piemonte, Nexi, Satispay i Garante Privacy, ale współpracujemy z klientami w całych Włoszech i za granicą. Wiele firm w Turynie obsługuje magazyn w Piemoncie i klientów Mediolanie bez osobnego sklepu na każde miasto.

Jak obsługujecie sklepy wielojęzyczne? WPML WooCommerce Multilingual albo osobna strategia slugów i hreflang. Każda wersja językowa dostaje zlokalizowany checkout, maile transakcyjne i reguły IVA tam gdzie rynek tego wymaga. IT/EN to osobna decyzja architektoniczna zapisana przed implementacją.

Co obejmuje bieżące wsparcie? Po zakończeniu budowy sklep może przejść na opiekę techniczną WordPress w Turynie: testowane aktualizacje, regresja checkoutu, kopie, monitoring i runbook freeze premiery produktu. Szczegóły na stronie opieki, nie w tym briefie WooCommerce.

Czym różni się współpraca z WPPoland od lokalnej agencji w Turynie? Doświadczenie WooCommerce od lat, własne zaplecze techniczne, praca na jasnych założeniach: zakres, etapy i odpowiedzialność opisane przed wdrożeniem. Wycena jest indywidualna i zależy od zakresu, nie z gotowego cennika.

#Powiązane usługi

Jeśli obecna strona firmowa działa i potrzebuje motywu, Gutenberga albo refaktoryzacji przed sklepem, zobacz programistę WordPress w Turynie z integracjami i GDPR w kontekście całego WordPressa. Pillar bez miasta: programista WordPress. Stała opieka po uruchomieniu sklepu: opieka techniczna WordPress w Turynie albo pillar utrzymanie stron WordPress. Pełny zakres Woo bez miasta: programista WooCommerce. Dla porównania kontekstu lokalnego w innych włoskich ośrodkach: programista WooCommerce w Mediolanie, w Rzymie i we Florencji.

#Rozpocznij swój projekt w Turynie

Jeśli chcesz omówić programowanie WooCommerce, wyślij krótki opis obecnej sytuacji: bramki, integracje magazynowe, wersje językowe, ograniczenia compliance i terminy kampanii albo premiery produktu. Na tej podstawie sprawdzamy checkout, wskazujemy ryzyka callbacków i proponujemy praktyczny plan działania.

Jeśli planujesz nowy sklep, migrację checkoutu na Blocks albo refaktoryzację Nexi i Satispay przed premierą produktu, zacznij od spisania celów, ograniczeń i obecnego stanu integracji. Wycena jest indywidualna i zależy od zakresu prac.