Hellas Next — od statycznej strony do WordPressa
Przeniesienie HOME bez zmiany wyglądu: od istniejących treści i zdjęć do WordPressa. Pierwszy etap, naprawy i dalsza praca nad serwisem.

Hellas Next nie zaczynało jako WordPress. Miałem już stronę o Grecji: własne zdjęcia, greckie teksty, News, galerie i kolekcje miejsc oraz doświadczeń. Chciałem zachować jej wygląd, a jednocześnie przenieść edycję wybranych treści do panelu WordPressa.
To jest zapis pierwszego etapu: przeniesienia HOME. Nie opisuję tutaj ukończonej migracji całego serwisu. Strona główna działa na wersji testowej, ale pozostałe działy nadal wymagają pracy.
Punkt wyjścia
Wersja V01 powstawała ze statycznego generatora w Node.js. Treści i ustawienia były w plikach JSON, a własne szablony, CSS i JavaScript tworzyły strony HTML. Nie było tam WordPressa ani motywu Sage.
Istniały już artykuły, galerie i opisy miejsc. Ich przeniesienie pozostaje osobnym etapem.
Były też materiały, których nie należało traktować jako gotowej oferty: wcześniejsze elementy demo, nieaktywne języki i zapowiedź większej kolekcji doświadczeń. Migracja nie miała zamieniać tych zapowiedzi w rzekomo ukończone funkcje.
Dlaczego chciałem zmiany
W statycznej wersji istniał już lokalny panel redakcyjny News. Nie chodziło więc o to, że niczego nie dało się edytować. Chodziło o przejście na normalny CMS: treści, media i wybrane ustawienia w WordPressie, z własnym frontendem.
Nie chciałem przy okazji wymyślać strony od nowa. Najpierw należało sprawdzić, czy można przenieść istniejący HOME i nadal widzieć tę samą stronę.
Co postanowiliśmy zachować
Punktem odniesienia były rzeczywiste pliki i screeny V01: układ sekcji, greckie litery, font GFS Didot, fotografie, kadry i kolejność materiałów. Zachowano również identyfikatory zdjęć oraz informacje o autorstwie i prawach.
Nie zrobiono drugiego wyboru zdjęć ani nowych ilustracji tylko dlatego, że zmieniał się silnik strony. Fotografie, materiały na licencji i istniejące obrazy AI miały pozostać rozróżnione.

Archiwalny zrzut statycznej wersji V01, używanej jako wzorzec. Źródło: zapis lokalnego porównania sprzed migracji.
Jak podeszliśmy do migracji
Powstał oddzielny projekt Bedrock z WordPressem i motywem Sage. Vite przygotowuje frontend, a ACF Free udostępnia 21 pól HOME. Ten etap nie potrzebował płatnych pól galerii ani rozbudowanego systemu treści.
Szablon podzielono na komponenty, ale pozostawiono dotychczasowy CSS i jego kolejność. Nie przepisano całej strony na nowe klasy przy okazji portowania.
Najpierw przeniesiono stronę główną. Artykuły i pozostałe działy będą rozwijane w kolejnych etapach.
Etapy pierwszego sprintu
- Audyt V01 i zachowanie wzorca
- Oddzielny WordPress, motyw i build
- Port HOME oraz 21 pól ACF
- Import zdjęć i logo
- Naprawa niekompletnego pliku ACF
- Kontrola wyglądu i mediów na wersji testowej
Co poszło nie tak
Poprawiono ładowanie fontów, formatowanie tekstów i obsługę nawigacji.
Na wersji testowej pojawił się inny problem. ACF było nieaktywne, a w procesie importu występował komunikat Missing imported attachment: balos. Działający lokalny projekt nie gwarantował więc poprawnego stanu hostingu.
Jak znaleźliśmy przyczynę
Jeden z plików wtyczki ACF był pusty. Po wgraniu poprawnej kopii można było dokończyć import.
To wystarczyło, żeby zmienić kierunek diagnozy. Nie trzeba było od razu przepisywać HomePresentera ani importera. Najpierw należało naprawić niekompletny plik zależności.
Nie ma potwierdzenia, dlaczego transfer pozostawił pusty plik. Nie przypisuję tego liczbie plików, zerwaniu połączenia ani błędowi FileZilli. Wiemy, co było niekompletne; nie wiemy, co dokładnie doprowadziło do tego stanu.
Jak to naprawiliśmy
Przez FileZillę wgrano poprawny lokalny plik. Podczas diagnozy tymczasowo użyto standardowego motywu Twenty Twenty-Five, a następnie przywrócono Sage. Nie zmieniono wersji wtyczki, HomePresentera ani importera.
Po naprawie import HOME zakończył się poprawnie. Biblioteka miała 27 załączników: 26 obrazów i logo. Mapa 26 dawnych identyfikatorów prowadziła do poprawnych mediów WordPressa, a wszystkie 21 pól HOME było uzupełnionych.

Rzeczywisty ekran sprawdzenia importu na wersji testowej z 2 października 2026. Nie jest to wizualizacja ani odtworzony komunikat błędu.
Jak wyglądało testowanie
Lokalne testy obejmowały szerokości od 360 do 1440 px. Na hostingu raport importu potwierdza desktop i 390 px mobile bez poziomego overflow oraz 53 pliki mediów z odpowiedzią HTTP 200 i zgodnym rozmiarem.
Co działa teraz
Strona główna działa w wersji testowej. Pełna migracja serwisu nadal trwa.
Nie ma w tych materiałach dowodu końcowej migracji produkcyjnej całej platformy ani pełnego testu odtworzenia serwera z backupu. Status projektu: W TRAKCIE.
Czego nauczył mnie ten projekt
Najważniejsza rzecz była mała: sprawdzić, czy plik naprawdę zawiera kod. Sama nazwa w katalogu nie wystarcza.
Druga rzecz to zakres. Działający HOME jest dobrym wynikiem pierwszego etapu, ale nie można nazwać go ukończoną migracją całego projektu.
I jeszcze jedno: warto mieć wzorzec. Kiedy wygląd jest już dopracowany, migracja może zmienić sposób edycji treści bez zmieniania strony w zupełnie inny projekt.

HOME wersji testowej na telefonie: aktualny zrzut przeglądarki z 3 października 2026. Test przeglądarkowy, nie zdjęcie fizycznego telefonu.
Źródła i granice
Aktualizacja: 4 października 2026. Gotowy jest pierwszy etap — strona główna. Pozostałe działy czekają na migrację.