Om 10 uger vil ca 62 procent af alle websider køre en ikke-supporteret PHP-version

Vi har i vores hosting virksomhed valgt at tvinge kunderne op på PHP71. Det har vi gjort i små bider da der bestemt er mange 5.6 sider der breaker efter opgradering. Men de kan så downgrade midlertidig og få deres side rettet til inden vi helt deaktivere mulighed for at bruge 5.6 og 7.0 ved årsskiftet.

Vi har prøvet at informerer vores kunder om det i løbet af året, men oplevet ikke det store reaktion. Men at ens site breaker får folk til at reagerer. Og de fleste kunder kan bagefter godt forstå den lidt hårde fremgangsmåde er for deres eget bedste. At køre med en PHP version uden updates på vores serverer er udelukket. Det er også en kæmpe bjørnetjeneste til kunderne.

Vi vil også hellere døje med løbende support i god ro og orden op til skiftet, end pludseligt at stå med et hav af kunder der alle har fået compromised deres wordpress installation efter de første exploits ser dagens lys næste år.

I artiklen står bl.a.: "Dermed vil vil de omkring 62 procent af alle internetsider, der stadig kører på en PHP 5.x-version, ikke længere modtage sikkerhedsopdateringer"

Det er noget vrøvl. Mange (de fleste?) PHP-installationer er del af grund-operativsystemet, dvs. følger med i fx Red Hat Enterprise Linux, CentOS, Ubuntu, etc. Og dér vil man fortsat modtage sikkerdhedsopdateringer til PHP 5 lang tid endnu, fordi distributøren sørger for at "back-port'e" evt. sikkerhedsrettelser.

Debian, ubuntu mv. backporter normalvis rettelser de får fra leverandører. Så hvis php ikke udgiver sikkerhedsrettelser, er der ikke noget at backporte. De kan derfor blive nødt tilat fjerne support til php5 også.

Mikkel,

Jeg kender ikke detaljerne for alle distributioner, men jeg vil mene, at Red Hat bryder kontrakten, hvis de ikke sørger for at rette de sikkerhedsfejl, som bliver påvist i de PHP5-pakker, som er del af deres aktivt understøttede operativsystem-generationer (6 + 7). Det er jo bl.a. derfor, at de har ansat en hel del programmører.

Mig bekendt, er det også meget udbredt, at Debian pakker indeholder fixes, som Debian selv har tilføjet uden nødvendigvis at have fået dem leveret opstrøms fra.

Kun Drupal har taget et officielt skridt til at tilpasse til den nye version - i marts 2019. Wordpress og Joomla lader stadig vente på dig.

Især Wordpress kritiseres for stædigt at holde fast i en PHP-version fra 2011

Jeg forstår ikke, hvad der menes med dette. WP’s anbefalede PHP-version er 7.2, så hvorfor påstå, at de ikke har taget skridt til at tilpasse til den nye version?

Ganske som du siger. "anbefalet" så det er ikke et krav. Hvis de satte det som et krav vil det se anderledes ud.

Det er noget vrøvl. Mange (de fleste?) PHP-installationer er del af grund-operativsystemet, dvs. følger med i fx Red Hat Enterprise Linux, CentOS, Ubuntu, etc. Og dér vil man fortsat modtage sikkerdhedsopdateringer til PHP 5 lang tid endnu, fordi distributøren sørger for at "back-port'e" evt. sikkerhedsrettelser.

Det er præcis problemet. Nogle distributioner vælger nemlig også at stoppe med opdateringer til deres ældre versioner, og så hænger folk på den forældede version af bl.a. PHP.

Så spørger man måske hvorfor folk ikke opgraderer deres distribution, og her er svaret ofte netop PHP, der stort set altid har haft den 'feature' at hver ny version IKKE er 100% bagudkompatibel med de forrige versioner, hvilket gør at man ikke 'bare' kan opgradere uden at efterlade en masse PHP-programmer i defekt tilstand. Og mange brugere med egenudviklede PHP-applikationer har simpelt hen ikke mulighed for at få tingene checket og opdateret så man vælger at blive hvor tingene virker - og så er der problemer.

Ganske som du siger. "anbefalet" så det er ikke et krav. Hvis de satte det som et krav vil det se anderledes ud.

Ifølge artiklen har WP ikke taget skridt til at tilpasse til den nye version. Men det har de jo gjort. WP understøtter (og anbefaler) PHP 7.2.

Jeg har svært ved at se, at man kan kritisere WP for, at deres produkt herudover stadig kan anvendes på PHP 5.2. Det er fint at have den mulighed, f.eks. hvis man kører legacy-tjenester på et lukket netværk. Og det bør da aldrig være en CMS-leverandør, der skal tage ansvaret for, om kundens bagvedliggende infrastruktur er optimal.