Modernizacja starszych baz kodu WordPress: strategia 2026 dla firm

Starsza baza kodu WordPress (legacy code) to taka, w której nikt nie potrafi przewidzieć, co zepsuje dana zmiana. Problemem nie jest wiek, tylko brak pomiaru. Ten przewodnik pokazuje, jak najpierw zebrać te pomiary, a potem wymieniać kod w kolejności, w której każdy krok da się cofnąć.

Strony, o których mowa, rozpoznasz od razu: zbudowane w latach 2015-2020, klasyczny motyw z functions.php, który przekroczył dwa tysiące linii, kilka wtyczek pisanych na zamówienie bez repozytorium upstream i tabela wp_options, do której nikt nie zaglądał od startu. Zwykle nadal działają. Przestała działać możliwość zmieniania ich bez nerwów.

WordPress 7.1.1 ukazał się 17 września 2026 roku. Dystans między tą wersją a stosem z 2018 roku rzadko leży w rdzeniu. Leży w wersji PHP pod spodem, w skryptach, które kolejkuje motyw, i w bazie danych, która latami zbierała wiersze po wtyczkach, których już nie ma.

Więcej o profesjonalnym programowaniu WordPressa w WPPoland.

#1. Jak przeprowadzić audyt starszego WordPressa

Zacznij od liczb, które da się odczytać z działającej strony produkcyjnej, a nie od opinii o kodzie.

#Minimalna i zalecana wersja PHP dla WordPressa

Minimum i zalecenie to dwie różne rzeczy. Trunk WordPressa nadal ustawia $required_php_version = '7.4' w src/wp-includes/version.php, a strona z wymaganiami zaleca PHP 8.3 lub nowsze oraz MariaDB 10.11 albo MySQL 8.0. Rdzeń uruchomi się na 7.4, ale uruchomienie na 7.4 oznacza pracę bez poprawek bezpieczeństwa.

O migracji decydują daty z php.net, a nie obiecany procent przyspieszenia:

Plan celujący w 8.2 ma około trzech miesięcy zapasu. Celuj w 8.3 lub 8.4.

Strona na 7.4, 8.0 albo 8.1 nie dostała nowego wydania przy krytycznej luce w PHP z 21 października 2026 roku. Kroki dla takiej strony opisuje wpis co zrobić z PHP2Shell na stronie WordPress.

#Jak logować przestarzałe funkcje na produkcji bez WP_DEBUG

Tę część większość audytów robi źle. Rdzeń wywołuje do_action( 'deprecated_function_run', ... ) wewnątrz _deprecated_function() przed sprawdzeniem WP_DEBUG; od tej stałej zależy tylko wywołanie trigger_error(). To samo dotyczy deprecated_hook_run, deprecated_argument_run, deprecated_file_included, deprecated_class_run i deprecated_constructor_run. Mały mu-plugin daje prawdziwą inwentaryzację z ruchu na żywo i niczego nie wyświetla na ekranie:

<?php
// mu-plugins/deprecation-log.php
$hooks = array(
	'deprecated_function_run',
	'deprecated_hook_run',
	'deprecated_argument_run',
	'deprecated_file_included',
	'deprecated_class_run',
	'deprecated_constructor_run',
);

foreach ( $hooks as $hook ) {
	add_action(
		$hook,
		static function () use ( $hook ) {
			error_log( $hook . ' ' . wp_json_encode( func_get_args() ) );
		},
		10,
		4
	);
}

Zostaw go włączonego przez pełny cykl biznesowy. Cotygodniowy import albo kwartalna strona raportu dotykają przestarzałego kodu, do którego nie dotrze żaden crawl frontendu.

#Jak sprawdzić sumy kontrolne WordPressa w WP-CLI

wp core verify-checksums i wp plugin verify-checksums porównują zainstalowane pliki z hashami z WordPress.org. Na stronie z dziesięcioletnią historią prawie zawsze wychodzi w ten sposób wtyczka poprawiona ręcznie przez kogoś, kogo już nie ma w zespole. To właśnie te pliki cofną się przy następnej aktualizacji i to one powinny jako pierwsze trafić do kontroli wersji.

#Ile wersji jQuery ładuje stary WordPress

Zanim obwinisz jQuery, policz, ile jest kopii. Rdzeń rejestruje dokładnie jedną: script-loader.php deklaruje jquery-core w wersji 3.7.1 i jquery-migrate w wersji 3.4.1, a jquery to alias zależny od obu. Jeśli na stronie pojawia się kilka wersji, pochodzą z wtyczek i motywów, które kolejkują własną kopię pod innym uchwytem albo wpisują znacznik <script src> na sztywno w stopce. wp_scripts()->queue w minutę pokaże, która jest która. Wyrejestrowanie jQuery z rdzenia, żeby wymusić kopię z CDN, to dokładnie ta zmiana, która psuje panel administracyjny: zostaw uchwyt rdzenia w spokoju i usuń duplikaty.

jquery-migrate wymaga osobnej decyzji. Usunięcie go z kolejki to jedna linia, a jeśli konsola zapełni się wtedy błędami, te błędy są prawdziwą listą wzorców jQuery 1.x, które zostały w motywie.

#Skanowanie zgodności PHP narzędziem PHPCompatibilityWP

PHPCompatibilityWP istnieje po to, żeby reguły nie zgłaszały polyfilli, które rdzeń już dostarcza:

vendor/bin/phpcs -p wp-content/themes wp-content/plugins \
  --standard=PHPCompatibilityWP \
  --extensions=php \
  --runtime-set testVersion 8.3-

Bez testVersion wynik mówi bardzo mało. Z nim dostajesz listę plików uporządkowaną według tego, co dzieli Cię od wersji, do której chcesz dojść.

Inwentaryzacja, którą powinieneś mieć na koniec pierwszego tygodnia, to cztery kolumny: obecna wersja PHP, deprecjacje według endpointu, pliki, które nie przechodzą sumy kontrolnej, oraz błędy PHPCS według wtyczki. Wszystko, co przychodzi potem, priorytetyzujesz na podstawie tej tabeli.

Aktualizacja, 28 października 2026. PHPCompatibilityWP pokazuje, co przestanie działać na nowszym PHP. Dużą część poprawek automatyzuje Rector. Według notatek wydania wersja 2.8 z 26 października 2026 jest o około 26% szybsza od 2.7, a na PHP 8.3 i nowszym, z rozszerzeniem PHPStan Turbo, około trzy razy szybsza. Reguły dochodzą do wyniku w jednym przebiegu i są testowane na idempotentność, więc drugie uruchomienie na tym samym pliku nic już nie zmienia. Na starym projekcie dokumentacja Rectora zaleca ->withPhpLevel() i podnoszenie poziomu krok po kroku zamiast pełnego ->withPhpSets() od razu. Każdy przebieg uruchamiaj na osobnej gałęzi i przejrzyj diff przed wdrożeniem.

#2. Jak refaktoryzować WordPress wzorcem strangler fig

Nie próbuj zmieniać wszystkiego naraz. Strangler fig Martina Fowlera, opisany w 2004 roku i zaktualizowany w sierpniu 2024, to jedyna strategia przepisywania, przy której strona zarabiająca pieniądze cały czas stoi: postaw nowy system obok starego, skieruj do nowego wycinek ruchu i pozwól staremu kurczyć się, aż nie zostanie nic do odcięcia.

WordPress daje do tego dwa naturalne szwy i oba są w rdzeniu.

#Faza 1: aktualizacja rdzenia i infrastruktury

Zanim ruszysz szablony, doprowadź infrastrukturę do porządku: PHP na wspieranej gałęzi, WordPress w najnowszej stabilnej wersji, MySQL 8.0 albo MariaDB 10.11 zgodnie ze stroną wymagań, HTTPS na całej stronie i kopie zapasowe, które ktoś choć raz naprawdę przywrócił.

#Faza 2: migracja szablonów ścieżka po ścieżce

Pierwszy szew to template_include. To filtr, więc pojedyncza ścieżka może przejść na nowy kod, podczas gdy wszystkie pozostałe nadal wchodzą przez stare szablony. To wystarczy, żeby przenieść stronę kontaktu, sekcję kariery albo jeden typ treści na przepisany szablon z własnymi zasobami i jedną linią przywrócić poprzedni stan, jeśli spadnie konwersja.

Drugi szew to hybrydowa obsługa szablonów blokowych. locate_block_template() w src/wp-includes/block-template.php kończy działanie wcześnie, chyba że current_theme_supports( 'block-templates' ) zwraca prawdę, a gdy ta obsługa jest zadeklarowana, bierze pod uwagę tylko szablony blokowe o specyficzności równej lub wyższej niż szablon PHP, który hierarchia już znalazła. W praktyce:

add_action(
	'after_setup_theme',
	static function () {
		add_theme_support( 'block-templates' );
	}
);

Od tego momentu plik templates/page-contact.html w klasycznym motywie przejmuje dokładnie tę ścieżkę. single.php, archive.php i reszta zostają bez zmian. Ten mechanizm zamienia „migrację na bloki” w serię małych wdrożeń zamiast weekendu z planem wycofania, którego nikt nie przetestował.

Kolejność wycinków ustalaj według ryzyka, nie entuzjazmu. Dobry pierwszy wycinek to szablon z prawdziwym ruchem, mierzalnym wynikiem i bez procesu zakupowego w środku. Zły pierwszy wycinek to strona główna, bo daje największy możliwy zasięg skutków w dniu, w którym najsłabiej znasz nowy kod.

#Faza 3: wycofanie starych szablonów PHP

Duś stare szablony PHP, aż cała strona będzie działać na nowoczesnym stosie. Dwie zasady sprawiają, że to się trzyma. Każdy wycinek zabiera własne zasoby, żeby nowy szablon nie odziedziczył przypadkiem starego globalnego arkusza stylów. A stary kod usuwasz w tym samym wdrożeniu, które go zastępuje, bo martwy szablon pozostawiony w repozytorium ktoś edytuje w ciągu pół roku.

#3. Jak wyczyścić bazę danych starego WordPressa

Prawie każde zgłoszenie „baza danych działa wolno” w starym WordPressie sprowadza się do trzech rzeczy, a tylko jedna ma związek z rozmiarem.

#Jak zmniejszyć autoload w wp_options

Za autoload płacisz przy każdym żądaniu. Od WordPressa 6.6 kolumna autoload nie przechowuje już tylko yes i no. Notatka deweloperska o Options API wprowadziła on, off, auto-on, auto-off i auto, a wp_filter_default_autoload_value_via_option_size() w src/wp-includes/option.php odmawia automatycznego ładowania każdej zserializowanej wartości, która przekracza filtr wp_max_autoloaded_option_size, domyślnie 150000 bajtów. To zabezpieczenie działa w chwili zapisu opcji. Nic nie robi z blobem, który odinstalowana wtyczka zostawiła tam w 2019 roku.

Prawdziwą listę czytaj zapytaniem SQL, a nie z panelu wtyczki:

SELECT option_name, LENGTH(option_value) AS bytes, autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 25;

Te cztery wartości wp_load_alloptions() traktuje jako ładowane automatycznie. Ma to znaczenie, bo wp option list --autoload=on --format=total_bytes w WP-CLI dopasowuje tylko autoload='on' OR autoload='yes'. Na stronie z wersją 6.6 lub nowszą, gdzie nowe opcje trafiają jako auto, to polecenie pokazuje mniejszy rozmiar autoload niż ten, za który płacisz przy każdym ładowaniu strony. Użyj zapytania albo czytaj liczbę z WP-CLI ze świadomością, co pomija.

#Jak wyczyścić osierocone postmeta

Osierocone postmeta to liczba, nie zagadka. Policz je, zanim uznasz, że mają znaczenie:

SELECT COUNT(*)
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

Wiersze bez istniejącego wpisu można usunąć, a i tak najpierw robisz zrzut bazy danych. Meta należące do wtyczki, którą już wycofałeś, to osobne, ostrożniejsze przejście: pogrupuj według meta_key, porównaj prefiksy z wtyczkami, których nadal używasz, i usuwaj według klucza.

Stare rewizje to trzecia grupa, a wartość post_type zostaje po angielsku nawet na polskiej stronie:

DELETE FROM wp_posts
WHERE post_type = 'revision'
AND post_date < DATE_SUB(NOW(), INTERVAL 6 MONTH);

#Indeksy wp_postmeta, InnoDB i utf8mb4

Indeksy to część, której nikt nie czyta. src/wp-admin/includes/schema.php nadaje wp_postmeta klucz główny na meta_id, klucz post_id i klucz meta_key przycięty do 191 znaków, bo utf8mb4 używa czterech bajtów na znak, a historyczny limit indeksu wynosił 767 bajtów. Nie ma indeksu złożonego na (post_id, meta_key). Zapytanie filtrujące po obu kolumnach, czyli to, co robi szablon archiwum obciążony meta w każdym wierszu, nie może użyć jednego indeksu dla obu. Na dużej stronie rozwiązaniem jest indeks złożony dodany migracją, a nie kolejna warstwa cache na wierzchu.

W tym samym przejściu są jeszcze dwa sprawdzenia. Upewnij się, że wszystkie tabele to InnoDB, bo tabela MyISAM odziedziczona po imporcie z czasów MySQL 5.1 blokuje się przy zapisie i ignoruje transakcje. I upewnij się, że zestaw znaków to utf8mb4: rdzeń wybiera utf8mb4_unicode_520_ci w determine_charset(), gdy serwer to obsługuje, ale baza utworzona przed WordPressem 4.2 i przeniesiona przez mysqldump zostanie w utf8 i nadal będzie po cichu gubić znaki spoza podstawowej płaszczyzny.

#4. Jak zmodernizować CSS i JavaScript w starym motywie

Frontend starego WordPressa rzadko jest wolny z powodu frameworka, którego używa. Jest wolny, bo nic w motywie nie wie, co kolejkuje cała reszta.

#Jak podzielić monolityczny style.css na moduły

Starszy motyw z jednym ręcznie edytowanym style.css i bez bundlera nie ma jak dostarczyć ograniczonej zmiany. To, czy wynikiem będzie Tailwind, moduły CSS czy właściwości niestandardowe, znaczy dużo mniej niż możliwość odpowiedzi na pytanie, jakich selektorów potrzebuje dany szablon. Struktura, która na to pozwala, wygląda mniej więcej tak:

styles/
├── critical.css (inline w <head>)
├── components/
│   ├── header.css (na wszystkich stronach)
│   ├── blog.css (tylko na stronach bloga)
│   └── product.css (tylko na stronach produktów)
└── utilities.css (współdzielone klasy narzędziowe)

Gdy istnieje build, możliwe staje się ładowanie zasobów per szablon, a to ładowanie per szablon przesuwa ścieżkę renderowania, nie wybór frameworka.

#Jak ładować skrypty z defer i async w WordPressie

Użyj strategii ładowania, którą rdzeń już ma. Od WordPressa 6.3 wp_enqueue_script() przyjmuje tablicę w ostatnim parametrze:

wp_enqueue_script(
	'site-main',
	get_theme_file_uri( 'build/main.js' ),
	array(),
	filemtime( get_theme_file_path( 'build/main.js' ) ),
	array(
		'strategy'  => 'defer',
		'in_footer' => true,
	)
);

Pułapka jest opisana w notatce deweloperskiej do 6.3 i zaimplementowana w WP_Scripts::filter_eligible_strategies(): rdzeń przechodzi po drzewie zależności i jeśli któryś skrypt w kolejce zależny od Twojego nie jest również odroczony, Twój zostaje wyemitowany jako blokujący. Możesz ustawić defer na uchwycie, nie zobaczyć żadnego atrybutu defer w HTML i nie mieć nic w logu. Rdzeń wpisuje data-wp-strategy do znacznika zawsze, gdy zarejestrowano strategię odroczoną, niezależnie od tego, czy została zdegradowana, więc szukanie samego tego atrybutu zwraca wszystkie odroczone skrypty. Sygnałem degradacji jest znacznik z data-wp-strategy bez odpowiadającego mu defer lub async. Jedna stara wtyczka, która kolejkuje blokujący skrypt zależny od Twojego bundla, wystarczy, żeby cała zmiana poszła na marne.

Ten sam plik odrzuca też strategię ustawioną na uchwycie-aliasie, dlatego wp_script_add_data( 'jquery', 'strategy', 'defer' ) nie robi nic użytecznego: jquery nie ma src.

#Jak usunąć jQuery ze starego motywu

Proces jest stopniowy i opiera się na inwentaryzacji z sekcji 1:

1. Wypisz uchwyty w kolejce przez wp_scripts()->queue i oddziel jQuery z rdzenia od zduplikowanych kopii.
2. Ustal, które wtyczki zależą od uchwytu jquery.
3. Usuń jquery-migrate z kolejki i traktuj błędy w konsoli jako listę zadań.
4. Zastąp proste funkcje natywnym JavaScriptem.
5. Wycofaj zależność, gdy nic już jej nie wymaga.

#5. Jak zabezpieczyć stary WordPress

Starszy kod nie jest niebezpieczny dlatego, że jest stary. Jest niebezpieczny, bo powierzchnie, które wystawia, skonfigurowano, gdy wartości domyślne były inne.

#Narzędzia do skanowania bezpieczeństwa WordPressa

Więcej daje zaplanowana weryfikacja sum kontrolnych, log deprecjacji i alerty integralności plików niż skaner zwracający ocenę ważności. Typowe narzędzia do reszty przeglądu to PHPStan do statycznej analizy PHP, npm audit do zależności JavaScript i WPScan do już opublikowanych podatności.

#Jak ograniczyć REST API WordPressa

REST API nie da się wyłączyć, a snippety, które to obiecują, są gorsze niż nieruszanie niczego: rdzeń używa go w edytorze blokowym, w Site Health i przy hasłach aplikacji. Możesz natomiast wymagać uwierzytelnienia dla wszystkiego, co nie jest jawnie publiczne:

add_filter(
	'rest_authentication_errors',
	static function ( $result ) {
		if ( ! empty( $result ) || is_user_logged_in() ) {
			return $result;
		}

		return new WP_Error(
			'rest_not_logged_in',
			__( 'Dostęp do REST API wymaga uwierzytelnienia.' ),
			array( 'status' => 401 )
		);
	}
);

Potem przetestuj bez zalogowania części strony, które od niego zależą: formularze komentarzy, bloki wyszukiwania, formularze kontaktowe zbudowane na endpointach REST i każdego klienta headless. Na firmowej stronie marketingowej ten filtr zwykle jest nieszkodliwy. Na stronie z interaktywną funkcją dla anonimowych odwiedzających zepsuje ją i lepiej odkryć to na stagingu.

Zanim dodasz reguły, sprawdź, co już jest ograniczone. Endpoint użytkowników to powracający strach, ale WP_REST_Users_Controller stosuje has_published_posts przy żądaniach kolekcji zawsze, gdy wywołujący nie przechodzi current_user_can( 'list_users' ), co obejmuje zarówno niezalogowanych odwiedzających, jak i konta z małymi uprawnieniami. Typy treści, które bierze pod uwagę, to get_post_types( array( 'show_in_rest' => true ) ), a nie typy publiczne, i te dwie listy się nie pokrywają. Endpoint zwraca więc autorów, którzy publikowali w typie wystawionym w REST, a nie wszystkie konta. Enumeracja autorów na firmowej stronie zwykle wycieka przez przekierowania /?author=1 i archiwa autorów, nie przez REST.

Hasła aplikacji działają ponadto tylko przez HTTPS: wp_is_application_passwords_supported() zwraca is_ssl() || 'local' === wp_get_environment_type(). Stara strona, która wciąż serwuje panel z mieszaną treścią po zwykłym HTTP, ich nie oferuje i dlatego integracje na takich stronach kończą się współdzieleniem prawdziwego hasła administratora. Naprawa certyfikatu jest poprawką bezpieczeństwa; hasło aplikacji jest jej konsekwencją.

#Jak zaktualizować zależności starego WordPressa

Każdą bibliotekę zewnętrzną aktualizujesz albo zastępujesz:

• Biblioteki PHP z opublikowanymi podatnościami
• Komponenty JavaScript z aktywnymi CVE
• Fonty i zasoby ładowane z zewnętrznych CDN
• Integracje z wycofanymi już API

Inwentaryzację wtyczek zrób przy okazji, bo każda wycofana wtyczka to powierzchnia, której przestajesz utrzymywać.

#6. Jak przejść na Gutenberga z klasycznego motywu

#Zgodność starszego motywu z Gutenbergiem

W motywach budowanych w latach 2015-2018 obsługę włącza się etapami. add_theme_support( 'block-templates' ) to przełącznik, który otwiera migrację szablon po szablonie z sekcji 2; reszta to ustawienia edytora:

add_action('after_setup_theme', function() {
    // Podstawowa obsługa bloków
    add_theme_support('wp-block-styles');
    add_theme_support('align-wide');
    add_theme_support('responsive-embeds');

    // Paleta kolorów starszego motywu
    add_theme_support('editor-color-palette', [
        ['name' => 'Podstawowy', 'slug' => 'primary', 'color' => '#1a1a2e'],
        ['name' => 'Dodatkowy', 'slug' => 'secondary', 'color' => '#16213e'],
    ]);
});

Schemat theme.json jest w wersji 3. Wersja 4 nie istnieje, więc każdy przykład, który ją deklaruje, sprawi, że rdzeń zignoruje plik.

#Jak przejść z Elementora lub Divi na Gutenberga

Migracja z Elementora, Divi lub Visual Composera na Gutenberga przebiega według uporządkowanego procesu:

1. Inwentaryzacja: udokumentuj każdą stronę i jej obecny builder
2. Priorytetyzacja: zacznij od stron z największym ruchem
3. Konwersja: odtwórz układy wzorcami bloków
4. Weryfikacja: porównaj wizualnie i funkcjonalnie
5. Przełączenie: zmieniaj stronę po stronie z testowymi przekierowaniami
6. Sprzątanie: wyłącz stary page builder, gdy wszystkie strony są zmigrowane

Wersję buildera sprawdzaj w API wtyczek wordpress.org (api.wordpress.org/plugins/info/1.0/elementor.json dla Elementora, które na 12 października 2026 r. podaje 4.3.4 jako stabilną), a nie w readme.txt z repozytorium, które się dezaktualizuje.

#7. Jak mierzyć efekty modernizacji WordPressa

Nie obiecuj procentów przed pomiarem. Przed startem da się natomiast ustalić instrument, którym sprawdzisz każdą rzecz, i wartość wyjściową strony w obecnym stanie.

Po stronie biznesowej jedyna uczciwa liczba przed startem to ta, którą już masz: obecny ruch organiczny, konwersja i koszt utrzymania. Porównanie robisz później, względem tej samej linii bazowej i w oknie pomiaru ustalonym z góry.

#8. Audyt i modernizacja WordPressa z WPPoland

W WPPoland zajmujemy się ratowaniem stron na WordPressie i zawsze w tej kolejności.

1. Due diligence i audyty: dostarczamy inwentaryzację techniczną z sekcji 1, z priorytetami i szacowanym kosztem każdej interwencji.

2. Wdrożenia przyrostowe: modernizujemy etapami, każdy z własnym kryterium akceptacji i sposobem wycofania.

3. Cele mierzone, nie obiecywane: zanim dotkniemy kodu, ustalamy, która metryka ma się zmienić, jakim instrumentem ją mierzymy i w jakim oknie. Czego nie da się zmierzyć, nie wchodzi w zakres.

4. Przekazanie wiedzy: dokumentujemy proces i szkolimy Twój zespół, żeby samodzielnie utrzymywał zmodernizowany kod.

#9. Od czego zacząć modernizację starszego WordPressa

Starsza strona na WordPressie nie jest automatycznie kulą u nogi. Jest nią dług techniczny, którym nikt nie zarządza, a różnica między tymi dwoma przypadkami polega na tym, czy ktoś potrafi powiedzieć, ile kosztuje zmiana, zanim ją zrobi.

Kolejność w tym przewodniku jest celowa. Zmierz lukę PHP względem dat z php.net, zbierz deprecjacje z prawdziwego ruchu hookami, które rdzeń już wywołuje, zweryfikuj pliki sumami kontrolnymi, a potem duś szablony ścieżka po ścieżce przez template_include albo block-templates. Napraw autoload i indeksy postmeta, bo działają przy każdym żądaniu. Napraw ładowanie skryptów, bo rdzeń daje Ci mechanizm, a stare wtyczki po cichu go odbierają. Dopóki to nie jest zrobione, wszystko inne jest kwestią preferencji.

Jeśli strona nadal stoi na stosie z 2018 roku, pierwszym rezultatem nie jest kod. Jest nim dokument: wersja PHP, log deprecjacji, błędy sum kontrolnych, lista wtyczek z osobą odpowiedzialną i szablony, które niosą ruch.

Twoja strona firmowa utknęła w 2018 roku? Napisz do WPPoland w sprawie audytu i zacznij od inwentaryzacji, nie od przepisywania.

Modernizacja starszego kodu zaczyna się od inwentaryzacji tego, co naprawdę jest używane, a nie od przepisywania wszystkiego od zera. Taki etapowy plan układamy razem z klientem, korzystając z naszego doświadczenia w refaktoryzacji WordPressa.

#Powiązane materiały

• Profesjonalne programowanie WordPressa - modernizacja dla firm
• Przyspieszenie strony na WordPressie - wydajność po modernizacji
• Audyt bezpieczeństwa WordPressa - bezpieczeństwo starszego kodu
• Przebudowa i modernizacja strony - pełna modernizacja wizualna
• Migracja na Next.js lub Astro - nowoczesne architektury po refaktoryzacji