Czy Twoja strona na WordPressie ma realną opiekę? 6 pytań przed końcem PHP 8.2
Opieka nad stroną WordPress w 2027 roku to przede wszystkim trzy rzeczy: szybkie aktualizacje, bo luki we wtyczkach są atakowane w ciągu godzin od ujawnienia, przejście z PHP 8.2, które 31 grudnia 2026 r. traci wsparcie, oraz kopie zapasowe i monitoring, dzięki którym strona szybko wraca do działania po awarii. Strona bez opieki zwykle nadal działa, ale z każdym miesiącem jest łatwiejszym celem. Zacznij od sześciu pytań.
Sześć pytań o Twoją stronę
- Czy w panelu WordPressa jest mniej niż kilka oczekujących aktualizacji wtyczek?
- Czy wiesz, na jakiej wersji PHP działa strona?
- Czy wiesz, gdzie są kopie zapasowe i kiedy ostatnio ktoś sprawdził, że da się z nich odtworzyć stronę?
- Czy każdego administratora na liście użytkowników umiesz przypisać do konkretnej osoby?
- Czy o awarii dowiadujesz się wcześniej niż od klientów?
- Czy jest ktoś, kto dziś odpowiada za stronę, jeśli jej twórca już jej nie prowadzi?
Sześć razy „tak”: strona ma opiekę, sprawdź tylko, czy obejmuje punkty z tabeli niżej. Jedno lub dwa „nie”: uzupełnij braki, zaczynając od PHP i kopii. Trzy „nie” lub więcej: zacznij od przeglądu technicznego, który opisujemy we wpisie o audycie strony internetowej, bo strona najpewniej wymaga najpierw uporządkowania, a dopiero potem stałej opieki.
Dlaczego aktualizacja nie może czekać
Według raportu Patchstack „State of WordPress Security in 2026”:
- w 2025 r. wykryto 11 334 nowe podatności w ekosystemie WordPressa, o 42% więcej niż rok wcześniej,
- 91% dotyczyło wtyczek, 9% motywów, a w samym rdzeniu było ich tylko 6,
- 46% luk nie miało poprawki od autora w chwili ujawnienia,
- przy lukach atakowanych masowo mediana czasu od ujawnienia do ataków wynosiła około 5 godzin,
- standardowe zabezpieczenia firm hostingowych zablokowały tylko 26% ataków.
Słabym punktem prawie nigdy nie jest sam WordPress, tylko wtyczki i motywy, a czas na reakcję liczy się w godzinach. Rdzeń też czasem wymaga pilnej reakcji: WordPress 7.1.2 z 22 września 2026 r. łatał krytyczną lukę, przez którą niezalogowany atakujący mógł w pewnych warunkach wykonać kod na serwerze. Szczegóły tego wydania opisujemy we wpisie o lukach w rdzeniu WordPressa.
Koniec wsparcia PHP 8.2
PHP to język, w którym działa WordPress, i osobny element serwera. Po końcu wsparcia wersja nie dostaje poprawek bezpieczeństwa, nawet gdy ktoś znajdzie w niej poważną lukę.
| Wersja PHP | Poprawki bezpieczeństwa do | Co zrobić |
|---|---|---|
| 8.1 i starsze | wsparcie już się skończyło | Zaktualizować jak najszybciej |
| 8.2 | 31.12.2026 | Zaplanować przejście jeszcze w tym roku |
| 8.3 | 31.12.2027 | Bezpieczne w 2027 r., ale to krótki horyzont |
| 8.4 | 31.12.2028 | Dobry wybór przy aktualizacji teraz |
| 8.5 | 31.12.2029 | Najdłuższe wsparcie, wymaga sprawdzenia wtyczek |
Daty pochodzą z oficjalnej tabeli na php.net. WordPress od wersji 7.0 wymaga co najmniej PHP 7.4, a zaleca 8.3 lub nowsze. Według zespołu WordPressa wersje 6.9 i 7.0 w pełni obsługują PHP 8.5. Problemem bywają nie rdzeń, tylko starsze wtyczki, motywy pisane na zamówienie i własne fragmenty kodu, które na nowszym PHP zgłaszają błędy.
Wersję sprawdzisz w panelu: Narzędzia, Zdrowie witryny, zakładka Informacje, sekcja Serwer. Samo przejście robi się tak: pełna kopia plików i bazy, kopia strony z docelową wersją PHP, przejście formularzy, koszyka, logowania, importów i integracji, wymiana wtyczek, które zgłaszają błędy, i dopiero wtedy przełączenie na produkcji w spokojnym momencie, z obserwacją logów przez kilka dni. Nie w piątek po południu.
Co powinno być w abonamencie opieki
| Element opieki | Jak często | Po co |
|---|---|---|
| Aktualizacje wtyczek, motywu i WordPressa | Poprawki bezpieczeństwa od razu, reszta według harmonogramu | Zamyka znane luki, zanim zostaną wykorzystane |
| Testy po aktualizacji | Po każdej większej aktualizacji | Formularze, koszyk i integracje działają, zanim zauważą to klienci |
| Kopie zapasowe | Codziennie, w sklepie częściej | Odtworzenie po awarii lub włamaniu |
| Test odtworzenia kopii | Kilka razy w roku | Potwierdza, że kopia naprawdę działa |
| Monitoring dostępności | Stale, z alertami | Wiesz o awarii, zanim zadzwoni klient |
| Ochrona przed atakami (WAF, wirtualne łatki) | Stale | Blokuje ataki na luki bez poprawki |
| Wersja PHP i serwer | Przegląd co najmniej raz w roku | Wspierane wersje oprogramowania |
| Przegląd kont i wtyczek | Co kwartał | Mniej zbędnych administratorów i dodatków |
| Reakcja na incydent | Czas określony w umowie | Wiadomo, kto działa i w jakim czasie |
| Raport | Co miesiąc lub co kwartał | Widzisz, co zrobiono i co wymaga decyzji |
Najczęściej pomijane są dwie pozycje: test odtworzenia kopii, bo kopia, której nikt nie odtwarzał, daje niewielką pewność, i ochrona przed atakami na luki bez poprawki, bo skoro prawie połowa podatności nie ma łatki w chwili ujawnienia, sama aktualizacja nie wystarczy.
Automatyczne aktualizacje: tak, ale nie wszędzie
WordPress sam instaluje drobne wydania z poprawkami bezpieczeństwa, od wersji 5.5 pozwala włączyć automatyczne aktualizacje wtyczek, a od 6.6 wycofuje aktualizację wtyczki, która powoduje błąd krytyczny. W praktyce sprawdza się podział: automatycznie drobne wydania rdzenia i proste wtyczki, ręcznie po teście na kopii duże wydania WordPressa, WooCommerce, page buildery, płatności i integracje. Automat nie sprawdzi, czy po aktualizacji działa BLIK albo import z hurtowni. O przejściu na nową wersję główną piszemy we wpisie czy aktualizować do WordPressa 7.
Jak robimy to na tej stronie
Strona it360.pl działa na WordPressie 7.1.2 i PHP 8.3, czyli na wersji ze wsparciem do końca 2027 r. Każda zmiana, od aktualizacji po zmianę w motywie, przechodzi najpierw przez kopię lokalną i stronę testową, a przed zmianą na serwerze zapisujemy zrzut bazy. Zadania WordPressa, takie jak publikacja zaplanowanych wpisów czy odświeżanie pamięci podręcznej, uruchamia systemowy cron co 5 minut, a nie odwiedziny użytkowników. Dzięki temu nie zależą od ruchu na stronie.
Co wpisać do umowy o opiekę
Od kwietnia 2026 r. obowiązuje nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (NIS2) i firmy nią objęte zaczynają pytać swoich dostawców o te same rzeczy, co w tabeli wyżej. Dobrze opisana opieka to gotowa odpowiedź na ich ankietę (więcej we wpisie o NIS2 i dostawcach IT). W umowie warto mieć:
- zakres opieki z częstotliwością i osobą odpowiedzialną,
- czas instalacji poprawek, osobno dla luk krytycznych i pozostałych,
- czas i kanał powiadomienia o incydencie, także poza godzinami pracy,
- zasady dostępów: konta imienne, logowanie dwuskładnikowe, odbieranie dostępu,
- lokalizację danych, hosting i zgodę na zmianę podwykonawcy,
- prawo do ankiety bezpieczeństwa raz w roku i po incydencie,
- przekazanie kodu, repozytorium, dokumentacji i kopii przy końcu współpracy.
Od czego zależy koszt opieki
Abonament za prostą stronę firmową i za sklep z integracjami to dwie różne usługi, nawet jeśli obie nazywają się „opieką WordPress”. Cenę zmieniają przede wszystkim: liczba i rodzaj wtyczek, integracje (płatności, kurierzy, hurtownie, ERP, KSeF), własny kod, wymagany czas reakcji, to, czy wykonawca utrzymuje też serwer, oraz stan wyjściowy, bo strona zaniedbana przez lata najpierw wymaga jednorazowego uporządkowania. Porównując oferty, pytaj, co dokładnie wchodzi w abonament, ile godzin prac rozwojowych zawiera i jak rozliczane są prace poza nim.
Jak możemy pomóc
Po wdrożeniu zajmujemy się aktualizacjami, kopiami zapasowymi, monitoringiem i rozwojem stron, sklepów i aplikacji, jak w serwisie Bezet, którym opiekujemy się po uruchomieniu. Przejmujemy też strony zbudowane przez innych wykonawców: zaczynamy od przeglądu kodu, wtyczek i serwera, a potem proponujemy zakres opieki. Zasady współpracy opisujemy w FAQ.
Jeśli Twoja strona działa na PHP 8.2 lub starszym albo odpowiedziałeś „nie” na któreś z sześciu pytań, napisz do nas przed końcem roku. Sprawdzimy stan techniczny i zaplanujemy przejście tak, żeby nie przerwać sprzedaży.
