+48 501 250 220

Frontend w jQuery i Smarty wymieniamy krok po kroku

Państwa frontend opiera się na jQuery 1.x lub 2.x i na szablonach Smarty, których nikt nie chce dotykać? Odnawiamy go obszar po obszarze obok działającego systemu i testujemy po każdym kroku. Gałęzi 1.x i 2.x projekt jQuery już nie wspiera (stan: 2026-10).

Zamów przegląd systemu legacy JavaScript i TypeScript w skrócie
  • PHP, Smarty i Slim od 2012 r.
  • Full stack od 2012 r., frontend i backend
  • Odpowiedź w ciągu jednego dnia roboczego
Po lewej stos cienkich warstw pełnych splątanych, poskręcanych linii, po prawej cztery czyste bloki jeden nad drugim, połączone krótkimi pomarańczowymi liniami

Po czym poznać przestarzały frontend

Frontend opiera się na jQuery 1.x lub 2.x

Od lat nikt nie aktualizował jQuery, bo zależą od niego wtyczki, których nikt już nie rozwija. Projekt jQuery wspiera tylko aktualną wersję: gałęzie 1.x i 2.x nie dostają już aktualizacji, 3.x tylko krytyczne poprawki bezpieczeństwa, a aktualna jest 4.x (stan: 2026-10, jquery.com (otwiera się w nowym oknie)).

Szablony Smarty trzymają stare wersje

Własne wtyczki i bloki {php} w szablonach sprawiają, że każda aktualizacja Smarty i PHP staje się ryzykiem. Smarty 2 i 3 nie dostają już poprawek bezpieczeństwa (stan: 2026-10, projekt Smarty (otwiera się w nowym oknie)). Jeśli czeka Państwa aktualizacja PHP, warto przeczytać też stronę Aktualizacja do PHP 8.

Każda mała zmiana trwa dni

Skrypty tkwią bezpośrednio w szablonach, biblioteki są dołączone podwójnie, a nowa funkcja psuje starą stronę. Wtedy każda zmiana kosztuje więcej czasu, niż powinna.

Okno przeglądarki, w którym cztery bloki treści łączy plątanina cienkich linii; pod nim wiszą trzy stare wtyczki, jedna z pomarańczowym konturem

Tak wymieniamy frontend: obszar po obszarze, każdy z pisemnym wynikiem

  1. Inwentarz frontendu

    Spisujemy wersje jQuery i Smarty, wtyczki, własne rozszerzenia Smarty, bloki {php} i skrypty w szablonach. Do tego strony i formularze, które są używane najczęściej albo niosą największe ryzyko. Inwentarz otrzymują Państwo na piśmie.

  2. Przypadki testowe przed każdą zmianą

    Dla krytycznych procesów, na przykład formularzy, logowania i wyszukiwania, tworzymy przypadki testowe. Dzięki nim po każdym kroku widać, czy wszystko działa jak wcześniej.

  3. Aktualizacja tam, gdzie wystarczy

    Gdzie wystarczy aktualizacja, podnosimy jQuery i Smarty do wspieranych wersji i wymieniamy wtyczki, których nikt już nie rozwija. Przy okazji porządkujemy szablony.

  4. Wymiana tam, gdzie się opłaca

    Obszary, które często się zmieniają, budujemy od nowa, strona po stronie, obok starych. Backend działa dalej. Jeśli nowy frontend potrzebuje danych, udostępniamy je przez interfejs API.

  5. Przełączenie z drogą powrotu

    Każdy obszar przełączamy osobno, w uzgodnionym z Państwem oknie czasowym. Dopóki nie działa stabilnie, stary stan zostaje jako droga powrotu.

  6. Przekazanie

    Otrzymują Państwo dokumentację nowego stanu i przypadki testowe. Kod jest w Państwa repozytorium.

Zaktualizować, wymieniać etapami czy napisać od nowa?

Kryterium Aktualizacja jQuery i Smarty Stopniowa wymiana frontendu Nowy frontend od zera
Pasuje, gdy Aplikacja będzie działać jeszcze kilka lat, ale rzadko się zmienia. Chodzi przede wszystkim o wspierane wersje. Poszczególne obszary często się zmieniają lub mają dostać nowe funkcje, a backend jest solidny. Backend i tak jest odnawiany albo starego frontendu nie da się już sensownie zaktualizować.
Czego nie rozwiązuje Nieczytelny kod w szablonach zostaje, działa tylko na wspieranych wersjach. Przez pewien czas stare i nowe strony działają obok siebie i obie wymagają utrzymania. Do czasu przełączenia istnieją dwa frontendy, a zachowanie, którego nikt nie zapisał, łatwo się gubi.

Czego nie obiecujemy

  • Nowy frontend nie czyni bezpiecznym niezabezpieczonego backendu. Luki w kodzie serwera zamykamy jako osobne zadanie.
  • To, że wygląd i obsługa pozostają takie same, przypadki testowe potwierdzają tylko dla sprawdzonych procesów.
  • Aktualizacja jQuery i Smarty nie zmienia wyglądu. Jeśli interfejs ma wyglądać inaczej, planujemy to jako osobny krok.
  • Nakład pracy podajemy dopiero wtedy, gdy inwentarz jest gotowy.
Rama z trzema prostokątami oznaczającymi to, co wchodzi w zakres; poza nią przerywany prostokąt na to, czego nie obejmuje; odcinek ramy między nimi jest pomarańczowy

Doświadczenie naszych inżynierów z frontendami i stosem za nimi

jQuery
Rozbudowywane latami aplikacje, aktualizacja do wspieranych wersji
Nowy stos
React, Next.js i TypeScript na Node.js, także jako nowy frontend do istniejącego backendu
Serwery i bazy danych
Linux, Docker, MySQL i MariaDB

Jak zaczynamy pracę nad frontendem

  • Kod, dane dostępowe i dokumentacja zostają u Państwa.
  • Obszar trafia na produkcję dopiero po Państwa akceptacji.
  • Mówimy też wprost, gdy wymiana się nie opłaca, na przykład dlatego, że aplikacja wkrótce zostanie zastąpiona.

A co, jeśli u nas ktoś będzie niedostępny? Dokumentację sporządzamy na życzenie. Repozytorium z reguły znajduje się u Państwa. Zastępstwo organizujemy na życzenie.

Wymiana frontendu należy do naszej usługi Migracja i modernizacja.

Po lewej kartka z wierszami tekstu i linią podpisu z pomarańczowym haczykiem; strzałka wskazuje serwer narysowany przerywaną linią po prawej

Pierwszy krok: przegląd systemu legacy z wersjami jQuery i Smarty

Przegląd systemu legacy

Dla firm z systemem, którego nikt już dokładnie nie zna: przed aktualizacją, przed migracją lub przy zmianie dostawcy.

  • Inwentarz wersji i zależności
  • Mapa aplikacji, bazy danych, serwera i poczty e-mail
  • Rejestr ryzyk dotyczących bezpieczeństwa, wsparcia i wiedzy
  • Ocena kopii zapasowych i odtwarzania danych
  • Rekomendacja „zostać przy obecnej wersji, podnieść wersję lub migrować” z macierzą opcji, która obejmuje także „przeniesienie do kontenera” i „udostępnienie jako API”
  • Oszacowanie nakładu pracy w dniach

Cena obejmuje jeden system, czyli jedną aplikację wraz z jej bazą danych i serwerem. Kolejne systemy wyceniamy osobno.

Co zawiera wynik

Pisemny raport z inwentaryzacją, rejestrem ryzyk, rekomendacją i oszacowaniem nakładu pracy. Raport należy do Państwa.

od 3 800 € netto

Zwykle 5 dni roboczych

Zamów przegląd systemu legacy

Przypadek z naszej pracy

  • Telefon z kodem QR, plik podzielony na porcje, trzy równoległe strumienie do serwera z dyskiem i siatka galerii

    Aplikacja do zbierania zdjęć od gości weselnych

    Goście weselni skanują kod QR, otwierają jeden sekretny adres i wysyłają zdjęcia oraz filmy prosto z telefonu: bez aplikacji, bez konta, bez logowania. Pliki do 5 GB lądują na dysku klienta, a para młoda ogląda galerię, która zapełnia się jeszcze w trakcie przyjęcia. Jeden wieczór, bez drugiej szansy, i telefony sprzed sześciu lat.

Pytania o wymianę jQuery i Smarty

Czy wystarczy podnieść jQuery do aktualnej wersji?

Często to pierwszy krok. Wtyczka jQuery Migrate zgłasza przestarzałe wywołania, które potem zastępujemy jedno po drugim. Najwięcej pracy wymagają wtyczki: niektóre nie są już rozwijane i nie działają z nowymi wersjami jQuery, wtedy je wymieniamy.

Czy aktualizacja wystarczy, czy poszczególne obszary lepiej zbudować od nowa, pokazuje inwentarz frontendu.

Czy nasze szablony Smarty działają w PHP 8?

Ze Smarty 5 tak: według projektu Smarty ta wersja działa z PHP od 7.2 do 8.5 (stan: 2026-10). Projekt utrzymuje tylko najnowszą wersję poboczną Smarty 4 i Smarty 5, starszych wersji już nie.

Przy przejściu na Smarty 5 pracy wymagają przede wszystkim własne wtyczki, bloki {php} i funkcje PHP w szablonach. Ujmujemy to w inwentarzu, zanim cokolwiek zmienimy.

Czy musimy przejść na Reacta lub inny framework?

Nie. Framework opłaca się, gdy frontend jest rozwijany latami, a wiele obszarów ma działać bez przeładowania strony. Aplikacji, która rzadko się zmienia, często wystarczą wspierane wersje jQuery i Smarty oraz uporządkowane szablony.

Jaka technologia pasuje do Państwa systemu, ustalamy razem z Państwem, gdy inwentarz jest gotowy. Zmianę zalecamy tylko wtedy, gdy się Państwu opłaca.

Czy musimy przepisać system, żeby korzystać z nowego stosu technologicznego?

Nie. Jeśli stary system działa, udostępniamy jego logikę jako API i jednorazowo zamykamy znane luki. Funkcje mają przy tym pozostać bez zmian, co sprawdzają testy porównawcze. Nowe elementy budujemy obok, w nowym stosie, który korzysta z tego API.

Przepisanie od nowa rzadko się opłaca. Wchodzi w grę, gdy framework nie jest już rozwijany, brakuje testów, a reguły biznesowe da się spisać. Czy dotyczy to Państwa systemu, wyjaśnia Przegląd systemu legacy.

Kiedy mogą Państwo zacząć?

Pierwszą odpowiedź otrzymają Państwo w ciągu jednego dnia roboczego. Kiedy zaczniemy pracę, zależy od bieżącego obłożenia i od zakresu. Powiemy to Państwu wiążąco podczas rozmowy wstępnej. Jeśli sprawa jest pilna, Ocena awaryjna w 48 godzin rozpoczyna się z chwilą, gdy uzyskamy dostęp do systemu.

Jaka jest Państwa stawka godzinowa?

To zależy od zakresu, modelu współpracy i pilności. Prosimy krótko opisać Państwa sytuację, a po rozmowie otrzymają Państwo ofertę. Nie trzeba przy tym podawać budżetu. Stałe ceny podajemy przy produktach wejściowych.

Który frontend ma zostać odnowiony?

Wystarczy podać, jeśli są znane, wersje jQuery, Smarty i PHP oraz powód zmiany. Odpowiadamy w ciągu jednego dnia roboczego i proponujemy odpowiedni pierwszy krok.

Pola oznaczone jako „opcjonalnie” można zostawić puste.

Kontakt e-mailowy

Do kontaktu telefonicznego wystarczy numer: awarie całą dobę, w pozostałych sprawach w ciągu jednego dnia roboczego.

Jaki system, jaka technologia, co chcą Państwo osiągnąć? Prosimy nie przesyłać haseł ani poufnych dokumentów.

Odpowiedź w ciągu jednego dnia roboczego · bez zobowiązań

Wykorzystujemy Państwa dane wyłącznie do odpowiedzi na zapytanie. Prownex IT Services Sp. z o. o. jest administratorem danych. Okres przechowywania i Państwa prawa opisano w polityce prywatności.