WordPress, PHP en plugins: wie houdt wat bij?

Eén website bestaat uit meerdere afspraken

Van buiten zie je een website met pagina's, afbeeldingen en knoppen. Achter die voorkant kunnen meerdere leveranciers en technische onderdelen samenwerken. Een probleem in het ene onderdeel kan zichtbaar worden in een heel ander onderdeel.

Een fictief voorbeeld: een bezoeker vult een offerteformulier in en ziet een bedankmelding. Dat voelt als een geslaagde aanvraag. Maar als de koppeling naar de mailbox of het CRM niet werkt, heeft het bedrijf niets ontvangen. De pagina werkte; de zakelijke route niet.

Daarom willen we niet alleen weten of ‘de website onderhouden wordt’. We willen weten welke onderdelen onder die afspraak vallen en wie de complete route controleert. Onderhoud is pas duidelijk wanneer je het kunt koppelen aan een concrete handeling van een bezoeker of medewerker.

De vijf lagen in gewone taal

Een bruikbaar denkmodel voor een WordPress-website bestaat uit vijf lagen. De hosting levert de omgeving. PHP voert servercode uit. WordPress verzorgt de basis van de website. Thema's en plugins voegen uiterlijk en functies toe. Externe diensten verzorgen bijvoorbeeld mail, betalingen of planning.

Dat is een praktische indeling, geen volledige technische architectuur. Sommige leveranciers combineren lagen in één pakket. Andere verdelen ze over verschillende partijen. De namen op de factuur vertellen niet vanzelf hoe de verantwoordelijkheid is verdeeld.

Schrijf daarom per laag op wie toegang heeft, wie wijzigingen uitvoert en wie fouten onderzoekt. Dezelfde persoon mag meerdere rollen hebben. Het probleem is niet dat één partij veel doet, maar dat niemand weet wie een bepaalde taak daadwerkelijk heeft aangenomen.

WordPress bijwerken is niet hetzelfde als PHP bijwerken

Een WordPress-update verandert het CMS. Een PHP-update verandert een onderdeel van de uitvoeromgeving. Het ene bijgewerkte onderdeel bewijst niet dat het andere ook is bijgewerkt. Vraag dus om afzonderlijke bevestiging wanneer beide relevant zijn.

WordPress publiceert een compatibiliteitsoverzicht voor zijn eigen versies en PHP-versies. Dat overzicht zegt iets over WordPress zelf; een complete website bevat daarnaast thema's, plugins en eventueel maatwerk die eigen aandacht vragen. WordPress-overzicht van PHP-compatibiliteit.

Voor jou als eigenaar volgt daar een eenvoudige vraag uit: ‘Geldt jullie bevestiging voor WordPress zelf of ook voor onze gebruikte functies?’ Het antwoord hoeft niet direct perfect te zijn. Het moet wel duidelijk maken wat bekend is en wat nog getest moet worden.

Een groen dashboard is een deelantwoord

Een dashboard met weinig meldingen kan prettig zijn, maar is geen zelfstandig onderhoudsrapport. Het laat alleen zien wat die specifieke interface kan zien. De status van een andere server, een verlopen externe koppeling of een achtergrondtaak hoeft er niet in te staan.

Vraag daarom niet om een verzameling groene vinkjes. Vraag om een korte beschrijving van de belangrijke routes: contact, boeking, account, bestelling of download. Zijn die getest? Wanneer? Waar eindigde de handeling? Wat kon niet worden gecontroleerd?

Dat gesprek levert vaak sneller nuttige informatie op dan een discussie over welk technisch onderdeel ‘de schuld’ heeft. Je begint bij de uitkomst die je nodig hebt en verdeelt daarna de benodigde controles over de juiste mensen.

Plugins zijn functies met een eigenaar

Plugins breiden WordPress uit. De officiële documentatie beschrijft ze als software die functies toevoegt en via het beheer geïnstalleerd en bijgewerkt kan worden. Het feit dat een plugin beschikbaar is, zegt nog niet dat hij voor jouw volledige werkwijze voldoende wordt onderhouden of getest. WordPress-documentatie over plugins.

Wij zouden iedere belangrijke plugin behandelen als een kleine zakelijke afhankelijkheid. Niet met een dik contract voor iedere knop, maar met antwoord op vier vragen: waarom gebruiken we hem, wie beheert hem, wat gebeurt er bij een storing en wat is het alternatief?

Een plugin voor een kleine visuele toevoeging verdient een andere behandeling dan een plugin die alle reserveringen beheert. Beiden kunnen onderhoud nodig hebben. De gevolgen van uitval verschillen alleen sterk, en daarmee ook de volgorde van testen en vervangen.

Deel functies in op gevolgen, niet op populariteit

Maak drie groepen. In de eerste staan functies waardoor klanten niet kunnen aanvragen, betalen of inloggen als ze uitvallen. In de tweede staan functies die werk vertragen of handmatige correctie vragen. In de derde staan onderdelen waarvan een tijdelijke afwijking vooral zichtbaar, maar minder ingrijpend is.

Die indeling is een eigen werkhulpmiddel, geen keurmerk voor software. Een bescheiden formulier kan voor jouw bedrijf belangrijker zijn dan een groot pakket met veel downloads. De vraag is wat jouw onderneming nodig heeft om haar afspraken na te komen.

Loop ook ongebruikte functies na. Wat niemand bewust meer gebruikt, kan toch nog onderdeel zijn van een oude route. Verwijder daarom niet blind alles wat onbekend lijkt. Laat eerst controleren of er nog pagina's, taken of gegevens van afhankelijk zijn en spreek daarna een gerichte opruimactie af.

Wie is waarvoor verantwoordelijk?

Een onderhoudsafspraak wordt pas bruikbaar als zij onderscheid maakt tussen uitvoeren, controleren en beslissen. De uitvoerder past software aan. De controleur beoordeelt het resultaat. De eigenaar beslist over kosten, beperkingen en acceptabele bedrijfsimpact.

Bij een klein bedrijf kunnen die rollen deels samenvallen. Toch helpt het om ze apart te benoemen. Een host kan een PHP-update technisch uitvoeren, maar weet niet vanzelf hoe jouw offerteproces hoort te eindigen. Een webbouwer kan het formulier testen, maar mag niet automatisch beslissen dat jouw winkel een dag dicht kan.

Gebruik onderstaande verdeling als gesprekstart, niet als aanname over jouw contract:

De tabel moet uiteindelijk namen of rollen bevatten die voor jouw bedrijf herkenbaar zijn. ‘De techniek’ is geen aanspreekpunt. ‘Onze host voor de runtime, onze webbouwer voor de aanvraagroute’ is dat wel.

Maak onderhoud begrijpelijk voordat je het koopt

Een pakket met ‘updates inbegrepen’ kan heel verschillende dingen betekenen. Misschien voert de leverancier updates automatisch uit. Misschien beoordeelt hij ze handmatig. Misschien vallen betaalde plugins, maatwerk of herstel na een conflict buiten de afspraak.

Geen van die modellen is op zichzelf verkeerd. Onduidelijkheid is het probleem. Vraag vooraf wat de leverancier doet vóór, tijdens en na een wijziging. Vraag ook welke werkzaamheden extra overleg of een aparte opdracht vragen.

Een bruikbare uitleg past meestal in gewone taal: wij controleren deze onderdelen, voeren deze soorten updates uit, testen deze routes en melden deze uitzonderingen. Als het antwoord alleen uit productnamen bestaat, vraag dan door naar de gevolgen voor jouw bedrijf.

Acht vragen voor je onderhoudsgesprek

Neem deze vragen mee naar je huidige leverancier of naar een mogelijke nieuwe beheerder:

1. Welke onderdelen van onze website vallen precies onder jullie beheer?
2. Wie houdt PHP en de hostingomgeving bij?
3. Welke klantacties controleren jullie na een relevante wijziging?
4. Hoe horen wij dat een update niet uitgevoerd kan worden?
5. Wie betaalt en beheert licenties voor noodzakelijke plugins?
6. Wat gebeurt er wanneer een leverancier zijn plugin niet meer onderhoudt?
7. Hoe wordt herstel voorbereid en wie beslist over terugzetten?
8. Welke informatie krijgen we mee als we later overstappen?

Let vooral op samenhang tussen de antwoorden. Een leverancier die backups noemt, maar niet kan uitleggen hoe een herstel wordt aangevraagd of getest, heeft nog geen volledig antwoord op continuïteit gegeven.

Automatisch bijwerken vraagt nog steeds om afspraken

Automatische updates kunnen werk uit handen nemen. WordPress biedt instellingen voor automatische plugin- en thema-updates. Daarmee is de uitvoering echter nog niet hetzelfde als het beoordelen van jouw bedrijfsproces. WordPress-uitleg over automatische updates.

Onze voorkeur is niet automatisch alles aan of alles uit. We willen een bewuste keuze per omgeving en functie. Een eenvoudige informatiesite heeft andere gevolgen bij uitval dan een omgeving waarin klanten dagelijks dossiers aanpassen.

Bepaal daarom wie meldingen ontvangt, hoe fouten ontdekt worden en wanneer iemand kan ingrijpen. Zonder die afspraken kan automatisering vooral sneller onduidelijkheid produceren. Met goede afspraken kan zij juist terugkerend werk verminderen en ruimte geven voor de controles die menselijk oordeel nodig hebben.

Laat een uitzondering niet ongemerkt permanent worden

Soms wordt een update tijdelijk uitgesteld omdat een noodzakelijke functie nog niet compatibel is. Noteer dan de reden, de verantwoordelijke en de eerstvolgende beslissing. Maak ook duidelijk welke tijdelijke maatregel passend is bij het risico.

Een notitie als ‘deze plugin niet updaten’ zonder datum wordt gemakkelijk een jarenlange blokkade. Een betere notitie beschrijft welk probleem de update veroorzaakt, welke vervanging of aanpassing wordt onderzocht en wanneer de keuze opnieuw wordt beoordeeld.

Bij een beveiligingsprobleem kun je niet alleen naar gebruiksgemak kijken. De afweging kan betekenen dat een functie tijdelijk beperkt moet worden. Voor het feitelijke updateproces, inclusief een veilige terugweg, hebben we een afzonderlijk draaiboek voor PHP updaten zonder uitval.

Een plugin vervangen is ook een proceswijziging

Wanneer een plugin niet meer past, lijkt vervangen soms eenvoudig. Je kiest een alternatief, installeert het en verwijdert het oude pakket. Maar de echte vraag is wat er met gegevens, links, werkwijzen en klantverwachtingen gebeurt.

Een fictieve opleider bewaart inschrijvingen in een boekingsplugin. Een alternatief kan technisch goed werken en toch niet dezelfde exports, herinneringen of toegang voor medewerkers hebben. De beslissing gaat dan niet alleen over softwarekwaliteit, maar over de volledige manier waarop het team werkt.

Maak daarom eerst een lijst van noodzakelijke functies. Zet gewenste verbeteringen apart. Anders groeit een noodzakelijke vervanging ongemerkt uit tot een groot vernieuwingsproject dat de oorspronkelijke onderhoudstaak maanden vertraagt.

Controleer de uitweg voordat je instapt

Vraag hoe gegevens kunnen worden geëxporteerd, wie eigenaar is van het account en welke onderdelen stoppen als een abonnement eindigt. Controleer ook of documenten of bevestigingen buiten de website worden opgeslagen. Dat zijn praktische continuïteitsvragen, geen wantrouwen tegenover een leverancier.

Een overstapplan hoort te beschrijven welke gegevens mee moeten, welke oude links behouden blijven en hoe medewerkers worden geïnformeerd. Test bovendien een representatieve handeling van begin tot einde voordat de oude route wordt uitgezet.

Gebruik voor een eerste vergelijking geen echte klantdossiers in allerlei proefaccounts. Begin met verzonnen voorbeelden die de benodigde functies laten zien. Pas wanneer een oplossing werkelijk gekozen is, bepaal je hoe gegevens zorgvuldig en met de juiste toegang worden overgebracht.

De websitebouwer is niet automatisch de host

Veel misverstanden ontstaan doordat de partij die de website bouwde als vanzelf verantwoordelijk wordt gehouden voor alle onderliggende diensten. Soms is dat afgesproken, soms niet. De facturen en toegangsrechten kunnen een heel ander beeld geven.

Als je zelf hosting hebt aangeschaft en een andere partij de website bouwde, moet iemand de overgang tussen die twee beheren. Anders kan de host wijzen op applicatiecode terwijl de bouwer wijst op serverinstellingen. De eigenaar blijft dan met een probleem zitten dat technisch tussen de partijen hangt.

Spreek af wie het onderzoek coördineert. Dat betekent niet dat één partij ieder probleem zelf moet oplossen. Het betekent dat er één aanspreekpunt is dat informatie verzamelt, de juiste partij inschakelt en terugkoppelt wat wel en niet bevestigd is.

Een heldere melding versnelt samenwerking

Stuur bij een storing een beschrijving van de handeling, het tijdstip, de betrokken route en het zichtbare resultaat. Vermeld ook wat kort daarvoor is gewijzigd. Voeg geen wachtwoorden of complete klantgegevens toe om een probleem uit te leggen.

Een bruikbaar fictief bericht luidt: ‘Na de wijziging van vanochtend geeft het aanvraagformulier wel een bevestiging, maar het afgesproken testrecord ontbreekt. De gewone pagina's openen. Kunnen jullie samen vaststellen waar de overdracht stopt?’ Dat richt het onderzoek op een toetsbare route.

‘De website doet raar’ kan een eerlijk eerste signaal zijn, maar is nog geen werkopdracht waarmee twee leveranciers efficiënt kunnen handelen. De coördinator helpt dat signaal te vertalen zonder dat jij alle technische details hoeft te leren.

Onderhoud en doorontwikkeling zijn andere soorten werk

Onderhoud houdt bestaande afgesproken functies bruikbaar en verantwoord beheerd. Doorontwikkeling voegt nieuwe functies of werkwijzen toe. In de praktijk raken die elkaar, maar ze verdienen verschillende besluiten.

Als een verouderde plugin vervangen moet worden, kan een nieuw ontwerp aantrekkelijk zijn. Toch wil je weten welk deel noodzakelijk is om de bestaande dienst te behouden en welk deel een commerciële verbetering is. Zo kun je urgent onderhoud goedkeuren zonder automatisch een complete herbouw te bestellen.

Vraag daarom om een voorstel in twee delen. Eerst de minimale noodzakelijke ingreep met risico's en controles. Daarna eventuele verbeteringen met een eigen afweging. Dat helpt bij budget, planning en verwachting, vooral wanneer een beveiligingsmelding druk op de beslissing zet.

Een fictieve eigenaar maakt de verdeling concreet

Stel dat een interieurbouwer een WordPress-site heeft met projecten, een contactformulier en een afspraakaanvraag. De host regelt de server. Een webbouwer beheert het ontwerp. Een medewerker ontvangt aanvragen in een gedeelde mailbox. Er is geen webshop en geen complex ledenplatform.

De eigenaar vraagt iedere partij eerst wat zij daadwerkelijk beheert. Daaruit blijkt dat de webbouwer wel plugins bijwerkt, maar niet controleert of aanvragen aankomen. De host onderhoudt PHP, maar heeft geen inzicht in het formulier. De medewerker merkt fouten pas wanneer een klant belt.

De oplossing hoeft geen nieuw groot systeem te zijn. Het team spreekt af dat de webbouwer na relevante wijzigingen een herkenbare testaanvraag doet, de medewerker ontvangst bevestigt en de host wijzigingen aan de runtime vooraf meldt wanneer dat mogelijk is. De eigenaar krijgt alleen uitzonderingen die een besluit vragen.

Vervolgens leggen ze vast wie de betaalde pluginlicentie bezit en hoe de website overdraagbaar blijft. Dat voorkomt een tweede probleem: afhankelijk worden van een account dat niemand meer kan beheren als een samenwerking stopt.

Dit voorbeeld is bewust verzonnen. Het laat zien dat een betere onderhoudsafspraak vaak begint bij een ontbrekende overdracht, niet bij nóg een plugin of een duurder hostingpakket.

Een beslisroute bij tegenstrijdige adviezen

Krijg je verschillende adviezen van host en bouwer? Begin dan met de feiten waarover ze het eens zijn. Welke omgeving wordt bedoeld? Welke wijziging is voorgesteld? Welke functie geeft een fout? Welke ondersteuning is bevestigd?

Vraag vervolgens iedere partij om het eigen onderdeel te beschrijven. De host kan aangeven wat beschikbaar en actief is. De bouwer kan aangeven welke applicatieonderdelen getest zijn. Zo wordt zichtbaar of er echt een inhoudelijk verschil is of alleen een verschil in perspectief.

Laat een onopgeloste afhankelijkheid expliciet staan. Als niemand kan bevestigen dat een noodzakelijke plugin werkt op een passende runtime, is de volgende stap onderzoek of vervanging. Het is geen reden om ‘alles zal wel goed gaan’ als gezamenlijk besluit te noteren.

Bij de actuele beveiligingsmeldingen helpt het om één bronoverzicht te gebruiken. Daarvoor verwijzen we naar de PHP-kwetsbaarheid van oktober 2026. Zo voeren partijen het gesprek over dezelfde aanleiding en niet over verschillende, doorgestuurde samenvattingen.

Wat een bruikbaar onderhoudsverslag bevat

Een ondernemer heeft meestal geen behoefte aan tientallen technische pagina's. Wel aan een kort verslag dat onderscheid maakt tussen uitgevoerd, gecontroleerd en nog open. Dat onderscheid voorkomt dat ‘geüpdatet’ als synoniem voor ‘volledig getest’ wordt gebruikt.

Vraag per relevante wijziging om datum, omgeving, betrokken onderdelen en resultaat van de belangrijke controles. Laat open punten voorzien van een eigenaar en een volgende stap. Als een leverancier iets buiten zijn opdracht heeft gelaten, moet dat zichtbaar zijn zonder dat je kleine lettertjes hoeft te ontcijferen.

Bewaar ook de relatie met herstel. Is de terugweg alleen beschreven of ooit beproefd? Wat is het laatste bewijs? Wie kan het proces starten als de vaste contactpersoon afwezig is? Het artikel over backup en hersteltest helpt om die vragen praktisch te maken.

Veelgestelde vragen

Zorg dat er iemand over de grenzen heen kijkt

De beste afspraak is niet degene met de meeste technische termen. Het is de afspraak waarbij iedereen weet wat hij doet, welke uitkomst hij controleert en wanneer hij een ander nodig heeft. Dan wordt een melding van de host geen rondgestuurde vraag zonder eigenaar.

Wil je de huidige verdeling laten beoordelen en duidelijk krijgen waar onderhoud of functionele controle ontbreekt? Bekijk wat een WordPress-specialist voor die samenhang kan betekenen. We beginnen bij je bestaande website en de functies die je bedrijf werkelijk gebruikt.