2011-02-04 13 views
14

Musimy przenieść około 50+ aplikacji (małych/dużych) do PHP 5.3 (z PHP 4.1). Czy niektórzy mają jakieś doświadczenie z takim zadaniem?Twoje doświadczenie Przeniesienie PHP 4 na PHP 5

  • Czas potrzebny
  • Narzędzia
  • najlepszych ustawień dla środowiska (Serwery/Test?)

Czy jest sens, aby przejść pierwszy PHP 5.2? Czy istnieje sposób automatycznego wykrywania aplikacji za pomocą "Funkcji PHP 4", które nie działają w PHP 5?

Nie mam pojęcia, jak sobie z tym poradzić. Dzięki!

+3

Erm .... powodzenia. – sevenseacat

Odpowiedz

6
  1. Niektóre składni dla klas zmieniła między PHP4 i PHP5 - na przykład w PHP4, metoda konstruktor został nazwany tak samo jak klasy, natomiast w PHP5, konstruktor nazywa __construct().

    PHP5 może nadal radzić sobie z definicjami klasy w stylu PHP4, więc Twój kod prawdopodobnie nadal będzie działał, ale mimo wszystko dobrze byłoby zmienić go na nowy, ponieważ jest wiele funkcji, których nie będziesz musiał. w stanie użyć inaczej. Ponadto, oczywiście, stara składnia zostanie ostatecznie usunięta; Twoje klasy PHP4 będą pękać w przyszłości, więc lepiej je teraz zmienić zamiast czekać, aż będzie to pilne.

  2. Globals. Powinieneś już używać $_REQUEST, $_POST, $_GET i $_COOKIES w PHP4, wiele starszych kodów wciąż może używać starego stylu auto-globals, który był standardem PHP3. Jest to ogromne zagrożenie dla bezpieczeństwa, więc jeśli nadal używasz register_globals, powinieneś zacząć pracę nad swoim kodem, aby zamiast tego używać co najmniej $_REQUEST w każdym miejscu, w którym korzystałeś z automatycznej globalizacji. Może to w rzeczywistości być bardzo trudnym zadaniem - może być trudno prześlizgnąć się przez dużą aplikację, próbując ustalić, które zmienne mają być globalne, a które nie, gdy w kodzie nie ma nic, co wskazywałoby w taki czy inny sposób. . Weź to od kogoś, kto musiał to zrobić, może to być prawdziwy koszmar. Ale to nie jest specyficzne, aby przejść do PHP5 - jak już powiedziałem, nawet jeśli trzymasz się PHP4, naprawdę musisz poradzić sobie z tym problemem. PHP5 niczego nie zmienia, poza tym, że flaga register_globals jest teraz domyślnie wyłączona, co może dać ci nieco więcej impetu do wykonania tej pracy.

  3. Jeśli używasz funkcji wyrażeń regularnych ereg_, zostały one wycofane. Należy zastąpić je odpowiednikami funkcji preg_. Nie jest to duże zadanie, a w rzeczywistości funkcje są nadal dostępne, więc może czekać, o ile jesteś gotowy ignorować ostrzeżenia informujące, że funkcja jest przestarzała. Ale znowu, podobnie jak w przypadku składni klas, może być rozsądne rozważenie zmiany ich teraz.

  4. Kolejną zmienioną funkcją, w której starą składnię uznano za przestarzałą, jest przekazywanie.W PHP4 zachęcono nas do używania znaku & w wywołaniu funkcji do przekazywania zmiennych przez referencję. W PHP5 poprawnym sposobem jest umieszczenie znaku & w deklaracji funkcji, a nie w miejscu, w którym ją wywołujesz. Znowu stara składnia nadal działa, ale tylko wtedy, gdy możesz znosić napisy PHP wyświetlające ostrzeżenia w każdym miejscu.

+0

To __construct, a nie __constructor. Warto również wspomnieć, że bardzo stare superglobalne ($ HTTP_POST_VARS, itp.) Były przestarzałe w PHP 4 (na korzyść $ _POST, itp.) I nie sądzę, że one już istnieją w PHP 5. –

+0

@ Daniel15 - oops w '__construct()'; dzięki za spostrzeżenie, zredagowałem odpowiedź. Re stare superglobale - one wciąż istnieją; przestarzałe, ale wciąż na razie. Jednak nie są one superglobalami, więc nie są tak funkcjonalne jak '$ _POST' itd. Zostaną usunięte w pewnym momencie w przyszłości, więc nie jest to dobry pomysł na ich wykorzystanie. – Spudley

3

Jeśli włączysz error_reporting i ustawisz na E_ALL, powinieneś być w stanie zobaczyć przestarzałe błędy itp. Nie zawracałbym sobie głowy kierowaniem na PHP5.2, a następnie 5.3.

Zależy, czy chcesz, aby aplikacje działały, czy też chcesz korzystać z nowych funkcji PHP i poprawy wydajności. Jeśli po prostu muszą działać, napraw błędy i zignoruj ​​ostrzeżenia.

Jeśli projekty zostały napisane w przyzwoity sposób, to nie powinno być zbyt trudno je zaktualizować.

To nie znaczy, że nie będzie to strasznie nudna i żmudna praca. Zajmie to również znacznie dłużej, niż się spodziewasz; w szczególności dla 50 aplikacji!

11

Najważniejszą rzeczą do przeczytania będzie the php.net section on migrating from PHP 4 to PHP 5. Odkąd PHP 5 pojawił się po raz pierwszy, zmierzają one w stronę bardziej rygorystycznego języka (domyślnie PHP będzie w trybie ścisłym w wersji 6), więc powinieneś spodziewać się ostrzeżenia o błędach, a nie lot.

Było więcej wstecznie kompatybilność przełomowe zmiany wprowadzone od PHP 5.0 wyszedł, dla kompletności należy również przeczytać:

Migrating from PHP 5.0.x to PHP 5.1.x

Migrating from PHP 5.1.x to PHP 5.2.x

Migrating from PHP 5.2.x to PHP 5.3.x

Zdaję sobie sprawę, że jest to dużo czytania, ale to powinna być pełna lista wszystkiego, co może się zepsuć.

5

Przede wszystkim należy sprawdzić ustawienia php.ini, szczególnie takie jak register_globals, magic_quotes_gpc - może to złamać logikę twoich aplikacji.

6

PHP_CompatInfo może pomóc w kilku kontrolach zależności. PHP_CodeSniffer może ze znalezieniem przestarzałych konstrukcji.

Różnice między wersjami PHP są jednak często udoskonalone. Nigdy nie miałem problemów z kodem polegającym na przypadkach skrajnych. O ile oczywiście ten kod nadal opiera się na długich superglobach $ HTTP_POST_VARS, to można się spodziewać kilku innych potrzasków.

Pomocne idiom zastąpić zależność magic_quotes na przykład to:

$_POST = array_map("mysql_real_escape_string", $_POST); 

realistycznie Ponieważ większość aplikacji nie są przepisany użyć bardziej współczesne API bazy danych.

3

Wyłącz display_errors, włącz log_errors ustaw error_reporting do -1 i wypatrywać E_STRICT i E_DEPRECATED ostrzeżeń.

This migration script (Bezwstydna wtyczka) może ci pomóc w niektórych zaniechanych rzeczach. Jest napisane od 5.2 do 5.3, ale może być również przydatne przy migracji z 4. Możesz go rozszerzyć (patche mile widziane), ponieważ często odkrywane są rzeczy, które odkrywasz.

PHPStorm IDE ma całkiem przyzwoity analizator kodu, który może wskazać niektóre potencjalne problemy w kodzie. Daj mu bieg przez swoją aplikację i zobacz, czy ma coś ciekawego do powiedzenia. Prawdopodobnie pomoże ci to szybko znaleźć błędy, które mogą wynikać z użycia nowych słów kluczowych jako nazw funkcji itp.

Dla twojego ostatniego pytania: IMHO powinieneś pójść z 5.3, wykonanie tej pracy dwa razy nie ma sensu.

+0

Idealnie powinno być wyłączone 'display_errors' w zakładzie produkcyjnym. – Spudley

+0

@ Teoretycznie, teoretycznie, tak, ale byłbyś zaskoczony, jak wiele narzekań, jak "E_STRICT zepsuł mój serwer produkcyjny", słyszałem. Ludzie ignorują tę radę, jakby nie było jutra. – StasM