holas.pl działał na WordPressie od 2007 do początku 2026 roku. Dziewiętnaście lat. W tym czasie WordPress wyrósł z przyzwoitej platformy blogowej w coś, czego prawie nie rozpoznaję — a jego utrzymanie stało się większym wysiłkiem niż utrzymanie samej treści.

To pierwszy wpis z serii dokumentującej migrację do własnego generatora stron statycznych opartego na Symfony. Kolejne wpisy omawiają architekturę, formularz kontaktowy, środowisko deweloperskie i budowanie strony z pomocą AI.

Taśmociąg aktualizacji

WordPress regularnie wydaje aktualizacje bezpieczeństwa. Wtyczki wydają aktualizacje niezależnie. Motywy też. W spokojnym tygodniu miałem trzy pozycje w kolejce. W gorszy tydzień — piętnaście. Każda wymagała:

  1. Kopii zapasowej bazy danych i plików
  2. Zastosowania aktualizacji
  3. Sprawdzenia, czy nic się nie posypało

Ten ostatni krok to największy problem. Wtyczki WordPressa wchodzą ze sobą w interakcje w sposób niemożliwy do przewidzenia. Aktualizacja wtyczki do cache'owania psuła wyniki wtyczki SEO. Aktualizacja wtyczki SEO zmieniała sposób generowania map strony. Każda aktualizacja to mały hazard.

Dla portfolio z wpisem co kilka miesięcy ten narzut na utrzymanie jest absurdalny.

Dziesiątki wtyczek do podstawowych funkcji

Świeża instalacja WordPressa nie robi prawie nic. Żeby prowadzić przyzwoite portfolio blogowe, potrzebowałem wtyczek do:

  • SEO — Yoast lub Rank Math, z własnym interfejsem, ustawieniami i cyklem aktualizacji
  • Cache'owania — W3 Total Cache lub WP Super Cache, ze skomplikowaną konfiguracją
  • Bezpieczeństwa — Wordfence lub podobna, skanowanie intruzji, blokowanie IP, codzienne raporty
  • Formularza kontaktowego — Contact Form 7 lub Gravity Forms
  • Kopii zapasowych — UpdraftPlus lub podobna, zwykle wysyłająca dane do zewnętrznego serwisu
  • Wydajności — optymalizacja obrazów, lazy loading, minifikacja
  • SMTP — bo WordPress domyślnie wysyła e-maile przez mail() w PHP, które trafiają do spamu

Każda wtyczka to kod, którego nie kontroluję, utrzymywany przez kogoś innego, potencjalnie porzucony jutro, działający przy każdym wczytaniu strony.

Kiedy zacząłem planować migrację, miałem 22 aktywne wtyczki.

Ataki botów i problemy z logowaniem

Strona logowania do WordPressa jest dobrze znana botom. URL to zawsze /wp-admin/ lub /wp-login.php. Każdy bot w internecie to wie. Efekt: ciągłe próby włamania przez brute-force, przez całą dobę.

Wordfence ograniczał próby logowania, blokował podejrzane IP i wysyłał mi codzienne raporty o atakach. Działało — ale to kolejny element pochłaniający zasoby serwera na stronie, która w ogóle nie potrzebuje logowania użytkowników. Jedyną osobą logującą się byłem ja, raz w miesiącu.

XML-RPC to kolejny wektor ataku. WordPress domyślnie go włącza dla pingbacków i aplikacji mobilnej. Boty ciągle go sondują. Rozwiązaniem była reguła nginx blokująca ten endpoint — ale dowiedziałem się o tym dopiero po zobaczeniu ruchu w logach.

PHP i MySQL na Raspberry Pi

holas.pl działa na własnym sprzęcie — najpierw Banana Pi, teraz Raspberry Pi 5. To sprawne płyty ARM, ale nie są maszynami serwerowymi. Uruchamianie PHP-FPM i MySQL jednocześnie dla bloga, który zmienia się raz w miesiącu, to czyste marnotrawstwo.

Typowe wczytanie strony WordPress na tym sprzęcie: PHP przetwarza żądanie, MySQL wykonuje kilka zapytań po treść wpisu, dane nawigacji, widżety paska bocznego i opcje strony, PHP renderuje szablony, każda aktywna wtyczka wykonuje swoje hooki. Wszystko to dla treści identycznej z poprzednim żądaniem i identycznej z następnym.

Ze stroną statyczną nginx serwuje wstępnie wyrenderowany plik HTML bezpośrednio z dysku. Procesor ARM ledwo się budzi. Strony ładują się szybciej niż WordPress zdążył przetworzyć żądanie.

Baza danych jako ryzyko

Dziewiętnaście lat WordPressa to baza danych z tysiącami wierszy metadanych wpisów, opcji, rewizji i transientów. Wymaga:

  • Regularnych kopii zapasowych (i testowania, że przywracanie faktycznie działa)
  • Okazjonalnego czyszczenia — WordPress gromadzi śmieci: rewizje wpisów, wygasłe transienty, osierocone wiersze metadanych
  • Monitorowania pod kątem uszkodzeń po nieoczystym wyłączeniu
  • Ciągle działającego procesu MySQL, zużywającego pamięć

Portfolio blog to zbiór tekstów i obrazów. Przechowywanie go w relacyjnej bazie danych dodaje złożoności operacyjnej bez dodawania wartości.

Co zostało zachowane

Treść. Wszystkie 26 wpisów zostało wyeksportowanych i przekonwertowanych do plików Markdown — tytuły, daty, kategorie, tagi, obrazy. Adresy URL zostały zachowane dokładnie: 25 indywidualnych przekierowań wpisów i 43 przekierowania ścieżek obrazów jest teraz wbudowanych w konfigurację nginx. Pozycje w wyszukiwarce przetrwały migrację nienaruszone.

Wszystko inne — baza danych, wtyczki, kolejka aktualizacji, strona logowania /wp-admin/ — zniknęło.

Następny wpis opisuje, co zastąpiło WordPressa: własna aplikacja Symfony generująca statyczne pliki HTML, serwowane przez nginx bez udziału PHP w dostarczaniu treści do odwiedzających.