Programista WordPress w Bernie

Strona instytucji albo dostawcy usług w Bernie stoi obok Bundeshaus przy Bundesplatz, kantonu Bern i siedziby Swisscom przy Alte Tiefenaustrasse. To nie jest powód, żeby WordPress udawał portal federalny admin.ch. To powód, żeby motyw, wtyczki i model treści były napisane tak, jak oczekuje szwajcarski dział prawny, niemieckojęzyczny redaktor w Bernie i francuskojęzyczny recenzent z kantonu Vaud, który czyta wersję FR zanim trafi na produkcję.

WPPoland buduje ten WordPress z polskiego zespołu seniorów dla firm, dostawców sektora publicznego i organizacji, które mają siedzibę, oddział albo klientów Bernie. 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. Dla zespołów międzynarodowych dostępny jest także dedykowany brief w języku angielskim. Sklep WooCommerce i abonament opieki są osobnymi tematami, z linkami na końcu.

#Programowanie WordPress w Bundesstadt i kantonie Bern

Berno to nie Basel z farmaceutyką i giełdą, ani Genewa z ONZ i WTO. To Bundesstadt: siedziba Rady Federalnej, parlamentu i kluczowych urzędów federalnych w okolicy Bundesplatz. Kanton Bern dokłada własną administrację, uczelnie i gęstą sieć dostawców IT obsługujących zamówienia publiczne. Swisscom z siedzibą w Bernie-Ost to jeden z największych pracodawców technologicznych w mieście, ale brief WordPressa rzadko brzmi „zróbcie stronę jak operator telekomu”. Częściej brzmi: odziedziczony motyw z trzema wtyczkami wielojęzycznymi, publikacje DE/FR, które się rozjeżdżają po aktualizacji, redakcja w Polsce, a recenzent w Bernie pyta o nDSG, hosting w CH i oświadczenie o dostępności zanim ktoś wpuści landing na produkcję.

Dla strony WordPress te fakty oznaczają trzy twardsze wymagania niż na typowym rynku B2B. Po pierwsze formalność językowa: niemiecki front w rejestrze Sie, francuska wersja równoległa, nie tłumaczenie maszynowe z polskiego briefu. Po drugie ślad decyzji: kto akceptuje DE, kto FR, co idzie na środowisko testowe, co na produkcję, gdy sesja parlamentu albo termin zamówienia publicznego zbliża zamrożenie zmian. Po trzecie rezydencja i retencja: hosting w Szwajcarii, kopie, logi i integracje formularzy to temat rozmowy przed pierwszym commitem, nie dopisek w umowie po incydencie.

Bern Digital Hub przy Wylerstrasse i okoliczne coworkingi (Impact Hub Bern, Biel/Bienne w aglomeracji) dokładają recenzentów, którzy czytają pull request i pytają, czy wtyczka consent nie wysyła IP do USA bez podstawy prawnej. Uniwersytet w Bernie (Universität Bern) i Bern University of Applied Sciences (BFH) wypuszczają ludzi, którzy odróżnią motyw od wtyczki i wiedzą, że Polylang nie zastąpi procesu redakcyjnego. Pendlerzy z Biel/Bienne, Thun i Solothurn pracują w jednym biurze po niemiecku i po francusku, więc strona DE/FR z polskim zapleczem redakcyjnym jest tu częstsza niż czysto polski front z niemieckim panelem.

Typowy brief, który trafia do seniorów, nie brzmi „zróbcie ładną stronę”. Brzmi: federalny szablon sprzed pięciu lat, WPML albo Polylang po patchu serwuje niemiecki tekst na wersji francuskiej, Gutenberg używany jak notatnik, a nowa publikacja urzędowa 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 wykonawcą admin.ch ani kantonu Bern. Sąsiedztwo Bundeshaus ustawia poprzeczkę dokumentacji, ról i dwujęzyczności. Nie ustawia listy referencji rządowych.

#Motyw blokowy, motyw klasyczny i własna wtyczka

Nowa budowa w Bernie 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 FR w weekend przed terminem” kończy się regresją hreflang i skargą działu prawnego.

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

Motyw blokowy trzyma tokeny: paletę, skalę typografii, odstępy, szerokości treści. Dla bernskiego B2B i dostawców sektora publicznego oznacza to stonowaną paletę, czytelny krój bez ozdobników i przyciski, które nie pękają na niemieckich złożeniach federalnych ani na francuskich formułach urzędowych. Wzorce bloków opisują powtarzalne układy: hero z zastrzeżeniem prawnym, siatka osób z działu, blok cytatu z atrybucją, stopka z Impressum i linkiem do polityki prywatności zgodnej z nDSG. Redaktor składa stronę z wzorców, zamiast prosić programistę o nowy szablon na każdą publikację czy komunikat prasowy.

Pełna edycja witryny (FSE) ma sens, gdy zespół redakcyjny naprawdę ma dostać kontrolę nad nagłówkiem i stopką. W praktyce wiele instytucji i firm z Bernie 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 Bernie 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 dostawców, inne dla obywateli) 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 DE/FR, 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 urzędowych, 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ń federalnych, 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 bernski 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 administrację i sektor publiczny

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 Bernie listy są konkretne: publikacje, komunikaty, osoby, stanowiska, wydarzenia konsultacyjne, lokalizacje biur (Bundesplatz to nie Wylerstrasse, Biel to nie Thun). 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 urzędowym. 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 szwajcarskimi 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 Bernie 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 DE/FR każdy ciąg w bloku przechodzi przez funkcje i18n WordPressa. Niemiecki albo francuski 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 DE i treści redagowane z Polski da się ogarnąć rolami i locale użytkownika, bez pełnego stacku wielojęzycznego, ale front DE/FR w Bernie 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 sesję parlamentu, termin konsultacji publicznej albo wydarzenie Bern Digital Hub 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 DE/FR: polski zespół, szwajcarski front

Najczęstsze tarcie we współpracy Polska - Bernie nie jest w PHP. Jest w tonie i w parze języków. Niemiecki UI strony instytucjonalnej używa formy grzecznościowej Sie. Francuska wersja nie może być dosłownym tłumaczeniem z polskiego briefu ani maszynowym exportem z DE 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 niemiecku w formalnym Sie na wersji DE i po francusku w formalnym vous na wersji FR, jeśli front jest dwujęzyczny. Polski wariant, jeśli powstaje dla wewnętrznego panelu, nie kopiuje Sie ani vous 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 i francuska: ß, umlauty, apostrofy we francuskich skrótach, 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.
• Impressum, polityka prywatności (Datenschutzerklärung / politique de confidentialité) i oświadczenie o dostępności są szablonami z polami, nie blokami, które redaktor może przypadkiem usunąć z drzewa. W Bernie te strony są elementem zgodności, nie stopką marketingową. Wpis w rejestrze handlowym (Zefix) i dane kantonu Bern 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 niemiecki tekst, kto francuski, zanim pójdzie na produkcję. W briefie zapisujemy, czy akceptacja leży po stronie klienta w Bernie, po stronie polskiego content leada, czy po obu równolegle. środowisko testowe pokazuje obie wersje językowe, bo regresja „DE się zepsuło, bo ktoś edytował FR” wychodzi dopiero na porównaniu, nie w Lighthouse.

Federalna i kantonalna kultura komunikacji w Bernie jest bardziej formalna niż startupowy copy z coworkingu. Sie w DE, vous w FR w UI, mailu transakcyjnym i komunikacie błędu formularza. Du albo tutoi bywa dopuszczalne na stronie kariery startupu, jeśli brief to zapisze. Domyślne mieszanie rejestrów jednym motywie jest błędem, nie „elastycznością”.

#Dostępność w kontekście szwajcarskim i sektora publicznego

Dostępność w Bernie nie jest jednym checkboxem. Instytucje publiczne i wielu dostawców pracujących na rzecz sektora publicznego muszą liczyć się z wymogami dostępności cyfrowej odsyłającymi do EN 301 549 i WCAG 2.1 AA (z migracją do WCAG 2.2 tam, gdzie audytor tego wymaga). To nie jest niemiecki BITV ani BFSG. Szwajcarski kontekst federalny ma własne oczekiwania co do oświadczenia o dostępności, kanału informacji zwrotnej i testowalności przed publikacją dokumentów ważnych dla obywateli.

Sektor prywatny w Bernie (Swisscom, dostawcy IT, kancelarie obsługujące zamówienia) często kopiuje te same standardy, bo recenzent po stronie klienta przyzwyczaił się do listy WCAG z projektów federalnych. Zespół nie sprzedaje „certyfikatu dostępności admin.ch”. 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 urzędowa 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 sektora publicznego albo 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 Bernie.

#Bezpieczeństwo, nDSG i hosting w Szwajcarii

Sąsiedztwo Bundeshaus i Swisscom nie czyni marketingowego WordPressa systemem klasyfikacji informacji federalnej. Zespół nie pisze, że strona „spełnia ISO 27001” albo „jest certyfikowana przez NCSC”, jeśli audytu nie było. ISO 27001 dotyczy systemu zarządzania bezpieczeństwem informacji u klienta. WordPress ma dostarczyć inwentarz, ślad dostępu i dyscyplinę aktualizacji, które klient wkleja do własnej dokumentacji zamówienia publicznego albo umowy powierzenia, 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 CH 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 nDSG i polityką klienta, nie „trzymamy wszystko wiecznie”. Przy incydencie klient może musieć zgłosić naruszenie do Prezesa Urzędu Ochrony Danych (EDÖB); dziennik ma dać się włożyć do formularza, agencja nie składa zgłoszenia za administratora danych.

RODO i nDSG to osobne warstwy w briefach transgranicznych: minimalizacja pól formularza, umowa powierzenia, consent na skrypty, lokalizacja hostingu. Hosting „w Szwajcarii” jest argumentem o jurysdykcji, nie magiczną tarczą. Formularz, który zbiera dane osobowe bez podstawy prawnej i bez informacji w polityce prywatności, nie naprawi go sama lokalizacja serwera w Bernie-Ost.

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 Bernie klient z działem IT albo z doświadczeniem zamówień publicznych i tak zapyta o to na drugim spotkaniu, zwłaszcza jeśli recenzent przychodzi z BFH, z Bern Digital Hub albo z wewnętrznego IT Swisscom.

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 DE/FR. 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; szwajcarskie IT w Bernie zwykle woli angielski w diffie i DE/FR 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 terminem publikacji federalnej.

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 albo Enregistrer 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 DE i FR. 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 Bundesstadt”.

#Bern Digital Hub i lokalna scena techniczna

Bern Digital Hub przy Wylerstrasse 60A to punkt orientacyjny dla ekosystemu cyfrowego w mieście: spotkania, networking, projekty łączące administrację, startupy i dostawców IT. To nie jest argument sprzedażowy WPPoland. To barometr: redakcje i działy IT w Bernie pytają o repozytorium, o środowisko testowe i o to, czy motyw nie psuje edytora po aktualizacji Core, bo widzieli takie pytania na lokalnych meetupach i w korytarzach BFH.

Impact Hub Bern i okoliczne inicjatywy dokładają recenzentów, którzy czytają copy i kod. Uniwersytet w Bernie (Universität Bern) i BFH dostarczają ludzi, którzy umieją odróżnić motyw od wtyczki i wiedzą, że Polylang nie zastąpi procesu akceptacji FR. Swisscom 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.

Szersza scena szwajcarska ma WordCamp Switzerland i spotkania w Zurichu czy Bazylei, ale brief bernski nie musi udawać bankowości z Baselu ani dyplomacji z Genewy. Dla tego miasta ważniejsze jest dwujęzyczne DE/FR, sektor publiczny i kanton Bern 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ę francuską, czy formularz nie wysyła danych poza CH bez podstawy prawnej.

#Sklep WooCommerce to osobny zakres

Ta strona nie buduje checkoutu, bramek TWINT ani katalogu produktów. Jeśli brief schodzi na sklep, VAT, integrację z PostFinance albo QR-Rechnung, zakres zmienia właściciela i opisuje go programista WooCommerce w Bernie. Pillar bez miasta: programista WooCommerce. Mieszanie sklepu z motywem instytucjonalnym w jednym repozytorium bez granicy wtyczek to najszybsza droga do tego, żeby aktualizacja Woo rozwaliła landing pod konsultacje publiczne, 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ę DE/FR bez regresji hreflang. Jeśli po starcie potrzebne są aktualizacje Core, monitoring i stały dyżur, to jest opieka techniczna WordPress w Bernie, 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 federalnym) wraca do zapisu, zanim wejdzie w sprint.

#Jak zacząć projekt w Bernie

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

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