PHP: de motor die je alleen merkt als hij hapert

De meeste ondernemers hebben nog nooit van PHP gehoord, en dat is prima. Tot het moment dat er een mail komt van de hostingpartij. Uw PHP-versie wordt uitgefaseerd, actie vereist. Dan blijkt ineens dat er onder je website iets draait waar je een besluit over moet nemen.

Dat besluit is meestal simpel. Maar het uitstellen ervan is een van de grootste beveiligingsrisico’s die ik bij MKB-sites tegenkom.

Ik loop de versie daarom mee bij elk onderhoudsmoment. Niet omdat het spannend is, maar omdat het stil verouderd.

Een site die twee jaar op een oude versie draait, werkt gewoon. Tot hij het niet meer doet. Of tot iemand binnenkomt via een gat dat allang gedicht had kunnen zijn.

PHP uitgelegd in het webdesign woordenboek van Project Direct
De motor onder je website, die je alleen merkt als hij hapert.

Wat is PHP?

PHP is de programmeertaal waarin WordPress is geschreven. Hij draait aan de serverzijde, dus op je server en niet in de browser van je bezoeker.

Bij elk bezoek doet hij hetzelfde. Hij haalt je teksten uit de database en plakt ze in je sjabloon. Daarna stuurt hij het resultaat naar de browser.

Waarom WordPress erop draait

Omdat het in 2003 de logische keuze was. PHP draaide overal en het was makkelijk te leren.

Dat is nog steeds een voordeel. Vrijwel elke hostingpartij ondersteunt het, en er zijn veel mensen die ermee kunnen werken. Meer over het systeem lees je bij CMS.

Welke versie je nodig hebt

De vuistregel: een versie die nog beveiligingsupdates krijgt. Oudere versies krijgen geen beveiligingsfixes meer.

Elke versie wordt ongeveer twee jaar volledig ondersteund, met daarna nog een jaar alleen beveiligingsfixes. Daarna stopt het.

Draai je op een versie die uit de ondersteuning is, dan blijven bekende lekken openstaan. Dat is geen theoretisch risico.

Wat een oude versie kost

Vier gevolgen

  1. Beveiligingslekken die niet meer gedicht worden.
  2. Plugins die stoppen met werken of niet meer bijgewerkt kunnen worden.
  3. Een tragere site, want nieuwere versies zijn merkbaar sneller.
  4. Een hostingpartij die op enig moment zelf verhoogt.

Die laatste is het vervelendst. Dan gebeurt het op hun moment en niet op het jouwe.

Hoe je verhoogt

Nooit rechtstreeks op je live site. Dit is bij uitstek iets voor een kopie.

Zet je site op een testomgeving, verhoog daar de versie en klik alles door. Je formulieren, je webshop, je inlogscherm. Meer daarover lees je bij DTAP.

Werkt alles, dan verhoog je live. Gaat er iets stuk, dan weet je van tevoren welke plugin de boosdoener is. Bij goede hosting is dat een schakelaar in je klantenpaneel.

Foutmeldingen

Zie je een witte pagina of een blok tekst met bestandsnamen? Dan kijk je naar een van de foutmeldingen.

Zet die nooit zichtbaar op een live site. Ze verraden paden en instellingen die niemand hoeft te weten.

Loop je tegen een geheugenlimiet aan, dan is dat vaak op te lossen bij je hostingpartij. Dat is een instelling en geen bouwwerk. Meer over die kant lees je bij backend.

Je hoeft niet op de nieuwste te zitten

Een versie die net uit is, kan nog problemen geven met oudere plugins. Een versie of twee achter de nieuwste is meestal het veiligst.

Vraag je hostingpartij welke versies zij ondersteunen en welke ze aanraden. Dat antwoord zegt ook iets over hoe actueel hun omgeving is.

Log fouten in plaats van ze te tonen

Laat foutmeldingen wegschrijven naar een logbestand in plaats van ze op het scherm te zetten. Dan kan je bouwer erbij zonder dat je bezoeker iets ziet.

Op een testomgeving zet je ze juist wel zichtbaar. Daar wil je meteen weten wat er misgaat.

Wat een oude versie je kost aan snelheid

Nieuwere versies zijn merkbaar sneller. Bij een verhoging van twee versies zie je dat terug in je laadtijd. En je verandert niets aan je site.

Dat is een van de goedkoopste snelheidswinsten die er zijn. Meer daarover lees je bij hosting.

Meer vragen over PHP

Dit zijn de vragen die ik hierover het vaakst krijg. Ik werk ze los uit.

  • Wat is PHP?
  • Welke PHP-versie heb je nodig?
  • Wat gebeurt er als je PHP-versie verouderd is?
  • Hoe verhoog je je PHP-versie?
  • Wat is een PHP-foutmelding?
  • Waarom draait WordPress op PHP?
De vuistregel is simpel: een versie die nog beveiligingsupdates krijgt. Elke versie wordt ongeveer twee jaar volledig ondersteund. Daarna volgt nog een jaar met alleen beveiligingsfixes, en dan stopt het. Draai je op een versie die uit de ondersteuning is, dan blijven bekende lekken openstaan. Dat is geen theoretisch risico maar een bekend adres voor wie er misbruik van wil maken. Je hoeft niet op de allernieuwste te zitten. Een versie die net uit is, kan nog problemen geven met oudere plugins. Een versie of twee achter de nieuwste is meestal het veiligst. Vraag je hostingpartij welke versies zij ondersteunen en welke ze aanraden. Vraag je hostingpartij welke versies zij ondersteunen en welke ze aanraden. Dat antwoord zegt ook iets over hoe actueel hun omgeving is. Een versie of twee achter de nieuwste is meestal het veiligst, want de allernieuwste kan nog problemen geven met oudere plugins. Vraag ook of ze je waarschuwen voordat ze zelf verhogen.
PHP is de programmeertaal waarin WordPress is geschreven. Hij draait aan de serverzijde, dus op je server en niet in de browser van je bezoeker. Bij elk bezoek doet hij hetzelfde. Hij haalt je teksten uit de database, plakt ze in je sjabloon en stuurt het resultaat naar de browser. De meeste ondernemers hebben er nog nooit van gehoord, en dat is prima. Tot het moment dat er een mail komt van de hostingpartij. Uw PHP-versie wordt uitgefaseerd, actie vereist. Dan blijkt ineens dat er onder je website iets draait waar je een besluit over moet nemen. Dat besluit is meestal simpel. Het uitstellen ervan is een van de grootste beveiligingsrisico’s die ik bij MKB-sites tegenkom. Meer over die kant lees je bij backend. Je hoeft hier niets van te snappen om je site te beheren. Het helpt wel om te weten dat dit bestaat als je hostingpartij erover mailt. Dan weet je dat het over de motor onder je site gaat en niet over je website zelf.
Er gebeurt eerst niets, en dat is precies het probleem. Je site werkt gewoon door. Ondertussen stapelen vier gevolgen zich op. Beveiligingslekken worden niet meer gedicht. Plugins stoppen met werken of kunnen niet meer bijgewerkt worden. Je site wordt trager, want nieuwere versies zijn merkbaar sneller. En op enig moment verhoogt je hostingpartij zelf. Dat laatste is het vervelendst. Dan gebeurt het op hun moment en niet op het jouwe, en dan sta je met een gebroken site op een dinsdagochtend. De kans dat je site het niet overleeft is klein maar reëel. Het gaat vooral mis bij oude plugins die al jaren niet zijn bijgewerkt. Stel het verhogen niet uit omdat je site het nog doet. Dat is precies het probleem: er gebeurt eerst niets. Ondertussen blijven bekende lekken openstaan en wordt je site trager dan nodig. Zet het verhogen daarom in je jaarlijkse onderhoudsronde en wacht niet op een mail.
Nooit rechtstreeks op je live site. Dit is bij uitstek iets voor een kopie. Zet je site op een testomgeving en verhoog daar de versie. Klik daarna alles door: je formulieren, je webshop, je inlogscherm en je speciale functies. Werkt alles, dan verhoog je live. Gaat er iets stuk, dan weet je van tevoren welke plugin de boosdoener is en kun je die eerst vervangen. Bij goede hosting is het verhogen zelf een schakelaar in je klantenpaneel. Het terugzetten ook, en dat is minstens zo belangrijk. Werk je zonder testomgeving, plan het dan op een rustig moment en zorg dat je een recente back-up hebt. Meer over die werkwijze lees je bij DTAP. Doe dit nooit rechtstreeks op je live site. Zet een kopie klaar, verhoog daar en klik alles door. Gaat er iets stuk, dan weet je van tevoren welke plugin de boosdoener is en kun je die eerst vervangen.
Zie je een witte pagina of een blok tekst met bestandsnamen en regelnummers, dan kijk je naar een foutmelding. Die ontstaat als er iets misgaat in de code. Meestal door een plugin die niet met je versie overweg kan, of door een geheugenlimiet die is bereikt. Zet die meldingen nooit zichtbaar op een live site. Ze verraden paden en instellingen die niemand hoeft te weten, en dat is een beveiligingsrisico. Laat ze in plaats daarvan wegschrijven naar een logbestand. Dan kan je bouwer erbij zonder dat je bezoeker iets ziet. Loop je tegen een geheugenlimiet aan, dan is dat vaak op te lossen bij je hostingpartij. Dat is een instelling en geen bouwwerk, dus het kost je een mailtje. Zet foutmeldingen nooit zichtbaar op een live site. Ze verraden paden en instellingen die niemand hoeft te weten. Laat ze wegschrijven naar een logbestand, dan kan je bouwer erbij zonder dat je bezoeker iets ziet. Op een testomgeving zet je ze juist wel zichtbaar, want daar wil je meteen zien wat er misgaat.
Weet je op welke PHP-versie jouw website draait? Stuur me de link via het formulier hieronder. Ik zoek het op en zeg je of hij nog ondersteund wordt en wat er nodig is om veilig te verhogen. Vermeld je plaats, dan weet ik meteen waar je zit.

Waar kan ik je mee helpen?