Czy mając na serwerze php 7.4 będzie obsługiwany kod w php 5.6 ?

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.:

1. Było użyte mysql zamiast mysqli.
2. Projekt używał composera, w którym było trzeba zmienić constraint na php z wersją wyższą, np. ~7.2.
3. 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.
4. 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.