Jak zdegradować WordPress? (Wtyczka, FTP, WP-CLI)

W środowisku produkcyjnym nie ma czasu na chaotyczne zgadywanie i edycję plików na żywo. Potrzebna jest sprawdzona, powtarzalna procedura wycofania zmian (rollback / downgrade), która przywróci stabilność serwisu w kilka minut. W tym technicznym przewodniku przedstawiamy kompletny proces postępowania: od natychmiastowej izolacji awarii i diagnostyki logów, przez operacje za pomocą terminala WP-CLI oraz wtyczki WP Rollback, aż po bezpieczną, ręczną podmianę plików rdzenia i zarządzanie schematem bazy danych.

#Co zrobić przed cofnięciem wersji WordPressa

Najgorszym błędem podczas awarii po aktualizacji jest wykonywanie nieskoordynowanych działań, które mogą nadpisać bazę danych lub skasować pliki mediów. Zanim zmienisz choćby jedną linijkę kodu, wykonaj dwa kluczowe kroki:

#1. Włączenie trybu konserwacji (Maintenance Mode)

Jeśli strona rzuca błędy PHP 500, roboty wyszukiwarki Google próbujące zaindeksować witrynę mogą napotkać pętle błędów. Aby temu zapobiec, serwer powinien zwracać nagłówek HTTP 503 Service Unavailable z parametrem Retry-After.

W terminalu WP-CLI wykonasz to natychmiast:

wp maintenance-mode activate

Jeśli nie masz dostępu do WP-CLI, utwórz w głównym katalogu instalacji plik .maintenance zawierający kod PHP:

<?php $upgrading = time(); ?>

#2. Zrzut bazy danych przed cofnięciem wersji

Nawet jeśli serwis częściowo nie działa, stan bazy danych musi zostać natychmiast zabezpieczony. Jeżeli późniejsza degradacja nie powiedzie się, ten plik pozwoli wrócić do punktu wyjścia:

wp db export backup-awaryjny-przed-downgrade.sql

#3. Zapis bieżących wersji

Rollback zaciera ślady. Zanim podmienisz pierwszy plik, zapisz, co dokładnie działa teraz na stronie. Dzięki temu po wydaniu poprawki wrócisz do przodu bez zgadywania, a jeśli rollback nie pomoże, porównasz dwa stany:

wp core version --extra
wp plugin list --fields=name,status,version,update_version --format=csv > wtyczki-przed.csv
wp theme list --fields=name,status,version --format=csv > motywy-przed.csv

wp core version --extra pokazuje wersję rdzenia razem z rewizją bazy danych, której oczekuje działający kod. Porównaj ją z wp option get db_version, czyli rewizją faktycznie zapisaną w bazie. Jeśli zapisana liczba jest wyższa od tej, której oczekuje docelowe wydanie, baza została już zmigrowana do przodu i sama podmiana plików do niej nie pasuje. Dwa pliki CSV dają dokładne numery wersji na drogę powrotną, zamiast odtwarzania ich z pamięci o północy.

#4. Nagłówki Requires at least i Requires PHP we wtyczkach

Dwa nagłówki decydują, czy downgrade rdzenia jest w ogóle możliwy. Wtyczka może zadeklarować w głównym pliku Requires at least i Requires PHP. Tam, gdzie te nagłówki są, WordPress blokuje aktywację, gdy wersja rdzenia albo PHP ich nie spełnia. Jeśli wtyczka wymaga WordPressa 6.6, a cofniesz rdzeń do 6.4, po downgrade nie aktywujesz jej ponownie, a jej kod może wywoływać funkcje, których starsze wydanie nie ma. Przeczytaj nagłówki, zanim wybierzesz wersję docelową:

grep -RE "Requires (at least|PHP)" wp-content/plugins/*/*.php

#Jak zdiagnozować uszkodzenie po aktualizacji WordPressa

Downgrade całego WordPressa, gdy winna jest pojedyncza wtyczka do formularzy kontaktowych, to niepotrzebne ryzyko operacyjne. Diagnostykę należy zacząć od analizy logów błędów.

#Jak włączyć debug.log w wp-config.php

Otwórz plik wp-config.php i upewnij się, że błędy są zapisywane do pliku dziennika zamiast być wyświetlane użytkownikom:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', '0' );

Otwórz plik wp-content/debug.log i przeanalizuj ostatnie wpisy. Ścieżka pliku w komunikacie błędu natychmiast wskaże źródło awarii:

• Błąd w wp-content/plugins/nazwa-wtyczki/... oznacza, że problem tkwi wyłącznie we wtyczce.
• Błąd w wp-content/themes/nazwa-motywu/... wskazuje na niekompatybilność motywu (często z nowszą wersją biblioteki w rdzeniu).
• Błąd w wp-includes/... lub wp-admin/... świadczy o uszkodzeniu plików rdzenia lub braku kompatybilności zainstalowanej wtyczki z nową wersją silnika.

#Jak wyłączyć wtyczki przez WP-CLI lub SFTP

Jeśli błąd uniemożliwia wejście do kokpitu WordPressa:

# Wyłączenie wszystkich wtyczek naraz
wp plugin deactivate --all

# Sprawdzenie czy strona wstaje
wp core is-installed

# Włączanie wtyczek pojedynczo, aby zlokalizować winowajcę
wp plugin activate woocommerce

W przypadku braku SSH, zmień tymczasowo nazwę folderu wp-content/plugins na wp-content/plugins_off przez klienta SFTP, co automatycznie odłączy wszystkie rozszerzenia.

#Jak obniżyć wersję WordPressa przez WP-CLI

WP-CLI to najszybsze, najbardziej precyzyjne i najbezpieczniejsze narzędzie dla administratorów serwerów i deweloperów. Pozwala na pobranie oficjalnego pakietu z serwerów WordPress.org bez ryzyka przypadkowego usunięcia katalogu z mediami.

#1. Cofanie wersji WordPress Core

Aby cofnąć rdzeń WordPressa do starszego wydania (np. z 7.1 do 7.0.7), stosujemy polecenie wp core update z flagą wymuszenia instalacji:

# Sprawdzenie aktualnej wersji i rewizji bazy danych
wp core version --extra

# Wymuszenie instalacji docelowej stabilnej wersji
wp core update --version=7.0.7 --force

Flaga --force jest obowiązkowa. Dokumentacja WP-CLI opisuje ją wprost: aktualizuj nawet wtedy, gdy zainstalowana wersja jest wyższa od żądanej.

Po podmianie plików porównaj wersje bazy danych bez wprowadzania zmian:

wp core update-db --dry-run
wp option get db_version

Jeśli zapisana wartość db_version jest wyższa od tej, którą wp core version --extra podaje dla cofniętego kodu, aktualizacja zdążyła już zmigrować schemat. Wtedy pomoże tylko zrzut bazy sprzed aktualizacji (opisany niżej).

#2. Cofanie wersji pojedynczej wtyczki

Jeżeli diagnostyka wykazała, że awarię wywołała najnowsza wersja wtyczki (np. WooCommerce lub Advanced Custom Fields), nie cofaj rdzenia systemu. Wycofaj wyłącznie problematyczną wtyczkę:

# Sprawdzenie dostępnych informacji o wtyczce
wp plugin get woocommerce

# Instalacja konkretnej poprzedniej wersji z nadpisaniem obecnej
wp plugin install woocommerce --version=9.2.3 --force

WP-CLI pobierze archiwum z oficjalnego repozytorium WordPress.org i podmieni pliki w katalogu wp-content/plugins/woocommerce. Flaga --force należy tu do wp plugin install: według dokumentacji nadpisuje każdą zainstalowaną wersję bez pytania o potwierdzenie. wp plugin update takiej flagi nie ma, choć też przyjmuje --version. Motywy cofasz tak samo: wp theme install twentytwentyfour --version=1.0 --force.

#Na którą wersję WordPressa zrobić rollback

Nie każde starsze wydanie jest bezpiecznym celem. WordPress.org publikuje status bezpieczeństwa każdej wersji rdzenia w API stable-check. Z tej samej listy korzysta wtyczka Core Rollback, która według swojego opisu proponuje tylko najnowsze wydanie oraz starsze, ale bezpieczne. 14 października 2026 API oznacza 7.1.3 jako latest, ostatnie wydanie poprawkowe każdej starszej gałęzi (7.0.7, 6.9.10, 6.8.11 itd.) jako outdated, a wszystkie wcześniejsze wydania poprawkowe tych gałęzi jako insecure. Wersja 6.6.2, którą ten przewodnik podawał jako przykład do tej aktualizacji, jest na liście niebezpiecznych.

Zasada brzmi więc: cofaj się do ostatniego wydania poprawkowego gałęzi, która działała, a nie do dokładnego numeru, który był zainstalowany wcześniej. Jeśli stronę zepsuło 7.1.x, celem jest 7.0.7, a nie 7.0.2. Status sprawdzisz przed uruchomieniem polecenia:

curl -s https://api.wordpress.org/core/stable-check/1.0/ | grep '"7.0.7"'

Drugi test dotyczy PHP. Tabela zgodności zespołu rdzenia podaje, z którymi wersjami PHP testowano każde wydanie. Rollback potrafi wypchnąć stronę poza tę tabelę:

Jeśli hosting przeszedł już na PHP 8.5, rollback do 6.8 ląduje na kombinacji, której zespół rdzenia nigdy nie wymienił jako wspieranej. Granica działa też w drugą stronę: WordPress 7.0 zakończył wsparcie dla PHP 7.2 i 7.3, więc na takim serwerze najnowsze wydanie, które uruchomisz, to 6.9. Wybierz cel, który przechodzi oba testy: bezpieczny według stable-check i wymieniony dla wersji PHP na Twoim serwerze. Wersję, którą faktycznie widzi WordPress, pokaże wp eval 'echo PHP_VERSION;'.

#Jak wycofać WordPressa w kokpicie z WP Rollback

Jeśli panel administracyjny /wp-admin pozostaje dostępny, a awaria dotyczy jedynie frontendu lub pobocznych funkcji, najwygodniejszym rozwiązaniem dla redaktorów i mniej technicznych administratorów jest wtyczka WP Rollback.

#WP Rollback krok po kroku

1. W menu Wtyczki otwórz Dodaj wtyczkę.
2. Zainstaluj i włącz bezpłatną wtyczkę WP Rollback, a potem przejdź do Zainstalowane wtyczki.
3. Pod nazwą każdej zainstalowanej wtyczki lub w szczegółach motywu pojawi się dedykowany odnośnik Rollback.
4. Po kliknięciu odnośnika wtyczka odpyta oficjalne API WordPress.org i wyświetli listę wszystkich historycznych wydań wraz z informacjami o datach publikacji i dziennikach zmian.
5. Zaznacz wersję, na której system działał poprawnie przed aktualizacją, i zatwierdź operację.
6. Wtyczka pobierze właściwy pakiet, rozpakuje go i zapyta o ponowną aktywację.

Ważna uwaga: Bezpłatna wersja WP Rollback według strony wtyczki obsługuje wtyczki oraz motywy z WordPress.org. Wtyczki premium obsługuje dopiero płatna wersja Pro. Do cofania samego rdzenia z poziomu kokpitu służy osobna wtyczka Core Rollback autorstwa Andy’ego Fragena, dostępna w menu Narzędzia.

#Jak ręcznie obniżyć wersję WordPressa przez SFTP lub SSH

Gdy witryna uległa całkowitemu zablokowaniu, a hosting nie udostępnia powłoki SSH, jedyną drogą ratunku pozostaje ręczna podmiana plików na serwerze za pomocą protokołu SFTP (np. przez FileZilla lub WinSCP).

Ta operacja wymaga żelaznej dyscypliny, aby nie uszkodzić danych użytkowników i konfiguracji.

#Krok 1: Pobranie czystego archiwum

Przejdź do oficjalnego archiwum wydań na stronie wordpress.org/download/releases/ i pobierz paczkę ZIP wybranej wersji archiwalnej.

Jeśli masz WP-CLI na własnym komputerze, przygotuje paczkę za Ciebie: wp core download --version=7.0.7 --skip-content --path=wp-7.0.7 pobiera to wydanie bez domyślnych motywów i wtyczek, zgodnie z dokumentacją. Z tego katalogu wgrywasz potem wp-admin, wp-includes i pliki z katalogu głównego, jak opisano niżej.

#Krok 2: Przygotowanie pakietu na komputerze lokalnym

Rozpakuj pobrane archiwum na dysku lokalnym i natychmiast usuń z niego dwa elementy:

1. Folder wp-content: Bezwzględnie usuń ten folder z rozpakowanej paczki. Jeśli wgrasz go na serwer, możesz przypadkowo nadpisać katalog uploads, szablony motywów i zainstalowane wtyczki.
2. Plik wp-config-sample.php: Usuń go, aby uniknąć pomyłkowego nadpisania Twojego produkcyjnego pliku konfiguracyjnego wp-config.php.

#Krok 3: Wgranie plików na serwer

Połącz się z serwerem przez klienta SFTP, przejdź do katalogu głównego witryny (np. public_html lub www) i prześlij przygotowane pliki:

• Folder wp-admin (zastąp istniejący)
• Folder wp-includes (zastąp istniejący)
• Pliki PHP w katalogu głównym (index.php, wp-login.php, wp-settings.php itd.)

Podczas przesyłania wybierz opcję “Zastąp nowsze pliki” (Overwrite). Po zakończeniu transferu zaloguj się do /wp-admin. Jeśli WordPress wyświetli komunikat Wymagana jest aktualizacja bazy danych, kliknij Zaktualizuj bazę danych WordPressa.

#Jak przywrócić WordPressa z kopii zapasowej hostingu

Zanim dotkniesz pierwszego pliku, sprawdź, czy hosting cofnie aktualizację za Ciebie. Na zarządzanym hostingu WordPressa to często najszybsza droga i nie wymaga wiersza poleceń.

Większość zarządzanych hostingów tworzy automatyczne dzienne punkty przywracania i udostępnia w panelu przywracanie jednym kliknięciem, zwykle w zakładce w rodzaju “Kopie zapasowe” albo “Przywracanie”. Wybierasz migawkę sprzed aktualizacji i potwierdzasz. Hosting odtwarza pliki i bazę danych razem do tego momentu. Ponieważ obie warstwy wracają synchronicznie, ta droga omija pułapkę niezgodnego schematu opisaną niżej.

Dwie rzeczy do sprawdzenia. Część hostingów przywraca pliki i bazę osobno, więc czytaj etykiety i wybieraj pełną migawkę, a nie same pliki. Przywrócenie nadpisuje też wszystko, co powstało po migawce: zamówienia, komentarze i wpisy z tego okresu przepadną. W sklepie, który właśnie sprzedaje, porównaj to z celowanym rollbackiem jednej wtyczki. Na stronie firmowej, na której przez noc nic się nie zmieniło, przywrócenie jednym kliknięciem jest zwykle najczystszą opcją.

#Jak sprawdzić, czy rollback WordPressa zadziałał

“Strona główna się ładuje” to nie jest weryfikacja. Rollback może zostawić w połowie skopiowane drzewo plików, nieaktualny cache kodu bajtowego albo zepsutą ścieżkę w panelu, podczas gdy strona główna nadal leci z cache.

Najpierw sprawdź wersję, która faktycznie jest zainstalowana, a nie tę, którą chciałeś zainstalować:

wp core version
wp plugin get woocommerce --field=version
wp core verify-checksums
wp plugin verify-checksums --all

verify-checksums porównuje każdy plik na dysku z sumami kontrolnymi, które WordPress.org publikuje dla tego konkretnego wydania. To najszybszy sposób na wyłapanie klasycznej awarii FTP: transferu, który pominął albo uciął kilka plików bez zgłoszenia błędu. Czysty wynik oznacza, że drzewo plików odpowiada zamierzonej wersji. Wariant dla wtyczek obejmuje tylko wtyczki z WordPress.org, więc wtyczki premium nadal wymagają ręcznego porównania plików.

Następnie wyczyść każdy cache, który może dalej serwować usunięty kod:

• Cache obiektów: wp cache flush (Redis albo Memcached trzymają zserializowane obiekty utworzone przez nowszy kod).
• Cache stron i CDN: wyczyść cały cache, a nie pojedynczy adres, bo błąd krytyczny mógł trafić do cache jako odpowiedź 500.
• PHP OPcache: ten, o którym większość zapomina. Na serwerach z opcache.validate_timestamps=0 skompilowany kod bajtowy nowszych plików zostaje w pamięci do przeładowania puli PHP-FPM. Na dysku leżą wtedy starsze pliki, a wykonuje się nadal nowszy kod. Przeładuj PHP w panelu hostingu albo uruchom skrypt wywołujący opcache_reset().

Potem przetestuj więcej niż stronę główną. Błędy krytyczne po aktualizacji siedzą zwykle w admin-ajax, w REST API albo w koszyku, a nie na zcache’owanej stronie głównej:

curl -o /dev/null -s -w "%{http_code}\n" https://twoja-domena.pl/
curl -o /dev/null -s -w "%{http_code}\n" https://twoja-domena.pl/wp-json/

Zaloguj się, otwórz ekran ustawień cofniętej wtyczki i wykonaj jedną operację zapisu: zapisz wpis, wyślij formularz kontaktowy, złóż testowe zamówienie. Operacje odczytu przechodzą na wielu zepsutych instalacjach.

Przed tym testem opróżnij wp-content/debug.log, a po nim przeczytaj go ponownie. Log, który zostaje pusty, to mocniejszy sygnał niż strona, która tylko wygląda poprawnie, bo wyklucza też ostrzeżenia i komunikaty o przestarzałych funkcjach, które w kolejnym wydaniu staną się błędami krytycznymi. Na koniec otwórz Narzędzia > Stan witryny: jego testy zgłaszają wersję rdzenia, której brakuje wydań bezpieczeństwa, oraz wersję PHP, której WordPress nie uważa już za wspieraną.

#Kiedy cofnięcie plików WordPressa nie wystarczy

Wielu deweloperów zakłada, że cofnięcie plików w katalogu witryny całkowicie rozwiązuje problem. W przypadku wydań poprawkowych w obrębie jednej gałęzi (np. z 7.0.7 do 7.0.6) zwykle jest to prawda. Jednak przy dużych wydaniach głównych (Major Releases) sytuacja staje się bardziej złożona.

#Co oznacza db_version przy cofaniu wersji

WordPress przechowuje numer wewnętrznej wersji schematu bazy danych w tabeli wp_options pod kluczem db_version:

wp option get db_version

Gdy dokonujesz aktualizacji do nowej gałęzi WordPressa, skrypt migracyjny może dodać nowe kolumny, przebudować indeksy lub zmienić format przechowywania metadanych. Starszy kod PHP po wykonaniu downgrade’u może nie poradzić sobie ze zmodyfikowaną strukturą zapytań SQL.

#Wtyczki z własnymi tabelami, np. WooCommerce

Problem ten jest szczególnie widoczny w złożonych wtyczkach e-commerce. Przykładowo, wprowadzenie struktury High-Performance Order Storage (HPOS) w WooCommerce przeniosło zamówienia z tradycyjnej tabeli wp_posts do dedykowanych tabel wp_wc_orders.

Jeśli zaktualizujesz WooCommerce, wykonana zostanie migracja danych do nowych tabel, a następnie cofniesz pliki wtyczki o kilka wydań wstecz, starszy kod zacznie odpytywać nieaktualne tabele. W takich sytuacjach jedynym w 100% bezpiecznym rozwiązaniem jest:

1. Przywrócenie plików do stanu sprzed aktualizacji.
2. Równoległe przywrócenie bazy danych ze zrzutu wykonanego tuż przed rozpoczęciem procesu aktualizacji:

   wp db import backup-przed-aktualizacja.sql

#Jak zablokować ponowną aktualizację cofniętej wtyczki

Nic w downgrade nie mówi WordPressowi, żeby na nim został. Automatyczne aktualizacje uruchamiają zdarzenia cron wp_version_check, wp_update_plugins, wp_update_themes i wp_maybe_auto_update, więc wtyczka cofnięta rano może tego samego dnia wrócić do wadliwego wydania. To zwykłe wyjaśnienie, gdy strona “sama” pada znowu kilka godzin po udanym rollbacku.

Najpierw przypnij konkretną wtyczkę:

wp plugin auto-updates disable woocommerce
wp plugin auto-updates status

To ustawienie trafia do opcji auto_update_plugins jako lista ścieżek plików wtyczek. Ma to znaczenie z jednego powodu: jeśli później przywrócisz kopię bazy zrobioną przed ustawieniem blokady, blokada zniknie razem z nią. Ustaw ją ponownie po każdym przywróceniu bazy.

Dla rdzenia użyj wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

WP_AUTO_UPDATE_CORE przyjmuje true, false albo 'minor'. 'minor' przepuszcza wydania bezpieczeństwa i blokuje wersję główną, która zepsuła stronę, więc to ustawienie na czas po awarii. AUTOMATIC_UPDATER_DISABLED i filtr automatic_updater_disabled wyłączają cały mechanizm aktualizacji, łącznie z tłumaczeniami, dlatego stosuj je tylko na godziny diagnozy.

Poleceniem wp cron event list upewnij się, że nic nie czeka w kolejce, i zajrzyj też do panelu: zarządzane hostingi uruchamiają własny harmonogram aktualizacji poza WordPressem, który ignoruje stałe z wp-config.php. Jeśli strona jest budowana Composerem, przypnij dokładną wersję tam ("wpackagist-plugin/woocommerce": "8.5.0"), żeby blokadę egzekwowało wdrożenie, a nie ustawienie, które ktoś może wyczyścić w kokpicie.

Każde przypięcie traktuj jako tymczasowe. Zapisz wersję, której unikasz, i powód, śledź dziennik zmian wtyczki i zdejmij blokadę, gdy tylko wyjdzie poprawione wydanie. Wtyczka przypięta na stałe staje się luką bezpieczeństwa, którą aktualizacja miała zamknąć.

#Którą metodę rollbacku WordPressa wybrać

Właściwa metoda zależy od dostępu, jaki masz, i od tego, co się zepsuło:

Jeśli pasują dwa wiersze, wybierz wyższy: celowany rollback wtyczki zawsze mniej ingeruje niż pełne przywrócenie, a pełne przywrócenie jest siatką bezpieczeństwa na przypadki, w których celowany rollback nie może zadziałać.

#Jak sprawdzić kompatybilność PHP przed obniżeniem wersji WordPressa

Zdarza się, że awaria serwisu po aktualizacji nie wynika z błędu w kodzie WordPressa, lecz ze zmiany środowiska serwerowego. Jeśli firma hostingowa podniosła wersję interpretera PHP (np. z 8.1 do 8.3), starsze wtyczki mogą zgłaszać błędy fatal error z powodu usunięcia przestarzałych funkcji w silniku PHP.

Przed wykonaniem procedury cofania wersji WordPressa sprawdź aktualne środowisko wykonawcze:

php -v
wp eval 'echo PHP_VERSION;'

Jeśli błąd w logu wskazuje na Call to undefined function lub krytyczną niezgodność typów w bibliotece wtyczki, często szybszym rozwiązaniem niż downgrade WordPressa jest tymczasowe obniżenie wersji PHP w panelu hostingu do czasu wydania poprawki przez autora rozszerzenia.

#Jak zapobiegać awariom po aktualizacji WordPressa

Procedura downgrade powinna być traktowana jako ostateczność w planie ciągłości działania (Disaster Recovery). Aby uniknąć stresu związanego z ratowaniem działającego serwisu:

1. Środowisko Staging: Wszystkie aktualizacje wydań głównych testuj na wiernej kopii serwisu (staging). Narzędzia takie jak WP-CLI pozwalają sklonować środowisko w kilka minut.
2. Automatyczne backupy z retencją: Zadbaj o codzienne kopie zapasowe przechowywane poza serwerem produkcyjnym (np. w chmurze AWS S3 lub Google Cloud Storage).
3. Blokowanie automatycznych aktualizacji wydań głównych: W pliku wp-config.php zdefiniuj stałą kontrolującą automatyczne aktualizacje:

   define( 'WP_AUTO_UPDATE_CORE', 'minor' );

   Dzięki temu system automatycznie zainstaluje łatki bezpieczeństwa (np. 7.0.6, 7.0.7), ale nie przejdzie sam na wersję 7.1 bez Twojego nadzoru.

#Podsumowanie

Procedura degradacji WordPressa to podstawowa umiejętność każdego profesjonalnego administratora. Kluczem do sukcesu jest zachowanie spokoju, precyzyjna diagnostyka logów i korzystanie ze sprawdzonych narzędzi, takich jak WP-CLI, które minimalizują ryzyko błędu ludzkiego.

Potrzebujesz pomocy w opanowaniu awarii po aktualizacji lub chcesz wdrożyć zautomatyzowane procedury stagingowe w swojej firmie? Skorzystaj z naszego wsparcia w ramach naprawy i serwisu WordPress lub zleć nam kompleksowy audyt bezpieczeństwa WordPress.