Programista WordPress w Leeds

Strona firmowa w Leeds stoi obok wieżowców finansowych przy Park Row, studia Channel 4 przy City Square, kampusów uniwersyteckich w Headingley i kalendarza, w którym Leeds Digital Festival zamraża wdrożenia tak samo jak zamknięcie księgowe przed raportem kwartalnym. To nie jest powód, żeby WordPress udawał system bankowy albo platformę VOD. To powód, żeby motyw, wtyczki i model treści były napisane tak, jak oczekuje dział compliance w Yorkshire i polski redaktor, który codziennie publikuje po polsku, a panel ma po angielsku.

WPPoland buduje ten WordPress z polskiego zespołu seniorów dla firm w Leeds i Yorkshire, które mają siedzibę, oddział albo klientów Wielkiej Brytanii. 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 i abonament opieki są osobnymi tematami, z linkami na końcu.

#Programowanie WordPress dla firm w Leeds

Leeds spina trzy rzeczy, które rzadko spotykają się w jednym mieście w takiej skali. Po pierwsze finanse: po Londynie to największy ośrodek usług finansowych w UK, z bankami, towarzystwami ubezpieczeniowymi, funduszami i doradcami regulowanymi przez Financial Conduct Authority (FCA). Po drugie media i kreatywność: Channel 4 przeniosło krajową siedzibę do Leeds, obok BBC w White City Place, Sky w Leeds Dock i rosnącego klastra cyfrowego w Leeds Digital Hub. Po trzecie usługi profesjonalne i edukacja: cztery uniwersytety, Leeds Beckett, kancelarie przy The Calls i software house’y, które obsługują klientów całej Europie z biura w Yorkshire.

Dla strony WordPress te fakty nie oznaczają, że motyw ma liczyć transakcje SWIFT albo streamować program na żywo. Oznaczają trzy twardsze wymagania. Treść bywa regulowana (FCA disclaimers, risk warnings, privacy notice pod UK GDPR). Interfejs dla gościa jest formalny i po angielsku, nawet gdy redaktorzy siedzą w Polsce. Hosting, retencja logów i pytanie o jurysdykcję danych po Brexicie są tematem rozmowy, bo obok siedzi ktoś, kto pyta o UK GDPR, o PCI DSS albo o slot na raport kwartalny.

Typowy brief, który trafia do seniorów, nie brzmi „zróbcie ładną stronę”. Brzmi: odziedziczony motyw z 35 wtyczkami, redakcja w Polsce, compliance w Leeds, Gutenberg używany jak klasyczny edytor, a nowa podstrona pod Leeds Digital Festival powstaje przez kopiowanie strony z zeszłego roku i ręczne podmienianie dat w treści. To jest problem modelu treści i procesu Git, nie problem szablonu z marketplace.

WPPoland nie jest dostawcą Channel 4, First Direct ani Yorkshire Building Society. Sąsiedztwo finansów i mediów ustawia poprzeczkę dokumentacji, ról i Git. Nie ustawia listy referencji.

#Motyw blokowy, motyw klasyczny i własna wtyczka

Nowa budowa w Leeds 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.

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

Motyw blokowy trzyma tokeny: paletę, skalę typografii, odstępy, szerokości treści. Dla leedsowskiego B2B oznacza to stonowaną paletę korporacyjną, czytelny krój bez ozdobników i przyciski, które nie pękają na długich angielskich złożeniach w stylu regulatory-compliance-framework albo investment-management-services. Wzorce bloków (block patterns) opisują powtarzalne układy: hero z zastrzeżeniem prawnym FCA, siatka osób z działu, blok cytatu z atrybucją, stopka z privacy notice i company registration number. Redaktor składa stronę z wzorców, zamiast prosić programistę o nowy szablon na każde wydarzenie w Leeds Dock albo na każdą edycję festiwalu.

Pełna edycja witryny (FSE) ma sens, gdy zespół redakcyjny naprawdę ma dostać kontrolę nad nagłówkiem i stopką. W praktyce wiele firm z Yorkshire 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 Leeds 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. 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 inwestora, inne dla prasy, inne dla kandydata) 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 i autoload, 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 wydarzeń festiwalowych, kolejka do CRM, endpoint REST dla intranetu, rola użytkownika „redaktor PL” bez capability publish_pages na produkcji angielskiej: 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). Logika biznesowa nie trafia do functions.php motywu, bo functions.php umiera razem z motywem, a leedsowski serwis zmienia agencję brandingową częściej niż model treści.

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

#Gutenberg, CPT i ACF w modelu treści

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 Leeds listy są konkretne: wydarzenia festiwalowe, publikacje, osoby, stanowiska, lokalizacje biur (Park Row to nie Headingley, Leeds Dock to nie City Square). 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 wydarzenia (kongres, webinar, festiwal) 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: data rozpoczęcia, lokalizacja w Leeds Dock, język wystąpienia, plik PDF z regulaminem. 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 z brytyjskimi wtyczkami consent i cache.

#Bloki serwerowe zamiast shortcode’ów

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

Dla redakcji dwujęzycznej każdy ciąg w bloku przechodzi przez funkcje i18n WordPressa. Angielski string w kodzie PHP jest wyjątkiem, nie regułą. Tłumaczenia leżą w plikach po, nie w hardcoded tablicy w motywie. Polylang albo WPML dokładamy dopiero gdy naprawdę są dwa (albo trzy) języki na froncie. Sam panel w EN i treści w PL da się ogarnąć rolami i locale użytkownika, bez pełnego stacku wielojęzycznego.

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 Leeds Digital Festival albo pod wydarzenie w Leeds Dock nie powstaje jako kopia strony z zeszłego roku. Powstaje jako obiekt CPT z datą, lokalizacją, językiem i wzorcem. Po festiwalu obiekt zostaje w archiwum, a nie jako osierocona podstrona w drzewie.

#Leeds: finanse, Channel 4 i Leeds Digital Festival

Leeds nie jest klastrem mediów jak MediaCityUK w Manchesterze i nie jest węzłem logistycznym jak port w Hamburgu. Tu liczy się sektor finansowy, relokacja mediów narodowych i kalendarz cyfrowy Yorkshire. Te trzy osie ustawiają priorytety techniczne dla WordPressa, który ma działać w tym mieście, a nie tylko nosić je w tytule.

#Finanse: FCA, risk warnings i stabilność

Leeds jest drugim co do wielkości ośrodkiem usług finansowych w UK po Londynie. Wokół Park Row, Wellington Place i Trinity Leeds siedzą banki, towarzystwa ubezpieczeniowe, doradcy inwestycyjni i fintechy regulowane przez FCA. Dla WordPressa wynika z tego prosta rzecz: serwis „firmowy” zarządzającego aktywami, brokera albo doradcy żyje w roku, w którym regulacje się zmieniają, a risk warning na stronie produktowej musi być aktualny. Awaria panelu partnera albo formularza leadowego boli w compliance, nie w „UX”.

Strona regulowana przez FCA wymaga disclaimerów, które nie mogą zniknąć po zmianie motywu. Risk warnings muszą być widoczne bez scrollowania na mobile. Link do rejestru FCA musi prowadzić do właściwego numeru firmy. Motyw, który chowa disclaimer w stopce edytowalnej przez każdego redaktora, to incydent compliance, nie „drobny bug CSS”. Dlatego disclaimery i privacy notice idą do szablonów z polami, nie do bloków, które redaktor może przypadkiem usunąć.

#Channel 4: relokacja i nowy profil mediów Leeds

Channel 4 przeniosło krajową siedzibę z Londynu do Leeds, inwestując w nowe studio przy City Square i tworząc setki miejsc pracy w Yorkshire. To nie jest case study WPPoland. Jest mapą rynku: wokół relokacji siedzą agencje kreatywne, producentzy, software house’y i dostawcy, których WordPress trzyma kariery, portfolio i landingi B2B. Łatka, która w piątek wyłącza webhook statusu, zostawia zespół z ręcznym klejeniem numerów. Dlatego integracje REST i webhooki idą do wtyczki z testami, a nie do functions.php motywu.

Serwis wydawniczy albo kreatywny na WordPressie w Leeds ma inny profil regresji niż landing finansowy. Publikacja o statusie future musi respektować embargo. Cache nie może serwować szkicu przed czasem. Motyw, który woła get_post bez sprawdzenia statusu, to wyciek przed embargiem, nie „drobny bug CSS”.

#Leeds Digital Festival i freeze wdrożeń

Leeds Digital Festival to coroczne wydarzenie, które zbiera branżę technologiczną, startupy i korporacje z Yorkshire. W oknie festiwalowym ruch na stronie rośnie, newslettery idą w tysiącach, a każda zmiana na produkcji jest ryzykiem. Dlatego w runbooku zapisujemy freeze wdrożeń: w oknie festiwalowym nie idą aktualizacje wtyczek, nie idą nowe bloki, nie idą zmiany w motywie. środowisko testowe dostaje zmiany, produkcja czeka do poniedziałku po festiwalu.

To nie jest superstycja. To jest proces Git: gałąź czeka na merge, tag czeka na deploy, a redakcja ma checklistę publikacji (szkic, future, purge, URL newslettera, privacy notice w stopce). Bez tego freeze wygląda jak „nic nie robimy”, a z nim wygląda jak plan, który przeżył Leeds Digital Festival i nie wymaga post-mortem w poniedziałek rano.

#Leeds Digital Hub i compliance w budowie

Leeds Digital Hub koncentruje firmy technologiczne w centrum miasta, obok kampusów uniwersyteckich i biurowców przy Wellington Place. Firmy w Leeds w 2026 siedzą w nakładających się ramach: UK GDPR, FCA Consumer Duty i - przy działalności finansowej - PCI DSS. Hybryda (produktywność w chmurze, kopie lokalne) jest tam częstsza niż „wszystko na najtańszym VPS”.

WordPress nie spełnia FCA ani PCI DSS sam z siebie. Może dostarczyć inwentarz, ślad dostępu i dyscyplinę Git, które klient wkleja do własnej dokumentacji. Pytanie o hosting w UK, origin w Yorkshire i retencję logów pada na kickoffie, nie po trzech miesiącach wdrożenia.

#UK GDPR i ochrona danych po Brexicie

Po Brexicie Wielka Brytania ma własny reżim ochrony danych: UK GDPR (kopia rozporządzenia UE z brytyjskimi poprawkami) oraz Data Protection Act 2018. To nie jest to samo co RODO w Unii, choć w praktyce wymagania są zbliżone. Dla firm w Leeds, które obsługują klientów UK i w UE, pytanie o transfer danych, standardowe klauzule umowne i reprezentanta w UE pada na kickoffie, nie po wdrożeniu.

#Co WordPress może, a czego nie może w UK GDPR

WordPress nie jest DPO i nie wystawia certyfikatu UK GDPR. Może dostarczyć techniczne środki, które właściciel procesu opisuje w dokumentacji:

• Formularze zbierają tylko pola, które są potrzebne. Pole „data urodzenia” na formularzu kontaktowym B2B to red flag.
• Consent na skrypty marketingowe jest jawny, z możliwością wycofania. Wtyczka consent musi blokować tag manager do momentu zgody, nie tylko pokazywać banner.
• Privacy notice jest szablonem z polami, nie blokiem, który redaktor może usunąć. Link do polityki prywatności jest w stopce, nie w stopce edytowalnej przez każdego.
• Logi dostępu do wp-admin mają retencję uzgodnioną z polityką, nie „trzymamy wszystko wiecznie”.
• Eksport i usunięcie danych użytkownika działają przez natywne narzędzia WordPressa albo wtyczkę privacy, nie przez ręczne SQL w phpMyAdmin.

Dla firm z klientami w UE dodatkowo: reprezentant w UE (jeśli wymagany), standardowe klauzule umowne, ocena wpływu na ochronę danych (DPIA) przy nowych formularzach zbierających dane wrażliwe. Zespół nie obiecuje „zgodności UK GDPR” bez właściciela procesu po stronie klienta. Obiecuje konfigurację techniczną, którą właściciel może opisać w dokumentacji.

#Sektor finansowy: dane wrażliwe i retencja

Firmy regulowane przez FCA często przetwarzają dane finansowe klientów. WordPress marketingowy zwykle nie trzyma numerów kont ani historii transakcji. Trzyma formularze leadowe, newslettery i logi dostępu. Granica musi być zapisana: co jest w WordPressie, co jest w CRM, co jest w systemie core banking. Jeśli formularz zbiera dane, które powinny trafić bezpośrednio do CRM przez API, wtyczka integracyjna nie zapisuje kopii w wp_postmeta.

Retencja logów: kto zalogował się do wp-admin, skąd poszła zmiana wtyczki, kiedy wysłano formularz. W UK GDPR retencja musi być uzasadniona i ograniczona. Logi sprzed trzech lat bez powodu to ryzyko, nie archiwum.

#Redakcja dwujęzyczna: polski zespół, angielski interfejs

Najczęstsze tarcie we współpracy Polska - Leeds nie jest w PHP. Jest w tonie. Angielski UI strony firmowej z UK używa formalnego rejestru B2B. Polski redaktor, który tłumaczy z headlinera napisanego u siebie na „ty”, publikuje tekst, który przy kancelarii w The Calls i w korespondencji z FCA brzmi jak newsletter siłowni. To nie jest kwestia wtyczki translatorskiej. To jest brief językowy i lista ciągów motywie.

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

• Ciągi interfejsu (przyciski, błędy formularza, aria-label, placeholder) są po angielsku w formalnym rejestrze B2B, jeśli front jest EN. Polski wariant, jeśli powstaje, nie kopiuje angielskiego jeden do jednego, tylko naturalny polski rejestr 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 „Posts” na „Wpisy” w połowie ekranu.
• Typografia angielska: długie złożenia, risk warnings w jednej linii. Przyciski i pozycje menu mają rezerwę szerokości. Łamanie w CSS nie może ucinać tekstu compliance.
• Privacy notice, terms of use i cookie policy są szablonami z polami, nie blokami, które redaktor może przypadkiem usunąć z drzewa. w Leeds te strony są elementem zgodności, nie stopką marketingową.

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

#Dostępność: WCAG 2.2 AA i Equality Act 2010

Dostępność w UK nie jest jednym przepisem. Publiczny sektor podlega The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, które odsyłają do WCAG 2.1 AA (z migracją do 2.2). Sektor prywatny podlega Equality Act 2010, który wymaga rozsądnych dostosowań dla osób z niepełnosprawnościami. To jest kontekst rynku w Leeds, nie certyfikat WPPoland.

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, nie tylko w kolorze ramki.
• Media: tekst alternatywny jako pole wymagane w procesie redakcji, nie jako „uzupełnimy później”.
• PDF: jeśli regulamin, karta produktu albo raport roczny idzie jako załącznik, dostępność dokumentu 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 sektora publicznego albo z wymogami FCA dokładamy ręczną ścieżkę klawiatury i porównanie z listą WCAG. Zespół nie wystawia certyfikatu, jeśli testu nie było. Zespół nie obiecuje pełnej zgodności bez właściciela procesu po stronie klienta.

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

#Bezpieczeństwo przy stronach z sąsiedztwa finansów i mediów

Sąsiedztwo Park Row i studia Channel 4 nie czyni marketingowego WordPressa systemem bankowym ani platformą VOD. Zespół nie pisze, że strona „spełnia FCA” albo „jest certyfikowana ISO 27001”. FCA reguluje działalność finansową, nie strony marketingowe. ISO 27001 dotyczy systemu zarządzania bezpieczeństwem informacji. Większość korporacyjnych stron WordPress w Leeds nie jest samodzielnym podmiotem tych reżimów. Część stoi obok organizacji, które są. Wtedy WordPress 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, 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ą.
• Kopie i odtworzenie: backup bez przetestowanego restore to ozdoba. Test odtworzenia na stagingu jest w runbooku.
• Logi: kto zalogował się do wp-admin, skąd poszła zmiana wtyczki. Retencja uzgodniona z UK GDPR, nie „trzymamy wszystko wiecznie”.

UK GDPR jest osobną warstwą: minimalizacja pól formularza, umowa powierzenia (DPA), consent na skrypty, lokalizacja hostingu. Hosting „w UK” (AWS eu-west-2 w Londynie, DigitalOcean w Londynie, albo inny DC w Wielkiej Brytanii) jest argumentem o jurysdykcji, nie magiczną tarczą. Firma z Park Row nie naprawi wtyczki, która trzyma CV kandydatów wp_posts bez limitu dostępu.

Testy penetracyjne i ISO 27001 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 zero incydentach. Szerszy audyt bezpieczeństwa opisuje audyt bezpieczeństwa WordPress.

#Git, środowisko testowe i przegląd kodu

To jest warstwa, która odróżnia seniorskie prace WordPress od „wgrania ZIP-a na FTP”. w Leeds klient z działem IT i tak zapyta o to na drugim spotkaniu, zwłaszcza jeśli recenzent przychodzi z Leeds Digital Hub albo z wewnętrznego IT firmy z Wellington Place.

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. 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.

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; brytyjskie IT w Leeds zwykle woli angielski w diffie i angielski 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 klientów. Redakcja klika po stagingu z prawdziwymi wzorcami Gutenberg, nie po localhostcie programisty. Regresja wielojęzyczna, regresja klawiatury i regresja embargo (status future, purge cache) 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 Leeds Digital Festival.

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 Save w angielskim 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. 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 firmach finansowych”.

Dla serwisu B2B albo redakcyjnego w Leeds liczy się czas do pierwszego bajtu z sieci w Yorkshire, nie tylko z telefonu na tarasie. Monitoring z jednego regionu USA kłamie. Punkt pomiaru w UK albo przynajmniej w Europie jest częścią kontraktu operatorskiego, nie dodatkiem.

#Leeds Digital Festival i lokalna scena techniczna

Leeds Digital Festival co roku zbiera branżę technologiczną, startupy i korporacje z Yorkshire. W 2026 roku program obejmuje wydarzenia w Leeds Dock, przy Park Row i na kampusach uniwersyteckich. To nie jest kanał sprzedaży. To jest miejsce, w którym widać, jak lokalni maintainerzy aktualizują, jak rozmawiają o uprawnieniach i o hoście.

Konkretne tematy, które ustawiają poprzeczkę dla motywu:

• Bezpieczeństwo WordPressa: niezałatany Core jest gorszy niż brak nowej wtyczki „security”.
• Wtyczki eventowe: bezpośrednio dotyczą briefów z Leeds Digital Festival i Leeds Dock.
• Bloki wyłącznie w PHP: render serwerowy, nie React na froncie.
• Aktualizacja Core to proces, nie klik w panelu.

WP-CLI w development nie jest ozdobą festiwalową. To sposób, żeby scaffold bloku, różnicę wtyczek i eksport listy użytkowników zrobić powtarzalnie, z logiem, bez klików wp-admin na produkcji. Po sesji o bezpieczeństwie na festiwalu argument „zrobimy to ręcznie w panelu” brzmi jeszcze gorzej.

Szersza scena leedsowska obejmuje też Leeds Digital Hub i Sky w Leeds Dock, gdzie branża medialna i marketingowa spotyka się z technologią. Dla briefu leedsowskiego ważniejsze od WordCampu jest to, że lokalny kalendarz siedzi w centrum: ludzie, którzy przychodzą na performance, pluginy i bezpieczeństwo, zadają inne pytania niż marketingowa agencja z prezentacją „AI w treściach”. Motyw i wtyczki, które wychodzą z tego zespołu, muszą przeżyć takie pytania: skąd alt tekst, kto go akceptuje, czy blok eventowy nie psuje cache przy embargo.

Relokacja Channel 4 do Leeds zmieniła profil miasta z „drugiego Londynu finansowego” na „centrum mediów i finansów Yorkshire”. Dla WordPressa to oznacza więcej briefów z sektora kreatywnego obok tradycyjnych firm z Park Row. Oba segmenty wymagają innego profilu regresji, ale ten sam proces Git.

#Sklep WooCommerce to osobny zakres

Ta strona nie buduje checkoutu, bramek ani katalogu produktów. Jeśli brief schodzi na sklep, VAT, Royal Mail albo bramkę, zakres zmienia właściciela i opisuje go programista WooCommerce w Leeds. 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 Leeds Digital Festival, albo odwrotnie.

Korporacyjna strona z jednym przyciskiem „shop” 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. Jeśli po starcie potrzebne są aktualizacje Core, monitoring i stały dyżur, to jest opieka techniczna WordPress w Leeds, 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 drugi język, nagle integracja z intranetem) wraca do zapisu, zanim wejdzie w sprint.

#Jak zacząć projekt w Leeds

Do rozmowy wystarczy krótki opis: jaki motyw i jakie wtyczki są dziś, kto redaguje (PL/EN), czy front ma być formalnym angielskim B2B, czy w grze jest CPT pod wydarzenia i publikacje, czy IT po stronie Leeds wymaga Git i stagingu od dnia zero, czy firma jest regulowana przez FCA i jakie disclaimery muszą być na każdej podstronie. Zespół ogląda instalację, spisuje ryzyka (Gutenberg używany jak notatnik, sekrety w repo, brak privacy notice, ACF zdublowane z blokami) i proponuje plan z kryteriami odbioru.

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