Programista WordPress w Düsseldorfie

Strona firmowa w Düsseldorfie stoi przy Renie, w Medienhafen albo przy Messeplatz. To nie jest powód, żeby WordPress udawał system transakcyjny centrali. To powód, żeby motyw, bloki Gutenberg, CPT i wtyczki były napisane tak, jak oczekuje niemiecki dział prawny, japoński desk i polski redaktor, który publikuje z Warszawy albo Krakowa, a panel ma po niemiecku.

WPPoland buduje ten WordPress z polskiego zespołu seniorów dla firm z DACH, które mają siedzibę, oddział albo klientów Düsseldorfie. 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 w Düsseldorfie

Düsseldorf jest stolicą Nadrenii Północnej-Westfalii i jednym z najgęstszych węzłów japońskiego biznesu w Europie kontynentalnej. NRW.Global Business podaje około 400 japońskich firm w samym mieście i około 550 w najbliższym otoczeniu. Miasto mówi o rzędu 410 spółek i ponad siedmiu tysiącach Japończyków mieszkających na miejscu. W skali landu wokół stolicy pojawia się liczba rzędu 650 firm. To nie jest tło do sloganu. To jest brief modelu treści: trzy locale (DE, EN, JA), osobne Impressum, glosariusz prawny, którego nie wolno nadpisać wtyczką translatora, i redakcja rozciągnięta między Polską, NRW i Tokio.

Medienhafen trzyma biura, agencje i europejskie siedziby, nie „startupową scenę z plakatu”. The Cradle przy Speditionstraße, drewniany hybryd według zasady cradle-to-cradle, jest jednym z częściej cytowanych budynków tym porcie. Micware otworzył tam europejską siedzibę. WordPress z tego nabrzeża jest wejściem do spółki-córki: formalne Sie na froncie DE, angielski dla gości targowych, japoński dla macierzy. Motyw, który łamie hreflang albo gubi stopkę z Pflichtangaben, nie przejdzie recenzji prawnej, niezależnie od wyniku Lighthouse.

Po drugiej stronie miasta Messe Düsseldorf dokłada kalendarz, który w developmentcie jest ograniczeniem wydania, nie ozdobnikiem w hero. boot 2026 trwał od 17 do 25 stycznia (57. edycja, hale 1-17). EuroShop 2026, jubileuszowa 60. edycja handlu detalicznego, zajmowała ten sam teren od 22 do 26 lutego. ProWein: 15-17 marca. interpack: 7-13 maja. Caravan Salon: 28 sierpnia do 6 września (28 sierpnia to Preview Day). REHACARE International: 23-26 września, pod hasłem self-determined living. drupa wraca 9-17 maja 2028. Nowa architektura motywu, nowy CPT albo zmiana mapy hreflang nie wchodzi na produkcję w tych oknach. Daty idą do runbooka wydań, nie do hardcoded stringa w front-page.php.

Japan-Tag NRW 2026 wypadł 23 maja, z Burgplatz i Rheinuferpromenade jako osią programu. Japan Business Day, gospodarcze ramy tego weekendu, odbył się 27 maja w Hotelu Kö59, ze sceną o gospodarce obiegu zamkniętego (między innymi Mitsubishi Electric Europe, Toshiba Electronics Europe, cylib, LyondellBasell). Landing partnerski albo strona stowarzyszenia, która w tym tygodniu dostaje nowy szablon nagłówka „bo FSE tak ładniej wygląda”, produkuje incydent wizerunkowy, nie „drobny deploy”.

Typowy brief, który trafia do seniorów, nie brzmi „zróbcie ładną stronę”. Brzmi: odziedziczony motyw z page builderem, redakcja w Polsce, compliance w Düsseldorfie, Gutenberg używany jak klasyczny edytor, a nowa podstrona pod targi powstaje przez kopiowanie strony z zeszłego boot i ręczne podmienianie numeru hali. To jest problem modelu treści i procesu Git, nie problem szablonu z ThemeForest.

#Motyw blokowy, motyw klasyczny i własna wtyczka

Nowa budowa w Düsseldorfie 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 motywu

Motyw blokowy trzyma tokeny: paletę, skalę typografii, odstępy, szerokości treści. Dla B2B z Medienhafen oznacza to stonowaną paletę korporacyjną, czytelny krój bez ozdobników i przyciski, które nie pękają na niemieckich złożeniach w stylu Barrierefreiheitserklärung albo Datenschutzerklärung. Wzorce bloków opisują powtarzalne układy: hero z zastrzeżeniem prawnym, siatka osób z Japan desk, blok cytatu z atrybucją, karta stoiska z numerem hali, stopka z Impressum. Redaktor składa landing targowy z wzorców, zamiast prosić programistę o nowy szablon na każde ProWein.

Pełna edycja witryny (FSE) ma sens, gdy zespół redakcyjny naprawdę ma dostać kontrolę nad nagłówkiem i stopką. W praktyce wiele central w Düsseldorfie tej kontroli nie chce: nagłówek jest elementem brandu i Pflichtangaben, 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. Handbook na developer.wordpress.org jest źródłem kontraktu API, nie slajdem ze szkolenia.

#Kiedy klasyczny motyw PHP zostaje

Odziedziczone instalacje w Düsseldorfie 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, osobna kopia strony pod każdy boot. 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 gościa targowego, inne dla kandydata, inne dla wersji JA) 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 stoiska targowego, kolejka do CRM, endpoint REST dla intranetu, rola „redaktor PL” bez publish_pages na produkcji niemieckiej: to wtyczka. Kolory, siatka, wzorzec hero: to motyw. Jeśli po zmianie motywu znika katalog hal, 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 zapisu na stoisko). Logika biznesowa nie trafia do functions.php motywu, bo functions.php umiera razem z motywem, a serwis z Medienhafen zmienia agencję brandingową częściej niż model treści.

Porównanie warstw przy kickoffie:

#Gutenberg, CPT i ACF pod targi i centrale

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 Düsseldorfie listy są konkretne: stoiska, hale, osoby z Japan desk, lokalizacje biur (Medienhafen to nie Immermannstraße, Immermannstraße to nie Messeplatz), publikacje, stanowiska. To są obiekty, nie „kolejne strony w drzewie”.

#Własne typy treści zamiast kopiowanych landingów

CPT rejestrujemy z własnymi kapabilities, nie z mapowaniem na post. Redaktor w Polsce ma edytować kartę stoiska, a nie kasować wtyczek. Archiwum CPT dostaje szablon albo wzorzec zapytań. Pojedynczy obiekt ma szablon, który nie pozwala rozpychać layoutu poza ustalony układ. Taksonomie są osobne: typ wydarzenia (boot, EuroShop, ProWein, Caravan Salon, REHACARE) 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 otwarcia hali, numer stoiska, język rozmowy przy stoisku, plik PDF planu, flaga „Preview Day”. 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 niemieckimi wtyczkami consent i cache.

Landing targowy jako kopia strony z zeszłego roku jest długiem, który wychodzi w styczniu. Obiekt CPT z polami roku, hali i locale przeżywa boot 2027 bez kopiowania drzewa. Szablon czyta obiekt. Redaktor zmienia numer hali, nie HTML.

#Bloki serwerowe zamiast shortcode’ów

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

Dla redakcji trójjęzycznej każdy ciąg w bloku przechodzi przez funkcje i18n WordPressa (__(), _x(), esc_html__). Niemiecki string wkodowany w PHP jest wyjątkiem, nie regułą. Tłumaczenia leżą w plikach .po, nie w hardcoded tablicy w motywie. Polylang albo WPML dokładamy, gdy naprawdę są dwa albo trzy języki na froncie. Sam panel w DE i treści w PL da się ogarnąć rolami i locale użytkownika, bez pełnego stosu wielojęzycznego. JA na froncie to już pełny stos: hreflang, osobne slugi, test WAF pod znaki CJK, font z pokryciem kana, PDF Impressum, którego wtyczka translatora nie ma prawa nadpisać.

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.

#Redakcja DE, EN i JA

Najczęstsze tarcie we współpracy Polska - Düsseldorf nie jest w PHP. Jest w rejestrze. Niemiecki UI strony firmowej z DACH używa formy grzecznościowej Sie. Polski redaktor, który tłumaczy z headlinera napisanego u siebie na „ty”, publikuje tekst, który przy Königsallee brzmi jak newsletter siłowni. Japońska locale dokłada trzeci rejestr, którego nie da się „dorobić DeepL-em w nocy”. To jest brief językowy i lista ciągów motywie, nie wtyczka.

Zasady, które wpisujemy w dokumentację motywu:

• Ciągi interfejsu (przyciski, błędy formularza, aria-label, placeholder) są po niemiecku w formalnym Sie, jeśli front jest DE. Angielski wariant, jeśli jest, też jest formalny. Polski wariant, jeśli powstaje, nie kopiuje Sie 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 „Beiträge” na „Wpisy” w połowie ekranu.
• Typografia niemiecka: ß, umlauty, długie złożenia. Przyciski i pozycje menu mają rezerwę szerokości. JA wymaga fontu z kana i testu, czy WAF nie traktuje znaków jako anomalnego payloadu. To jest decyzja w motywie i w konfiguracji, nie ticket opieki po pierwszym zgłoszeniu z Tokio.
• Impressum, Datenschutz i oświadczenie o dostępności są szablonami z polami, nie blokami, które redaktor może usunąć z drzewa. W Düsseldorfie te strony są elementem zgodności, nie stopką marketingową. Wersja JA dostaje własne pola, nie maszynowy przekład niemieckiego tekstu prawnego.

Polylang i WPML rozwiązują hreflang i kopie językowe. Nie rozwiązują procesu: kto akceptuje niemiecki i japoński tekst, zanim pójdzie na produkcję. W briefie zapisujemy, czy akceptacja leży po stronie klienta w Düsseldorfie, po stronie Japan desk, czy po stronie polskiego content leada. środowisko testowe pokazuje wszystkie locale obok siebie, bo regresja „DE się zepsuło, bo ktoś edytował JA” wychodzi dopiero na porównaniu, nie w Lighthouse.

digihub Düsseldorf/Rheinland i status JETRO Global Acceleration Hub pokazują drugą warstwę miasta: japońskie zespoły wchodzące na DE przez mentoring i desk, nie przez stronę-wizytówkę z translatora. Motyw dla takiej spółki-córki dostaje od dnia zero i18n, a nie „dorobimy JA w fazie drugiej, po targach”.

#Dostępność: BITV 2.0, BFSG i REHACARE

Dostępność w Düsseldorfie nie jest jednym przepisem. Sektor publiczny (strony miasta, instytucji landu, Heinrich-Heine-Universität) podlega BITV 2.0. Rozporządzenie odsyła do EN 301 549. Na sierpień 2026 roku obowiązująca warstwa web to WCAG 2.1 na poziomie AA (EN 301 549 V3.2.1). Wersja 4.1.1 normy, zmapowana na WCAG 2.2, była oczekiwana w Dzienniku Urzędowym około października 2026. BITV dokłada obowiązki, których czysty WCAG nie kopiuje jeden do jednego: oświadczenie o dostępności, kanał informacji zwrotnej, a na stronach władz federalnych także Leichte Sprache i Deutsche Gebärdensprache. To jest kontekst rynku, nie certyfikat WPPoland.

Sektor prywatny od 28 czerwca 2025 roku ma BFSG, niemieckie wdrożenie European Accessibility Act. BFSG nie jest BITV. Trafia w usługi konsumenckie, między innymi handel elektroniczny, z wyłączeniem mikroprzedsiębiorstw przy usługach. Czysta strona informacyjna centrali, bez zakupu, rezerwacji i płatności, zwykle nie wpada w ten sam koszyk. Zespół nie sprzedaje więc „zgodności BITV” sklepowi ani „BFSG” intranetowi. Na kickoffie zapisujemy, który reżim w ogóle dotyczy witryny, a potem testujemy to, co da się przetestować w motywie i blokach.

REHACARE International 2026 (23-26 września, Motto self-determined living) jest lokalnym barometrem, którego Frankfurt ani Monachium nie mają w tej skali. Wystawcy, organizacje i publiczne stoiska przyjeżdżają do Düsseldorfu rozmawiać o włączeniu. Landing wystawcy, który na tym tygodniu ma niedziałający focus, kontrast poniżej AA albo formularz bez etykiet, jest błędem produktowym, nie „ticketem UX na po targach”. Dla developmentu wynika z tego twardy odbiór: skan axe w CI plus ręczna ścieżka klawiatury na wzorcu stoiska, zanim tag wejdzie na produkcję.

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 i w modalu zapisu na stoisko.
• 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. Zgoda na locale JA nie może znikać, bo szablon woła stary filtr.
• Media: tekst alternatywny jako pole wymagane w procesie redakcji, nie jako „uzupełnimy później”.
• PDF: jeśli plan hali albo regulamin idzie jako załącznik, klauzula 10 EN 301 549 (dokumenty 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 sektora publicznego albo z BFSG w zakresie e-commerce dokładamy ręczną ścieżkę klawiatury i porównanie z listą WCAG. Zespół nie wystawia certyfikatu BIK BITV-Test, jeśli testu nie było. Nie obiecuje Leichte Sprache ani DGS prywatnej stronie produktowej, bo to obowiązek innej klasy podmiotów.

Sklep i checkout to osobna rozmowa. Jeśli brief schodzi na WooCommerce, zakres przenosi się na programistę WooCommerce w Düsseldorfie.

#Git, środowisko testowe i zamrożenie wydania

To jest warstwa, która odróżnia seniorskie prace WordPress od wgrania ZIP-a na FTP. Klient z IT w Düsseldorfie zapyta o to na drugim spotkaniu, szczególnie gdy macierz w Tokio chce śladu, kto wgrał zmianę.

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. Japońskie IT przy europejskiej siedzibie zwykle woli angielski w diffie i niemiecki 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 gości stoiska. Redakcja klika po stagingu z prawdziwymi wzorcami Gutenberg, nie po localhoście programisty. Regresja wielojęzyczna (DE/EN/JA), regresja klawiatury i regresja hreflang 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 otwarciem bram Nord.

Zamrożenie wydania przy kalendarzu Messe jest decyzją developerską, nie tylko operatorską. W oknie boot, EuroShop, Caravan Salon albo REHACARE na produkcję nie wchodzi nowy theme.json, nowy CPT, zmiana mapy URL ani przebudowa nagłówka. Łatka bezpieczeństwa, która nie może czekać, idzie jako hotfix przez środowisko testowe, z rollbackiem zapisanym zanim ktoś naciśnie deploy. Daty 2026, które trzymamy w runbooku wydań:

drupa 2028 (9-17 maja) jest już w kalendarzu jako przyszłe okno. Daty nie są wkodowane w motyw. Żyją w runbooku, który przeżyje zmianę roku.

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. XML-RPC zostaje wyłączony, jeśli nie ma uzasadnionego klienta. Edytor plików panelu też.

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 Speichern w niemieckim 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 stoisk, single, strona z wzorcem hero, locale JA. 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 porcie”.

#Meetup WPDUS w LibraryLab

WordPress Meetup Düsseldorf (WPDUS) spotyka się na miejscu, zwykle w drugi wtorek miesiąca o 18:30, w LibraryLab Zentralbibliothek przy Konrad-Adenauer-Platz 1 (KAP1). Grupa ma rzędu 1 500 członków na Meetup. Strona społeczności to meetup.com/de-DE/dusseldorf-wordpress-meetup, z własnym serwisem wpdus.de. To nie jest kanał sprzedaży. To jest lokalny barometr: motywy i bloki, które łamią edytor, wychodzą na meetupie szybciej niż w tickecie z Tokio.

W 2026 roku program pokazał, czym żyje scena. 14 lipca WPDUS #101 wracało do tematu „KI als Gamechanger II - 3 Jahre später”, o 18:30 w KAP1. Sierpień był przerwą letnią. Urodzinowe #102, po dekadzie istnienia grupy, tradycyjnie wychodzi poza bibliotekę; kalendarz miejski Stadtbüchereien podawał 8 września, 18:30, z adnotacją, że to nie Zentralbibliothek. Zespół nie udaje organizatora. Zespół wie, że redakcje z NRW będą klikać nowe funkcje Core, w tym narzędzia AI w edytorze, i że motyw, który psuje InspectorControls albo wlewa dane z mediów do zewnętrznego API bez zgody, nie przeżyje takich pytań.

Szersza scena niemiecka w 2026 roku miała WordCamp Leipzig (9 maja) i WordCamp Mannheim (początek lipca). Wyjazd tam jest po temat, nie po wpisanie miasta do oferty. Dla briefu düsseldorfskiego ważniejsze od WordCampu jest to, że lokalny meetup siedzi w bibliotece miejskiej: ludzie, którzy przychodzą na bloki, dostępność i WP-CLI, zadają inne pytania niż agencja z Königsallee z prezentacją „nowy lookbook”. Motyw i wtyczki, które wychodzą z tego zespołu, muszą przeżyć takie pytania: skąd alt tekst, kto go akceptuje, czy prompt AI nie wylewa danych osobowych z biblioteki mediów.

#Sklep WooCommerce to osobny zakres

Ta strona nie buduje checkoutu, bramek ani katalogu produktów. Jeśli brief schodzi na sklep, VAT, SEPA albo etykiety DHL, zakres zmienia właściciela i opisuje go programista WooCommerce w Düsseldorfie. 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 na boot, 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, które daty Messe blokują wydanie. Jeśli po starcie potrzebne są aktualizacje Core, monitoring, WAF i stały dyżur operatorski, to jest opieka techniczna WordPress w Düsseldorfie, nie ukryty aneks do motywu. Szerszy opis produktu opieki, niezależny od 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 Düsseldorfie

Do rozmowy wystarczy krótki opis: jaki motyw i jakie wtyczki są dziś, kto redaguje (PL/DE/JA), czy front ma być formalnym Sie, czy w grze jest CPT pod stoiska i osoby, czy IT po stronie Düsseldorfu wymaga Git i stagingu od dnia zero, które daty Messe są w kalendarzu. Zespół ogląda instalację, spisuje ryzyka (Gutenberg używany jak notatnik, sekrety w repo, brak oświadczenia o dostępności, ACF zdublowane z blokami, landingi targowe kopiowane co rok) i proponuje plan z kryteriami odbioru.

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