Programista WordPress w Göteborgu

Strona firmy albo instytucji w Göteborgu stoi obok Volvo Campus, Lindholmen Science Park, największego portu w Skandynawii i ekosystemu maritime tech, który ustawia oczekiwania co do webhooków, rezydencji danych i dokumentacji integracji. To nie jest powód, żeby WordPress udawał system ERP. To powód, żeby motyw, wtyczki i model treści były napisane tak, jak oczekuje szwedzki dział prawny, redaktor SV/EN i compliance officer, który pyta o Integritetsskyddsmyndigheten (IMY) zanim ktoś wpuści landing na produkcję.

WPPoland buduje ten WordPress z polskiego zespołu seniorów dla firm, które mają siedzibę, oddział albo klientów Göteborgu. Zakres to programowanie WordPress: motyw blokowy albo klasyczny, własne wtyczki, Gutenberg, CPT, ACF albo natywne bloki, integracje REST i przegląd kodu na Git. Sklep WooCommerce z Klarna i Swish oraz abonament opieki są osobnymi tematami, z linkami na końcu.

#Programowanie WordPress w Göteborgu i na rynku szwedzkim

Göteborg to nie Sztokholm fintech ani Malmö e-commerce. To drugie co do wielkości miasto Szwecji, dom Volvo i hub automotive oraz maritime tech wokół Lindholmen. Brief WordPressa rzadko brzmi „zróbcie stronę jak startup z Avenyn”. Częściej brzmi: odziedziczony motyw z trzema wtyczkami wielojęzycznymi, publikacje SV/EN, które się rozjeżdżają po aktualizacji, redakcja w Polsce, a recenzent w Göteborgu pyta o RODO, hosting w UE, organisationsnummer w stopce i cookie banner zgodny ze szwedzką interpretacją zgody.

Dla strony WordPress te fakty oznaczają trzy twardsze wymagania niż na typowym rynku B2B. Po pierwsze formalność językowa: szwedzki front w rejestrze formalnym, angielska wersja równoległa dla ekspansji międzynarodowej, nie tłumaczenie maszynowe z polskiego briefu. Po drugie ślad decyzji: kto akceptuje SV, kto EN, co idzie na środowisko testowe, co na produkcję, gdy premiera modelu albo konferencja maritime tech na Lindholmen zbliża zamrożenie zmian. Po trzecie rezydencja i retencja: hosting w UE, kopie, logi i integracje formularzy to temat rozmowy przed pierwszym commitem, nie dopisek w umowie po incydencie.

Lindholmen Science Park i okoliczne biura przy Volvo Campus dokładają recenzentów, którzy czytają pull request i pytają, czy wtyczka consent nie wysyła IP poza UE bez podstawy prawnej. Chalmers University of Technology i University of Gothenburg wypuszczają ludzi, którzy odróżnią motyw od wtyczki i wiedzą, że Polylang nie zastąpi procesu redakcyjnego. Pendlerzy z Mölndal, Partille i Kungsbacka pracują w jednym biurze po szwedzku i po angielsku, więc strona SV/EN z polskim zapleczem redakcyjnym jest tu częstsza niż czysto polski front ze szwedzkim panelem.

Typowy brief, który trafia do seniorów, nie brzmi „zróbcie ładną stronę”. Brzmi: motyw sprzed pięciu lat, WPML albo Polylang po patchu serwuje szwedzki tekst na wersji angielskiej, Gutenberg używany jak notatnik, a nowa publikacja powstaje przez kopiowanie strony z zeszłego roku i ręczne podmienianie numeru dokumentu. To problem modelu treści i procesu Git, nie problem motywu z marketplace.

WPPoland nie jest kancelarią prawną ani dostawcą automotive. Sąsiedztwo Volvo i portu ustawia poprzeczkę dokumentacji, ról i wielojęzyczności. Nie ustawia listy referencji przemysłowych.

#Motyw blokowy, motyw klasyczny i własna wtyczka

Nowa budowa w Göteborgu startuje od decyzji, która później kosztuje miesiącami: czy prezentacja żyje w motywie blokowym z theme.json, czy w klasycznych szablonach PHP, i co idzie do wtyczki. Ta decyzja jest zapisywana przed pierwszym commitem, bo późniejsze „dokładamy EN w weekend przed kampanią produktową” kończy się regresją hreflang i skargą działu compliance.

#theme.json, wzorce i granica odpowiedzialności motywu

Motyw blokowy trzyma tokeny: paletę, skalę typografii, odstępy, szerokości treści. Dla göteborskiego B2B, automotive i maritime tech oznacza to stonowaną paletę, czytelny krój bez ozdobników i przyciski, które nie pękają na szwedzkich złożeniach ani na angielskich formułach compliance. Wzorce bloków opisują powtarzalne układy: hero z zastrzeżeniem prawnym, siatka osób z zespołu, blok cytatu z atrybucją, stopka z linkiem do integritetspolicy zgodnej z RODO. Redaktor składa stronę z wzorców, zamiast prosić programistę o nowy szablon na każdą publikację czy komunikat przed konferencją maritime tech.

Pełna edycja witryny (FSE) ma sens, gdy zespół redakcyjny naprawdę ma dostać kontrolę nad nagłówkiem i stopką. W praktyce wiele firm z Göteborgu tej kontroli nie chce: nagłówek jest elementem brandu i compliance, a nie placem zabaw. Wtedy motyw blokowy zostaje, ale szablony części (header, footer) są zablokowane, a redakcja pracuje w obrębie wzorców i własnych bloków. To kompromis, nie półśrodek.

Każdy własny blok dostaje block.json, kategorię, ikonę i atrybuty ze schematem. Tam, gdzie treść ma trafić do wyszukiwarki i do RSS, render idzie po stronie serwera. React w edytorze służy do InspectorControls i podglądu, nie do tego, żeby front był aplikacją SPA udającą WordPressa.

#Kiedy klasyczny motyw PHP zostaje

Odziedziczone instalacje w Göteborgu często mają pięć, siedem lat: child theme na komercyjnym szkielecie, ACF wklejone w page.php, shortcode’y w treściach, jQuery z epoki przed blokami, wtyczka wielojęzyczna sklejona na hookach. Przepisanie tego na FSE „bo tak wypada w 2026” jest droższe niż naprawa hierarchii szablonów, wyciągnięcie logiki do wtyczki i dokładanie Gutenberg tylko tam, gdzie redakcja naprawdę składa nowe landingi.

Klasyczny motyw zostaje, gdy:

• logika warunkowa siedzi w szablonach (inne menu dla mediów, inne dla inwestorów, inne dla partnerów B2B) i przeniesienie jej do theme.json nic nie upraszcza;
• zespół redakcyjny publikuje setki stron w klasycznym edytorze i szkolenie z FSE byłoby większym ryzykiem niż dług;
• child theme jest cienki, a problemem są wtyczki, autoload i synchronizacja SV/EN, nie sam silnik szablonów.

Nawet wtedy nowe klocki idą jako bloki, nie jako kolejne shortcode’y. Shortcode w treści z 2019 roku zostaje do migracji, nowy kod go nie dokłada.

#Funkcja do wtyczki, wygląd do motywu

Granica jest prosta i zapisana w runbooku. Motyw umie pokazać. Wtyczka umie wiedzieć. CPT publikacji, kolejka do CRM, endpoint REST dla intranetu, rola użytkownika „redaktor PL” bez capability publish_pages na produkcji szwedzkiej: to wtyczka. Kolory, siatka, wzorzec hero: to motyw. Jeśli po zmianie motywu znika kalendarz wydarzeń, 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 (daty wydarzeń, mapowanie pól do CRM, walidacja formularza z organisationsnummer). Logika biznesowa nie trafia do functions.php motywu, bo functions.php umiera razem z motywem, a göteborski klient zmienia agencję brandingową częściej niż model treści.

Porównanie warstw, którego używamy przy kickoffie:

#Gutenberg, CPT i model treści pod firmy i instytucje

Gutenberg bez modelu treści kończy się tym, że każda podstrona jest unikalnym kolażem bloków i nikt nie potrafi zrobić listy. W Göteborgu listy są konkretne: publikacje, komunikaty, osoby, stanowiska, wydarzenia, lokalizacje biur (Lindholmen to nie centrum, Mölndal to nie port). To są obiekty, nie „kolejne strony w drzewie”.

#Własne typy treści pod realne obiekty

CPT rejestrujemy z własnymi capabilities, nie z mapowaniem na post. Redaktor w Polsce ma edytować publikację, a nie kasować wtyczek. Archiwum CPT dostaje szablon albo wzorzec zapytań, a pojedynczy obiekt ma szablon, który nie pozwala redaktorowi rozpychać layoutu poza ustalony układ. Taksonomie są osobne: typ dokumentu (raport, komunikat, formularz) nie miesza się z tagami bloga.

ACF ma tu miejsce, ale nie jako substytut bloków. Pola ACF na CPT sprawdzają się przy danych, które są polami, nie layoutem: numer publikacji, data wejścia w życie, język wersji, plik PDF z załącznikiem. Layout strony osoby albo artykułu składa Gutenberg. Mieszanie ACF Flexible Content z pełnym edytorem bloków na tym samym obiekcie kończy się dwoma źródłami prawdy i redaktorem, który nie wie, gdzie kliknąć.

Gdzie ACF jest zbędne, atrybuty bloku w block.json wystarczą. Blok „osoba z cytatem” nie potrzebuje grupy pól na każdej stronie. Potrzebuje atrybutów i ewentualnie InnerBlocks na biogram. Mniej wtyczek w panelu to mniej powierzchni ataku i mniej konfliktów ze szwedzkimi wtyczkami consent i cache.

#Bloki serwerowe zamiast shortcode’ów

Shortcode w treści to dług, który widać dopiero przy migracji albo przy eksporcie do PDF. Nowy kod w Göteborgu idzie jako blok z renderem serwerowym: znaczniki semantyczne, atrybuty w komentarzu bloku, możliwość filtrowania wyjścia. Blok listy publikacji czyta CPT, cache’uje zapytanie transjentem z jawnym TTL i invalidacją przy save_post, a nie przy każdym request.

Dla redakcji dwujęzycznej SV/EN każdy ciąg w bloku przechodzi przez funkcje i18n WordPressa. Szwedzki albo angielski string w kodzie PHP jest wyjątkiem, nie regułą. Tłumaczenia leżą w plikach po albo w mechanizmie wtyczki wielojęzycznej, nie w hardcoded tablicy w motywie. Polylang albo WPML dokładamy dopiero gdy naprawdę są dwa języki na froncie. Sam panel w SV i treści redagowane z Polski da się ogarnąć rolami i locale użytkownika, bez pełnego stacku wielojęzycznego, ale front SV/EN w Göteborgu zwykle wymaga pełnej pary.

przegląd kodu bloku sprawdza trzy rzeczy, zanim gałąź wpadnie do main: czy blok działa po wyłączeniu JS w podglądzie frontu, czy atrybuty mają typy i defaulty, czy nie ładuje całego builda edytora na froncie. Gutenberg, który dokłada megabajt Reacta do strony osoby z zarządu, nie przejdzie review.

Landing pod kampanię produktową, termin wydarzenia albo publikację inwestorską nie powstaje jako kopia strony z zeszłego roku. Powstaje jako obiekt CPT z datą, językiem, numerem referencyjnym i wzorcem. Po terminie obiekt zostaje w archiwum, a nie jako osierocona podstrona w drzewie.

#Redakcja dwujęzyczna SV/EN: polski zespół, szwedzki front

Najczęstsze tarcie we współpracy Polska - Göteborg nie jest w PHP. Jest w tonie i w parze języków. Szwedzki UI strony firmowej używa formalnego rejestru. Angielska wersja nie może być dosłownym tłumaczeniem z polskiego briefu ani maszynowym exportem z SV bez recenzji native speakera. To nie jest kwestia samej wtyczki translatorskiej. To jest brief językowy, lista ciągów motywie i proces akceptacji przed produkcją.

Praktyczne zasady, które wpisujemy w dokumentację motywu:

• Ciągi interfejsu (przyciski, błędy formularza, aria-label, placeholder) są po szwedzku w formalnym rejestrze na wersji SV i po angielsku w formalnym you na wersji EN, jeśli front jest dwujęzyczny. Polski wariant, jeśli powstaje dla wewnętrznego panelu, nie kopiuje rejestru jeden do jednego, tylko naturalny polski ton B2B.
• Redaktorzy w Polsce dostają locale panelu, w którym potrafią pracować. To nie musi być ten sam język co front. Mieszanie locale użytkownika z locale strony bez testu kończy się datami w złym formacie i menu, które ucieka z „Inlägg” na „Wpisy” w połowie ekranu.
• Typografia szwedzka i angielska: å, ä, ö, apostrofy, długie złożenia. Przyciski i pozycje menu mają rezerwę szerokości. Łamanie w CSS nie może ucinać sensu w PDF-ach generowanych z treści.
• Integritetspolicy i cookie banner są szablonami z polami, nie blokami, które redaktor może przypadkiem usunąć z drzewa. W Göteborgu te strony są elementem zgodności, nie stopką marketingową. Organisationsnummer w stopce weryfikuje klient; motyw dostarcza pola i szablony, nie „magiczną zgodność prawną”.

Polylang i WPML rozwiązują hreflang i kopie językowe. Nie rozwiązują procesu: kto akceptuje szwedzki tekst, kto angielski, zanim pójdzie na produkcję. W briefie zapisujemy, czy akceptacja leży po stronie klienta w Göteborgu, po stronie polskiego content leada, czy po obu równolegle. środowisko testowe pokazuje obie wersje językowe, bo regresja „SV się zepsuło, bo ktoś edytował EN” wychodzi dopiero na porównaniu, nie w Lighthouse.

Szwedzka kultura komunikacji B2B jest bezpośrednia, ale formalna w UI i mailach transakcyjnych. Du albo ni albo w interfejsie, nie mieszanie rejestrów jednym motywie. Du bywa dopuszczalne na stronie kariery startupu z Lindholmen, jeśli brief to zapisze.

#Dostępność w kontekście szwedzkim

Dostępność w Göteborgu nie jest jednym checkboxem. Firmy pracujące z sektorem publicznym albo z wymogami zamówień muszą liczyć się z EN 301 549 i WCAG 2.1 AA (z migracją do WCAG 2.2 tam, gdzie audytor tego wymaga). Szwedzki kontekst ma własne oczekiwania co do oświadczenia o dostępności, kanału informacji zwrotnej i testowalności przed publikacją. Europejski Akt o Dostępności (EAA) dokłada presję na produkty cyfrowe B2C i B2B w UE.

Sektor automotive i maritime tech w Göteborgu często kopiuje te same standardy, bo recenzent po stronie klienta przyzwyczaił się do listy WCAG z projektów enterprise. Zespół nie sprzedaje „certyfikatu dostępności IMY”. Na kickoffie zapisujemy, który reżim w ogóle dotyczy witryny, a potem testujemy to, co da się przetestować w motywie i blokach.

Co konkretnie robi zespół w kodzie:

• Semantyka: jeden h1, kolejność nagłówków, przycisk jako button, link jako a, nie div z kliknięciem.
• Klawiatura i focus: omijanie powtarzalnej nawigacji, widoczny focus, brak pułapek w mega menu.
• Kontrast i ruch: tokeny w theme.json, szacunek dla prefers-reduced-motion, brak informacji niesionej samym kolorem.
• Formularze: etykiety powiązane z polami, błędy w tekście w obu językach, nie tylko w kolorze ramki.
• Media: tekst alternatywny jako pole wymagane w procesie redakcji, nie jako „uzupełnimy później”.
• PDF: jeśli publikacja idzie jako załącznik, klauzula dokumentów poza WWW trafia do briefu. WordPress nie zrobi z JPG-a dostępnego PDF-a.

Skan automatyczny (axe, Lighthouse) jest bramką CI, nie dowodem zgodności. Dla klienta z wymogiem WCAG w umowie dostawy dokładamy ręczną ścieżkę klawiatury i porównanie z listą WCAG w obu wersjach językowych. Zespół nie wystawia certyfikatu, którego nie było w scope.

Sklep i checkout to osobna rozmowa: jeśli brief schodzi na WooCommerce, zakres przenosi się na programistę WooCommerce w Göteborgu.

#Bezpieczeństwo, RODO/IMY i hosting w UE

Sąsiedztwo Volvo Campus i portu nie czyni marketingowego WordPressa systemem klasyfikacji informacji. Zespół nie pisze, że strona „spełnia ISO 27001”, jeśli audytu nie było. WordPress ma dostarczyć inwentarz, ślad dostępu i dyscyplinę aktualizacji, które klient wkleja do własnej dokumentacji compliance, a nie „pieczątkę zgodności” od agencji.

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

• Sekretów nie ma w Git. Klucze, hasła bazy i tokeny CRM idą przez zmienne środowiska albo poza repo. wp-config.php w historii Gita z hasłem to incydent, nie „drobiazg na później”.
• Konta administracyjne mają 2FA. Redaktorzy PL nie dostają install_plugins na produkcji. Rola jest cięta do tego, czego wymaga Gutenberg.
• 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 (consent, tag manager, czcionki), nie skopiowane z bloga.
• Zależności: Composer albo zapisane wersje wtyczek, skan CVE w CI, aktualizacje na stagingu przed produkcją. Niezałatany Core jest gorszy niż brak nowej wtyczki „security”.
• Kopie i odtworzenie: backup bez przetestowanego restore to ozdoba. Test odtworzenia na stagingu jest w runbooku. Rezydencja kopii w UE jest tematem umowy, nie domyślnym założeniem chmury globalnej.
• Logi: kto zalogował się do wp-admin, skąd poszła zmiana wtyczki. Retencja uzgodniona z RODO i polityką klienta, nie „trzymamy wszystko wiecznie”. Przy incydencie klient może musieć zgłosić naruszenie do IMY w 72 godziny; dziennik ma dać się włożyć do formularza, agencja nie składa zgłoszenia za administratora danych.

RODO i szwedzka IMY to osobne warstwy w briefach transgranicznych: minimalizacja pól formularza, umowa powierzenia, consent na skrypty, lokalizacja hostingu. Hosting „w UE” jest argumentem o jurysdykcji, nie magiczną tarczą. Formularz, który zbiera dane osobowe bez podstawy prawnej i bez informacji w integritetspolicy, nie naprawi go sama lokalizacja serwera w eu-north-1 w Sztokholmie albo u frankfurckiego dostawcy.

Testy penetracyjne wymieniamy tylko wtedy, gdy klient je ma albo zamawia u laboratorium. WPPoland nie dopisuje sobie certyfikatów, których nie posiada. Hartowanie WordPressa to zestaw decyzji w pull requestach, nie slajd o zerowych incydentach.

#Git, środowisko testowe i przegląd kodu

To jest warstwa, która odróżnia seniorskie prace WordPress od „wgrania ZIP-a na FTP”. W Göteborgu klient z działem IT albo z doświadczeniem automotive i tak zapyta o to na drugim spotkaniu, zwłaszcza jeśli recenzent przychodzi z Chalmers, z Lindholmen albo z wewnętrznego IT Volvo.

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ę: nowy blok, nowy CPT, poprawka a11y, synchronizacja SV/EN. Pull request ma opis, ekrany albo nagranie z edytora, i checklistę: i18n, dostępność, brak sekretów, czy blok nie psuje klasycznego szablonu jeśli jeszcze żyje, czy obie wersje językowe przechodzą regresję.

przegląd kodu robi senior, który nie pisał tej gałęzi. Review czyta WordPress Coding Standards (PHPCS, sniffs WordPress-Core), ale też czyta intencję: czy CPT nie powinien być wtyczką, czy ACF nie dubluje atrybutów bloku, czy hook nie wisi na init bez potrzeby. Komentarz w PR jest po angielsku albo po polsku, zależnie od recenzenta po stronie klienta; szwedzkie IT w Göteborgu zwykle woli angielski w diffie i SV/EN w dokumentacji redakcyjnej.

Środowisko testowe jest kopią produkcji z zanonimizowanymi danymi. WP-CLI search-replace na URL, osobne klucze, wyłączone crony, które wysyłają maile do prawdziwych adresów. Redakcja klika po stagingu z prawdziwymi wzorcami Gutenberg w obu językach, nie po localhostcie programisty. Regresja wielojęzyczna i regresja klawiatury dzieją się tutaj. Promocja na produkcję jest udokumentowanym krokiem: tag albo merge do main, build zasobów, cache warmup, ścieżka wycofania (poprzedni tag). Zespół nie wgrywa „na szybko” jednego pliku PHP przez SFTP, bo potem nikt nie odtworzy, co stało na produkcji w piątek przed premierą modelu.

WP-CLI jest narzędziem operacyjnym: flush transients, wp scaffold, import CPT, sprawdzanie autoload. Nie zastępuje testów. Tam, gdzie wtyczka liczy (daty, mapowanie, walidacja), idzie PHPUnit. Bloki z nietrywialnym UI dostają test w edytorze na stagingu, bo jsdom nie złapie, że InspectorControls zasłania przycisk Spara albo Save w odpowiednim locale.

Budżet wydajności jest częścią odbioru, nie osobnym projektem. Lighthouse i Core Web Vitals na szablonach, które naprawdę istnieją: archiwum CPT, single, strona z wzorcem hero w SV i EN. Obrazy w AVIF/WebP przez proces budowania, CSS motywu bez importu całego uniwersum bloków, JS edytora nie na froncie. Redis i obiektowy cache mają sens, gdy transjenty i zapytania CPT to pokazują, nie gdy „tak się robi przy Göteborgu”.

#Premiera modelu, konferencja maritime tech i freeze wdrożeń

W przeciwieństwie do kalendarza targowego w Madrycie, göteborski rynek ma inne szczyty: premiery modelów automotive, konferencje produktowe na Lindholmen, okna kampanii przed konferencją maritime tech przy porcie. Runbook freeze zapisuje: brak deployów od tygodnia przed eventem, aktualizacje krytyczne bezpieczeństwa tylko przez środowisko testowe i okno nocne, osobny przegląd cache i limitów PHP przed szczytem ruchu. Marketing zaplanował kampanię na wtorek rano; developer, który robi „drobny patch motywu” w niedzielę wieczorem, uczy się kosztu na własnej skórze, kiedy formularz zapytania ofertowego zwraca 500 przy pełnym ruchu z newslettera do partnerów portowych.

To nie preferencja developera. To decyzja operacyjna uzgodniona z klientem przed sezonem. Ten sam schemat stosujemy przy wdrożeniach B2B, gdzie portal musi zostać dostępny w oknie zamówień tygodniowych albo przed rundą inwestycyjną.

#Lindholmen, WordPress Göteborg Meetup i lokalna scena techniczna

Lindholmen Science Park to jeden z najbardziej rozpoznawalnych hubów technologicznych w Göteborgu. WordPress Göteborg Meetup spotyka się regularnie w ekosystemie göteborskim (grupa na Meetup.com i lokalne spotkania w Lindholmen oraz w coworkingach przy nabrzeżu). To nie kanał sprzedaży WPPoland. To miejsce, w którym widać, jak lokalni maintainerzy aktualizują Core, jak rozmawiają o uprawnieniach i o hoście w UE. Programowanie, które nigdy nie wychodzi poza ticket, gubi ten kontekst: w Göteborgu część zespołów i tak siedzi po stronie automotive albo maritime tech i usłyszy te same pytania o IMY i rezydencję danych na meetupie przy porcie albo w Lindholmen.

Volvo Campus jako pracodawca ustawia poprzeczkę dla dostawców łańcuchu: pytania o lokalizację danych i retencję logów pojawiają się wcześniej niż na typowym polskim rynku B2B. Chalmers i University of Gothenburg dostarczają ludzi, którzy umieją odróżnić motyw od wtyczki i wiedzą, że Polylang nie zastąpi procesu akceptacji EN.

Szersza scena nordycka ma WordCamp Europe i spotkania w Sztokholmie czy Oslo, ale brief göteborski nie musi udawać stolicy. Dla tego miasta ważniejsze są wielojęzyczność SV/EN, automotive, maritime tech i B2B niż slajd o „globalnych organizacjach”. Motyw i wtyczki, które wychodzą z tego zespołu, muszą przeżyć pytania: skąd alt tekst, kto akceptuje wersję angielską, czy formularz nie wysyła danych poza UE bez podstawy prawnej.

#Przypadek: patch cache położyłby formularz przed konferencją, środowisko testowe to zatrzymał

Strona operatora logistycznego na WordPress, landing kampanii pod konferencję maritime tech na Lindholmen, formularz zapytania ofertowego z polem organisationsnummer, treść zaplanowana na wtorek 8:00, tydzień przed otwarciem wydarzenia. W kolejce do produkcji leżała aktualizacja wtyczki cache obiektowego plus patch SEO, „drobny, na żywo, bo to tylko object cache”.

Na stagingu, sklonowanym z produkcji razem z Redisem i ofertami w stanie „szkic”, publikacja o 8:00 serwowała ceny z poprzedniego sezonu. Przyczyna: zmiana klucza cache po patchu, stary fragment motywu wołał get_post bez sprawdzenia statusu future, CDN trzymał HTML bez Cache-Control dla zalogowanego redaktora. Na produkcji ten sam zestaw poszedłby w niedzielę wieczorem. Oferta wyszłaby przed terminem, formularz zbierałby dane bez zaktualizowanej integritetspolicy, a wtorkowy ruch z newslettera do partnerów portowych trafiłby w 404 po panicznym cofnięciu wpisu.

środowisko testowe zatrzymał promocję. wycofanie zmian na kopii testowej potwierdził, że sama wtyczka SEO jest niewinna, gdy motyw nie woła szkicu po kluczu bez statusu. Motyw dostał poprawkę, checklista publikacji (szkic, future, formularz, purge, URL w newsletterze, cookie banner) przeszła, dopiero potem produkcja. Nie ma tu nazwy firmy, bo to kształt zdarzenia, nie case study z logotypem. Jest mechanizm: najpierw kopia, potem produkcja.

Ten sam kształt wraca przy wtyczce consent, która po aktualizacji wysyła Meta Pixel przed zgodą cookie, przy formularzu demo, który po patchu gubi stawkę moms, i przy „drobnej” aktualizacji, która wyłącza webhook CRM. Göteborg nie wybacza tego ciszej niż inny rynek. Wygląda to gorzej, bo obok siedzi ktoś, kto pyta o IMY, o premierę modelu albo o slot w kalendarzu konferencji maritime tech.

#Sklep WooCommerce to osobny zakres

Ta strona nie buduje checkoutu, bramek Klarna ani Swish ani katalogu produktów. Jeśli brief schodzi na sklep, moms szwedzki, integrację z Fortnox albo katalog B2B, zakres zmienia właściciela i opisuje go programista WooCommerce w Göteborgu. Pillar bez miasta: programista WooCommerce. Mieszanie sklepu z motywem korporacyjnym w jednym repozytorium bez granicy wtyczek to najszybsza droga do tego, żeby aktualizacja Woo rozwaliła landing pod kampanię, albo odwrotnie.

Korporacyjna strona z jednym przyciskiem „sklep” do zewnętrznego Woo może zostać w motywie jako link. Sama logika koszyka nie.

#Po wdrożeniu: przekazanie albo opieka

Zlecenie programistyczne kończy się dokumentacją, sesją przekazania i dostępem Git dla zespołu klienta. Runbook opisuje: jak dodać wzorzec, jak zarejestrować nowy CPT, jak wypuścić gałąź, jak odtworzyć środowisko testowe, kogo wołać gdy edytor nie zapisuje, jak opublikować parę SV/EN bez regresji hreflang. Jeśli po starcie potrzebne są aktualizacje Core, monitoring i stały dyżur, to jest opieka techniczna WordPress w Göteborgu, nie ukryty aneks do motywu. Pillar bez miasta: utrzymanie stron WordPress.

Wycena prac programistycznych jest indywidualna i wychodzi na piśmie po ustaleniu zakresu. Na tej stronie nie ma cennika ani „pakietów godzin”. Zmiana zakresu (nagle FSE, nagle trzeci język, nagle integracja z intranetem) wraca do zapisu, zanim wejdzie w sprint.

#Jak zacząć projekt w Göteborgu

Do rozmowy wystarczy krótki opis: jaki motyw i jakie wtyczki są dziś, kto redaguje (PL/SV/EN), czy front ma być formalnym SV i EN, czy w grze jest CPT pod publikacje i wydarzenia, czy IT po stronie Göteborgu wymaga Git i stagingu od dnia zero, gdzie stoi hosting i czy kopie muszą zostać w UE. Zespół ogląda instalację, spisuje ryzyka (Gutenberg używany jak notatnik, sekrety w repo, brak integritetspolicy, ACF zdublowane z blokami, rozjechana para SV/EN) i proponuje plan z kryteriami odbioru.

Kontakt: formularz WPPoland. Pillar usługowy, bez miasta w slugach, zostaje przy programiście WordPress.