Programista WordPress w Stuttgarcie

Strona firmowa w Stuttgarcie stoi obok siedziby Porsche AG w Zuffenhausen, kompleksu Mercedes-Benz w Untertürkheim i hal Messe Stuttgart przy Flughafenstraße. To nie jest powód, żeby WordPress udawał system MES albo portal dostawców Tier-1. To powód, żeby motyw, wtyczki i model treści były napisane tak, jak oczekuje baden-württembergski dział prawny i polski redaktor, który codziennie publikuje po polsku, 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 Stuttgarcie. 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 z DACH, które działają w Stuttgarcie

Stuttgart spina trzy rzeczy, które rzadko spotykają się w jednym mieście w takiej skali. Po pierwsze motoryzację i łańcuch dostaw: Porsche AG ma siedzibę i główną fabrykę w dzielnicy Zuffenhausen, Mercedes-Benz Group AG ma centralę w Stuttgarciu, a zakład montażowy w Untertürkheim leży tuż obok muzeum marki. Po drugie Mittelstand i maszynę: region Stuttgart i Neckar-Alb to jeden z najgęstszych klastrów dostawców Tier-2 i Tier-3 w Europie, a inicjatywa CARS 2.0 (Cluster Automotive Region Stuttgart 2.0), koordynowana przez Wirtschaftsförderung Region Stuttgart GmbH, wspiera małe i średnie firmy z automotive i maszynownictwa w transformacji cyfrowej i dywersyfikacji. Po trzecie kalendarz targów: Messe Stuttgart (Landesmesse Stuttgart) przy lotnisku to miejsce, gdzie w 2026 roku odbyły się między innymi CMT (17-25 stycznia, około 1200 kamperów i stoisk turystycznych) oraz LogiMAT (24-26 marca, ponad 1600 wystawców intralogistyki na dziesięciu halach i ponad 120 000 m² powierzchni wystawienniczej).

Dla strony WordPress te fakty nie oznaczają, że motyw ma liczyć milisekundy jak sterownik linii montażowej. Oznaczają trzy twardsze wymagania. Treść bywa regulowana (disclaimer, Impressum, Datenschutzerklärung, oświadczenie o dostępności). Interfejs dla gościa jest formalny i niemiecki, nawet gdy redaktorzy siedzą w Polsce. Hosting, retencja logów i integracje z intranetem są tematem rozmowy, bo sąsiedztwo OEM-ów uczy pytać o lokalizację danych, zanim ktoś wklei klucz API do wp-config.php w repozytorium.

Obok koncernów stoi Mittelstand, z którego rekrutują się wewnętrzni odbiorcy projektu. Dostawca z Esslingen am Neckar, producent komponentów z Ludwigsburgu albo firma usługowa z Vaihingen an der Enz potrzebuje strony, która nie brzmi jak szablon z ThemeForest, ale ma ten sam rejestr formalny co katalog PDF wysyłany do działu zakupów Zuffenhausen. ARENA2036 w Stuttgarcie-Vaihingen i ekosystem startupów wspierany przez WRS dokładają recenzentów, którzy czytają pull request. Hochschule der Medien, Universität Stuttgart i okoliczne uczelnie dostarczają ludzi, którzy umieją odróżnić motyw od wtyczki. Pendlerzy z Böblingen, Waiblingen, Reutlingen i Heilbronn pracują po niemiecku i angielsku w jednym biurze, więc strona dwujęzyczna DE/EN z polskim zapleczem redakcyjnym jest tu częstsza niż na typowym polskim rynku B2B.

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 Baden-Württembergii, Gutenberg używany jak klasyczny edytor, a nowa podstrona pod LogiMAT 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ą Porsche ani Mercedes-Benz. Sąsiedztwo Zuffenhausen i Untertürkheim ustawia poprzeczkę dokumentacji, ról i Git. Nie ustawia listy referencji.

#Motyw blokowy, motyw klasyczny i własna wtyczka

Nowa budowa w Stuttgarcie 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 stuttgarckiego B2B 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 Intralogistik-Lösungen albo Transformationsnetzwerk. Wzorce bloków (block patterns) opisują powtarzalne układy: hero z zastrzeżeniem prawnym, siatka osób z działu, blok cytatu z atrybucją, stopka z Impressum. Redaktor składa stronę z wzorców, zamiast prosić programistę o nowy szablon na każde wydarzenie Messe.

Pełna edycja witryny (FSE) ma sens, gdy zespół redakcyjny naprawdę ma dostać kontrolę nad nagłówkiem i stopką. W praktyce wiele firm z DACH 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 Stuttgarcie 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 dostawcy Tier-2, 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ń targowych, kolejka do CRM, endpoint REST dla intranetu, rola użytkownika „redaktor PL” bez capability publish_pages na produkcji niemieckiej: 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 stuttgarcki serwis zmienia agencję brandingową częściej niż model treści.

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

Warstwa	Co tam żyje	Przykład w Stuttgarcie
Motyw	prezentacja, tokeny, wzorce	landing pod LogiMAT, stopka z Impressum
Wtyczka	CPT, role, REST, integracje	katalog wydarzeń, kolejka do CRM, logi audytowe
Gutenberg	redakcja bez HTML	wzorzec z zastrzeżeniem, blok osoby z działu
środowisko testowe i Git	proces, nie feature	gałąź, review, promocja na produkcję

#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 Stuttgarcie listy są konkretne: wydarzenia targowe, publikacje techniczne, osoby, stanowiska, lokalizacje biur (Zuffenhausen to nie Vaihingen, Messe to nie centrum miasta). 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, targi) 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, hala Messe Stuttgart, 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 niemieckimi 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 Stuttgarcie 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. Niemiecki 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 DE 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 LogiMAT 2026 (24-26 marca, Messe Stuttgart) albo pod CMT (17-25 stycznia) nie powstaje jako kopia strony z zeszłego roku. Powstaje jako obiekt CPT z datą, halą, językiem i wzorcem. Po targach obiekt zostaje w archiwum, a nie jako osierocona podstrona w drzewie.

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

Najczęstsze tarcie we współpracy Polska - Stuttgart nie jest w PHP. Jest w tonie. 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 Zuffenhausen i w korespondencji z IHK Region Stuttgart 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 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. Łamanie w CSS nie może ucinać ß na „ss” w PDF-ach generowanych z treści.
• Impressum, Datenschutz i oświadczenie o dostępności są szablonami z polami, nie blokami, które redaktor może przypadkiem usunąć z drzewa. W Stuttgarcie 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 niemiecki tekst, zanim pójdzie na produkcję. W briefie zapisujemy, czy akceptacja leży po stronie klienta w Stuttgarcie, czy po stronie polskiego content leada. środowisko testowe pokazuje obie wersje językowe, bo regresja „DE się zepsuło, bo ktoś edytował PL” wychodzi dopiero na porównaniu, nie w Lighthouse.

Universität Stuttgart i Hochschule der Medien regularnie wypuszczają ludzi, którzy czytają zarówno kod, jak i niemiecki compliance. Jeśli po stronie klienta jest taki recenzent, przegląd kodu po stronie WPPoland i recenzja treści po stronie Stuttgartu idą równolegle, nie sekwencyjnie na tydzień przed startem.

Baden-württembergski rejestr formalny nie jest „twardszym niemieckim”. Jest konkretny: Sie w UI, Sie w mailu transakcyjnym, Sie w komunikacie błędu formularza. Du na stronie kariery bywa dopuszczalne, jeśli brief to zapisze. Domyślne mieszanie obu form w jednym motywie jest błędem, nie „elastycznością”.

#Dostępność: BITV 2.0, EN 301 549 i BFSG

Dostępność w Stuttgarcie nie jest jednym przepisem. Publiczny sektor (Landeshauptstadt Stuttgart, uczelnie, instytucje landu Baden-Württemberg) 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, z wersją 4.1.1 normy (WCAG 2.2) oczekiwaną w Dzienniku Urzędowym około października 2026. BITV dokłada obowiązki, których Europa nie kopiuje jeden do jednego: oświadczenie o dostępności, kanał informacji zwrotnej, a na stronach władz 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 firmy, 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.

W Baden-Württembergii szkolenia z cyfrowej dostępności są lokalnym faktem, nie slajdem. Landesmedienzentrum Baden-Württemberg i projekty takie jak barrierefreie WordPress-Website dla stowarzyszeń pokazują, że recenzent po stronie klienta może znać listę WCAG lepiej niż agencja, która obiecuje „pełną zgodność” bez testu klawiatury. Test BITV na bitv-test.de jest narzędziem orientacyjnym, nie pieczęcią od 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, 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. Zespół 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 Stuttgarciu.

#Bezpieczeństwo przy stronach z sąsiedztwa automotive Mittelstand

Sąsiedztwo Porsche i Mercedes-Benz nie czyni marketingowego WordPressa systemem sterowania produkcją. Zespół nie pisze, że strona „spełnia TISAX” albo „jest certyfikowana ISO 27001”. TISAX dotyczy łańcucha dostaw motoryzacji. ISO 27001 dotyczy systemu zarządzania bezpieczeństwem informacji. Większość korporacyjnych stron WordPress w Stuttgarcie 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ę aktualizacji, które klient wkleja do własnej dokumentacji, 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ą. W lipcu 2026 roku głośne było wp2shell (CVSS 9,8) na niezałatanych instalacjach. Moral z tego jeden: 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.
• Logi: kto zalogował się do wp-admin, skąd poszła zmiana wtyczki. Retencja uzgodniona z RODO, nie „trzymamy wszystko wiecznie, bo koncern może spytać”. Koncern pyta swoich dostawców, nie agencję od motywu, ale klient z Esslingen i tak zapyta nas pierwszy.

RODO jest osobną warstwą: minimalizacja pól formularza, umowa powierzenia, consent na skrypty, lokalizacja hostingu. Hosting „w Niemczech” jest argumentem o jurysdykcji, nie magiczną tarczą. Mittelstand z Ludwigsburgu 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.

#Git, środowisko testowe i przegląd kodu

To jest warstwa, która odróżnia seniorskie prace WordPress od „wgrania ZIP-a na FTP”. W Stuttgarcie klient z działem IT i tak zapyta o to na drugim spotkaniu, zwłaszcza jeśli recenzent przychodzi z Universität Stuttgart, z ARENA2036 albo z wewnętrznego IT dostawcy Tier-1.

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; niemieckie IT w Stuttgarcie 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 klientów. Redakcja klika po stagingu z prawdziwymi wzorcami Gutenberg, 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 LogiMAT.

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, 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 koncernach”.

#WordPress Meetup Stuttgart i lokalna scena techniczna

WordPress Meetup Stuttgart jest luźnym spotkaniem społeczności, nie eventem sprzedażowym. Oficjalna strona to wpmeetup-stuttgart.de, grupa na Meetup.com to wpmeetup-stuttgart. Kalendarz na wp0711.de podaje regularny rytm: comiesięczne spotkania w RegioHelden GmbH przy Rotebühlstr. 50 (70178 Stuttgart), start o 19:00. Wirtschaftsförderung Region Stuttgart wspiera meetup i publikuje terminy w swoim kalendarzu.

Konkretne terminy z 2026 roku, które ustawiają poprzeczkę dla motywu, a nie slajd „jesteśmy organizatorem”:

• 2 września: „Gute KI Inhalte entstehen vor dem Prompt” (131. spotkanie).
• 7 października: temat do ogłoszenia.
• 4 listopada (WRS) / 11 listopada (Meetup.com): kolejne spotkanie comiesięczne.
• 2 grudnia: zamknięcie roku spotkań.

W czerwcu 2026 meetup miał rundę pluginów, w maju wieczór o pomiarze wydajności. To nie jest argument sprzedażowy. To jest lokalny barometr: redakcje w Stuttgarcie będą klikać nowe funkcje Core, a motyw, który łamie edytor, wyjdzie na meetupie szybciej niż w tickecie. Wieczór o KI i treściach we wrześniu 2026 jest szczególnie istotny dla briefów PL/DE: prompt nie zastąpi modelu treści ani formalnego Sie.

Szersza scena baden-württembergska w 2026 roku obejmuje też WordCamp Mannheim i inne spotkania wpmeetups.de. Zespół jeździ tam, gdzie jest temat, a nie po to, by wpisać miasto do oferty. Dla briefu stuttgarckiego ważniejsze od WordCampu jest to, że lokalny meetup siedzi przy Feuersee: ludzie, którzy przychodzą na performance, pluginy i KI w treściach, 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 prompt AI nie wylewa danych osobowych z mediów do zewnętrznego API.

CARS 2.0 i ARENA2036 dokładają recenzentów, którzy pytają o repozytorium i o RODO, nie o „czy będzie slider”. IHK Region Stuttgart i Südwestmetall dokładają recenzentów, którzy pytają, czy strona dostawcy nie udaje produktu OEM. Oba pytania są zdrowe. Odpowiedź siedzi w modelu treści i w copy, nie w kolejnej wtyczce.

#Sklep WooCommerce to osobny zakres

Ta strona nie buduje checkoutu, bramek ani katalogu produktów. Jeśli brief schodzi na sklep, VAT, Magento-to-Woo albo bramkę, zakres zmienia właściciela i opisuje go programista WooCommerce w Stuttgarciu. 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 Messe, 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. Jeśli po starcie potrzebne są aktualizacje Core, monitoring i stały dyżur, to jest opieka techniczna WordPress w Stuttgarciu, 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 Stuttgarcie

Do rozmowy wystarczy krótki opis: jaki motyw i jakie wtyczki są dziś, kto redaguje (PL/DE), czy front ma być formalnym Sie, czy w grze jest CPT pod wydarzenia i publikacje, czy IT po stronie Stuttgartu wymaga Git i stagingu od dnia zero. 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) i proponuje plan z kryteriami odbioru.

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