Kennisbank · Webdevelopment
Wat is PHP?

PHP is een programmeertaal die op de server draait. Hij bouwt de pagina op voordat die naar de browser wordt gestuurd, en de bezoeker krijgt de code zelf nooit te zien.
Het is de taal waarin WordPress is geschreven, en daarmee de taal waarop een fors deel van het web draait. Ook Drupal, Joomla, Magento en veel maatwerksystemen gebruiken PHP. Voor wie een website beheert komt het bijna altijd op hetzelfde neer: PHP is de motor onder je site en de versie ervan is een instelling waar je iets mee moet.
Wat er gebeurt als iemand je pagina opent
Een bezoeker tikt een adres in. De webserver, meestal Apache of nginx, ziet dat er een PHP-bestand bij hoort en geeft dat door aan PHP. PHP voert de code uit, haalt onderweg dingen op uit de database, plakt daar HTML omheen en levert het resultaat terug.
Wat de browser binnenkrijgt is dus gewoon HTML, aangevuld met stijl en scripts. Klik op je site op "paginabron weergeven" en je ziet geen letter PHP. Dat is het hele punt: de code blijft op de server.
Bij WordPress betekent dit dat elk bezoek aan een pagina die niet in de cache staat een klein programma start. WordPress laadt zichzelf, je thema en al je plugins, stelt de pagina samen en gooit die weg. Bij het volgende bezoek begint dat opnieuw. Zodra je dat doorhebt begrijp je ook waarom een site met veertig plugins traag is.
Wat je met PHP doet
Alles wat per bezoeker of per moment verschilt. Een pagina samenstellen uit een database, een formulier verwerken, iemand inloggen en herkennen, een bestelling opslaan, een betaling afhandelen, een factuur maken.
Ook alles wat op de achtergrond loopt. WordPress heeft een eigen taakplanner die geplande berichten publiceert, updates controleert en back-ups start. Dat is allemaal PHP dat draait zonder dat iemand het ziet.
Wat PHP niet doet is iets in het scherm van de bezoeker veranderen: een menu dat openklapt of een veld dat rood wordt terwijl je typt is het werk van JavaScript.
Hoe PHP-code er ongeveer uitziet
Een variabele begint met een dollarteken en bewaart een waarde: een naam, een bedrag, een lijst met producten. Zo'n lijst heet een array. Met een lus loop je die af, en zo ontstaan de tien blogberichten onder elkaar op je overzichtspagina.
Een functie is een stukje werk met een naam. PHP levert er honderden mee. echo zet iets op het scherm, strlen telt het aantal tekens in een tekst, count telt de items in een lijst en date geeft datum en tijd van de server. Daarnaast schrijf je zelf functies voor werk dat terugkeert.
PHP-code staat tussen openings- en sluitingstekens, en alles daarbuiten wordt onveranderd doorgegeven. Daardoor kun je HTML en PHP door elkaar zetten. Prettig om mee te beginnen, en precies de reden dat er zoveel onleesbare oude code bestaat.
PHP en de database
Vrijwel elke PHP-site praat met een database, meestal MySQL of MariaDB. Je teksten, gebruikers, instellingen en bestellingen staan daar, niet in je bestanden. PHP stelt een vraag, krijgt rijen terug en maakt daar een pagina van. Gaat dat mis, dan zie je meestal geen foutmelding maar een lege of half opgebouwde pagina.
Binnen WordPress praat je zelden rechtstreeks met de database. Je gebruikt de functies die WordPress aanbiedt, en die regelen meteen dat je vraag veilig wordt samengesteld. Wie toch zelf een query schrijft, hoort dat via de voorbereide variant te doen, waarbij de waarden apart worden meegegeven in plaats van in de tekst geplakt. Dat is de belangrijkste gewoonte die je jezelf kunt aanleren.
Objecten, pakketten en raamwerken
Bij grotere projecten schrijf je geen losse functies maar klassen: een bouwtekening met eigenschappen en handelingen bij elkaar, waarvan je objecten maakt. Een klasse Factuur weet wat een factuurnummer is, hoe je btw berekent en hoe je hem naar pdf schrijft.
Daar hoort een pakketbeheerder bij. Met Composer haal je bestaande onderdelen binnen, bijvoorbeeld een pakket dat pdf's maakt of dat met de API van een boekhoudpakket praat, en hij regelt meteen dat je klassen worden geladen zodra je ze gebruikt.
WordPress zelf is grotendeels op de oude manier geschreven, met losse functies en een systeem van haken waarmee je code op een bepaald moment laat meedraaien. Dat is verouderd in opzet en het is ook de reden dat plugins van twaalf jaar oud vaak nog werken. Achterwaartse compatibiliteit heeft daar gewonnen van schoonheid.
Voor toepassingen die geen website maar echt een programma zijn, schrijf je zelden vanaf nul. Laravel is het bekendste raamwerk, Symfony zit onder veel grote projecten en CodeIgniter kom je vooral tegen in oudere code. Voor een WordPress-site heb je dat niet nodig: WordPress is zelf het kader, en maatwerk schrijf je in een eigen plugin.
PHP naast HTML, CSS en JavaScript
Deze vier komen in elk gesprek over een website langs en ze doen echt iets anders. HTML is de structuur van de pagina: koppen, alinea's, links, afbeeldingen. CSS bepaalt hoe dat eruitziet. JavaScript maakt het beweegbaar in de browser. PHP maakt de HTML die de andere drie te zien krijgen.
Het verschil dat het vaakst voor verwarring zorgt: PHP draait vóór de pagina bij de bezoeker aankomt, JavaScript draait daarna in zijn browser. Iemand kan JavaScript uitzetten of ermee knoeien, PHP-code kan een bezoeker niet aanraken. Daarom hoort elke controle die er echt toe doet aan de PHP-kant te staan. Een formuliercontrole in JavaScript is beleefdheid tegenover de bezoeker, geen beveiliging.
De twee praten wel met elkaar. JavaScript kan tijdens het bekijken van een pagina iets ophalen bij de server, waarna PHP antwoordt. Zo werken een zoekveld met suggesties en een winkelwagen die bijwerkt zonder dat de pagina herlaadt.
Sinds enkele jaren kan JavaScript ook op de server draaien, met Node.js. Dat is dus geen vervanger van PHP maar een concurrent op hetzelfde terrein: beide horen bij back-end ontwikkeling, de kant van de site die de bezoeker niet ziet.
De reputatie van PHP
PHP heeft jarenlang een slechte naam gehad en dat was niet helemaal onterecht. De taal begon in 1994 als een handjevol hulpmiddelen van Rasmus Lerdorf om zijn eigen pagina's bij te houden, en groeide daarna organisch verder. Dat zie je terug in inconsistente functienamen, een losse omgang met datatypes en veel manieren om iets onveilig te doen.
Met versie 7, uit 2015, is dat flink veranderd. De taal werd fors sneller, kreeg strakkere typering en modernere mogelijkheden. Versie 8, uit eind 2020, ging daarmee door. Wie PHP kent uit 2010 kent een andere taal dan wat er nu ligt. Er draait alleen nog enorm veel oude code waarin die verbeteringen nooit zijn doorgevoerd, en het verwijt dat PHP rommelig is slaat vaker op die code dan op de taal.
PHP is open source en gratis. Er zit geen bedrijf achter dat licenties verkoopt, wel een groep ontwikkelaars die met voorstellen en stemmingen bepaalt wat erin komt.
Waarom je PHP-versie ertoe doet
Dit is het punt waar een sitebeheerder het meest aan heeft.
Elke PHP-versie wordt ongeveer twee jaar actief onderhouden en krijgt daarna nog een jaar alleen beveiligingsoplossingen. Daarna stopt het. Wordt er na die datum een lek gevonden, dan komt er voor jouw versie geen reparatie meer. Elk najaar verschijnt er een nieuwe versie, dus die klok tikt door of je nu meekijkt of niet.
Draai je op een versie die uit onderhoud is, dan staat er software op je server waarvan bekend is dat er gaten in zitten die niet meer dichtgaan. Aanvallers scannen het web massaal op verouderde onderdelen, want dat is goedkoop werk met een voorspelbare uitkomst.
Er is ook een prettige kant. Nieuwere versies zijn merkbaar sneller. Bij de sprong van PHP 5 naar 7 ging er een flinke hap van de laadtijd af zonder dat er iets aan de site veranderde. Blijven hangen kost je dus behalve veiligheid ook gratis snelheid.
Je versie opzoeken en wijzigen
In WordPress staat je huidige versie onder Gereedschappen, bij Sitestatus, op het tabblad Info. Daar zie je ook je geheugenlimiet en je databaseversie. WordPress waarschuwt zelf als je versie verouderd is.
Bij je hostingpartij staat het in het beheerpaneel. In Nederland zie je vaak DirectAdmin, daarnaast Plesk, cPanel of een eigen paneel van de hoster. Zoek op PHP of op versiebeheer. Let op dat je de versie bij veel pakketten per domein of per map instelt, dus je testomgeving kan op iets anders draaien dan je hoofdsite.
Het omzetten zelf is een keuzelijstje en een klik. Het risico zit in wat er daarna gebeurt.
Wat er kan breken
Oude functies die uit de taal zijn gehaald. De oude manier om met MySQL te praten verdween met PHP 7, en code die daar nog op leunt geeft meteen een harde fout. Verder is PHP 8 strenger geworden: van alles wat vroeger een waarschuwing gaf die je kon negeren is nu een echte fout gemaakt. Code die jarenlang met een rommelig randje draaide, valt daardoor ineens stil.
Wat er in de praktijk het vaakst omvalt: een plugin die al jaren geen update meer heeft gehad, een thema van een marktplaats waarvan de bouwer verdwenen is, en zelfgeschreven codefragmenten in functions.php die iemand ooit van een forum heeft geplakt.
De volgorde die ik aanhoud
- Eerst updaten, dan overzetten. Werk WordPress, je thema en al je plugins bij. De helft van de problemen lost zichzelf hiermee op.
- Maak een back-up van bestanden en database, en weet hoe je hem terugzet. Een back-up die je nooit hebt teruggezet is een aanname.
- Test op een kopie. Wissel de versie op een testomgeving en loop de belangrijke routes langs: homepage, productpagina, afrekenen, een formulier, de beheeromgeving.
- Zet foutmeldingen tijdelijk aan op die kopie, zodat je ziet wat er misgaat in plaats van naar een witte pagina te staren.
- Wissel daarna live op een rustig moment en klik dezelfde route nog een keer na.
Gaat het mis, dan zet je de versie in hetzelfde keuzelijstje terug. Dat is het prettige aan deze ingreep: hij is in dertig seconden ongedaan te maken.
Kom je een plugin tegen die het op geen enkele nieuwe versie doet, dan is dat geen reden om terug te kruipen naar een oude PHP-versie. Dat is een reden om die plugin te vervangen. Anders houd je je hele site gegijzeld door één stuk verlaten software.
Instellingen die je vaker moet aanraken
PHP heeft limieten die voorkomen dat een doorgeslagen script de hele server opeet. Bij WordPress loop je er af en toe tegenaan.
- Geheugenlimiet. Loopt een pagina vast met een melding over geheugen, dan zit je hier tegenaan. Vaak veroorzaakt door een importscript of een pluginpaneel dat te veel tegelijk ophaalt.
- Maximale uitvoertijd. Een grote import of een back-up die halverwege stopt is meestal dit. Verhogen helpt, maar het werk in stukken knippen is beter.
- Maximale uploadgrootte. Krijg je je video of grote pdf niet in de mediabibliotheek, dan is dit de reden. Twee instellingen moeten samen kloppen: de uploadgrootte en de totale grootte van wat je verstuurt.
- Maximaal aantal invoervelden. De sluipmoordenaar. Sla je een menu met honderden items op en verdwijnt de helft, dan kapt PHP je formulier af bij een vast aantal velden. Je krijgt geen foutmelding, alleen ontbrekende gegevens.
Deze waarden pas je aan in het beheerpaneel van je hosting of in een instellingenbestand. Kan het bij jou geen van beide, dan zegt dat iets over je webhosting.
Beveiliging
De klassieke lekken in PHP-toepassingen zijn al twintig jaar dezelfde en ze zijn allemaal te voorkomen.
SQL-injectie. Iemand vult iets in dat door de database als opdracht wordt uitgevoerd. Dat gaat van gegevens uitlezen tot een tabel legen. De oplossing is altijd dezelfde: nooit invoer rechtstreeks in een query plakken en altijd de voorbereide variant gebruiken.
Cross-site scripting. Invoer die ongefilterd wordt teruggetoond, waarna er bij andere bezoekers script wordt uitgevoerd. De oplossing is alles ontsmetten op het moment dat je het uitvoert, met de functie die past bij de plek: in een tekst, in een attribuut of in een adres.
Onveilige uploads. Een bestand dat als afbeelding wordt aangeboden maar in werkelijkheid code is. Controleer het type, hernoem het bestand en zorg dat er in je uploadmap niets uitgevoerd kan worden.
Foutmeldingen op je live site. Een zichtbare foutmelding verklapt paden, versies en soms databasegegevens. Zet het tonen van fouten uit op productie en schrijf ze naar een logbestand.
In WordPress zitten hier ingebouwde functies voor. Gebruik die en verzin het niet zelf. De rest van de maatregelen, van sterke wachtwoorden tot rechten per gebruiker, staat in het artikel over een WordPress-website beveiligen.
PHP en de AVG
PHP is de plek waar persoonsgegevens door je site heen lopen. Een contactformulier, een bestelling, een account: het passeert allemaal je PHP-code voordat het in de database belandt.
Twee dingen gaan daarbij vaak mis. Het eerste is logging. Foutlogs en debugbestanden bevatten regelmatig complete formulierinhoud, dus namen, adressen en soms wachtwoorden. Zo'n bestand blijft jaren staan en niemand kijkt ernaar. Zet debuglogging uit als je hem niet gebruikt en ruim oude logs op.
Het tweede is de bewaartermijn. Formulierinzendingen in je database groeien eindeloos door. De AVG vraagt gegevens niet langer te bewaren dan nodig, dus stel in je formulierplugin in dat inzendingen na een bepaalde periode worden verwijderd.
Er is ook een direct verband met je PHP-versie. De AVG verlangt passende technische maatregelen om persoonsgegevens te beschermen, en software draaien waarvoor geen beveiligingsupdates meer verschijnen is daarmee moeilijk te rijmen. Moet je ooit een datalek melden bij de Autoriteit Persoonsgegevens, dan is achterstallig onderhoud een vervelend antwoord op de vraag welke maatregelen je had getroffen.
Waar de tijd blijft bij een trage PHP-site
Bij een langzame WordPress-site zit de vertraging bijna altijd in een van deze vier.
Te veel werk per bezoek. Elke actieve plugin draait bij elke paginaweergave mee, ook op pagina's waar hij niets doet. Opruimen levert hier meer op dan een zwaarder hostingpakket.
Database. Zoekopdrachten zonder index, een tabel vol verlopen tijdelijke gegevens, of een pagina die tweehonderd losse vragen stelt in plaats van één.
Wachten op iemand anders. Een script dat tijdens het opbouwen van de pagina een koers ophaalt of een voorraad controleert bij een externe partij. Ligt die partij eruit, dan ligt jouw pagina eruit. Zulke gegevens haal je op de achtergrond op.
Ontbrekende caching. Een opcodecache zit al jaren standaard in PHP en zorgt dat je code niet bij elk bezoek opnieuw wordt vertaald. Daarnaast helpt een objectcache voor databaseresultaten en paginacaching voor bezoekers die niet zijn ingelogd. Bij een gewone bedrijfssite is dat laatste de grootste sprong die je met één instelling maakt.
Om te zien waar het aan ligt heb je meetgegevens nodig. Een plugin die per pagina toont hoeveel query's er draaien en welke code de tijd opsoupeert, wijst je binnen een kwartier de dader aan.
Als je PHP wilt leren
Leer eerst programmeren en de taal zelf, voordat je aan een raamwerk begint. Wie met Laravel begint zonder de basis leert Laravel en niet PHP, en loopt vast zodra er iets buiten de gebaande paden gebeurt.
De officiële handleiding op php.net is je naslagwerk. Bij elke functie staat wat hij verwacht, wat hij teruggeeft en een reeks voorbeelden.
Pas op met oude tutorials. Er staat enorm veel materiaal online uit de tijd van PHP 5, met adviezen die nu onveilig zijn. Kijk altijd naar de datum: ziet een voorbeeld eruit alsof het uit 2009 komt, dan komt het waarschijnlijk uit 2009.
Veelgestelde vragen over PHP
Waar staat PHP voor?
Voor PHP: Hypertext Preprocessor. Dat is een afkorting die naar zichzelf verwijst, wat programmeurs grappig vonden. Oorspronkelijk stond het voor Personal Home Page Tools, de naam van het setje hulpmiddelen waarmee het in 1994 begon.
Wat is het verschil tussen PHP en JavaScript?
PHP draait op de server en maakt de pagina, JavaScript draait in de browser van de bezoeker en past de pagina aan nadat hij is geladen. Een bezoeker kan JavaScript uitzetten of aanpassen, PHP-code niet. Daarom horen controles die er echt toe doen aan de PHP-kant te staan.
Wat is het verschil tussen client-side en server-side?
Server-side betekent dat de code op de server draait voordat de pagina wordt verstuurd. Client-side betekent dat de code in het apparaat van de bezoeker draait. PHP is server-side, JavaScript in de browser is client-side. Wat aan de clientkant staat kan iedereen inzien, inclusief sleutels die je er per ongeluk in zet.
Welke PHP-versie draait mijn WordPress-site?
Ga in je beheeromgeving naar Gereedschappen, Sitestatus, tabblad Info. Onder het kopje over de server staat je PHP-versie. Je hostingpaneel toont hem ook, en daar kun je hem meestal meteen wijzigen.
Hoe wijzig ik de PHP-versie van mijn website?
Bij vrijwel elke Nederlandse hostingpartij doe je dat zelf in het beheerpaneel, bij een instelling die PHP-versie of PHP-selector heet. Je kiest een versie en slaat op.
Doe het niet zomaar op je live site. Update eerst alles, maak een back-up en probeer het op een kopie. Gaat er iets mis, dan zet je de oude versie in hetzelfde scherm terug.
Wat gebeurt er als ik een verouderde PHP-versie draai?
Op de korte termijn meestal niets zichtbaars. Je site draait door, alleen langzamer dan nodig. Het probleem is dat er voor die versie geen beveiligingsoplossingen meer verschijnen terwijl bekende lekken wel openbaar worden gemaakt. Daar komt bij dat WordPress, plugins en thema's een ondergrens stellen, dus op enig moment kun je ook niet meer bijwerken.
Breekt mijn site als ik naar een nieuwere PHP-versie ga?
Bij een goed onderhouden WordPress-site gaat het meestal zonder gedoe. Wat sneuvelt zijn verlaten plugins, oude thema's van marktplaatsen en zelfgeplakte codefragmenten in functions.php. Daarom test je het op een kopie, en vervang je een plugin die het niet overleeft in plaats van je hele site op een oude versie te houden.
Waarom krijg ik een witte pagina zonder foutmelding?
Omdat PHP is gestopt met een fatale fout en het tonen van fouten op je server uitstaat. Dat laatste hoort ook zo op een live site, want een foutmelding verklapt te veel.
Zet in wp-config.php tijdelijk het foutlogboek aan en kijk in het logbestand welke regel in welk bestand de boosdoener is. WordPress stuurt sinds 2019 bovendien een mail naar de beheerder bij een fatale fout, met een link waarmee je in een herstelmodus kunt inloggen.
Is PHP veilig?
De taal zelf is dat, zolang je een ondersteunde versie draait. De lekken die je in de praktijk ziet zitten vrijwel altijd in de code die er bovenop is geschreven, of in een plugin die iemand jaren geleden heeft verlaten.
Voor een WordPress-beheerder komt veiligheid neer op bijwerken, geen verlaten software installeren en een ondersteunde PHP-versie draaien.
Wat zijn populaire PHP-frameworks?
Laravel is de bekendste en heeft de grootste gemeenschap. Symfony wordt veel gebruikt in grotere en langlopende projecten. CodeIgniter en enkele oudere raamwerken kom je nog tegen in bestaande code.
Bouw je op WordPress, dan heb je geen raamwerk nodig. WordPress vervult die rol al, en maatwerk zet je in een eigen plugin.
Kan ik PHP op mijn eigen computer draaien?
Ja. Er zijn pakketten die een webserver, PHP en een database in één keer installeren op Windows of macOS. Daarmee zet je een testsite neer die alleen op je eigen computer bestaat. Dat is de verstandige manier om te leren en om wijzigingen uit te proberen, want wat op je eigen machine stukgaat ziet niemand.
Heb ik PHP-kennis nodig om een WordPress-site te beheren?
Nee. Je kunt jarenlang pagina's, berichten en producten beheren zonder een regel code te zien. Handig is wel dat je weet waar je versie staat en waarom die ertoe doet. Zodra je iets wilt dat geen plugin kan, of een foutmelding wilt begrijpen in plaats van doorsturen, begint kennis van de basis te lonen.
Wat is het verschil tussen PHP en MySQL?
PHP is de taal die de logica uitvoert, MySQL is de database die de gegevens bewaart. PHP stelt vragen aan MySQL en maakt van de antwoorden een pagina. Op de meeste Nederlandse hosting draait trouwens geen MySQL maar MariaDB, een variant die er voor jou hetzelfde uitziet.
Is PHP nog toekomstbestendig?
Voor websites en webtoepassingen met een database eronder is het nog steeds een verstandige keuze. Er verschijnt elk najaar een nieuwe versie en de taal wordt strenger en sneller. Voor mobiele apps, zware rekentaken of verbindingen die urenlang open moeten blijven kies je iets anders. Dat maakt PHP niet verouderd, alleen niet universeel.
Dit artikel hoort bij Webdevelopment. Daar vind je meer uitleg over hetzelfde onderwerp.
