Actieve ondersteuning voor php 5 is beëindigd

Hoewel de versie nog veel wordt gebruikt is de actieve ondersteuning van php 5 stopgezet. Php 5.6.30 verschijnt nog begin januari met enkele bugfixes, daarna volgen alleen nog eventuele beveiligingsupdates tot 31 december 2018.

De actieve ondersteuning van elke minor versie van php stopt twee jaar na de release, daarna is er nog twee jaar beveiligingsondersteuning. Php 5.6 werd op 28 augustus 2014 uitgebracht en de actieve ondersteuning werd met vier maanden verlengd omdat het de laatste versie van php 5 betrof.

Thephp.cc licht toe dat het releaseschema van php daarom inhoudt dat php 5.6 niet actief meer ondersteund wordt en op 31 december 2018 ook de beveiligingsondersteuning stopt. Volgens het bedrijf gaan steeds meer frameworks, componenten en andere tools ertoe over om de ondersteuning voor php 5 te schrappen en zouden organisaties moeten overstappen op php 7.

Heise haalt statistieken van W3tech aan die beschrijven dat van de onderzochte websites nog maar 2,5 procent php 7 draait, terwijl php 5.6 nog bij 21 procent in gebruik is. Statistieken van packagist.org laten een iets rooskleuriger beeld zien: in november 2016 zou php 7.0 en 7.1 goed zijn voor een aandeel van 36 procent, maar ook hier is php 5.6 met 37 procent nog flink vertegenwoordigd.

Reacties (89)

[Barryvdh]

Volgens http://php.net/supported-versions.php is de standaard security support slechts 1 jaar, maar ook die is verhoogd voor PHP5.6:

As it is the final PHP 5 release, support for PHP 5.6 has been extended: active support will run for an additional four months, and the security fix period has been doubled from one to two years. Other releases are unaffected.

Oorspronkelijk was active support t/m augustus 2016 en security support t/m augustus 2017. Via deze RFC werd dat verhoogd: https://wiki.php.net/rfc/php56timeline Dit omdat er anders te weinig tijd was na de release van PHP 7 (eind 2015)

Sinds PHP7 wordt het nieuwe release schema gebruikt, met 2 jaar active + 1 jaar security support per versie.

En 2 jaar vanaf nu zou ook genoeg moeten zijn, het grootste probleem is waarschijnlijk dat mysql_* niet meer gebruikt kan worden, maar dat is al deprecated sinds PHP5.5 (juni 2013); https://wiki.php.net/rfc/mysql_deprecation en daar heb je dan dus 4,5 jaar de tijd voor gehad..

[NLxDoDge]

Op mijn stage waar ik momenteel loop zijn ze net bezig met alle website die nog uit moeten gaan komen om ze te maken in 7.0. Zelf heb ik all meerdere malen gehad dat standaard functies in 7.0 niet in 5.5 ect. zaten waardoor ik 'hacks' van andere developers moest gebruiken waardoor het wel werkte. Dat is niet echt professioneel. Hoe denken andere (web) developers hierover?

[Cartman!]

Noem eens een paar van die functies? Waarschijnlijk zijn die al sinds PHP 5.3/5.4 deprecated en had er dus allang iets aan gedaan kunnen worden.

[MadEgg]

Eerder andersom - er zijn diverse functies aan PHP 7 toegevoegd die in 5.6, 5.5, 5.4 etc nog niet bestaan. Dan zul je dus een alternatieve implementatie van die functies toe moeten voegen als je het op een eerdere PHP-versie wilt draaien.

Op zich kun je prima een compat.php hebben met een setje if (!function_exists(...)) constructies om dat vrij netjes te doen.

Alsnog zou het uitgangspunt moeten zijn om te testen en de draaien op de versie waar het voor ontwikkeld is dus zou het niet nodig moeten zijn.

[Cartman!]

Eitje, daar heb je https://github.com/symfony/polyfill voor dus dat zou geen probleem moeten opleveren

[MadEgg]

Precies!

Waar je wel rekening mee moet houden is dat je dan PHP-implementaties krijgt ipv C-implementaties wat de performance niet ten goede komt. Voor de meeste zaken niet boeiend, voor sommige zaken wel. Het is dus wel zaak om niet klakkeloos van PHP 7 uit te gaan als je het gaat draaien op PHP 5.6, want mogelijk had je met gebrek aan die functies andere ontwerpkeuzes gemaakt. Het is dus wel zeer belangrijk om een minimale target-version in het achterhoofd te houden - en zeker als je software bouwt die je zelf moet gaan draaien moet je dus voorzichtig zijn met ontwikkelen voor PHP-versies die je zelf (nog) niet gebruikt.

[Cartman!]

Van te voren moet je de versie weten ja, sowieso. Als we zelf hosten is het gelukkig 7 maar veel klanten bieden nog 5.6. Geen drama opzich maar ben toch wel erg blij met strict types al

[P1nGu1n]

Waarom niet gewoon een website geschreven voor PHP 7.0 draaien op een webserver met PHP 7.0?

[NLxDoDge]

Ik loop momenteel stage ik de hoofd developer is er nu ook mee bezig. Maar hun zelf gemaakte systeem werkt niet helemaal soepel met 7.0 dat is eigenlijk de enigste reden.

[unglaublich]

Compatible maken met PHP 7.0 voordat het probleem groter wordt (en je direct naar 7.1 moet). Je kan deze tool gebruik voor een eerste inspectie van knelpunten:
https://github.com/sstalle/php7cc
Op een Mac met Homebrew kan je eenvoudig brew install php7cc uitvoeren.

[Barsonax]

Als jullie gezegd hebben dat het in PHP 7 gemaakt word en dus je een server moet hebben die dat ondersteunt dan moet die klant daarvoor zorgen.

Aan de andere kant hebben jullie dat niet gezegd dan moet je niet functionaliteiten gaan gebruiken die niet werken.

Je kan natuurlijk nog aan tafel gaan zitten om dit soort zaken proberen te veranderen omdat dat handiger zou zijn.

Dit probleem heeft dus eigenlijk niks te maken met het programmeren zelf maar meer met afspraken maken en in die hoek moet je zijn voor een oplossing.

[NLxDoDge]

"alle website die nog uit moeten gaan komen om ze te maken in 7.0" dus alle website daarvoor zijn nog 5.6 en lager.

[Yggdrasil]

Wij zijn ons primair CMS-platform aan het testen op PHP 7.0. De productieomgeving daarvoor staat al klaar. Zodra het werkt maken we tijd om alle tientallen sites over te zetten naar de nieuwe servers. Met PHP 7 schatten we dat de sites sneller draaien en we minder capaciteit nodig hebben. Zodra dat gebeurd is wordt de minimum-versie ook 7.0.

Onze legacy-frameworks, die we niet meer actief ontwikkelen maar nog wel ondersteunen worden niet geüpgraded. Deze geschikt maken voor PHP 7 is niet rendabel als de klant er niet voor betaald. Deze blijven op enkele legacy-servers draaien met PHP 5.5. De frameworks krijgen indien nodig fixes maar verder wordt daar niks aan gedaan. PHP 5.5 krijgt nog backported security-fixes van Ubuntu. Naarmate steeds meer van die oudere sites offline gaan kunnen we het restant consolideren op een handvol servers die weinig meer kosten of onderhoud nodig hebben.

[NLxDoDge]

Dit is precies wat ze ook bij ons op mijn stage doen.

[BvdW1978]

...en dat is dus niet goed. Om te voorkomen dat je jaar op jaar op jaar blijft zitten met steeds meer unsupported rommel op "legacy" systemen die een steeds hogere beheerlast en security-risico's met zich meebrengen, spreek je met de klant een lifecycle van het product. Een veelgemaakte fout bij vrijwel alle webbureaus die ik ben tegengekomen is dat zij een website maken "voor de eeuwigheid", omdat er stomweg niets over wordt afgesproken. De klant is veel te gefocust op het afleveren van het nieuwe project om te beseffen dat alles eindig is en de bureaus gaan daar net zo hard in mee. Dit terwijl de support op een stack met een beetje geluk een jaartje of 3 is, en je daarna tegen legacy-issues gaat aanlopen. Klanten die niet vooraf geïnformeerd zijn over dit probleem, gaan terecht steigeren wanneer het bureau drie jaar later "ineens" meldt dat de server niet meer ondersteund wordt. Spreek dus af met de klant dat de site onder SLA blijft zolang de onderliggende technologie nog volledig supported is en geef daarbij een schatting af van de verwachte levensduur van een site. Is een SLA daarna nog gewenst, dan moet de klant rekening gaan houden met kosten voor rework om compatibiliteit te waarborgen.

[Basszje]

Als het moet draaien op < PHP 7.0 de developers schoppen dat ze in de manual moeten checken of nieuwere functies wel bestaan in oude versies.

We draaien een aantal servers / virtual boxes met oudere PHP-versies om dit te kunnen testen.

Op zich zou ik in de requirement docs gewoon schrijven dat de beste klant maar een PHP 7 server moet draaien Is ook een stuk sneller trouwens,

[faim]

Waarom moet je hacks toepassen dan?
Als een website wordt gemaakt voor PHP7, ga je 'em niet op 5.6 draaien lijkt mij...

[wackmaniac]

Je moet je applicatie schrijven voor het platform waar het voor bedoeld is. Draait je systeem nog php 5.5 of 5.6, dan moet je geen php 7-functionaliteiten gaan gebruiken. Heel simpel.

[Timo002]

Ik zou zeggen, zet je servers om naar php7. Grote kans dat ze een eigen server hebben waar meerdere sites op draaien. Als ze alle sites naar php7 updaten, zal de server ook rustiger zijn, waardoor er weer meer sites op 1 server kunnen draaien (win-win). Als de sites op 5.6 functioneren, is de stap naar 7 niet zo groot meer. Als het om kleine fixes gaat lijkt me dat een uitgelezen kans voor een stagiair om te fixen, waarna het alleen nog maar getest hoeft te worden.

[Toettoetdaan]

Ik bouw Magento (1 en 2) modules voor PHP 5.3 tot 7.1 en moet toch zeggen dat ik niet veel problemen tegenkom. Het zijn soms kleine specifieke functies, waarvoor je toch al de documentatie opent, die niet hetzelfde kunnen. En soms een notice die opgewaardeerd is naar een error, maar die had er dan toch al niet in gemogen.
Nog niet zo lang geleden hebben we de support voor PHP5.2 laten vallen, de code die ik daarvoor nodig had is een meervoud van alle versie specifieke code die ik nodig heb voor 5.3 tot 7.1.

Meestal zijn de problemen met de PHP extenties die wel of niet draaien bij de gebruiker en in dat opzicht is een workaround (of wat jij noemt hack) niet verkeerd; Als iemand geen iconv/exif/zip op zijn PHP server heeft, dan valt mijn code gewoon terug op een eigen specifieke implementatie, een alternative oplossing of een kleine beperking in functionaliteit.

Het hangt puur af van wat je doet met PHP, als je voor een project de requirements kunt vastzetten, dan kun je gewoon zeggen dat minimaal PHP7 vereist is, maar als je een gedistribueerde applicatie moet bouwen die dus op systemen draait waar je geen invloed op hebt, dan pas je je code daar gewoon op aan.

[Anoniem: 2198]

Als je al composer gebruikt is het niet zo lastig, het Symfony project heeft "polyfills" die deze functionaliteit voor oudere versies van PHP beschikbaar maakt:

Bijvoorbeeld: https://packagist.org/packages/symfony/polyfill-php70. Er zijn ook polyfills voor 5.6 en 5.5 als je nog PHP 5.4 gebruikt (de default in CentOS7/RHEL7). De functies die ik nodig heb zijn `random_bytes`, `random_int` en `hash_equals`.

[Reactie gewijzigd door Anoniem: 2198 op 23 juli 2024 17:27]

[Anoniem: 426269]

Ja ehh, dat is toch logisch? In een nieuwe versie heb je nu eenmaal nieuwe functies die er eerst nog niet in zaten. En omgedraaid zullen er ook wat functies verdwijnen die op de oude versies het nog wel deden. En dat is alleen maar goed. Zoals geen rare Magic Quotes meer en mysqli... ipv mysql... (ik noem maar wat, maar dat vind ik er dus van, en dat was wat je vroeg. )

[Reactie gewijzigd door Anoniem: 426269 op 23 juli 2024 17:27]

[codebeat]

De websites die ik heb gemaakt gaan probleemloos over en zoals andere al schrijven is het goede beslissing gebleken depreciated functies voortijdig aan te passen. Altijd gaan voor 0 warnings, notices e.d., dat is professioneel ;-)

[NLxDoDge]

Wij gebruiken bibliotheken die niet werken met 7.0 maar als stagiaire heb ik niet echt veel inspraak op wat er allemaal gebeurd. Maar de hoofdprogrammeur is er wel mee bezig doordat we met 5 programmeurs actie gingen ondernemen.

[MrAndy9797]

Ik heb de optie om over te schakelen van php 5.6 naar php 7.0 & 7.1 bij mijn hosting maar eerlijk gezegd durf ik het niet echt omdat ik mogelijk dan problemen ga hebben met de website die niet meer goed functioneert. Althans, die 'schrik' heb ik toch. Zeker na een bericht van Tweakers over het geschikt maken van de code. Iemand die hier al ervaring mee heeft hoe dit is verlopen, of er veel dingen zijn om rekening mee te houden? Kan het natuurlijk ook zelf opzoeken maar wil graag jullie ervaring hiermee weten

[Anoniem: 55563]

Met een website ging dat bij mij een keer mis met de nodige foutmeldingen maar met een beetje googlen vond ik daar vrij snel workarounds voor waarna die site prima functioneerde met PHP 7. Met Wordpress heb je sowieso geen problemen met PHP 7 en dan draait de site nog sneller ook. Ik ben vrij a-technisch maar je kunt de site niet kapot maken als je simpelweg PHP 7 wilt testen dus er is geen enkele reden om bang te zijn.

[gooos]

Met de core van WordPress niet, dat klopt, maar er zijn nog voldoende plugins die nog verre van PHP 7 georiënteerd zijn doordat ze nog allerlei deprecated functies gebruiken.

Het is mij in het verleden dus gewoon gelukt om een WordPress site te "breken" door van PHP 5.6 naar PHP 7.0 over te schakelen in DirectAdmin. Gelukkig was alles weer in orde na het terugschakelen naar PHP 5.6.

Voor mij dus de reden geweest om maar voor een jaar een 2 hostingpakket te nemen (is gelijk een flinke upgrade die ik toch nodig had) om alles eerst rustig op de nieuwe PHP 7 server te testen en dan pas de data over te pompen

[offtopic]
Ik kan trouwens niet wachten totdat WordPress een roadmap gaat aankondigen voor de afbouw van de PHP 5.x ondersteuning. Zou een mooi moment zijn om de core van WordPress weer eens wat lichter te maken want die is best redelijk vol met code backwards PHP compatibiliteit (neem de password functionaliteit als voorbeeld die altijd nog MD5 gebruikt in plaats van bcrypt , zie ook: https://core.trac.wordpress.org/ticket/21022).

[Basszje]

Je moet dus ook een brakke plugins gebruiken die geen fatsoenlijke code bevatten of niet op tijd worden bijgewerkt. Helaas is het installeren van een plugin erg makkelijk ( elk voordeel heb zijn nadeel ) .

En idd de WP-wereld kijkt volgens mij smachtend uit naar het moment waarop core *eindelijk* eens beslist dat PHP 5.2 dood is en moet. Wij ( developer van plugins ) ondersteunen het in elk geval niet meer en veel grote andere plugins doen dat ook niet.

[gooos]

Helemaal eens, is ook de reden geweest dat ik een maandje of 18 geleden eens alle plugins (was sowieso al terughoudend in het aantal) nog eens tegen het licht heb gehouden en er toen circa de helft eruit heb gedonderd omdat ik de functionaliteit eigenlijk ook al anders kon oplossen. In sommige gevallen had het eindelijk zijn weg gevonden naar het handvol premium plugins die ik gebruik. Verder ben ik ook heel stuk kritischer gaan kijken naar de auteurs van de plugins, hoe actief zijn ze, hoe schrijven ze hun code etc etc. Kost wat tijd maar het betaald zich driedubbel terug in mijn beleving

[fvdberg]

Gewoon proberen je krijgt hooguit een error 500 en in het logboek kan je zo zien waar je code conflicteerd. 9 van de 10 keer is het een addon waar geen support meer voor is danwel support voor aangeschaft dient te worden omdat deze verlopen is. Zet je de php terug dan werkt het weer en kan je het op je gemak oplossen

[Reactie gewijzigd door fvdberg op 23 juli 2024 17:27]

[Antrax]

Toch vind ik de statistieken van packagist.org niet geheel transparant. Machines van developers hebben over het algemeen nog PHP 5.6, kijk o.a. naar de stock macOS. Velen gebruiken daar Docker/Vagrant maar die VM's bevatten over het algemeen ook nog PHP 5.6 vanwege de applicatie structuur. Het zal nog wel even duren voordat een groot gedeelte van developers/hosters en andere partijen overgaan naar PHP 7.

[Brummetje]

Wat dacht je van alle websites die niet compatible zijn met PHP 7.0. De meeste website's gebruiken denk ik mysql en sinds PHP 7.0 moet je over op mysqli (of iets anders), heb je dit nog niet veranderd werkt je website dus gewoon niet meer. Als ik kijk bij ons op de server dan draaien er nog te veel website's op die nog gebruik maken van de mysql extensie en daardoor kunnen wij niet zomaar even PHP 7.0 globaal aan zetten.

We kunnen gelukkig gewoon schakelen (meerdere versies van PHP) dus er is niet echt een probleem verder maar ik denk dat het nog wel even gaat duren voor de meeste PHP 5 servers weg zijn

[NullCrayfish]

Zijn de mysql_ functies niet sowieso al jaren deprecated?

Een klant van mij struikelde hier overigens wel over, website was al op leeftijd en moest zo snel en vooral ook zo goedkoop mogelijk weer online gebracht worden. Ik heb toen obv. mysqli gewoon even nieuwe functies aangemaakt die identiek werken aan de oude mysql_ functies.

[Kevin-de-Groot]

Sinds PHP 5.5.x (zie hier).

[Anoniem: 291692]

Klopt mysql_functies geeft al jaren warnings op dat het deprecated is, ik gebruik voor db sowieso een losse tussenlaag dus als je dt doe is het zo aangepast zoals jozuf ook al zegt.

[Cartman!]

Sinds Juni 2013 want toen kwam 5.5 uit dus tijd genoeg om het te verbouwen zou je denken

[jozuf]

Als je een beetje normale db/data access laag hebt in je website is het aanpassen hiervan een fluitje van een cent over het algemeen.
Natuurlijk zijn er altijd uitzonderingen en brakke implementaties.

[Reactie gewijzigd door jozuf op 23 juli 2024 17:27]

[Brummetje]

Vertel jij dat even aan klanten die al jaren een website hebben gemaakt door iemand waar ze allang geen contact meer mee hebben?

[Barsonax]

Een auto onderhoudt je toch ook? Een stuk software is niet anders. Helemaal voor zaken zoals websites vanwege security bijv.

Dat is natuurlijk erg naar als je er zelf geen verstand van hebt en degene die dat wel had al weg is maar zo is het nou eenmaal. Je auto kapt er uiteindelijk ook mee als je deze niet goed onderhoudt. Dan is het zaak dat je iemand vind die die onderhoud voor je kan doen.

[Brummetje]

Ja maar een auto gaat kapot omdat iets verslijt, daar ontkom je niet aan. Het is niet zo dat de weg wordt aangepast waardoor je nieuwe banden moet.

Er zijn genoeg klanten die het niet zomaar accepteren dat de website niet meer werkt door een wijziging van de hosting waardoor hun dus extra kosten moeten maken.

Neemt niet weg dat ik het met je eens ben hoor. Ik heb ook zoiets van, als iets niet meer supported is dan moet je gewoon updaten klaar. Al is dit met Windows ook een heel gedoe met sommige klanten die zo iets hebben van, het werkt nu toch gewoon?

[Barsonax]

Ja maar je auto zet je niet open zoals een publieke website met alle security issues die daarbij horen. Software verslijt gewoon op een andere manier.

[Brummetje]

Ik ben het helemaal met je eens maar probeer dat sommige mensen maar eens uit te leggen. Sommige zijn al te dom om te begrijpen dat een scherm uit en aan zetten niet de computer herstarten is. Je vraagt je bij sommige ook af waarom ze überhaupt gebruik maken van een computer.

[Barsonax]

Alles wat je doet als developer is als magie voor die mensen. Je kan het wel uitleggen maar ze snappen er toch niks van. Hoe vaak je dit soort vragen wel niet krijgt: https://s-media-cache-ak0...5ffe2a187982bfd7b4c7a.jpg

Echter voor hun eigen bestwil is het beter dat ze updaten ook al vinden ze zelf van niet. Anders gewoon lekker laten zitten met een website die niet werkt dan kan het ook geen kwaad .

[jozuf]

Dan zoeken die mensen contact met een bureau die het voor ze aanpast, lijkt mij. Er is altijd een oplossing...
Wil je niet veel betalen ga je naar een willekeurige IT student die het voor je doet.
Beter dan een niet werkende site lijkt mij.

[Reactie gewijzigd door jozuf op 23 juli 2024 17:27]

[Brummetje]

Die mensen denken daar over het algemeen heel anders over Die zijn van, hij werkt nu toch? Dus omdat jullie iets willen veranderen moet dat ons geld kosten. En daar ligt dan ook precies het probleem, wie gaat dat betalen?

[jozuf]

De klant als ze geen service contract afsluiten natuurlijk. Das met alles toch zo...
Zulke klanten hebben over het algemeen geen eigen server en zijn dus toegewezen op een externe dienstverlener. Als die ineens php 5 uitfaseerd dan is het niet de schuld van de ontwikkelaar.

Dat is het zelfde als je bv van xp upgrade naar windows 10. Werkt je maatwerk applicatie niet meer en er is niets over opgenomen in het contract/koopovereenkomst, dan pech voor die klant. 2 keuzes dan, terug naar xp en onveilig zijn of investeren in de toekomst.

Ik bedoel als je dan niets weet over dit soort zaken als klant zijnde, neem dan een full-service bureau in de hand vanaf het begin.

Je mag van een klant ook wel verwachten dat ,ondanks het niet zijn vakgebied is, hij/zij wel even onderzoek doet, of zich iig laat informeren.
Als ik als consument zijnde iets koop waar ik geen onderzoek naar heb gedaan en een miskoop doe, dan is dat ook jammer voor mij. Je kan niet alles in gaan dekken als er niet ook wat tegenover staat. Goedkoop blijft vaak gewoon duurkoop.

[Reactie gewijzigd door jozuf op 23 juli 2024 17:27]

[Khrome]

Kondig het netjes aan - 6 maanden voor je 5.5 uitzet, dan 2 maanden, dan 2 weken en dan uit. Dan hebben ze meer dan genoeg tijd om iets te regelen.

Het is de verantwoordelijkheid van de klant om te weten wat ze eigenlijk kopen en hoe ze het bij kunnen houden. Het is onzin om je systemen opzettelijk onveilig te maken omdat sommige mensen denken dat 'oh, mijn website is pas 5 jaar niet geupdate, ik hoef er pas over 10 jaar nog eens naar te kijken, dat loopt toch echt niet zo snel'. Opvoeden van de klant noemen ze dat. Wat @jozuf zegt klopt ook helemaal.

[Khrome]

Als er nog websites zijn die mysql_ gebruiken zijn ze dusdanig oud dat ze geheid een hoop vulnerabilities bevatten, zeker als het wordpress/joomla websites betreft of een andere (populaire) CMS. Updaten die hap.

Des te langer dat er mee gewacht wordt, des te groter wordt het risico dat die sites straks overhoop worden gehaald.

[Trommelrem]

"maar ook hier is php 5.6 met 37 procent nog flink vertegenwoordigd"
Voor mijn gevoel vergelijkbaar met einde mainstream support van Windows XP destijds.

[Cartman!]

Er blijft gewoon nog een lange tijd security support voor 5.6 dus volgens mij is dit zeker niet t zelfde als Windows XP

[Trommelrem]

Ik verwacht niet dat tegen die tijd de overstap is gemaakt.
Zo zijn er nog vele websites die nog SSL en Poedel hebben en nog niet over zijn op TLS.

[Cloud]

Het is inderdaad zeker niet hetzelfde als Windows XP maar volgens mij het omgekeerde van wat jij denkt:

Windows XP had support van October 25, 2001 (release) t/m April 8, 2014 (extended support)
PHP 5.6 heeft support van 28 August 2014 (release) t/m 31 December 2018 (extended support)

Windows XP had veel langer support, wat trouwens wel logisch is omdat het een besturingssysteem is

[easy-cloud]

Damn, dit gaat veel oude websites en bedrijven problemen opleveren!

[kozue]

Neuh. Je site draait gewoon door hoor. Je krijgt pas problemen wanneer je php 7 nodig gaat hebben voor 3rd party applicaties en je die om een of ander legacy-reden niet kunt installeren. Maarja, dat is een mooi moment om eindelijk je verouderde software een keer te upgraden.

[Reactie gewijzigd door kozue op 23 juli 2024 17:27]

[BeosBeing]

Ja fijn, al je oude pagina's werken niet meer als je de upgrade doet van 5 naar 7 zie hier:
Ook is er veel oude code verwijderd, zoals functies die sinds de 5.x-versies gedeprecieerd waren. Ook is een lange lijst aan oude en niet meer ondersteunde sapi's, of Server Application Programming Interfaces, verwijderd, zoals manieren om te verbinden met AOL, Apache 1.x en Microsoft IIS. (Ja ik chargeer een beetje maar je zult alles, maar dan ook alles moeten nalopen op die functies en ze moeten vervangen en testen anders kun je vreemde verrassingen tegenkomen en meestal zijn die niet plezierig.

Maar bestaande sites gaan echt niet binnenkort overgezet zijn.
Kortom, als nu 2,5 procent op 7 draait mag men blij zijn als in december de 5% en december 2018 de 10% gehaald wordt en dus gaat 90% van de sites vanaf 2019 onveilig zijn, tenminste als er zoiets als dit of dit ontdekt wordt.

Ik kom ook nog steeds pagina's tegen die ontwikkeld zijn voor IE6, vooral in bedrijfsinterne omgevingen, maar ook daarbuiten. Zoals iRicardo hieronder aangeeft zal het nog wel even duren voordat een groot gedeelte van de developers is overgestapt. Velen zullen nog gauw even een php5-site bouwen voordat ze definitief stoppen (pensioen, failliet, ...) en veel klanten zullen er geen weet van hebben dat ze betalen voor een website die verouderde techniek gebruikt, niet toekomstbestendig is en straks kapitalen kost om aan te passen.

[Reactie gewijzigd door BeosBeing op 23 juli 2024 17:27]

[Voutloos]

Die deprecated zaken waren dat ook al jaren en je hebt dus nog 2 jaar als je per se alles op laatste moment doet, ergo heb je dus enkel een probleem als je gedurende meer dan 4 jaar alle hints en noemenswaardig onderhoud uitstelt.

Bij PHP zijn ze zelfs nog behoorlijk conservatief. Onderhoud hoort er bij, en zoveel is dat echt niet met PHP als platform. Als je moeite hebt met dit tempo, ligt het probleem toch echt bij jezelf. Anders gezegd; elk project welke niet het bescheiden jaarlijkse onderhoudrondje kan verantwoorden is wellicht verkeerd berekend.

Een edge case is misschien als de auteur van je pakket inmiddels kopje onder gegaan is, maar eigenlijk geldt daar imo hetzelfde: Als het pakket dus al jaren door sluimert is het wellicht lullig en vervelende overmacht, maar is een php support probleem alsnog enkel een symptoom, je had al jaren naar een partij welke wel onderhoud en garanties kan leveren moeten overstappen.

[BeosBeing]

Die deprecated zaken waren dat ook al jaren en je hebt dus nog 2 jaar als je per se alles op laatste moment doet, ergo heb je dus enkel een probleem als je gedurende meer dan 4 jaar alle hints en noemenswaardig onderhoud uitstelt.

Heel veel websites worden gemaakt voor een klant en daarna nooit meer bijgewerkt. Ja er zijn developers die een onderhoudscontract aanbieden maar voor dat soort kleine websites is dat vaak te duur.

Dat iets deprecated wordt en nog jaren werkt is prima, al vraag ik mij altijd af waarom het tot deprecated wordt bestempeld. Bij Microsoft heb ik altijd het idee dat het enkel is omdat men de nieuwe technieken wilt pushen en de oude wilt uitfaseren, niet omdat er een technische noodzaak voor is. (Er zijn wel uitzonderingen hierop)

Mensen zijn gewoontedieren en als ze weten hoe ze iets kunnen doen zullen ze dat op die manier blijven doen, deprecated of niet. Pas als de nieuwe techniek het makkelijker maakt zal men overstappen. Om even de analogie met Microsoft vast te houden, ik zie dat er nog steeds batch-files gemaakt worden in windows-omgevingen, dit ondanks de komst van Powershell en daarvoor vbscript. Met die laatste heb ik een klein beetje ervaring en het is veel krachtiger maar ook ingewikkelder, juist omdat ontwikkelomgevingen op deze toepassing niet gericht zijn (of het is web-gericht of het is applicatie-gericht) en full-featured ontwikkelomgevingen ook te omvangrijk en te complex zijn hiervoor.
En Powershell is een heel nieuw iets dat in de praktijk evenmin vbscript vervangt bij wie het gebruiken, ondanks dat Microsoft het deprecated verklaard.
Pas op het moment dat iets in de nieuwe omgeving niet meer werkt zullen mensen overstappen en dan nog zullen de oude systemen in gebruik blijven, zie ook het probleem dat men nu met cobol heeft.

Als iets deprecated is dat het op de nieuwe versie dan niet meer werkt, is normaal. Dat je geen nieuwe features meer uitbrengt voor de oude versie is logisch. Wie die wilt gebruiken moet naar de nieuwe versie. Echter als de acceptatie van de nieuwe versie zodanig laag is dat de oude versie nog steeds de meest gebruikte versie is (nu 2,5% vs 97,5%) ben je dan niet te vroeg met het stopzetten van de support. Php7 is nu een jaar uit. Dat betekend dat eind 2017 het gebruik misschien op 5% zit en eind 2018 op 7,5%.

Ik snap dat het maken van bugfixes minder leuk is als het implementeren van nieuwe features. Maar gezien de userbase lijkt het me belangrijk om de draaiende boel veilig te houden.

Wat een optie zou zijn is om nieuwe websites met 7 te ontwikkelen en de anderen voorlopig zo te laten en als ze bijgewerkt moeten worden naar 7 te migreren. Echter beide versies (een tijdje) naast elkaar draaien gaat meestal niet. Men zal dus nog een tijdje bij 5.x blijven.

[MadEgg]

Op mijn werk hebben we een vrij complexe codebase in 15 minuten overgezet van PHP 5.6 naar PHP 7. De wijzigingen zijn echt minimaal.

Voor de kleine websites moet een community-ondersteund CMS gebruikt worden of als er sprake is van zelfgebouwde CMS'en moet daar ondersteuning voor dit soort zaken bij in zitten. Als je je technische neefje een website laat bouwen in PHP 5.3 en het vervolgens niet meer bijhoudt is het ook een keer klaar daarmee. Het tempo waarmee zaken deprecated en uitgefaseerd worden in PHP is echt traag, dus dat zou geen obstakel mogen vormen.

En tja, dat iets deprecated is betekent niet dat webhosters de overstap gaan maken. Ik kom te vaak hosters tegen die nog PHP 5.2 draaien wat al jaren unsupported is. Het moment waarop je het afschaft maakt eigenlijk geen bal uit, er blijven toch altijd te veel partijen achter. Dan kun je maar beter de kogel door de kerk jagen en 2 jaar (!!!) van tevoren aankondigen dat de ondersteuning eindigt. Natuurlijk blijven er na december 2018 genoeg partijen op PHP 5.6 of nog ouder draaien, maar dat is niet de schuld van het PHP-team, die hebben het al heel lang geleden aangekondigd.

Support kent zijn grenzen, zeker bij een open source project als PHP. Dat er veel lakse partijen zijn mag ze in de weg staan om de support te beeindigen.

[BeosBeing]

Op mijn werk hebben we een vrij complexe codebase in 15 minuten overgezet van PHP 5.6 naar PHP 7. De wijzigingen zijn echt minimaal.

Vijftien minuten voor alle websites voor alle klanten? Dat is razendsnel

Voor de kleine websites moet een community-ondersteund CMS gebruikt worden of als er sprake is van zelfgebouwde CMS'en moet daar ondersteuning voor dit soort zaken bij in zitten. Als je je technische neefje een website laat bouwen in PHP 5.3 en het vervolgens niet meer bijhoudt is het ook een keer klaar daarmee.

Dat technische neefje zal daarvoor ook nu een CMS gebruiken maar nog niet zo heel lang geleden waren die nog geen gemeengoed en waren er ook veel kleine commerciële webdesigners die voor kleine klantjes sites maakten en daarna overdroegen aan de klant. klant tevreden, project beëindigd. Dat die klant de kennis niet heeft en geen minimaal €1000 per jaar wilt betalen voor een onderhoudscontract is die ook niet diens schuld. De webdesigner, die inmiddels waarschijnlijk met de noorderzon is vertrokken, en anders inmiddels een heel andere clientele heeft en tevens een andere werkwijze, had een aan die klant aangepast onderhoudsplan moeten voorleggen zodat die klant wel de zin daarvan zou hebben ingezien en een onderhoudscontract was aangegaan tegen een voor hem redelijke prijs.

Het tempo waarmee zaken deprecated en uitgefaseerd worden in PHP is echt traag, dus dat zou geen obstakel mogen vormen.

Tegenwoordig niet, behalve als je dus sites hebt die niet meer bijgewerkt worden. Over een tijdje komt de klant er achter dat zijn site niet meer werkt omdat zijn hoster ooit eens is overgestapt op een nieuwe versie van PHP.

En tja, dat iets deprecated is betekent niet dat webhosters de overstap gaan maken. Ik kom te vaak hosters tegen die nog PHP 5.2 draaien wat al jaren unsupported is. Het moment waarop je het afschaft maakt eigenlijk geen bal uit, er blijven toch altijd te veel partijen achter. Dan kun je maar beter de kogel door de kerk jagen en 2 jaar (!!!) van tevoren aankondigen dat de ondersteuning eindigt. Natuurlijk blijven er na december 2018 genoeg partijen op PHP 5.6 of nog ouder draaien, maar dat is niet de schuld van het PHP-team, die hebben het al heel lang geleden aangekondigd.

Ik was een jaartje mis, had eerst gelezen dat het maar één jaar zou zijn. Wel vind ik het zinvol te kijken daar de adaptatie-rate en die is met 2,5% naar mijn mening nu nog te laag om support te beëindigen.
Ik mag hopen dat er tegen eind 2018 meer dan 70% van de websites is overgestapt. (En daarvoor dienen alle developers dus nu al overgestapt te zijn)

Support kent zijn grenzen, zeker bij een open source project als PHP. Dat er veel lakse partijen zijn mag ze in de weg staan om de support te beeindigen.

Open Source is in die zin wel beter als closed source. Immers je bent voor de migratie niet afhankelijk van dure licentie-constructies. Dat het niet altijd goed gaat zien we in de Android wereld waar de meeste telefoons (budgetmodellen worden meestal langer gebruikt als high-end toestellen) nooit geen updates krijgen.

Echter de update van PHP of een taal is iets anders als van een willekeurig softwarepakket. Dat duurt langer voordat dat uitgefaseerd en vervangen is.

[Reactie gewijzigd door BeosBeing op 23 juli 2024 17:27]

[MadEgg]

Vijftien minuten voor alle websites voor alle klanten? Dat is razendsnel

Waar haal je vandaan dat het om een hostingbedrijf gaat? Het gaat om een vrij complexe webapplicatie waar er maar één instance van in productie draait, op servers in eigen beheer. De grootste "incompatibiliteit" zat hem erin dat in PHP5 mbstring in de standaard package zit op Debian, terwijl op PHP7 je hiervoor php7.0-mbstring moet installeren.

Als je alle deprecation warnings die PHP 5.6 gaf ter harte genomen hebt is er geen kunst aan om over te stappen.

Voor de rest ben ik het wel met je eens dat het een geëvolueerd probleem is die voortkomt uit een toenemende professionalisering van PHP, waardoor veel mensen met verouderde websites / software zitten. Alsnog is dat geen reden om de afschaffing van PHP 5.6 langer uit te stellen. Het is heel spijtig dat er dan veel websites zijn die niet meer werken (al zullen die simpelweg niet upgraden en op termijn vatbaar voor exploits worden, dan merken ze de "slijtage" van de software vanzelf wel), maar ja. PHP zou natuurlijk ook zichzelf kunnen forken en gewoon direct stoppen met PHP 5.6, en dan maar hopen dat iemand nog energie in PHP 5.6 wil stoppen.

Ik vind dit een zeer fatsoenlijk tijdspad, zonder de druk van een op handen zijnde uitfasering zullen een hele hoop hosts alsnog wachten met upgraden.

[hackerhater]

Inderdaad.
Sites op 5.6 die zonder deprecation warnings draaien zullen zonder problemen werken op PHP 7.

[Voutloos]

Heel veel websites worden gemaakt voor een klant en daarna nooit meer bijgewerkt. Ja er zijn developers die een onderhoudscontract aanbieden maar voor dat soort kleine websites is dat vaak te duur.

Blame de opdrachtgever. Mits de opdracht uitgevoerd is volgens best practices, mag deze alsnog in zijn handjes knijpen dat hij zonder onderhoud minstens 2-4 jaar heeft kunnen genieten van zijn product.

Dat iets deprecated wordt en nog jaren werkt is prima, al vraag ik mij altijd af waarom het tot deprecated wordt bestempeld.

PHP is dus dusdanig conservatief dat zaken enkel deprecated worden indien onfixbaar onveilig of niet meer onderhoudbaar.
(Offtopic, maar Microsoft levert juist vaak bizar epische inspanningen om support te rekken, je kan wellicht geen slechter voorbeeld erbij halen)

Php7 is nu een jaar uit. Dat betekend dat eind 2017 het gebruik misschien op 5% zit en eind 2018 op 7,5%

Het zal wel niet zo lineair zijn dat men er 40 jaar over doet. Prima als men eerst de kat uit de boom kijkt, maar inmiddels mag (en zal ) de adoptie - mede door dit nieuws - wel wat vlotter gaan.

[Reactie gewijzigd door Voutloos op 23 juli 2024 17:27]

[BeosBeing]

Blame de opdrachtgever. Mits de opdracht uitgevoerd is volgens best practices, mag deze alsnog in zijn handjes knijpen dat hij zonder onderhoud minstens 2-4 jaar heeft kunnen genieten van zijn product.

Wist die destijds dat het web zo zou evolueren? Of is die er destijds ingestonken tijdens de eerste hype en na een mooi praatje van een webdeveloper terwijl hij toen nog geen site nodig had. Veel websites zijn in de eerste jaren echt niet volgens de best practices ontworpen. Men moest allerlei truken uithalen om het goed te krijgen op zowel phoenix/firebird/firefox als in IE6 en velen namen zelfs die moeite niet.
Best practices toen was vaak dat het werkte op IE6 en in andere browsers helemaal niet.

PHP is dus dusdanig conservatief dat zaken enkel deprecated worden indien onfixbaar onveilig of niet meer onderhoudbaar.
(Offtopic, maar Microsoft levert juist vaak bizar epische inspanningen om support te rekken, je kan wellicht geen slechter voorbeeld erbij halen)

Dan kan ik in de zin alleen PHP een pluim geven. En wat betreft Microsoft, beide komt voor. Zowel het rekken van compatibiliteit als het deprecaten van bepaalde onderdelen. Vaak sluit bij hun het ene het andere ook niet uit met allerlei mogelijk onvoorspelbare gedrag en bugs/beveiligingsgaten tot gevolg

Het zal wel niet zo lineair zijn dat men er 40 jaar over doet. Prima als men eerst de kat uit de boom kijkt, maar inmiddels mag (en zal ) de adoptie - mede door dit nieuws - wel wat vlotter gaan.

Reken realistisch op 10-20 jaar. Immers IE6 komt ook nog steeds voor in websites, XP is eerder uitgefaseerd (al draaien sommige gemeenten ook nog steeds W2K of Office 2K.

[WillySis]

Software en websites hebben normaal een lifspan van 3 à 4 jaar. Natuurlijk begin je niet elke 3 jaar opnieuw van nul af, maar neem je een groot deel van de code over.
Als je dat doet moet je wel bij de tijd blijven en de nieuwste technologie gebruiken, of minimaal in het achterhoofd houden. Alle depreciated functies zal je op moeten sporen en moeten vervangen. Als dit je dit systeem volgt hoeft niemand zich grote zorgen te maken en moet het compatible maken met PHP7.1 wel binnen twee jaar te doen zijn met het reguliere onderhoud.

Veel bedrijven houden echter te lang vast aan verouderende systemen. Aan de ene kan begrijpelijk. Wat werkt moet je niet veranderen, maar aan de andere kant maak je jezelf ook kwetsbaar. Het stoppen van de ondersteuning van PHP 5. zien we al twee jaar aankomen en in de handleiding staat al die tijd al welke depreciated code in PHP 7 gaat verdwijnen. Als je als bedrijf beslist om software een tijd lang niet te onderhouden is dat uiteindelijk verkeerde zuinigheid. Je schuift gewoon werk door en creeert pieken op het moment dat de ondersteuning wordt stopgezet.

[aadje93]

dus jouw site doet het prima op 7, maar die van de buurman die ernaast komt te draaien doet het niet

Dat is dus een beetje nonsense opmerking, je huidige site kan ook gewoon problemen ondervinden met php 7 *spreekt uit wat ervaring met enkele migraties van 5.x -> 7/7.1*

[Creesch]

Hoezo? Beveiligingsupdates blijven nog twee jaar uitkomen, dat is meer dan genoeg tijd om te migreren naar een nieuwe versie.

[FreshMaker]

Hoezo? Beveiligingsupdates blijven nog twee jaar uitkomen, dat is meer dan genoeg tijd om te migreren naar een nieuwe versie.

Dat is imho de grootste fout die je kan maken.
Al bestaande scripts blijven draaien, en je hebt 2 jaar de tijd om te updaten.

Maar om nu nog zaken weg te zetten in een formaat wat ( in die optiek nog ) máár twee jaar 'goed' is, is gewoon slecht beleid.
Datzelfde beleid had met met IE6 scripts, hele afdelingen die op een IE6only "webapp" werkten ..

[Creesch]

Beter lezen, ik zeg niet dat ze twee jaar moeten wachten. Ik zeg dat ze nog twee jaar hebben om goed te migreren. Uiteraard is het beter om dit vroeger dan later te doen.

[FreshMaker]

Maar dat vinden 'managers' vaak niet, want is overbodig werk ( lees - kost teveel )
Wij hadden hier ook zo'n interim, De administratie werkte prima, want alles deed het toch.

Ja, op de oude machines wel, XP + IE6, maar de nieuwe apparaten die al standaard met Win7 kwamen, ( en IE 8 / 9 ) waren problemen mee.
"Dan zet je toch 'even' IE6 terug !"

gevolg, NA zijn afscheid waren de bezuinigingen prima verlopen, de nieuwe manager mocht de puinzooi opriuimen ( en dus het budget opmaken wat eigenlijk voor de voorgaande jaren was, nu in zijn 'termijn' )
Dus achterstand en weer problemen die voorkomen hadden kunnen worden ( want er was toch nog 2 jaar ondersteuning op IE6, die ondertussen vervallen was

[NullCrayfish]

En zelfs daarna heb je eventueel nog Hardened-PHP.
Je zou zelfs nog zorgeloos een PHP4.4 script kunnen draaien.

[Faeron]

Het gaat ze vooral laten zien hoe goed hun code is. Een goed geschreven PHP5 applicatie draait zonder problemen met PHP7. Ik kon al mijn applicaties in ieder geval zonder enige aanpassing overzetten naar een server met PHP7.

[Basszje]

7.1.0 heeft wel een kleine verandering die bij mij in een enkele instantie (arrays) zorgde voor een Fatal Error. Maar idd over het algemeen is de overgang pijnloos tussen de PHP versies.

Helaas draait +/- 10% van het web nog zelfs op oude versies als 5.2 wat voor meer problemen zorgt.

[Yggdrasil]

Inderdaad. De upgrade van 5.2 naar 5.3 was pittiger. Toen waren er aardig wat veranderingen in onze (inmiddels) oudere applicaties.

[Anoniem: 426269]

Ander bedrijven gaan het weer geld opleveren. Ktsjinggg, uurtjes maken en kassa. Hehehe

[dj.verhulst]

vind het alleen stom dat veel hosting providers geen actief beleid hebben om hun klanten te upgraden.
en als het zo ver is soms vragen dat jij je site maar exporteerd en weer importeerd

[dbzokphp]

Sommige hostingproviders informeren weldegelijk omtrent PHP updates. Bij mijn hostingprovider bijvoorbeeld, mijn.host heb ik me aangemeld voor een mailing over nieuwe updates en kan ik zelf de PHP versie kiezen van mijn hosting.

[dj.verhulst]

sommige dus niet allemaal...

ze leggen de bal te veel bij de eindgebruiker, niet iedere klant is een tweaker.
het valt me gewoon op dat de ene er werk van maakt en de ander gewoon niet

[hackerhater]

Ik heb zelf een klein hosting bedrijfje en we bieden nu actief 5.5 en 7 aan (switch in DA control panel)
Binnenkort gaan de waarschuwing eruit dat we over een paar maanden naar 5.6 gaan (server hebben we een tijdje geleden overgenomen)
En dan over 1,5 jaar of zo 5.6 uit faseren.

Met zachte hand de klanten dwingen te upgraden.

[Reactie gewijzigd door hackerhater op 23 juli 2024 17:27]

[dj.verhulst]

je heb totaal weigeraars

maar ik kreeg een voorstel , ik moet 3 omgevingen erbij nemen en dat kost me geld
dan moest ik de boel zelf maar over zetten ...
dat vind ik niet een normale manier van doen.

terwijl mijn privé hosting partner , zette bijna alles over , de site 1:1 over zonder gedoe.

[hackerhater]

Het kost onze klanten niks extra's.
De voorwaarschuwing is puur dat ze hun sites bij moeten werken zodat ie niet kapot gaat.

[MadEgg]

Nog lang niet uit de running dus, en voorlopig ook niet onveilig. Maar goed dat ze vooruit blijven gaan. Bij Python had er ook wel wat meer druk op de overgang van 2.7 naar 3.x gezet mogen worden, dat is echt een gebed zonder eind.

[The Zep Man]

Nog lang niet uit de running dus, en voorlopig ook niet onveilig. Maar goed dat ze vooruit blijven gaan. Bij Python had er ook wel wat meer druk op de overgang van 2.7 naar 3.x gezet mogen worden, dat is echt een gebed zonder eind.

Python wordt breder ingezet dan PHP. Waar PHP meestal alleen webservices betreft, wordt Python bijvoorbeeld gebruikt voor server-side beheer. Er zijn veel (soms gesloten) systemen die uitgaan van Python 2. Hierom denk ik dat het lastig(er) is om Python 2 uit te faseren.

[MadEgg]

Och, een simpele EOL-stempel op Python 2.7 zou een hoop helpen denk ik. Zolang Python 2.x nog ondersteund wordt is er weinig druk om over te stappen. De meeste libraries zijn al over, en code porten van Python 2 naar 3 is ook helemaal niet zo lastig. Dan kunnen ze nog beter een from __past__ import * constructie toevoegen om het op file niveau anders te regelen.

Maar goed, off-topic bij PHP ;-)

Bij PHP vind ik het zelf iets te snel gaan (al ligt dit niet per se aan PHP zelf natuurlijk), in de zin dat Ubuntu bij 16.04 standaard geen packages voor PHP5.6 meelevert. Je moet dan zelf extra repositories toevoegen. Was mijns inziens een beetje te vroeg. Wel een beetje te verdedigen vanuit de extended support van PHP die december 2018 eindigd terwijl 16.04 nog wat langer ondersteund wordt maar het is niet de eerste keer dat die situatie optreedt en ze zijn ook geen vreemden van security fixes backporten.

[Kevin-de-Groot]

Als je applicatie goed is geschreven, is dit geen schokkend nieuws. Meeste (veelgebruikte) functionaliteit blijft gewoon naar behoren werken. Afgezien het feit dat het misschien wat werk is om hier en daar wat code te herschrijven, zie ik geen reden om niet over te stappen naar PHP7. Het lijkt mij alleen maar beter/mooier om over te stappen, denk aan scalar type hints, de null coalescing operator en de return type declarations (zie hier). Betreft de mysql_* functies, deze zouden eigenlijk al niet gebruikt moeten worden IMO. En dan heb ik het niet over de snelheidswinst.

[Booster]

Als het om webhosting gaat, denk ik dat veel websites nog op PHP 5.3 draaien. Sommige oudere webapplicaties die jaren geleden populair waren maar sindsdien niet meer geupdate voor nieuwe PHP-versies, worden nog steeds actief gebruikt. Denk aan oude gallery-software, kleine CMSjes met minder features dan WordPress, etc. Bovendien schakelen veel webhosters hun klanten niet actief over naar nieuwere PHP-versies, en is PHP 5.3 nog wel kiesbaar in het control panel dat wordt gebruikt.

Sterker nog, als we de statistieken van w3techs bekijken, dan zien we dat PHP 5.3 nog altijd de meest populaire versie uit de hele PHP 5-reeks is, met een aandeel van 25%. Als je alle PHP-versies van vóór PHP 5.6 pakt, hebben die samen zelfs een aandeel van bijna 80%.

Kort samengevat: veel mensen maakt het totaal niet uit of de ondersteuning voor een PHP-versie is vervallen. PHP 5 is op dit moment de meest compatible keuze, je kunt er de meeste software op draaien. In dat licht vrij logisch dat veel mensen nog niet over zijn naar PHP 7 (in de webhostingmarkt).