Czy mając na serwerze php 7.4 będzie obsługiwany kod w php 5.6 ? Dzięki za pomoc.
Nie będzie musisz mieć zainstalowane paczki w wersji 5.6
Oczywiście, że będzie. No chyba, że jakaś funkcja została zażegnana w wersji 7++. https://stackoverflow.com/a/54471175/3238517
Pan powyżej wprowadza Cię w błąd.
@Michał Domarecki Jak masz tak pisać to lepiej się nie udzielaj.
@adamon od 5.6 do 7.4 zostało usuniętych część rzeczy, bardzo często kod nie wymaga żadnych zmian, najczęściej jeśli już to zdarza się, brak kompatybilności na poziomie biblioteki szyfrującej (usunięto mcrypt w 7.1) Jeśli posiadasz php storma to możesz sobie przełączyć na odpowiednią wersje i wylistować wszystkie błędy niekompatybilności o ile jakiekolwiek masz.
Jakiś czas temu walczyliśmy z poleceniem '''mysql ()'''
Zobacz dokumentację https://www.php.net/manual/en/intro.mysql.php
I opis w niej:
."This extension is deprecated as of PHP 5.5.0, and has been removed as of PHP 7.0.0." .
Jest to przykład usunięcia funkcji między wersjami języka.
Przez dwie pośrednie wersje była informacja o tym, że funkcja będzie wycofana, aż w końcu została wycofana.
Resztę dobrze opisali @mr_jaro i @MexikanoS.
Niestety to nie takie proste, bo jak ktoś kiedyś zasiądzie albo jeszcze pracuje na jakimkolwiek projekcie (o ile jeszcze takie są ale są na pewno) na takiej Kohanie 3.2/3.3 a ma na serwerze PHP 5.x to przy aktualizacji wersji PHP z 5.x na 7.x może się dość mocno rozczarować (zwłaszcza jeśli to się stanie bez jego wiedzy :) ). Powiem więcej, już sama aktualizacja wersji PHP z 7.1 na 7.2 może być w pewnych przypadkach problemem (z powodu pewnej zmiany nie działało mi np. logowanie ale szybko się z tym uporałem). Podobnie może być na jakichś własnych autorskich rozwiązaniach. Nie każdy pracuje na nowoczesnych i w pełni przystosowanych do takich zmian frameworkach. Z niektórymi bibliotekami też wcale nie musi być tak różowo, np. do generowania PDF.
mr_jaro napisał(a):
@Michał Domarecki Jak masz tak pisać to lepiej się nie udzielaj.
@adamon od 5.6 do 7.4 zostało usuniętych część rzeczy, bardzo często kod nie wymaga żadnych zmian, najczęściej jeśli już to zdarza się, brak kompatybilności na poziomie biblioteki szyfrującej (usunięto mcrypt w 7.1) Jeśli posiadasz php storma to możesz sobie przełączyć na odpowiednią wersje i wylistować wszystkie błędy niekompatybilności o ile jakiekolwiek masz.
odpal dowolną bibliotekę napisaną w 5.6 pod 7.2 zobaczysz jaki procent działa...
@Michał Domarecki Przenosiłem niedawno system z 5,6 na 7.3 i nie było żadnego problemu, oprócz zmian w systemie szyfrowania ;)
to ja próbowałem przenieść duży serwis z 7.0 na 7.1 i było bardzo dużo problemów w efekcie serwis został przepisany. Wszystko zależy od konstrukcji ale przeniesienie z 5.6 na 7.4 może powodować wielkie problemy.
@Michał Domarecki omg... serio? To co wy tam za syf piszecie, przecież to jest nierealne przy tej drobnicy zmian, która jest między wersjami, a pomiędzy 7.0 a 7.1 to usunięto naprawde tyle co nic https://www.php.net/manual/en/migration71.deprecated.php :D Rozumiem, że pisaliście jakiś serwis przez parę miesięcy na nowo tylko dlatego, że była zmiana jednej małej wersji php? Nie no rozbawiłeś mnie dziś :D :D :D
@Michał Domarecki: No ale taki Zend został napisany w PHP z użyciem jakiejś wersji tego języka z użyciem w danym czasie dostępnych funkcji i standardów. Nie mylmy pojęć. Sam kod napisany w natywnym PHP bez użycia wycofanych funkcji będzie działał. Czym różni się
echo 'abc';
w PHP 7 a w PHP 5.X? A to, że do nowej wersji języka trzeba by dostosować starsze wersje jakiegoś oprogramowania to co innego. Twoja pierwsza odpowiedź ni jak ma się do tematu. Kto mówi, że autor używa jakiegoś framework`a czy jakiejś paczki?
@jurek1980 generalnie jeśli apka jest utrzymywana to i updaty powinny lecieć do kolejnych wersji lts, więc powinny przechodzić kolejne migracje a nie przepisywanie apki. Bo racją jest, że jak ktoś np robił coś na laravelu 4.2 (2015r) i nagle się obudził, że chce mieć najnowszego php to się robi problem, tylko, że wtedy nie robisz przepisania tylko migracje, która zajmie kilka razy krócej niż przepisywanie.
@mr_jaro: widzę jak jesteś oderwany od rzeczywistości i dużych projektów... w małych utrzymasz w dużych okaże się że z zf1 na zf2 to nie taka prosta migracja a już z zf 1 na zf 3 taniej wychodzi przepisanie... pytanie czy to takie proste dla dużego projektu?
@Michał Domarecki nie, jestem oderwany na całe szczęście od bagna jakim jest zend ;)
Migrowałem parę takich projektów (co prawda niezbyt dużych) i z reguły zawsze było ok. Jeśli coś nie banglało to np.:
- Było użyte
mysql
zamiastmysqli
. - Projekt używał composera, w którym było trzeba zmienić constraint na php z wersją wyższą, np.
~7.2
. - Projekt używał zewnętrznych libek, które nie były kompatybilne z php 7. Tu jest większy problem, jeśli libka nie ma wersji dla nowego php.
- Część rzeczy zaczęło wywalać warningi, to można je wyciszyć.
@jurek1980: W składni to też nie taka prosta sprawa, wystarczy przejrzeć te zmiany:
https://www.php.net/manual/en/migration70.incompatible.php
https://www.php.net/manual/en/migration72.incompatible.php
Zwłaszcza obsługa wyjątków albo działania na określonych typach danych. I to jest to na czym wywali się niejedna nieprzystosowana aplikacja a to przez niekompatybilność wsteczną.
@drorat1 to nadal nie zmienia sprawy, że jeśli ktoś nie odwala maniany w kodzie to problemów nie będzie. Żaden z tych elementów nie sprawiał problemów w tych systemach co migrowałem a migrowałem takie rozwijane latami.
@mr_jaro: Nie trzeba odwalać maniany i wszystko może być w porządku w kodzie a i tak mogą wystąpić różne niespodzianki. Ze dwa razy bez mojej wiedzy dokonano aktualizacji PHP z 5.6 na 7.1 a gdzieś tam z 5.6 na 7.2, tutaj jest problem jeśli działasz na frameworkach zasadniczo przystosowanych do PHP5 a nie masz aktualizacji żeby śmigało pod PHP7 (albo i jest tylko PHP 5.6 zakładałeś). Kolejna sprawa to biblioteki, bo któraś tam do generowania PDF pod PHP 5.6 działała bez problemu a już pod PHP 7 nie działało. Czyli albo pobierasz aktualizację, albo zmieniasz ręcznie. Dlaczego nie utrzymują pełnej kompatybilności wstecznej tylko wymyślają takie rzeczy jak w PHP 7.2 vs 7.1 a chodzi o operacje count($x) gdzie $x może być tablicą albo i nie a wyniki są zupełnie inne?
@drorat1 ależ jeśli ktoś nie aktualizuje frameworka przez kilka lat to sam się prosi o problemy, chociażby bezpieczeństwa w samym frameworku.
Podsumowując. Kod php 5.6 może działać bo samo PHP ma sporą kompatybilność wsteczną. Faktem też jest ze duże systemy w praktyce mają kompatybilność co najwyżej z dwiema wersjami minor czyli np 7.1 i 7.2 bo ilość zależności jest spora. Ogólnie im mniejszy system tym większa szansa, ale jak to coś dużego i działa na 5.6 to raczej na 7.4 nie zadziała. Dziwne jest natomiast, że działa na 5.6 bo to znaczy że to coś nie rozwijanego.