Opieka techniczna WordPress w Edynburgu

Polski zespół, który utrzymuje WordPressa dla firmy w Edynburgu, nie dokłada „jeszcze jednego abonamentu aktualizacji”. Utrzymuje serwis, który stoi obok biura fintechu w Quartermile, portalu rezerwacji noclegów na czas Edinburgh Festival Fringe, sklepu WooCommerce z checkoutem w GBP przez Stripe albo PayPal oraz formularzy aplikacyjnych z integracją CRM, na rynku, gdzie awaria formularza rezerwacji przed szczytem festiwalowym albo martwy checkout po aktualizacji wtyczki to temat na rozmowę z działem compliance i z dyrektorem operacji, a nie tylko z marketingiem. Ta strona opisuje opiekę techniczną WordPressa właśnie w tym układzie: polski delivery, szkocki kontekst Edynburga, bez cennika i bez obietnic dostępności w procentach.

Szerszy opis produktu opieki, niezależny od miasta, jest na stronie utrzymania stron WordPress. Tu schodzimy do Edynburga: CodeBase, Edinburgh Digital Hub, UK GDPR, freeze przed Edinburgh Festival Fringe oraz dziennik incydentów, który da się pokazać przy audycie ICO. Sklep WooCommerce z checkoutem pod rynek brytyjski to osobna ścieżka: programista WooCommerce w Edynburgu. Budowa od zera albo przebudowa motywu idzie do programisty WordPress w Edynburgu. Filary niezależne od miasta: programista WordPress i programista WooCommerce.

#Co oznacza opieka WordPress przy serwisie festiwalowym, fintech albo turystycznym w Edynburgu

Opieka to nie „włącz auto-update i miej nadzieję”. Dla portalu rezerwacji noclegów oknie Fringe, strony agencji kreatywnej z Leith, witryny firmy technologicznej z CodeBase albo serwisu B2B obsługującego klientów Glasgow, Aberdeen i Dundee utrzymanie ma cztery twarde elementy: aktualizacje na kopii testowej, kopie zapasowe, które da się odtworzyć, WAF z sensownymi regułami oraz dziennik incydentów, który przeżyje pytanie audytora. Reszta - drobna zmiana w motywie, nowy formularz rezerwacji, poprawka Core Web Vitals na stronie z mapą wydarzeń - wisi na tym fundamencie. Bez niego kolejna wtyczka tylko powiększa powierzchnię ataku.

Serwis w Edynburgu często zbiera dane, których nie wolno traktować jak treści bloga. Formularz rezerwacji z danymi osobowymi gościa, aplikacja do programu festiwalowego z załącznikami, panel partnera B2B z listą umów, logowanie do strefy prasowej z materiałami pod embargo: każdy z tych ekranów po aktualizacji wtyczki potrafi się rozsypać ciszej niż strona główna. Dlatego regresja nie kończy się na „strona się ładuje”. Kończy się na ścieżce, którą redaktor wydarzeń, gość albo partner w Glasgow naprawdę klika.

#Aktualizacje wyłącznie przez środowisko testowe

Rdzeń WordPress, wtyczki i motyw idą najpierw na środowisko testowe. środowisko testowe ma ten sam stos PHP, ten sam obiekt cache jeśli produkcja go ma, te same wtyczki płatności albo formularzy w trybie sandbox. Aktualizacja „od razu na żywo, bo to tylko patch” jest najkrótszą drogą do martwego formularza rezerwacji w piątek przed szczytem Fringe albo do landingu wydarzenia, który serwuje treść z poprzedniego roku.

Po wgraniu łatek na kopii testowej idzie checklista, nie wyczucie. Logowanie wp-admin, zapis strony, formularz kontaktowy, formularz rezerwacji, koszyk i płatność jeśli jest WooCommerce, cron, poczta wychodząca, webhooki CRM, purge cache po publikacji karty wydarzenia. Dopiero po tym produkcja. Ścieżka wycofania jest zapisana zanim ktokolwiek naciśnie deploy: która kopia, który tag, kto ma dostęp do hostingu. Jeśli tego nie ma na piśmie, to nie ma rollbacku, tylko improwizacja.

#Kopie operacyjne to nie archiwum compliance

Codzienna kopia WordPressa służy do odtworzenia serwisu po błędzie albo ataku. Archiwum compliance dotyczy czego innego: rejestrów przetwarzania, dowodów audytowych i możliwości wglądu organu nadzorczego. Kopia w panelu hostingu nie spełnia wymogów archiwum sama z siebie. Brakuje niezmienności, kompletności i dokumentacji procedury.

W praktyce utrzymania rozdzielamy trzy warstwy. Pierwsza: kopia operacyjna strony i bazy, z retencją zapisaną w runbooku, testem odtworzenia, nie tylko „backup job zielony”. Druga: logi zmian i incydentów, które pokazują kto, kiedy i co wgrał. Trzecia: archiwum compliance u klienta, zwykle w DMS albo u doradcy prawnego w Edynburgu albo w Londynie. Trzymając te trzy warstwy razem na FTP, po dwóch latach traci się możliwość powiedzenia, kiedy i dlaczego coś zostało zmienione.

#WAF, monitoring i dziennik pod audyt

WAF (mod_security, Cloudflare WAF albo reguły u hostera) odcina typowe skany i wstrzyknięcia, zanim dotrą do PHP. To nie zastępuje aktualizacji. To kupuje czas. Skan malware i kontrola integralności plików łapie to, co WAF przepuścił albo co weszło skradzionym hasłem. Dwuskładnikowe logowanie do wp-admin i ograniczenie liczby kont z uprawnieniem administratora są tańsze niż forensics po kradzieży sesji.

Dziennik incydentów jest równie ważny jak sama tama. Zapis: czas wykrycia, czas ograniczenia, czas przywrócenia, przyczyna, lista zmienionych plików i wtyczek, kto był powiadomiony. Dla właściciela portalu turystycznego w Old Town, agencji kreatywnej z Leith albo firmy fintech z Quartermile ten plik jest surowcem do zgłoszenia. Agencja WordPress nie składa raportu do ICO za klienta. Dostarcza oś czasu, której klient nie musi rekonstruować z pamięci.

#Edynburg jako kontekst Szkocji, nie jako ozdobnik w tytule

Edynburg nie jest Londynem. Stolica Szkocji ma inny profil klientów, inne szczyty ruchu i inny ekosystem vendorów. Edynburg jest centrum fintech, turystyki kulturalnej i technologii w Szkocji. Inicjatywa Fintech Scotland wiąże miasto z Glasgow, Aberdeen i Dundee w jedną narrację rozwoju sektora finansowego. To nie jest slogan na slajdzie. To realny kontekst briefu: firma w Edynburgu często obsługuje klientów całej Szkocji, a serwis musi działać po aktualizacji wtyczki, nie tylko w dniu audytu SEO.

#CodeBase i Edinburgh Digital Hub

CodeBase w Edynburgu to najbardziej rozpoznawalny hub technologiczny miasta. Setki startupów, scaleupów i agencji kreatywnych pracują w hubie, gdzie premiera produktu albo ogłoszenie rundy finansowania generuje skok ruchu w godzinach, nie w tygodniach. WordPress w tym środowisku to często portal produktu, strona agencji kreatywnej albo witryna firmy technologicznej obsługującej sektor finansowy. Motyw, który nie wytrzyma ogłoszenia w poniedziałek rano, produkuje incydent operacyjny, nie „drobny ticket po weekendzie”.

Dla utrzymania wynika z tego prosta rzecz: aktualizacja wtyczki cache, integracji z HubSpot albo WPML musi przejść checklistę, która obejmuje landing produktowy, formularz aplikacyjny i kartę wydarzenia z datą publikacji. środowisko testowe z tym samym stosem PHP i tymi samymi wtyczkami w sandbox to minimum, nie luksus. CTO z CodeBase nie akceptuje argumentu „strona główna działa”, kiedy formularz aplikacyjny zwraca 500 po aktualizacji wtyczki sesji.

#Edinburgh Festival Fringe i freeze wdrożeń przed szczytem festiwalowym

Edinburgh Festival Fringe to największy festiwal sztuk performatywnych na świecie. W sierpniu ruch na stronach rezerwacji, portali noclegowych i witrynach wydarzeń rośnie wielokrotnie. W oknie festiwalowym każda zmiana na produkcji jest ryzykiem. Dlatego w runbooku zapisujemy freeze wdrożeń: w tygodniu przed szczytem Fringe nie idą aktualizacje wtyczek, nie idą nowe bloki, nie idą zmiany w motywie. środowisko testowe dostaje zmiany, produkcja czeka do września po zamknięciu okna.

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ł piątek wieczorem przed szczytem ruchu i nie wymaga post-mortem w poniedziałek rano. Kto robi „drobny patch cache” w piątek przed otwarciem Fringe, uczy się tego na własnej skórze, kiedy serwis nie wytrzymuje skoku ruchu z telefonów turystów.

#Fintech Scotland i sektor finansowy w Quartermile

Quartermile i okolice George Street koncentrują biura firm finansowych, w tym dziedzictwo Royal Bank of Scotland i Standard Life Aberdeen. Fintech Scotland promuje ekosystem startupów finansowych w całej Szkocji. WordPress w tym środowisku to często portal onboardingu klienta, dokumentacja produktu albo witryna B2B z formularzami zbierającymi dane regulowane. Awaria formularza KYC albo wyciek logów z wp-admin to nie problem marketingu. To problem compliance i często temat dla audytora wewnętrznego.

Opieka, która testuje tylko stronę główną, tego nie widzi. Opieka, która ma runbook z listą endpointów i webhooków, widzi. Firma fintech z Edynburga nie wymaga DC w samym Quartermile. Wymaga, żeby origin i kopia miały sensowną jurysdykcję i żeby wycofanie zmian był zapisany przed wdrożeniem.

#EICC i kalendarz konferencyjny

Edinburgh International Conference Centre (EICC) przyciąga konferencje technologiczne, medyczne i korporacyjne przez cały rok. Strony wydarzeń konferencyjnych na WordPressie muszą przeżyć publikację programu, otwarcie rejestracji i skok ruchu w dniu eventu. Aktualizacja wtyczki formularza w tygodniu przed konferencją to incydent operacyjny, nie „drobny patch”. Runbook freeze obejmuje też kalendarz EICC, nie tylko Fringe.

#Operacje specyficzne dla UK

Polski zespół zna WordPressa. Brytyjski klient pyta o coś innego: UK GDPR, cookie consent, Public Sector Bodies Accessibility Regulations, kto jest administratorem danych, czy mamy Data Processing Agreement. Te pytania trzeba umieć obsłużyć procesem, nie sloganem o „zgodności z RODO”.

#UK GDPR i Data Protection Act 2018

Po Brexicie Wielka Brytania zachowała własną wersję RODO, powszechnie nazywaną UK GDPR, oraz Data Protection Act 2018. Organ nadzorczy to Information Commissioner’s Office (ICO). Dla WordPressa w Edynburgu wynika z tego konkretny zakres utrzymania: lista podprocesorów (host, CDN, poczta, analityka), umowa powierzenia tam, gdzie agencja przetwarza dane, procedura naruszenia w 72 godziny, minimalizacja danych w formularzach, polityka prywatności zgodna z art. 13 UK GDPR.

Utrzymanie nie zastępuje DPO klienta. Dostarcza logi, oś czasu i opis zmian po incydencie. Klient klasyfikuje, czy zdarzenie wymaga zgłoszenia do ICO. Nikt po stronie agencji nie podpisuje się pod „jesteście zgodni z UK GDPR, bo macie WAF”. Przy incydencie z danymi osobowymi art. 33 UK GDPR daje administratorowi 72 godziny na zgłoszenie do ICO, o ile naruszenie może wiązać się z ryzykiem dla praw osób. Dlatego dziennik z opieki musi mieć datę pierwszej wiedzy, nie datę „kiedy developer wrócił z urlopu”.

Co wpisujemy w runbook utrzymania:

• Formularze zbierające dane osobowe (rezerwacje, aplikacje, newslettery, zapytania B2B) dostają jawną podstawę prawną, checkbox zgody tam, gdzie consent jest wymagany, i minimalizację pól.
• Wtyczki consent (CookieYes, Complianz, podobne) konfigurujemy tak, żeby skrypty marketingowe nie ładowały się przed akceptacją. Kwartalny przegląd bannera i tagów na kluczowych szablonach jest częścią opieki, nie dodatkiem SEO.
• Polityka prywatności i cookie policy są szablonami z polami, nie blokami, które redaktor może usunąć z drzewa.
• Integracje z CRM (HubSpot, Salesforce, Pipedrive) dostają dokumentację przepływu danych: co trafia do systemu zewnętrznego, jak długo, kto jest administratorem.

#Dostępność: Public Sector Bodies Regulations i sektor prywatny

Dostępność w Edynburgu nie jest jednym przepisem. Publiczne instytucje (uniwersytety, NHS Scotland, Scottish Government) podlegają Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, które wymagają WCAG 2.1 AA (z perspektywą przejścia na WCAG 2.2). Sektor prywatny nie ma identycznego obowiązku prawnego, ale Equality Act 2010 tworzy kontekst, w którym niedostępna strona usługowa to ryzyko prawne i wizerunkowe.

Opieka nie zastępuje audytora dostępności. Pilnuje, żeby aktualizacja motywu albo wtyczki nie psuła etykiet formularzy, kontrastu, focusu klawiatury i hierarchii nagłówków. Skan axe-core w cyklu kwartalnym plus ręczna ścieżka klawiatury na formularzu rezerwacji i nawigacji głównej to minimum, nie certyfikat na stronie. Dla organizatorów festiwali i portali turystycznych dostępność ma też wymiar produktowy: materiał wideo z napisami, transkrypcje podcastów, playery, które da się obsłużyć klawiaturą.

#Checkout WooCommerce, którego nie wolno łatać w ciemno

Sklep w Edynburgu zbiera GBP przez Stripe albo PayPal, czasem fakturę B2B z polem VAT registration number. Webhooki bramki i status zamówienia muszą przeżyć aktualizację WooCommerce. Aktualizacja wtyczki płatności, która na produkcji nadpisuje mapowanie callbacków, zostawia magazyn z ręcznym klejeniem statusów zamówień. Dlatego te wtyczki nigdy nie idą w tym samym oknie co „drobna aktualizacja SEO”.

Przykład z audytu: zamówienie opłacone przez PayPal, a w panelu WooCommerce wciąż „oczekujące na płatność”, bo callback nie dotarł po patchu wtyczki. To nie jest błąd UX. To incydent operacyjny, który w tygodniu Fringe kosztuje więcej niż w zwykłym miesiącu. Szczegóły checkoutu, Royal Mail, DPD i HPOS opisuje programista WooCommerce w Edynburgu. Opieka pilnuje, żeby aktualizacja nie psuła webhooków i rezerwacji stanu.

#Reakcja na incydent bez pustych procentów

Obietnica dostępności zapisana procentem na stronie city to ozdobnik, nie kontrakt. Dostępność wynika z hostingu, DNS, CDN, wtyczek i ludzi. Opieka opisuje procedurę, nie talizman.

Wykrycie: monitoring syntetyczny plus alert z WAF albo z hosta. Triage: czy to treść, czy płatność PayPal, czy wp-admin, czy cała produkcja, czy wyciek materiału przed premierą. Ograniczenie: tryb konserwacji, cofnięcie wtyczki, wyłączenie endpointu, rotacja haseł, twardy WAF, purge cache. Odtworzenie z kopii, jeśli pliki są spalone. Dokumentacja osi czasu. Post-mortem z przyczyną i z działaniem, które ma nie powtórzyć się za miesiąc.

Czas pierwszej odpowiedzi zapisujemy w umowie. W dniach roboczych priorytet zwykle zamyka się w oknie godzin, nie dni. Dyżur poza tym oknem jest wtedy, gdy umowa go obejmuje. Przy freeze przed Fringe okno bywa szersze niż w zwykłym miesiącu, bo koszt martwego landingu w piątek wieczorem jest wyższy niż koszt dyżuru. Ta strona nie sprzedaje uniwersalnego SLA w tabelce. Sprzedaje porządek: widać, kto wszedł, co zmienił, kiedy serwis wrócił.

Jeśli klient musi złożyć zgłoszenie do ICO albo do wewnętrznego audytu, dziennik z opieki jest załącznikiem. Brak dziennika oznacza, że compliance składa raport ze zrzutów ekranu i ze wspomnień z WhatsAppa.

#Przypadek: aktualizacja cache położyłaby landing rezerwacji przed szczytem Fringe, środowisko testowe to zatrzymał

Serwis portalu noclegowego w Edynburgu na WordPressie, landing kampanii pod Edinburgh Festival Fringe, formularz rezerwacji z danymi osobowymi gościa, treść zaplanowana na piątek 18:00, trzy dni przed otwarciem festiwalu. W kolejce do produkcji leżała aktualizacja wtyczki cache obiektowego plus patch SEO, „drobny, na żywo, bo to tylko object cache”.

Na środowisku testowym, sklonowanym z produkcji razem z Redisem i z kartami wydarzeń w stanie „szkic”, publikacja o 18:00 serwowała opis festiwalu z poprzedniego roku. Przyczyna: zmiana klucza cache po patchu, stary fragment w motywie wołał get_post bez sprawdzenia statusu future, CDN trzymał HTML bez Cache-Control dla zalogowanego redaktora. Na produkcji ten sam zestaw poszedłby w czwartek wieczorem. Landing wyszedłby przed terminem, formularz zbierałby dane bez zaktualizowanej polityki prywatności, a piątkowy ruch z newslettera do turystów trafiłby w 404 po panicznym cofnięciu wpisu.

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

Ten sam kształt wraca przy wtyczkach płatności Stripe, przy formularzu rezerwacji, który po aktualizacji gubi dane gościa, i przy „drobnej” aktualizacji SEO, która nadpisuje robots i wycina strefę prasową z indeksu. Edynburg nie wybacza tego ciszej niż inny rynek. Wygląda to gorzej, bo obok siedzi ktoś, kto pyta o UK GDPR, o piątek wieczorem przed Fringe albo o slot w kalendarzu konferencji w EICC.

#WordPress Edinburgh Meetup i praktyka, której nie widać w panelu hostingu

WordPress Edinburgh Meetup spotyka się regularnie w ekosystemie szkockim (grupa na Meetup.com i lokalne spotkania w okolicach CodeBase oraz w coworkingach w Leith). 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. Opieka, która nigdy nie wychodzi poza ticket, gubi ten kontekst: w Edynburgu część zespołów i tak siedzi po stronie fintech albo turystyki kulturalnej i usłyszy te same pytania na wydarzeniach w CodeBase albo przy Scottish Enterprise.

WP-CLI w utrzymaniu nie jest ozdobą meetupową. To sposób, żeby aktualizację, 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 w społeczności argument „zrobimy to ręcznie w panelu” brzmi jeszcze gorzej.

#Miesięczny rytm, onboarding i przejęcie bałaganu

Onboarding to audyt, nie kick-off z prezentacją. Inwentaryzacja wtyczek, wersja PHP, cron, poczta, SSL, WAF, czy kopia w ogóle się odtwarza, gdzie stoi serwer, kto ma dostęp SFTP i do wp-admin, czy są konta-widma po agencji, która zniknęła. Baseline Lighthouse na stronie głównej i na najważniejszym formularzu rezerwacji, checkoucie albo landingu festiwalowym. Lista ryzyk z priorytetem: najpierw to, co psuje odtworzenie i bezpieczeństwo, potem to, co psuje konwersję albo publikację.

Pierwszy cykl aktualizacji na stagingu jest częścią onboardingu, nie „bonusem w miesiącu drugim”. Jeśli stagingu nie ma, jego postawienie jest pracą startową. Serwis portalu turystycznego albo firmy fintech w Edynburgu bez kopii testowej nie wchodzi w stały abonament z otwartymi auto-update.

Miesiąc stały: okno aktualizacji poza freeze przed Fringe, skan, przegląd logów WAF, test odtworzenia kopii w uzgodnionym cyklu, krótki raport. Raport ma metryki (uptime z monitoringu, błędy 5xx, czas odpowiedzi, lista wgranych wersji), decyzje (wtyczka X zostaje, wtyczka Y do wymiany) i residualne ryzyko (brak 2FA u redakcji, brak umowy powierzenia, cache bez reguły dla future, freeze przed Fringe jeszcze nie wpisany). Bez residualnego ryzyka raport jest broszurą.

Przejęcie zaniedbanej instalacji zaczyna się od tej samej listy, tylko dłuższej. Stary PHP, wtyczka page buildera bez łatek, kopia tylko na tym samym dysku co produkcja, hasło admin we wpisie w Notion, checkout z trzema wtyczkami podatkowymi naraz, Redis, który trzyma szkice landingów przed Fringe. Pierwszy miesiąc to remediacja. Stała opieka zaczyna się, gdy da się bezpiecznie wgrać łatki.

Budowa od zera albo przebudowa motywu to już inna usługa: programista WordPress w Edynburgu. Sklep, checkout, Stripe, PayPal i VAT: programista WooCommerce w Edynburgu. Opieka nie udaje, że jest projektem wdrożeniowym. Gdy w utrzymaniu wychodzi, że motyw trzeba napisać od nowa, to idzie jako osobne zlecenie, na piśmie.

#Wydajność przy skoku ruchu w oknie festiwalowym

Origin w UK nie naprawi ciężkiego motywu z embedami wideo i galeriami materiałów prasowych. HTTP/3, Brotli, AVIF, lazy load, który nie psuje LCP hero, cache, który nie trzyma prywatnego koszyka ani nieopublikowanego landingu przed Fringe, ograniczenie wtyczek z zapytań SQL na każdej podstronie: to nadal robota utrzymaniowa. Core Web Vitals mierzymy na realnych URL-ach z formularzami rezerwacji, nie na pustej instalacji. INP psuje się od skryptów czatu, od widgetu mapy i od tag managera, który marketing dodał poza ticketingiem. Opieka, która nie widzi GTM, będzie gonić „optymalizację obrazków” w nieskończoność.

Dla serwisu turystycznego w Edynburgu liczy się czas do pierwszego bajtu z sieci w Old Town, Leith albo z telefonu turysty w Glasgow, nie tylko z laptopa w CodeBase. Monitoring z jednego regionu USA kłamie. Punkt pomiaru w UK albo przynajmniej w Europie jest częścią kontraktu operatorskiego, nie dodatkiem. Strona z pełnoekranowymi materiałami wideo umiera na LCP od nieoszczędnych JPEG-ów szybciej niż od „słabego hostingu”. Przed Fringe idzie osobny przegląd cache, limitów PHP i CDN; po evencie idzie ścinka landingów, które mają zostać jako archiwum, i tych, które mają dostać 301.

#Bezpieczeństwo jako lista decyzji, nie jako plakietka

HTTPS z HSTS tam, gdzie infrastruktura to uniesie. Nagłówki ograniczające XSS. 2FA. Minimum kont administratorskich. Zakaz wtyczek „nulled”. Zakaz edytora plików wp-admin na produkcji. Rotacja haseł po odejściu freelancerów. Test odtworzenia kopii, bo kopia, której nikt nie odtwarzał, jest plikiem. Przy danych osobowych: umowa powierzenia, lista podprocesorów (host, CDN, poczta, analityka), procedura naruszenia pod UK GDPR.

To nie jest certyfikat ISO sprzedawany z abonamentem. To jest lista, którą da się odhaczyć przy onboardingowym audycie i wrócić do niej co kwartał. Klient z biura w Quartermile, z portalu turystycznego w Old Town albo ze sklepu B2B w aglomeracji i tak przyniesie własną checklistę. Lepiej mieć swoją wcześniej. Szerszy audyt bezpieczeństwa opisuje audyt bezpieczeństwa WordPress. Opieka w Edynburgu dodaje do niego kalendarz freeze przed Fringe, pytanie o ICO oraz jawny opis retencji logów.

#Kiedy ta strona, a kiedy programista WordPress albo WooCommerce

Ta strona zostaje przy utrzymaniu: aktualizacje, kopie, monitoring, WAF, dziennik, drobne poprawki w ramach umowy. Motyw od zera, Gutenberg, CPT, refaktoryzacja page buildera albo integracja CRM to programista WordPress w Edynburgu. Checkout w GBP, Royal Mail, DPD, HPOS i webhooki Stripe to programista WooCommerce w Edynburgu. CodeBase i Edinburgh Festival Fringe tłumaczą, skąd biorą się serwisy z formularzami rezerwacji i freeze przed szczytem festiwalowym. Nie tłumaczą, czemu webhook Stripe bez idempotencji zostawia zamówienie w pending po szczycie Fringe.

#Jak zaczynamy, bez zaliczek w procentach na stronie

Zakres, godziny reakcji i cena są indywidualne i lądują w umowie przed startem. Na tej stronie nie ma podziału płatności na transze procentowe i nie ma tabeli pakietów. Krótki opis serwisu, stacku, hostingu i tego, czy jest środowisko testowe, wystarczy, żeby zaproponować audyt onboardingu.

Kontakt: formularz. W zgłoszeniu przydaje się lokalizacja hostingu, lista wtyczek albo dostęp do stagingu, informacja czy serwis ma formularze pod UK GDPR, czy jest WooCommerce z Stripe albo PayPal, oraz które daty Edinburgh Festival Fringe albo konferencji w EICC blokują wydanie. Z tego powstaje plan: co naprawiamy zanim w ogóle wejdziemy w miesięczny rytm, a co zostaje w kadencji.

Opieka w Edynburgu ma sens, gdy serwis już niesie biznes i trzeba go nie zepsuć. Gdy trzeba go dopiero zbudować, wracamy do developmentu. Gdy trzeba go utrzymać przy formularzach rezerwacji, checkoutcie w GBP i UK GDPR pod ICO, zostajemy przy tym, co ta strona opisuje: środowisko testowe, kopia, WAF, dziennik, compliance po stronie klienta i runbook, który da się pokazać audytorowi bez rekonstruowania historii z pamięci.