PHP 8.2

Címkék

Megjelent a PHP 8.2-es kiadása. A 8.2 egy "major" kiadás, így benne számos újdonság található. Részletek a bejelentésben.

Hozzászólások

A HUP-on se kommentelnétek a PHP nélkül.

trey @ gépház

ez a kedvenc reszem a bejelentesben:  Deprecations and backward compatibility breaks

Ugyanmár hova rohanni, vannak webfejlesztők akik a mai napig 5 ös verziót kérik, mert a kódjuk azon fut ...

Fedora 38, Thinkpad x280

Hát igen, elterjedése előtt PERL-ben írtunk CGI-t. Ekkor még Slackware-t használtam.
A HTML kódba bárhova beilleszthető    <?php .... ?>   betétek nagyságrendekkel könnyebbé tették a dinamikus oldalak létrehozását.

A Slackware-ben viszonylag későn jelent meg:

   https://quantum-mirror.hu/mirrors/pub/slackware/slackware-8.0/FILELIST… 
   May 19 2001 ./slakware/n1/mod_php.tgz
   (Slackware 8.0 2001-07-01 dátummal lett kiadva.)

Érdekességképpen szintén a Slackware 8.0-ban jelent meg a MySQL is.

De nem volt nehéz, az ncurses alapú x-elgetőse elég kézenfekvő volt, vagy csak megszoktam. Debian érdekes, hogy sokkal később jelent meg a köreinkben, holott a Slackwarrel közel egyidőben indult.
Okát nem tudom megmondani. Lehet hogy csak nem kerestünk mást. Aztán egyszercsak bejött a SuSE és a Debian is a képbe. Ez kb. 1999 körül lehetett.

Visszagondolva a PHP+MySQL tényleg nagy technológiai robbanást hozott az ezredforduló környékétől. Addig a weblapok túlnyomó része statikus volt. Ellenben kevés energia kellett a kiszolgálásához.

Úgy hiányzott, mint egy falat kenyér!

Most, hogy kezd egy-két nagyobb projekt rendes, működő PHP 8.1 támogatással jönni, itt volt az ideje fejleszteni és újra megborítani az egészet... Most mi, üzemeltetők izgulhatunk, hogy a 8.1 lesz előbb EoL vagy 8.2 támogatás jön meg a használt rendszerekbe. User kódokról ne is beszéljünk, mikor a mai napig vannak 5.2-5.6 kódok élő adásban...

Szerintem érdemes lenne a PHP nyelv fejlesztőinek bevárni a világot kicsit...
Esetleg alaposabban megtervezni a fejlődés irányát, jobban kidolgozni, több energiát tenni a visszafelé kompatibilitásba, nem ad-hoc hozzádobni meg kivenni dolgokat.

Remélem az OAuth2/Modern Auth is megy a kukába valami új verzió által (amiben kapásból obsolote lesz minden a mostaniból), így, hogy elkezdik végre többen támogatni, és elszakadnak lassan az user/pass korláttól...

Nehéz dolguk van a PHP nyelv fejlesztőinek. Megy a hibáztatás, ha nem tud valamit a nyelv , amikor meg tud, akkor meg az baj. 

Jelenleg "sok" munkát ad a PHP nyelv fejlődése, de én speciel nem bánom, mert szerintem jó az irány. A PHP a lenézése is indokolatlan és idejétmúlt. Persze aki csak a felszínt ismeri, annak igaza van ebben. Aki viszont mélyebbre ás, az meglepődik mennyi olyan módszer, módszertan, standard és kódfigyelő alkalmazás/segédeszköz van már hozzá, amivel ipari minőségű kód állítható elő. Persze ehhez kell némi mérnöki tudás is, az meg a nyelvhasználatnak nem előfeltétele.

Alapjában véve/természetesen egyetértek. Egy ideális világban így kellene lennie.

De a nyelv fejlesztőinek a valóságot is figyelembe kellene venni, hogy hiába csinálnak jó nyelvet, toolset-et "néhány" hozzáértő fejlesztő folyamatos igényei alapján, ha a PHP fejlesztők jó nagy része (akinek nem inge...) hozzá nem értő önjelölt amatőr webfejlesztő, és az általa használt (jellemzően nem a legfrissebb, mert a régebbiben lévő lehetőségeket sem érti igazán) verzió lehetőségeit sem ismeri, nemhogy az újításokat.
Emiatt aztán kiizzad egy úgy-ahogy működő valamit, aminek örül, hogy megjelenik a képernyőn, kb. az amit a megrendelő kért, és jónapot, úgy marad örökre.
Aztán a szerencsétlen megrendelő sem a PHP-t nem ismeri, sem a kódról nem tudja megállapítani mennyire jó, így elfogadja, mert azt látja, amit kért (vagy kap egy számára akkor hihető magyarázatot, hogy miért nem olyan teljesen...).
De amikor meg az üzemeltető frissíti a PHP-t a cucc alatt, mert a támogatás megszűnt, biztonsági rés volt, stb. akkor jön a gond. Megáll a cucc mint szög, mert 1) eredetileg sem volt jó a kód a régebbi PHP verzióhoz sem, csak kerülő "trükkökkel" életre keltették, 2) jó volt ahhoz a verzióhoz, de obsolote lett a használt funkció. A felhasználó meg nem érti, hogy kifizette, eddig működött, és most miért nem. Az őt igazából nem érdekli (és tényleg nem is kellene érdekelje), hogy miért kellett frissíteni, az meg pláne nem, hogy fizessen a "javításért" úgy, hogy maga a cucc pont ugyan azt fogja tudni, mint annak előtte, csak újra fizetni kell érte. Már persze ha olyan szerencséje van, hogy az eredeti fejlesztő elérhető és hajlandó javítani, vagy talál helyette valakit, aki meg tudja és akarja csinálni...

Egy csomó nyelv esetében elég ritkán van olyan változás, hogy megborul az app a nyelv frissítésétől. PHP esetében viszont aránylag gyakori, ami nagyon nem jó, és szerintem igazából nem is védhető semmilyen észérvvel (legalábbis ilyen gyakran). Ha más meg tudja oldani úgy a nyelv fejlesztését, hogy nem borul meg egy csomó minden tőle, akkor a PHP fejlesztőinek is meg kellene tudni oldani. De lehet úgy vannak vele, hogy már úgy is megszokta a világ, minek foglalkozzanak a kompatibilitással többet, mint eddig.

A PHP most nekem amolyan rolling release, ami esetében minden benne írt kódot folyamatosan vinni kellene előre a PHP fejlődésével párhozamosan, hogy ne legyen gond. De szerintem programnyelvek esetében működésképtelen ez a modell... Pláne, hogy rengeteg olyan rendszer készül benne, ami "statikus", úgy értve, hogy amikor elkészült, onnantól használják sokáig, módosítás nélkül.

Például a Wordpress elég nagy, elterjedt és aktívan fejlesztett rendszer. Elég gyorsan jelenik meg az új PHP verzió támogatása (általában 1-2 hónappal a friss PHP megjelenése után). A PHP 8.0 támogatás 2020 decemberében, a PHP 8.1 2022 januárjában jelent meg először benne (5.6-ban és 5.9-ben). Azóta kijött a 6.0 és a 6.1, utóbbi már támogatja a PHP 8.2-t papíron. Viszont az összes érintett (5.6-6.1) verzióhoz jelzik, hogy a PHP 8.x támogatás béta verziós, nem teljes értékű részükről, mint a PHP 7.4 támogatás... Ha egy ekkora projekt sem tud rendesen utána menni a PHP fejlődésnek két év alatt sem, akkor ki tud?

Nem tudom mi  lenne a helyes üzemeltetői gyakorlat. Talán egy dist-upgrade előtt n idővel,  bekapcsolni egy fullosabb logot a php.ini-ben. Abból már esélyes, hogy látszik, ha gond lesz a kóddal a jövőben.

A másik lehetőség, ha csak konténerben vesznek át PHP-s alkalmazást üzemeltetésre.

> A másik lehetőség, ha csak konténerben vesznek át PHP-s alkalmazást üzemeltetésre.

talalkoztam mar ilyennel, hogy dockerben adtak a php szarjukat at, hat az sem egy elmeny... ott inkabb az a baj, hogy zabalja az eroforrast, siman elmegy fpm-el 100-200 kis forgalmu site is egy 8gb ramos gepen, de ha mind kulon kulon kontenerbe futna sajat apacs, php, mysql-el akkor a vilag osszes ramja is keves lenne hozza.

es security szempontbol semmivel se jobb egy nem frissitett kontener mint egy nem frissitett/tamogatott php verzioval futtatni nativan... sot!

> es security szempontbol semmivel se jobb egy nem frissitett kontener mint egy nem frissitett/tamogatott php verzioval futtatni nativan... sot!

Nem mindegy, hogy önmagát szívatja vagy egy komplett rendszert. Az üzemeltető így attól is megszabadul, hogy egy frissítés miatt ne menjen az adott oldal.

Ezért futtatják a weboldalak mindegyikét önálló user alatt chrootolt környezetben. Ha feltörik az adott weboldalt, akkor se tud máshoz hozzáférni a támadó. A konténer abban tud többet, hogy a szolgáltatás alkotócsapata a teljes runtime környezetét össze tudja rakni a szolgáltatásához + saját maga tudja feltölteni alapos kitesztelés után az új komplett mindent.

Egy magányos PHP fejlesztő ezzel a szuper lehetőséggel nem fog élni, a legtöbbjének egy ftp-ről elérhető htdocs mappa és egy SQL db-hez user+passwd kell. Ő csak a kódját szeretné feltölteni + SQL táblákat hozzá kialakítani. És szíve szerint utána elfelejteni. Ezért is macerás a sok régi kód alatt a PHP verzióváltás.

Szerencsére már a debianhoz is van repo amiben 5.6-8.2 ig van php, és egy dist upgrade nem jár php verzió frissítéssel. 

Tavasszal lőttem le régi webszervereket (debian 5.0, és centos 6). Voltak olyan  oldalak amik ősszefosták magukat 5.6-os php-tól is ...

Fedora 38, Thinkpad x280

Engem egy kérdés foglalkoztat régebb óta: vajon mikor lesz a PHP alapértelmezetten értelmes tempóra felgyorsítva?
   - compiler cache, hogy ne kelljen a változatlan PHP kódot újrafordítani
   - normálisabb előfordítás, hogy ne legyen akár 50-szeres erőforrás pazarlás (és energiapazarlás) egy binárisra fordított nyelv és a PHP között.

igy van, es tenyleg sokat szamit. foleg ha kikapcsolod, hogy minden requestnel nezze meg valtozott-e a file... meg lehet adni kell neki tobb memoriat, a default beallitasok nem sokra eleg. ezzel lehet jol nyomonkovetni:

https://github.com/rlerdorf/opcache-status/