Programista WooCommerce w Walencji

Sklep WooCommerce w Walencji stoi obok hurtowni B2B eksportera cytrusów z Huerta de Valencia z fakturą IVA i dostawą SEUR do Niemiec, sklepu meblowego z checkoutem Bizum dla klientów Comunitat Valenciana, subskrypcji boxa agrotech z Valencia Digital District rozliczanej cyklicznie przez Redsys oraz sklepu z pamiątkami turystycznymi, który w marcu musi przeżyć skok ruchu pod Las Fallas bez gubienia callbacków płatności. To nie jest powód, żeby Woo udawało system rezerwacyjny hotelowy ani platformę biletową portu. To powód, żeby checkout, bramki, IVA, dostawa i integracje magazynowe były napisane tak, jak oczekuje hiszpański dział compliance, magazyn przy Muelle Turia i zespół finansowy, który czyta wytyczne AEPD, a nie tylko wynik Lighthouse na stronie kategorii.

WPPoland realizuje programowanie WooCommerce z polskiego zespołu seniorów dla firm w Walencji i w szerszej Comunitat Valenciana, które mają siedzibę, magazyn albo klientów Hiszpanii. Zakres to checkout, Redsys, Bizum, 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 Walencji

Walencja to trzecie co do wielkości miasto Hiszpanii, węzeł logistyczny Morza Śródziemnego z Puerto de Valencia, ośrodek turystyczny od City of Arts and Sciences po plaże Malvarrosa oraz hub cyfrowy wokół Valencia Digital District w La Marina. To nie jest Madryt korporacyjny ani Barcelona modowa. Tu liczy się sklep produktowy marki z ekosystemu portowego, hurtownia B2B dostawcy mebli z okolic Gandii, eksport cytrusów z Huerta z checkoutem w EUR i dostawą do całej UE, subskrypcja boxa z rozliczeniem cyklicznym i checkout, który musi przeżyć skok ruchu w tygodniu Las Fallas, kiedy compliance i tak pyta o hosting w UE i o política de privacidad pod AEPD.

Brief od klienta w Walencji często brzmi: mamy Elementor i czterdzieści wtyczek, checkout trwa wieczność, Bizum działa losowo, a po aktualizacji Woo zamówienia wiszą na oczekującym. To jest problem architektury checkoutu i callbacków Redsys, nie problem szablonu z marketplace. Typowy projekt, który trafia do seniorów Walencji, nie brzmi zróbcie sklep. Brzmi: odziedziczony Woo z page builderem, Redsys skonfigurowany przez agencję trzy lata temu, magazyn klei statusy ręcznie po sezonie eksportowym, a dział prawny pyta, czy checkbox zgody w checkout i política de privacidad da się obronić przed AEPD. To jest dług integracyjny, który wychodzi w marcu przed Fallas albo w szczycie sezonu portowego, nie w audycie SEO.

#Checkout, Redsys, Bizum i bramki hiszpańskie

Sklep hiszpański zbiera kartę przez Redsys, płatność mobilną Bizum, czasem PayPal, Apple Pay albo Google Pay. Callbacki bramki i status zamówienia muszą przeżyć aktualizację WooCommerce i patch wtyczki płatności. W Walencji do Stripe dochodzi Redsys i Bizum - metody, których kupujący w Hiszpanii oczekują w kasie, nie ciekawostka z ulotki integratora.

Przykład z audytu: zamówienie opłacone przez Bizum, a w panelu WooCommerce wciąż oczekujące na płatność, bo callback Redsys 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 marcu, w tygodniu Fallas, 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:

Redsys, TPV wirtualny, który komercjalizują większość hiszpańskich banków, pracuje z parametrami Ds_MerchantParameters, Ds_Signature i Ds_SignatureVersion, i podpisuje HMAC SHA-256 z kluczem pochodnym od numeru zamówienia. Pole decydujące to Ds_Merchant_MerchantURL, powiadomienie, które bank wysyła bezpośrednio na serwer sklepu. Ds_Merchant_UrlOK i Ds_Merchant_UrlKO to tylko doświadczenie użytkownika. Bizum włącza się w tym samym TPV przez Ds_Merchant_PayMethods, więc dziedziczy ten sam kanał powiadomień, ale zmienia zachowanie kupującego: płatność z telefonu, skok do aplikacji bankowej, powrót do przeglądarki to krok, który najczęściej się gubi.

Status zamówienia ustala powiadomienie serwer do serwera. Powrót klienta na stronę podziękowania nie jest źródłem prawdy. Jeśli woocommerce_thankyou oznacza zamówienie jako opłacone, pojawiają się trzy klasyczne błędy: pobrania bez potwierdzonego zamówienia, zamówienia potwierdzone bez pobrania po manipulacji URL powrotu, podwójne odjęcie stanu po przeładowaniu strony. Wzorzec poprawny: traktować podpisane powiadomienie jako jedyne źródło prawdy, walidować podpis, sprawdzać kwotę i walutę, stosować idempotencję na identyfikatorze transakcji i wywołać payment_complete() raz, zostawiając woocommerce_order_status_changed dla reszty. Strona podziękowania tylko czyta.

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 Fallas. Decyzja trafia do pisemnego kompromisu technicznego, nie do mody na bloki.

Skrypt bramki Redsys nie może blokować LCP na stronie checkout. Ładujemy go po interakcji albo z defer, testujemy na stagingu z tym samym CDN co produkcja. Właściciel sklepu z centrum Walencji nie akceptuje argumentu strona produktu jest szybka, kiedy checkout na mobile wisi trzy sekundy przed polem karty albo przyciskiem Bizum.

#IVA hiszpański, faktury i dostawa z Walencji

Hiszpański sklep WooCommerce musi umieć IVA krajowy (21 procent stawka ogólna, 10 procent obniżona, 4 procent super obniżona), stawki specjalne dla Wysp Kanaryjskich (IGIC zamiast IVA) oraz OSS dla sprzedaży transgranicznej w UE bez ręcznego klejenia stawek w Excelu. Pola NIF/CIF w checkout B2B, numer faktury w eksporcie do ERP i zgodność z wymogami AEAT to decyzje w wtyczce checkoutu i integracji, nie w motywie.

Baleary, Ceuta i Melilla leżą poza terytorium stosowania IVA i fakturuje się je z własnymi podatkami pośrednimi. W logistyce traktujemy je osobno od dostawy peninsularnej. Kalkulator wysyłki w Walencji musi to odzwierciedlać od początku projektu, nie jako poprawkę po pierwszym zamówieniu na Majorkę.

Dostawa z Walencji to nie jedna stawka Hiszpania. Klienci oczekują SEUR, Correos Express, MRW albo GLS, czasem odbioru w punkcie locker. Kalkulator wysyłki musi liczyć wagę, wymiary i strefy (aglomeracja walencjańska, reszta Comunitat Valenciana, reszta Hiszpanii, Baleary, Kanary, 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.

Punkt odbioru to dwie warstwy techniczne: kalkulacja stawki przez filtr woocommerce_package_rates albo klasę rozszerzającą WC_Shipping_Method, oraz zapis punktu jako metadane zamówienia w woocommerce_checkout_create_order, które potem idzie do API etykiet. W runbooku zapisujemy godzinę cut-off odbioru, traktowanie Balearów i osobno Wysp Kanaryjskich, Ceuty i Melilli.

Waluta EUR jest domyślna, ale sklepy w Walencji obsługują też turystów i eksporterów z całej Europy. Wielojęzyczność wymaga osobnej decyzji: czy checkout w angielskim idzie przez te same bramki, czy pola adresowe mają walidację kodu pocztowego per kraj. Kampania w euro bez poprawnego IVA na produkcie cyfrowym albo bez OSS dla klienta z Niemiec kończy się porzuconymi koszykami i pytaniami od księgowości, których analytics nie wyjaśni bez nagrania sesji.

#Integracje, których wymaga hiszpański e-commerce

Sklep sprzedający w Hiszpanii zbiera integracje zanim zbiera ruch: bramka, przewoźnik, ERP, fakturowanie. Każda ma własny model awarii, a wszystkie piszą na tę samą encję, zamówienie. Architektura to decyzja, kto ma pierwszeństwo nad stanem zamówienia i w jakiej kolejności. W Walencji to waży więcej niż zwykle, bo profil gospodarczy miasta i aglomeracji łączy port, eksport agroalimentarny, meble, tekstyl i turystykę, czyli katalogi z realną logistyką za sobą i klientów kraju i poza półwyspem.

ERP, magazyn i synchronizacja: Sage, a3ERP albo Holded to zwykle system, w którym żyją cena, stan i klient, a WooCommerce jest witryną. Synchronizacja dostaje kierunek per pole, stabilny identyfikator zewnętrzny per produkt i zamówienie, kolejkę z retry i backoff oraz zaplanowaną reconciliację porównującą obie strony zamiast ufania, że wszystkie wiadomości dotarły. Stan to punkt wrażliwy: przy High Performance Order Storage odczyty i zapisy zamówień idą do dedykowanych tabel WooCommerce, a odjęcie magazynu musi dziać się wewnątrz flow zamówienia, nie w równoległym procesie, który z nim konkuruje.

Fakturowanie elektroniczne i Verifactu: hiszpański framework łączy dwa fronty. Faktura elektroniczna B2B opiera się na Facturae i, dla sektora publicznego, na platformie FACe. Systemy fakturowania muszą spełniać wymogi Real Decreto 1007/2023: łańcuchowe rejestry faktur z odciskiem, podpis elektroniczny gdy brak wysyłki w czasie rzeczywistym, kod QR na fakturze i oznaczenie systemu weryfikowalnego, plus zasady przekazania rejestrów do Agencji Tributaria. W Kraju Basków obowiązuje TicketBAI z własną specyfikacją. Dla sklepu WooCommerce trzeba wcześnie ustalić, kto wystawia fakturę, ERP czy WordPress, bo tylko jeden system może być systemem informatycznym fakturowania, i opisać numerację, faktury korygujące i zwroty częściowe. Kalendarz obowiązków publikuje AEAT i weryfikuje się go w źródle przed zobowiązaniem daty projektu.

#Walencja: port, Huerta, Fallas i Valencia Digital District

Walencja nie jest Sewillą ani Malagą. Tu liczy się Puerto de Valencia, Huerta de Valencia, Valencia Digital District w La Marina, Las Fallas w połowie marca oraz turystyka od City of Arts and Sciences po Malvarrosa. Te osie ustawiają priorytety techniczne dla sklepu, który ma działać w Walencji, a nie tylko nosić to w tytule strony usługowej.

#Puerto de Valencia i logistyka

Puerto de Valencia to jeden z największych portów kontenerowych w basenie Morza Śródziemnego. WordPress i WooCommerce trzymają katalogi usług portowych, formularze zgłoszeniowe dla przewoźników, panele statusu przesyłek i treści wielojęzyczne ES/EN dla klientów międzynarodowych. Sklep B2B z częściami, opakowaniami albo usługami logistycznymi musi przeżyć aktualizację wtyczki płatności w tym samym tygodniu, w którym szczyt sezonu kontenerowego generuje skok zamówień. Awaria checkoutu po patchu cache albo regresja w mailach transakcyjnych boli w lipcu, nie w styczniu.

#Huerta i agrotech

Huerta de Valencia dostarcza cytrusy, ryż i warzywa na rynki europejskie. Agrotech buduje platformy traceability, katalogi produktów i integracje z ERP rolnych. WooCommerce trzyma katalogi B2B, formularze zamówień sezonowych i treści wielojęzyczne dla eksporterów. Checkout musi obsłużyć stawki IVA na żywność, chłodnię w łańcuchu dostaw i zwroty towaru z jasnym komunikatem przed zakupem. Sklep, który obiecuje dostawę świeżego produktu w 48 godzin bez mapowania stref chłodniczych SEUR, generuje reklamacje, nie sprzedaż.

#Las Fallas i zamrożenie wdrożeń

Las Fallas odbywają się co roku w Walencji od 15 do 19 marca, z tygodniem przygotowań i falą ruchu turystycznego, która zaczyna się wcześniej. W tym oknie setki hoteli, biur podróży, restauracji i operatorów eventowych patrzą na sklepy promocyjne, kody rabatowe i landingi sezonowe. Awaria checkoutu w środku tygodnia Fallas to nie bug do backlogu. To utracone zamówienia i reputacja u partnerów, którzy mają pełny kalendarz na cały marzec.

Runbook developmentu dla klientów Walencji ma wpisane zamrożenie wdrożeń produkcyjnych na okno Fallas, zwykle od początku marca do końca pierwszego tygodnia po zakończeniu festiwalu. Aktualizacje krytyczne bezpieczeństwa przechodzą przez środowisko testowe i okno nocne, reszta czeka. To decyzja operacyjna uzgodniona z klientem przed sezonem, nie preferencja developera.

#Valencia Digital District

Valencia Digital District w La Marina to hub startupów, coworkingów i firm cyfrowych. WooCommerce trzyma landingi produktowe, sklepy merchu, subskrypcje boxów i kanały D2C testowane przed ekspansją na rynek hiszpański. Awaria po aktualizacji wtyczki formularza albo regresja w tłumaczeniach boli w tygodniu demo day albo przed rundą inwestycyjną, nie w sierpniu. Opieka z oknem aktualizacji poza Fallas i ze stagingiem to decyzja operacyjna, nie kaprys developera.

#RODO, AEPD i hosting w UE

Po stronie hiszpańskiej klient pyta o coś innego niż polski zespół domyślnie zakłada: gdzie leżą dane, czy serwer jest w Unii Europejskiej, jak długo trzymamy logi, kto jest administratorem danych, czy mamy Data Processing Agreement. Te pytania trzeba umieć obsłużyć procesem, nie sloganem o zgodności z RODO.

#RODO i hiszpańska AEPD

Hiszpania stosuje RODO (GDPR) oraz krajową ustawę organiczną o ochronie danych osobowych i gwarantowaniu praw cyfrowych (LOPDGDD). Organ nadzorczy to Agencia Española de Protección de Datos (AEPD). Dla WooCommerce w Walencji wynika z tego konkretny zakres developmentu: lista podprocesorów (host, CDN, poczta, analityka, bramka płatności), umowa powierzenia tam, gdzie agencja przetwarza dane, procedura naruszenia w 72 godziny, minimalizacja danych w checkout, política de privacidad zgodna z art. 13 RODO.

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 jesteście zgodni z RODO, bo macie WAF. AEPD publikuje wytyczne na aepd.es; runbook projektu powinien być z nimi zgodny co do tego, co agencja dokumentuje, a co zostaje po stronie administratora danych.

Co wpisujemy w brief i w kod:

• Checkout zbierający dane kupującego dostaje jawną podstawę prawną, checkbox zgody tam, gdzie consent jest wymagany, i minimalizację pól.
• Wtyczki consent (Complianz, Cookiebot, Iubenda) konfigurujemy tak, żeby skrypty marketingowe i analityczne nie ładowały się przed akceptacją zgodnie z LSSI-CE i wytycznymi AEPD.
• Polityka prywatności i cookie policy są szablonami z polami, nie blokami, które redaktor może usunąć z drzewa.
• Integracje z ERP, magazynem i bramką Redsys dostają dokumentację przepływu danych: co trafia do systemu zewnętrznego, jak długo, kto jest administratorem.

#Hosting w UE

Dane osobowe pod RODO ciągną pytanie: w której jurysdykcji stoi serwer. AWS w Madrycie (eu-south-2), OVH we Francji, Hetzner w Niemczech, Arsys albo Dinahosting w Hiszpanii, Scaleway w Paryżu to różne odpowiedzi dla compliance officer, ale wszystkie mieszczą się w UE. Ashburn albo Hillsboro to Stany i zwykle veto bez Standard Contractual Clauses albo innej podstawy transferu.

Pytanie czy hosting jest w Walencji wraca rzadziej niż czy w UE. Odpowiedź operacyjna jest dwuczęściowa. Jurysdykcja: UE, kopia nie wyjeżdża nocą na bucket w regionie US bez uzgodnienia. Latencja: origin w Madrycie albo Frankfurt plus CDN z terminałem TLS w UE zwykle wystarcza dla użytkowników Hiszpanii i w Europie Środkowej. Walencja ma centra danych w aglomeracji, ale origin WooCommerce nadal często stoi u dostawcy z regionem madryckim albo frankfurckim. To jawna decyzja rezydencji, którą trzeba opisać w runbooku.

#Hooki WooCommerce zamiast modyfikacji rdzenia

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

Granica jest prosta i zapisana w runbooku. Motyw umie pokazać. Wtyczka umie wiedzieć. Logika cen B2B, reguły dostaw per strefa, endpoint REST dla panelu magazynu, mapowanie callbacków Redsys: to wtyczka. Kolory, siatka, wzorzec hero z Huerta: to motyw. Jeśli po zmianie motywu znika kalkulator wysyłki albo przycisk Bizum, architektura była zła.

Własna wtyczka ma własny prefix, autoload PSR-4, plik główny z nagłówkiem Plugin Name i wersją semver oraz testy tam, gdzie logika liczy (mapowanie pól do ERP, walidacja NIF, reguły dostaw per kod pocztowy). Logika biznesowa nie trafia do functions.php motywu, bo functions.php umiera razem z motywem, a firma w Walencji zmienia partnera brandingowego częściej niż model checkoutu.

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

To jest warstwa, która odróżnia seniorskie prace WooCommerce od wgrania ZIP-a na FTP. W Walencji klient z działem IT i tak zapyta o to na drugim spotkaniu, zwłaszcza jeśli recenzent przychodzi z Valencia Digital District albo z wewnętrznego IT operatora logistycznego przy porcie.

Repozytorium trzyma motyw i własne wtyczki. Wtyczki z katalogu WordPress.org i Core nie żyją jako skopiowane foldery w Gicie, chyba że jest twardy powód (fork, łatka, air-gap). Gałąź funkcyjna na jedną zmianę: nowa strefa dostaw, poprawka callbacku Redsys, optymalizacja koszyka. Pull request ma opis, ekrany albo nagranie checkoutu, i checklistę: i18n, dostępność, brak sekretów, czy patch nie psuje Bizum na mobile.

Środowisko testowe jest kopią produkcji z zanonimizowanymi danymi. WP-CLI search-replace na URL, osobne klucze Redsys sandbox, wyłączone crony, które wysyłają maile do prawdziwych klientów. Manager sklepu klika po stagingu z prawdziwymi produktami i bramkami testowymi, nie po localhostcie programisty. Regresja wielojęzyczna ES/EN, regresja checkoutu Redsys i Bizum oraz regresja eksportu do magazynu dzieją się tutaj. Promocja na produkcję jest udokumentowanym krokiem: tag albo merge do main, build zasobów, cache warmup, ścieżka wycofania (poprzedni tag).

QA end-to-end na stagingu pokrywa pełną ścieżkę: koszyk, checkout, płatność testowa na Redsys i Bizum, mail potwierdzenia, edycja zamówienia w panelu, zwrot testowy, eksport do magazynu. Scenariusz opłacone u klienta, oczekujące w Woo po patchu wtyczki płatności jest obowiązkowy, nie opcjonalny. Magazyn nie powinien pakować na podstawie screenshotu z aplikacji bankowej.

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

Nie prezentujemy anonimowych case study z okrągłymi liczbami niemożliwymi do zweryfikowania. Zamiast tego opisujemy trzy profile projektów, które powtarzają się na rynku walencjańskim, i cele techniczne, które uzgadniamy na piśmie przed pierwszą linią kodu.

#Profil 1: eksport cytrusów i produktów z Huerta

Typowy projekt: eksporter z Huerta de Valencia potrzebuje katalogu B2B z wielojęzycznym checkoutem, Bizum exprés dla klientów krajowych i dostawą SEUR do UE.

Zakres pracy:

• WooCommerce Blocks Checkout z Redsys i Bizum.
• Strefy dostaw per kraj UE z obsługą OSS.
• Prawidłowa struktura hreflang dla wersji ES/EN.

Cele techniczne w umowie: stabilność callbacków Redsys po patchu wtyczki, checkout z minimalizacją danych pod AEPD, eksport zamówień do ERP bez ręcznego przepisywania NIF.

#Profil 2: operator turystyczny z centrum Walencji

Typowy projekt: firma traci zamówienia w tygodniu Fallas, bo checkout WooCommerce z Redsys i Bizum pada po aktualizacji wtyczki płatności.

Zakres pracy:

• Refaktoryzacja checkoutu z runbookiem callbacków i idempotencją.
• Optymalizacja bazy MySQL i cache obiektowy Redis.
• Testy obciążeniowe przed Fallas z zamrożeniem wdrożeń w marcu.

Cele techniczne w umowie: proces zakupu poniżej 20 sekund na mobile w stagingu przed wdrożeniem, stabilność checkoutu pod symulowanym szczytem ruchu, monitoring porzuconych koszyków.

#Profil 3: marka D2C z Valencia Digital District

Typowy projekt: firma produktowa potrzebuje sklepu z subskrypcją, integracją magazynową i wersjami ES/EN, który przejdzie audyt dostawcy.

Zakres pracy:

• WooCommerce Subscriptions z rozliczeniem cyklicznym przez Redsys.
• Integracja magazynowa przez REST z logiem audytowym.
• RODO z Consent Mode v2 i dokumentacja przepływu danych pod AEPD.

Cele techniczne w umowie: checkout ładujący się bez blokowania renderowania, dokumentacja przepływu danych dla compliance officer, runbook freeze Fallas wpisany w harmonogram wydań.

#Inżynieria wydajności

Core Web Vitals to nie tylko metryki, bezpośrednio wpływają na pozycję w wyszukiwarce i doświadczenie użytkownika. Projekty WooCommerce w Walencji są zaprojektowane, by przekraczać progi wydajnościowe Google:

• Largest Contentful Paint (LCP) poniżej 1,5 sekundy, dzięki zoptymalizowanej ścieżce renderowania krytycznego, preloadowanym obrazom hero w AVIF/WebP, edge cachingowi i generowaniu statycznemu tam, gdzie ma sens.
• Interaction to Next Paint (INP) poniżej 100 ms, dzięki minimalnej hydracji JavaScript, zdebouncowanym handlerom eventów, odroczonemu ładowaniu skryptu Redsys i zoptymalizowanemu ładowaniu skryptów zewnętrznych.
• Cumulative Layout Shift (CLS) poniżej 0,05, dzięki jawnym wymiarom obrazów, font-display:swap z dopasowanymi fallbackami, skeletonowym stanom ładowania i zarezerwowanemu miejscu dla przycisku Bizum.

Monitorujemy te metryki ciągle przez Lighthouse CI w procesie wdrożeniowym i monitoring rzeczywistych użytkowników. Każda regresja uruchamia automatyczny alert i blokuje wdrożenie. Dla sklepu w Walencji liczy się czas do pierwszego bajtu z sieci w Hiszpanii i w Europie Środkowej, nie tylko z telefonu na Malvarrosa. Monitoring z jednego regionu USA kłamie. Punkt pomiaru w UE jest częścią kontraktu operatorskiego, nie dodatkiem.

Checkout jest dynamiczny. Pełny page cache na cart i checkout serwuje cudzy koszyk albo pusty fragment mini-cart. Warstwa cache (Redis, Cloudflare) omija te ścieżki albo stosuje segmentację. Obrazy katalogu idą w AVIF / WebP z srcset. Kampanie sezonowe Fallas generują ciężkie JPEG ze stoiska; bez przetwarzania LCP na karcie produktu spada, zanim kupujący zobaczy przycisk Bizum.

#Bezpieczeństwo przy sklepach z danymi kupujących

Sąsiedztwo operatorów turystycznych i firm z Valencia Digital District nie czyni WooCommerce systemem core bankingu ani platformą płatniczą Redsys. Zespół nie pisze, że sklep spełnia PCI DSS Level 1 bez audytu po stronie klienta. WooCommerce ma dostarczyć inwentarz, ślad dostępu i dyscyplinę Git, które klient wkleja do własnej dokumentacji.

Postawa, którą da się utrzymać w kodzie i procesie:

• Sekretów nie ma w Git. Klucze Redsys, hasła bazy i tokeny ERP idą przez zmienne środowiska albo poza repo.
• Konta administracyjne mają 2FA. Redaktorzy nie dostają install_plugins na produkcji.
• XML-RPC zostaje wyłączony, jeśli nie ma uzasadnionego klienta. File editor w panelu też.
• Nagłówki: HTTPS, HSTS tam gdzie certyfikat i CDN na to pozwalają, CSP dopasowane do realnych skryptów bramki.
• Zależności: Composer albo zapisane wersje wtyczek, skan CVE w CI, aktualizacje na stagingu przed produkcją.
• Kopie i odtworzenie: backup bez przetestowanego restore to ozdoba. Test odtworzenia na stagingu jest w runbooku.

Szerszy audyt bezpieczeństwa opisuje audyt bezpieczeństwa WordPress.

#Lokalne SEO i widoczność cyfrowa w Walencji

Dobrze zbudowany sklep jest wartościowy tylko wtedy, gdy Twoja grupa docelowa w Walencji i w Comunitat Valenciana może go znaleźć. Projekty programowania WooCommerce obejmują fundamentalną architekturę SEO od pierwszego szkicu:

• Fundamenty techniczne SEO. Czyste struktury URL, mapy strony XML, konfiguracja robots.txt, tagi canonical i prawidłowa hierarchia nagłówków. Implementujemy dane strukturalne Schema.org: LocalBusiness, Organization, Product, Service, FAQ i HowTo tam, gdzie mają sens.
• Optymalizacja wyszukiwania lokalnego. Integracja z Google Business Profile, lokalne dane strukturalne z adresem w Walencji, spójność NAP (nazwa, adres, telefon) i strony przygotowane pod zapytania regionalne, uwzględniające Gandia, Alicante i aglomerację portową tam, gdzie biznes faktycznie działa.
• Core Web Vitals jako sygnały rankingowe. Google używa metryk doświadczenia strony w ocenie page experience. Budżety wydajnościowe ustalamy na starcie projektu i weryfikujemy je na danych terenowych z raportu CrUX, nie tylko w pomiarze laboratoryjnym.
• Architektura treści. Układamy strony filarowe, artykuły pomocnicze i linkowanie wewnętrzne tak, żeby użytkownik szybko trafiał do właściwego tematu, a wyszukiwarka jasno rozumiała zakres kompetencji firmy.
• SEO wielojęzyczne. Dla firm działających na kilku rynkach wdrażamy hreflang, osobne struktury URL i niezależne metadane dla każdej wersji językowej.

SEO nie jest dodatkiem po uruchomieniu strony. Jest częścią decyzji architektonicznych od pierwszego szkicu.

#Z Walencji na Baleary, Barcelona i Madryt

W logistyce Baleary traktujemy osobno od peninsularnej. Eksport walencjański i marki z katalońskiego czy madryckiego e-commerce dzielą hiszpańską bramkę i compliance, ale mają inne profile katalogów. Dla mody D2C i checkoutu wielojęzycznego: programista WooCommerce w Barcelonie. Dla hurtowni, ERP i SII: programista WooCommerce w Madrycie. Dla porównania na południu: programista WooCommerce w Maladze.

Po uruchomieniu sklepu opieka techniczna WordPress w Walencji przejmuje aktualizacje, kopie i monitoring z tym samym runbookiem bramek i zamrożeniem pod Fallas.

#Kiedy ta strona, a kiedy opieka albo programista WordPress

Ta strona zostaje przy sklepie: katalog, checkout, płatność, dostawa, stan, dokument, zwrot. Motyw bloga, Gutenberg, intranet albo strona korporacyjna centrali w Valencia Digital District nie są tutaj tematem - to programista WordPress w Walencji. Monitoring, aktualizacje rdzenia i kopie zapasowe bez przebudowy checkoutu to opieka techniczna WordPress w Walencji. Szerszy opis utrzymania bez miasta: utrzymanie stron WordPress. Wspólny filar e-commerce: programista WooCommerce.

Puerto de Valencia, Huerta i Fallas tłumaczą, skąd biorą się sklepy B2B z NIF i płatnością Bizum. Nie tłumaczą, czemu callback Redsys bez idempotencji zostawia zamówienie w pending w marcu.

#Rozpocznij projekt sklepu WooCommerce w Walencji

Do kontaktu wystarczy krótki opis: czy sklep już stoi, jakie bramki są włączone (Redsys, Bizum, PayPal, Stripe), skąd leci dostawa (SEUR, MRW, Correos Express, odbiór w aglomeracji walencjańskiej), czy HPOS jest włączony, jaki jest magazyn (Walencja, 3PL, centrala w regionie), czy księgowość czeka na eksport do Holded albo Sage, czy cookie consent blokuje tagi przed zgodą, i które daty Fallas blokują wydanie. Na tej podstawie widać, czy potrzebna jest przebudowa checkoutu, czy zestawienie webhooków i stanów.

WPPoland pracuje przy WooCommerce od strony zamówienia, nie od strony slajdu. Walencja dostaje ten sam rygor inżynierski co każdy inny sklep, tylko ze stackiem, którego kupujący w Hiszpanii naprawdę używa, i z kalendarzem Fallas wpisanym w harmonogram wydań.