Strona z FrontPage'a na WordPressie. Żaden ze starych adresów nie umarł

Ćwierć wieku ręcznej roboty w jednym katalogu

Stronę zbudował w Microsoft FrontPage i przez ćwierć wieku dokładał do niej kolejne wyprawy ręcznie. Zamiast zwykłych stron są ramki, w jednym archiwum siedzą cztery różne kodowania tekstu (iso-8859-1, windows-1252, windows-1250, iso-8859-2), miniatury mają żółtą obwódkę wypaloną w samym JPEG-u, a do każdego pliku z treścią FrontPage dołożył swój ukryty plik pomocniczy. Na serwerze leży 32 039 plików, 1 660 MB.

Powiedział wprost, czego chce. Archiwum ma stanąć na czymś, co sam obsłuży, wygląd ma zostać taki, jaki jest, a stare adresy mają dalej działać. Wskazał też palcem działy, których nie wolno ruszać, i tych działów nie ruszałem.

Program chodzący po stronie zobaczył połowę zdjęć

Najpierw policzyłem zdjęcia tak, jak robi to przeglądarka: chodząc po linkach. Wyszły 2 232. Spis plików wprost z serwera pokazał 4 786, czyli ponad dwa razy tyle. Obie liczby policzyłem tak samo starannie, tylko pierwsza była fałszywa. Do galerii, na którą nie prowadzi zwykły link, bo siedzi w ramce albo w menu zrobionym w JavaScripcie, program nie dojdzie. Człowiek, który zapisał ją sobie w ulubionych w 2011 roku, otworzy ją bez problemu.

Zaraz obok czekała pułapka odwrotna. Tych ukrytych plików pomocniczych jest 9 807, więc kto policzy katalog wprost, dostanie 16 216 zdjęć zamiast 4 786. Spis oparty na którejkolwiek z tych liczb kończy się tak samo źle: albo połowa archiwum nie zostanie przeniesiona, albo połowa zostanie przeniesiona dwa razy.

Migracja, której nie widać

Na obu zrzutach jest ta sama strona główna. Po lewej wersja z FrontPage'a taka, jaką zachowało Archiwum Internetu w grudniu 2024. Po prawej dzisiejszy WordPress, który składa te same kafelki z bazy danych. Pod spodem nie zostało nic wspólnego: ani HTML, ani szablon, ani jedna ścieżka do pliku.

O to właśnie chodziło: wygląd miał zostać. Tytuł kafelka poznaję po kolorze tekstu, bo w tym HTML-u nie ma nic, co odróżniałoby tytuł od reszty. Ćwierć wieku ręcznych poprawek nie zostawiło żadnej powtarzalnej struktury.

128 galerii. Okiem tego nie sprawdzisz

Każda galeria to teraz strona WordPressa z blokiem galerii, a każde zdjęcie to załącznik, który pamięta, z jakiego pliku powstał. Dzięki temu import można powtórzyć: zdjęcia się aktualizują, zamiast dublować. Podpisy przeszły znak w znak, razem z polskimi, które przy trzech z czterech kodowań rozsypałyby się bez ostrzeżenia.

Przy 128 galeriach otwieranie ich po kolei i kiwanie głową niczego nie sprawdza. Każdą galerię porównuje ze spisem skrypt: liczbę zdjęć, ich kolejność, podpisy znak w znak i to, jaki plik siedzi za każdą miniaturą. Sam skrypt też jest sprawdzony, bo psuję stronę celowo i patrzę, czy to wyłapie.

Dziewięć galerii nie miało w starym HTML-u żadnego tytułu. Nazw im nie wymyśliłem: wziąłem je z podpisów, którymi on sam linkował do tych galerii ze swojego menu, dziewięć na dziewięć. Trzy zestawy kolorów, granat w 37 galeriach, zieleń w 70 i pomarańcz w 21, odczytałem z metatagu zostawionego przez FrontPage'a, zamiast zgadywać po nazwach folderów.

15 205 starych adresów i dlaczego nie poszły do .htaccess

Lista, którą zatwierdził klient, miała 5 215 stron. Działać przestało 15 205 adresów, bo folder galerii schodzi z dysku w całości. Doszły więc adresy samych folderów, ramki FrontPage'a, stara strona startowa i 9 602 pliki ze zdjęciami, na które od lat kierowała Grafika Google.

Piętnaście tysięcy reguł w pliku .htaccess Apache czytałby przy każdym wejściu na stronę. Przekierowania siedzą więc w tabeli z indeksem, a czyta ją mała wtyczka, która odzywa się wcześniej niż WordPress. Ta kolejność jest tu najważniejsza. WordPress przy błędzie 404 sam szuka strony o podobnej końcówce adresu i czasem trafia, a takiego trafu nie odróżnisz od poprawnego przekierowania, dopóki nie wiesz, kto odpowiedział. Nasza wtyczka podpisuje swoją odpowiedź własnym nagłówkiem i dopiero dzięki temu sprawdzenie cokolwiek znaczy.

Pomiar na żywej stronie, tego samego wieczoru, kiedy ruszyła: 15 205 adresów odpowiada trwałym przekierowaniem z tabeli, 4 965 miejsc docelowych odpowiada kodem 200, zero błędów. Stare foldery przeniosłem do osobnego katalogu, dalej leżą na dysku, więc powrót to jedna zmiana nazwy.

Przełączenie w jednym ruchu, z drogą powrotu na każdym kroku

Na jego hostingu nie ma konsoli, a do bazy nie da się wejść z zewnątrz. Wszystko, co musiało wykonać się na serwerze, poszło więc jednorazowym skryptem, który po wszystkim kasuje sam siebie. Samo przełączenie to jedno wejście na adres: 21 rzeczy przenosi się do katalogu strony, stara strona startowa ląduje w osobnym folderze, adresy w bazie się aktualizują, a strona otwiera się dla wyszukiwarek.

Całość przećwiczyłem u siebie i wymusiłem w próbie awarie, które mogłyby się zdarzyć. Najważniejsza jest ta: folder zostawiony na dysku zasłania stronę WordPressa o tym samym adresie. Właśnie tak przeprowadzka potrafi wyglądać na skończoną, a części odwiedzających dalej pokazywać stare strony.

Zbudował następną wyprawę, jeszcze przed startem

Sensem całej roboty było to, żeby przestał mnie potrzebować. Nowa wyprawa to u niego zwykła strona: zakłada ją, galerie dokłada pod spodem, kolory biorą się z tytułu, menu z boku układa się samo z pozostałych galerii tej wyprawy, a na górze strony głównej pojawia się kafelek. Do tego dostał dwunastostronicowy poradnik z czterema rzeczami, które faktycznie robi.

Sprawdził to sam, na kopii roboczej, jeszcze przed przełączeniem: dołożył wyprawę z trzema galeriami i dziesięcioma opisanymi zdjęciami, nie pytając mnie o nic.

Co napisał na koniec

Jego publiczna opinia na Upworku, 5,0 na 5:

Publikuję za jego zgodą z 3 września 2026. Płatność za każdy etap zwalniał w ciągu kilku godzin od oddania roboty, a to zdarza się rzadziej niż dobry kod.