Dodatkowe opłaty za „obsługę starszych wersji PHP/MySQL” — co z tym zrobić, gdy masz stronę na DuoCMS

Problem: nowe pozycje na fakturach za hosting

Coraz więcej firm korzystających z hostingu nazwa.pl i home.pl znajduje na proformach i fakturach dodatkowe pozycje:

• „Wsparcie obsługi starszych wersji PHP”,
• „Obsługa starszych wersji MySQL 5.7″,
• „Obsługa starszych wersji serwerów baz danych”.

Mechanizm jest prosty — jeśli strona działa na PHP 7.x i MySQL 5.7 / MariaDB 10.1, hosting nalicza opłatę za utrzymywanie wycofanych wersji oprogramowania serwerowego. Alternatywą jest przełączenie na nowsze wersje, ale wtedy strona oparta na starym kodzie przestaje działać. Dla właściciela firmy wygląda to jak pat — płać za stare środowisko albo ryzykuj awarię.

Tło techniczne: dlaczego DuoCMS nie działa po zmianie PHP

DuoCMS to autorski system zarządzania treścią rozwijany w latach 2012–2022, zbudowany na frameworku CodeIgniter 3.1.5, PHP 5.x/7.x i MySQL 5.7 / MariaDB 10.1. W szczytowym okresie powstało na nim kilkadziesiąt stron firmowych i sklepów internetowych.

Problem polega na tym, że PHP 8.0 wprowadził dziesiątki zmian łamiących wsteczną kompatybilność, a PHP 8.2 jeszcze więcej. Kod, który działał na PHP 7.4 bez ostrzeżeń, na PHP 8.x generuje błędy krytyczne i strona wyświetla białą stronę lub komunikaty o błędach.

Typowe problemy, które napotykamy przy każdej instalacji DuoCMS po przełączeniu na PHP 8.x:

• Inicjalizacja sesji — stary kod session_set_cookie_params() z pozycyjnymi parametrami powoduje TypeError na PHP 8.2. Wymaga przepisania na składnię tablicową z parametrami samesite, httponly, secure.
• Null safety — PHP 8.1 rzuca TypeError gdy do funkcji strlen(), strtolower(), strip_tags(), htmlentities(), preg_replace() trafi null zamiast stringa. W typowej instalacji DuoCMS takich miejsc jest 15–30, rozrzuconych po helperach i kontrolerach.
• Stała LANG bez guardu — define('LANG', ...) wywoływane wielokrotnie (np. przy ładowaniu kontrolera) na PHP 8.0 rzuca fatal error zamiast dawnego warning.
• Dynamiczne właściwości — PHP 8.2 deprecjonuje tworzenie właściwości „w locie” (dynamic properties). Model CustomElementModel i inne modele korzystają z tego mechanizmu. Framework CI 3.1.5 sam generuje te ostrzeżenia przy ładowaniu każdego modelu.
• Literówki w nazwach zmiennych — np. $ci->sesssion (trzy „s”) zamiast $ci->session w helperach. PHP 7 po cichu tworzył nową pustą właściwość, PHP 8.1 rzuca Undefined property warning, a w trybie strict — fatal error.
• CAPTCHA z dynamicznymi zmiennymi — konstrukcje $$key w captcha_helper.php generują ostrzeżenia o niezdefiniowanych zmiennych.
• Walidacja reCAPTCHA — odwołanie do $res['success'] bez sprawdzenia czy odpowiedź API w ogóle zwróciła tablicę.
• Framework CI 3.1.5 — sam silnik CodeIgniter w wersji 3.1.5 zawiera dziesiątki niekompatybilności z PHP 8.x. Dopiero wersja 3.1.13 (ostatnia stabilna) ma oficjalne wsparcie dla PHP 8.1.

Do tego dochodzą problemy z bazą danych:

• MySQL 8.0 zmienia domyślny collation na utf8mb4_0900_ai_ci — tabele ze starym utf8_general_ci lub latin2_general_ci mogą generować błędy porównań i sortowania.
• Persistent connections (pconnect = TRUE w konfiguracji CI) źle współpracują z MySQL 8.0.
• Plik routes.php z bezpośrednim połączeniem mysqli — wiele instalacji DuoCMS buduje routing dynamicznie, odpytując bazę poza frameworkiem. Przy zmianie wersji MySQL brakuje set_charset('utf8mb4'), co powoduje problemy z polskimi znakami.
• Konwersja collation — w zależności od instalacji, tabele duo_* mogą mieć mieszane kodowania (utf8, latin2, utf8mb4). Każdą tabelę trzeba zweryfikować i skonwertować indywidualnie, bo błędna konwersja oznacza utratę polskich znaków.

Dlaczego to zajmuje programiście 4–8 godzin

Na pierwszy rzut oka wydaje się, że „wystarczy zaktualizować kilka plików”. W praktyce wygląda to inaczej.

Faza 1: Diagnostyka (1–2h)

Każda instalacja DuoCMS jest nieco inna — inny zestaw helperów, inne moduły (sklep, galeria, formularze, newsletter), inny routing. Nie ma jednego uniwersalnego patcha. Programista musi przeanalizować pliki konfiguracyjne (autoload.php, config.php, database.php, routes.php), kontrolery bazowe (MY_Controller.php, Frontend_Controller.php), wszystkie helpery (zwykle 4–6 plików) i modele autoładowane przy starcie aplikacji. W przypadku bardziej rozbudowanych instalacji lista plików do analizy przekracza 10 pozycji.

Nie da się tego zrobić automatycznie — skrypt diagnostyczny wykrywa wzorce składniowe, ale nie znajdzie problemów logicznych typu „ta funkcja zwraca null z bazy, a tamta oczekuje stringa”. Takie błędy ujawniają się dopiero przy testach na żywym środowisku.

Faza 2: Aktualizacja frameworka i łatki w kodzie (2–4h)

Podmiana folderu system/ na CI 3.1.13 to krok mechaniczny, ale sam w sobie niewystarczający — trzeba jeszcze zweryfikować, czy modele klienta są kompatybilne z nową wersją (np. brak konstruktora w CI_Model w starym CI powoduje fatal error we wszystkich modelach z parent::__construct()). W jednej z realizacji musieliśmy dodać pusty konstruktor do CI_Model, bo 44 modele wywoływały parent::__construct().

Następnie łatki w 7–10 plikach aplikacji — każda zmiana wymaga zrozumienia kontekstu (co zwraca dana funkcja, skąd przychodzą dane, jakie są warunki brzegowe). Łatka typu „dodaj ?? '' do strip_tags()” jest trywialna, ale w functions_helper.php takich miejsc jest 15+, a każde wymaga indywidualnej oceny, czy null to prawidłowy stan czy ukryty bug.

Faza 3: Migracja bazy danych (0.5–1.5h)

Na nazwa.pl istnieje narzędzie do automatycznej migracji bazy. Na home.pl — nie ma, więc programista musi ręcznie: utworzyć nową bazę MySQL 8.0, wyeksportować starą, zaimportować do nowej, uruchomić konwersję collation na każdej z tabel duo_*. W jednej realizacji było to 73 tabele do konwersji. Dodatkowo trzeba zaktualizować konfigurację w database.php i — jeśli istnieje — bezpośrednie połączenie mysqli w routes.php.

Faza 4: Testy i iteracyjne naprawy (0.5–1.5h)

Po przełączeniu PHP w panelu hostingu zaczynają się testy: frontend, panel CMS, edycja treści, upload plików, formularze kontaktowe, koszyk (jeśli jest sklep), generowanie maili, polskie znaki. Na tym etapie regularnie wychodzą problemy, których nie dało się przewidzieć na etapie analizy kodu — np. edytor CKEditor/KCFinder generujący błędy pod PHP 8.x, konfiguracja SMTP wymagająca jawnego smtp_crypto = 'tls' na nowym serwerze, czy niezdefiniowane stałe EMAIL_FROM / EMAIL_TO w formularzach.

To jest powód, dla którego migracja typowej instalacji DuoCMS to 4–8 godzin pracy programisty, a nie „15 minut na podmianę plików”.

Case study 1 — firma handlowa, okolice Tarnowa (nazwa.pl)

Sytuacja wyjściowa: Strona firmowa + formularze zapytań na DuoCMS. Hosting nazwa.pl, PHP 7.x, MariaDB 10.1. Na proformie pojawiły się pozycje „Obsługa starszych wersji PHP” i „Obsługa starszych wersji serwerów baz danych”.

Przebieg: Hosting nazwa.pl automatycznie przełączył PHP na 8.1 — strona przestała działać. Pierwszym problemem okazał się nie kod, a baza danych: nazwa.pl zablokowała MariaDB 10.1 (EOL od 2019) i zresetowała uprawnienia użytkownika. Dopiero po migracji bazy MariaDB 10.1 → 11.4 i przywróceniu uprawnień ujawniły się właściwe błędy PHP 8 — crashująca inicjalizacja sesji, literówka $ci->sesssion w helperze, niekompatybilność modelu CustomElementModel.

Zakres: Diagnostyka, migracja bazy, aktualizacja 3 plików aplikacji. Łącznie ~3.5h.

Efekt: Strona działa na PHP 8.1 + MariaDB 11.4. Pozycje za „obsługę starszych wersji” stały się zbędne.

Case study 2 — sklep B2B z maszynami, okolice Tarnowa (nazwa.pl)

Sytuacja wyjściowa: Sklep internetowy B2B na DuoCMS z rozszerzeniem sklepowym. Hosting nazwa.pl, PHP 7.x, MariaDB 10.1. Te same dodatkowe pozycje na proformie.

Przebieg: Analogiczny problem do case study 1 — baza wymagała migracji, kod łatek PHP 8.x. Zakres zbliżony — sklep korzystał z tych samych helperów bazowych, ale dodatkowo wymagał weryfikacji ścieżek sklepowych (koszyk, zamówienia, produkty).

Zakres: Diagnostyka, migracja bazy, aktualizacja kodu. Łącznie ~3h.

Efekt: Sklep działa na aktualnym środowisku. Brak dodatkowych opłat za stare wersje.

Case study 3 — placówka edukacyjna z Tarnowa (home.pl)

Sytuacja wyjściowa: Strona instytucji edukacyjnej prowadzącej trzy jednostki. DuoCMS z rozbudowanym routingiem dynamicznym (aktualności, galeria, podstrony szkół). Hosting home.pl, PHP 7.4, MySQL 5.7. Na proformie dwie pozycje: „Wsparcie obsługi starszych wersji PHP” i „Obsługa starszych wersji MySQL 5.7″.

Przebieg: Ten case okazał się najobszerniejszy. Plik routes.php zawierał bezpośrednie połączenie mysqli do bazy — 5 zapytań SQL budujących routing z tabel duo_news_translations, duo_pages_translations, duo_gallery_translations, duo_products_translations, duo_offer_categories_translations. Każde zapytanie wymagało zabezpieczenia null safety na wyniku ($result && $result->num_rows > 0) i dodania set_charset('utf8mb4'). Framework CI 3.1.5 wymagał podmiany na 3.1.13 plus dodanie pustego konstruktora do CI_Model (44 modele z parent::__construct()). Do tego functions_helper.php z 15+ miejscami wymagającymi null safety, captcha_helper.php z dynamicznymi zmiennymi, MY_Controller.php z guardem na define() i walidacją reCAPTCHA.

Baza MySQL 5.7 na home.pl nie miała automatycznego narzędzia konwersji jak nazwa.pl. Trzeba było: utworzyć nową bazę MySQL 8.0, wyeksportować starą, zaimportować, uruchomić konwersję collation na 73 tabelach duo_* (mieszanka utf8_general_ci i latin2_general_ci). Po konwersji — weryfikacja polskich znaków we wszystkich tabelach translacji.

Dodatkowo na etapie testów okazało się, że PHP 8.2 generuje E_DEPRECATED na dynamic properties z core CI 3 (CI_Loader::$MenuModel is deprecated). Na produkcji te ostrzeżenia są wyciszone, ale wymagały weryfikacji, że nie blokują działania.

Zakres: 10 plików do modyfikacji, podmiana frameworka, ręczna konwersja 73 tabel bazy, testy na PHP 8.2. Łącznie ~6h.

Efekt: Strona działa na PHP 8.2 + MySQL 8.0. Panel CMS, edycja treści, upload plików, polskie znaki — wszystko sprawne. Proforma za utrzymanie starszych wersji anulowana.

Case study 4 — sklep z wyposażeniem łazienek, Dąbrowa Tarnowska

Sytuacja wyjściowa: Sklep internetowy na DuoCMS z integracją PayU i Przelewy24. Migracja na nowy serwer z jednoczesnym podnoszeniem wersji PHP i bazy.

Przebieg: Oprócz standardowych łatek PHP 8.x i migracji bazy pojawił się dodatkowy problem — konfiguracja poczty SMTP. Na starym serwerze maile zamówień wysyłały się przez port 25 bez szyfrowania. Nowy serwer wymagał portu 587 z TLS. Bez jawnego smtp_crypto = 'tls' w konfiguracji CodeIgniter maile zamówień i formularzy po prostu nie wychodziły — bez żadnego komunikatu błędu. Debugowanie wymagało napisania skryptu diagnostycznego, weryfikacji stałych EMAIL_FROM / EMAIL_TO (niezdefiniowane w constants.php), a na koniec dodania brakujących kluczy do tabeli duo_options w bazie.

Zakres: Migracja, łatki PHP, konfiguracja SMTP, diagnostyka poczty. Łącznie ~5h.

Efekt: Sklep w pełni operacyjny — zamówienia, płatności, maile. Bez opłat za stare wersje.

Co z tego wynika

Jeśli na fakturze lub proformie z nazwa.pl albo home.pl widzisz pozycje typu „Obsługa starszych wersji PHP” czy „Obsługa starszych wersji MySQL 5.7″, to Twoja strona działa na wycofanych wersjach oprogramowania. Hosting proponuje Ci tymczasowe podtrzymywanie tego stanu za dodatkową opłatą — co rok.

Każdy z opisanych przypadków pokazuje, że zamiast płacić za utrzymywanie staroci, można raz wykonać migrację kodu i bazy na aktualne wersje. Jest to pełnoprawna usługa programistyczna wymagająca analizy kodu, łatek kompatybilności, migracji bazy danych i testów — dlatego zajmuje 4–8 godzin pracy w zależności od rozbudowania instalacji.

Po migracji strona działa na domyślnych, wspieranych wersjach PHP i MySQL/MariaDB. Dodatkowe opłaty hostingowe za „obsługę starszych wersji” stają się zbędne, a sama aplikacja jest przygotowana na kolejne aktualizacje środowiska serwerowego.

Co możesz zrobić

1. Wejdź do panelu nazwa.pl lub home.pl i sprawdź wersję PHP i bazy danych.
2. Sprawdź proformę — czy widzisz pozycje „Obsługa starszych wersji PHP/MySQL”.
3. Jeśli tak — skontaktuj się z nami. Wykonamy audyt Twojej instalacji DuoCMS i wycenimy migrację. Jednorazowy koszt modernizacji jest porównywalny z 1–2-letnimi opłatami za utrzymywanie starego środowiska.

AURANET — Jan Schenk | Migracje DuoCMS, WordPress, WooCommerce