Stare serwisy na PHP 8 - jak przywróciliśmy 36 projektów z lat 2007-2018

Większość naszych starszych projektów przez lata istniała tylko jako zrzuty ekranu w portfolio. Kod leżał w archiwach, bazy w kopiach zapasowych, a hostingi, na których działały, dawno przeszły na nowsze wersje PHP. W listopadzie 2026 roku postanowiliśmy to zmienić: każdy stary serwis, który się da, ma znów działać - nie jako obrazek, tylko jako prawdziwa strona, którą można kliknąć.

Efekt to 36 serwisów z lat 2007-2018 uruchomionych ponownie na PHP 8: 16 stron firmowych, 9 portali, 6 gier przeglądarkowych, 4 sklepy internetowe i jedna aplikacja webowa. Każdy działa na własnej subdomenie coolpage.pl, z danymi testowymi zamiast prawdziwych użytkowników. Wszystkie są opisane w naszych realizacjach, a przy każdym case study jest link do działającej wersji.

To nie był projekt dla samej nostalgii. Dokładnie tę samą pracę wykonujemy, kiedy przejmujemy system po innej firmie albo gdy klient ma aplikację, która przestała działać po aktualizacji serwera. Poniżej opisujemy, co się psuje i jak do tego podchodzimy.

Jakie serwisy wróciły do życia

Najstarsze pochodzą z 2007 roku: serwis domu aukcyjnego OnlyArt i internetowa telewizja jeździecka itvj.pl. Są wśród nich sklepy, w których można dziś przejść całą ścieżkę zakupu i złożyć zamówienie testowe (amiQs.pl z 2011 roku i MTDsklep.pl z 2016 roku), portale społecznościowe i fora, a także gry - od TransportGame.com, przeglądarkowej gry transportowej na prawdziwej mapie z 2010 roku, po edukacyjną grę ekonomiczną GraFirma.pl, w którą można zagrać w pokojach demo.

Większość z nich zbudowaliśmy na kolejnych wersjach naszego własnego CMS-a. To ułatwiało pracę, ale nie było regułą: trafiały się też serwisy z własnymi skryptami, innymi bibliotekami i kodem pisanym pod konkretny hosting sprzed kilkunastu lat.

Co psuje się w starym PHP po przejściu na PHP 8

Serwis napisany pod PHP 5 zwykle nie uruchamia się na PHP 8 wcale - kończy się białą stroną albo błędem krytycznym już przy pierwszym połączeniu z bazą. Przyczyny powtarzały się od projektu do projektu:

• Funkcje mysql_* - usunięte w PHP 7. Stary kod łączy się z bazą funkcjami, których po prostu nie ma.
• ereg, split, each() i create_function() - kolejne funkcje, które zniknęły, a były w starym kodzie na każdym kroku.
• magic_quotes i register_globals - mechanizmy, na których opierał się kod sprzed lat. Ich ustawienie w plikach .htaccess i php.ini kończy się w PHP 8 błędem serwera.
• Krótkie tagi <? zamiast <?php - na nowym serwerze kod PHP wyświetla się jako tekst.
• Zmiany w samym języku - odwołania do znaków przez $napis, count() na wartości, która nie jest tablicą, preg_replace z modyfikatorem /e czy funkcje graficzne z pustym argumentem są dziś błędami krytycznymi.
• Stare biblioteki, np. silnik szablonów Smarty 2, który w oryginalnej wersji nie działa na PHP 8.
• Baza danych w trybie ścisłym - dzisiejszy MySQL odrzuca zapytania, które MySQL 5 przepuszczał bez słowa, np. zapis rekordu bez wartości dla części kolumn.
• Różnice między serwerami - wielkość liter w nazwach plików, inne ścieżki katalogów, wymuszony HTTPS czy domyślne kodowanie znaków.

Warstwa zgodności zamiast przepisywania od zera

Przepisanie 36 serwisów na nowo byłoby pracą na miesiące, a w efekcie powstałyby inne serwisy niż te, które kiedyś oddaliśmy klientom. Wybraliśmy inną drogę: jedną warstwę zgodności, czyli plik dołączany na początku każdego serwisu, który odtwarza brakujące elementy starego PHP na nowym. Funkcje mysql_* działają w nim przez mysqli, ereg i split przez wyrażenia regularne PCRE, a do tego są each(), create_function(), stara obsługa sesji i - tam, gdzie kod tego wymaga - emulacja magic_quotes i register_globals.

Część zmian robi skrypt: poprawia krótkie tagi, podmienia Smarty 2 na wersję 2.6.33 zgodną z PHP 8, wyłącza nieistniejące dyrektywy w .htaccess i php.ini, a na koniec wypisuje listę miejsc do ręcznej poprawki. Ręczne poprawki dotyczą głównie miejsc, w których zmienił się sam język.

Dzięki temu kod każdego serwisu pozostał oryginalny. Widać w nim, jak budowaliśmy strony w 2009 czy 2013 roku, a różnica względem pierwowzoru to głównie jeden dołączony plik i lista drobnych poprawek, które da się prześledzić w repozytorium.

Baza danych: kodowanie znaków i dane osobowe

Bazy odtwarzaliśmy z kopii zapasowych, często tworzonych przez sam CMS wiele lat temu. Część serwisów działała w kodowaniu ISO-8859-2, więc polskie znaki trzeba było przekonwertować na UTF-8 albo świadomie zostawić stare kodowanie w całym serwisie - inaczej zamiast "ą" pojawiają się krzaczki.

Drugi temat to dane. Kopie prawdziwych serwisów zawierają prawdziwych ludzi: konta, zamówienia, wiadomości. W wersjach roboczych użytkowników i zamówienia zanonimizowaliśmy, dane kontaktowe i firmowe zastąpiliśmy testowymi, a hasła i klucze do zewnętrznych usług usunęliśmy, zanim kod trafił do repozytorium. To ten sam porządek, od którego zaczynamy przejęcie każdego cudzego systemu.

Usługi zewnętrzne, których już nie ma

Kod to nie wszystko. Stare serwisy korzystały z usług, które przez lata zniknęły albo się zmieniły. Dobrym przykładem jest gra TransportGame.com: jej mapy i wyznaczanie tras opierały się na usługach Bing z 2010 roku, które dziś już nie działają. Trasy i wyszukiwanie miejsc przenieśliśmy na otwarte usługi OSRM i Nominatim oparte na OpenStreetMap, brakujące style i grafiki biblioteki map odzyskaliśmy z Internet Archive, a muzykę gra odtwarza teraz przez HTML5. Dzięki temu w TransportGame znów da się jeździć ciężarówką po prawdziwej mapie.

Wersje demonstracyjne: można klikać, nie można zepsuć

Serwis, który wraca do sieci, musi być bezpieczny dla odwiedzających i dla nas. Dlatego większość wersji roboczych działa w trybie podglądu: wszystko można obejrzeć, ale formularze niczego nie zapisują. Tam, gdzie warto pokazać więcej, przygotowaliśmy wersje demonstracyjne z kontami testowymi - w serwisie dla par FlirtPartnerski.pl można się zalogować jednym kliknięciem, w dzienniczku treningowym MajaTeam.com dodać trening, a w sklepach złożyć zamówienie testowe. Baza takiego demo co noc wraca do stanu wyjściowego, wiadomości e-mail nie wychodzą na zewnątrz, a wgrywanie plików jest wyłączone.

Wszystkie wersje robocze są też wyłączone z indeksowania (noindex). Stare treści nie powinny konkurować w wyszukiwarce z obecnymi stronami naszych klientów - opis projektu i link do demo są na stronie case study.

Co to oznacza dla właściciela starszego systemu

Jeśli Twój sklep, portal albo aplikacja firmowa działa na starej wersji PHP i boisz się aktualizacji serwera, najważniejszy wniosek jest taki: stary kod zwykle da się uruchomić na nowym PHP bez przepisywania wszystkiego. To nie znaczy, że zawsze warto na tym poprzestać. Kod sprzed lat pisano według ówczesnych zasad bezpieczeństwa, więc samo przeniesienie na PHP 8 nie zastępuje przeglądu i poprawek. Dlatego nasze wersje robocze działają w trybie podglądu, a systemy klientów, które mają dalej zarabiać, zaczynamy od audytu.

Więcej o kosztach znajdziesz w artykule Ile kosztuje modernizacja starego systemu PHP?, o tym, kiedy aktualizacja się opłaca - w tekście o przepisywaniu starych systemów na nowe wersje PHP, a o tym, dlaczego PHP wciąż ma sens - w artykule PHP - dlaczego wciąż napędza dużą część internetu.

Czy serwis napisany w PHP 5 da się uruchomić na PHP 8 bez przepisywania?

W większości przypadków tak. Brakujące funkcje starego PHP, takie jak mysql_*, ereg czy each(), można odtworzyć warstwą zgodności, a zmiany w samym języku poprawić punktowo w kodzie. W ten sposób uruchomiliśmy 36 własnych serwisów z lat 2007-2018 z oryginalnym kodem i wyglądem. Przepisanie od zera ma sens dopiero wtedy, gdy system i tak wymaga dużych zmian funkcjonalnych.

Co najczęściej przestaje działać po aktualizacji PHP?

Najczęściej połączenie z bazą danych, bo funkcje mysql_* usunięto w PHP 7. Dalej idą funkcje ereg, split, each() i create_function(), ustawienia magic_quotes i register_globals w .htaccess, krótkie tagi <?, stare biblioteki (np. Smarty 2) oraz tryb ścisły nowszego MySQL, który odrzuca zapytania akceptowane dawniej bez ostrzeżenia.

Czy po przeniesieniu na PHP 8 serwis jest bezpieczny?

Nie automatycznie. Nowa wersja PHP usuwa problem niewspieranego środowiska, ale nie poprawia błędów samego kodu, na przykład zapytań SQL sklejanych z danych od użytkownika czy brakujących zabezpieczeń formularzy. Dlatego przed dalszym rozwojem systemu robimy audyt, a nasze archiwalne serwisy pokazujemy w trybie podglądu albo w demo z danymi testowymi.

Kiedy lepiej przepisać system od nowa niż go aktualizować?

Gdy system i tak wymaga przebudowy większości funkcji, gdy jego architektura blokuje rozwój albo gdy koszt utrzymania starego kodu przekracza koszt nowej wersji. Jeśli serwis działa, zarabia i potrzebuje głównie bezpiecznego środowiska, aktualizacja z warstwą zgodności i poprawkami jest zwykle szybsza i tańsza. Taką ocenę daje audyt przejęcia projektu.