WordPress-plugin maken met AI: kan dat veilig?

Een kleine WordPress-plugin, een eigen blok of een snippet maak je met AI in een middag, met ChatGPT, Claude Code of de AI-agent in WordPress Studio. Dat is prima voor een interne functie die je eerst op een testsite probeert. Voordat het live gaat, controleert een mens vier dingen: worden invoer en uitvoer opgeschoond, zijn rechten en nonces in orde, werkt het met de volgende versies van WordPress en PHP, en wie onderhoudt het over een jaar.

Een WordPress-plugin maken met AI: wat lukt er in een middag?

Een WordPress-plugin maken met AI kan sneller dan ooit. Je beschrijft in gewone taal wat je wilt, en een AI schrijft de code. Voor een kleine functie heb je binnen een middag iets wat werkt. Dat kan in drie vormen:

• Een snippet: een los stukje code, meestal PHP, dat je met een plugin als Code Snippets of WPCode toevoegt in plaats van het in je thema te plakken.
• Een eigen blok: een bouwsteen voor de blokeditor, zoals een kaart voor een teamlid of een blok met openingstijden.
• Een kleine plugin: een map met een of meer bestanden die je als plugin installeert en aan- of uitzet.

Goede voorbeelden zijn een extra kolom in het overzicht van bestellingen, een shortcode die je openingstijden toont, een melding in het dashboard voor je team of een kleine aanpassing aan de tekst op je productpagina. Allemaal klein, duidelijk afgebakend en makkelijk te testen.

Software laten maken door AI zonder de code te lezen, heet ook wel vibe coding. Wat dat wel en niet oplevert, lees je in vibe coding. Dit artikel gaat over één toepassing: eigen code in je WordPress-site.

Welke AI-tools je kunt gebruiken, stand oktober 2026

En Telex? Dat was het experiment van Automattic om met AI blokken voor WordPress te maken. Telex is gestopt. Op de eigen pagina verwijst Automattic nu onder meer naar WordPress Studio, Claude Code en Codex.

WordPress Studio is voor dit werk het interessantst. Volgens WordPress.com geeft Studio tools als Claude Code, Cursor en Codex de WordPress-kennis en toegang die ze anders missen, via MCP en zogeheten agent skills: vaste instructies over hoe WordPress werkt. Je bouwt dan op een site op je eigen computer, en je live site merkt er niets van. Hoe je met Claude Code een hele website bouwt en waar dat ophoudt, lees je in website bouwen met Claude Code.

Wanneer is het prima, en wanneer niet?

Niet elke functie is even riskant. Gebruik dit stoplicht.

Groen: doe het gerust zelf, met een test vooraf. Een functie die alleen beheerders zien, geen gegevens van bezoekers verwerkt en die je zonder schade uitzet. Een kolom in het beheerscherm, een melding voor je team, een rapportje van je producten zonder prijs.

Oranje: laat het nalezen. Een functie die bezoekers zien maar geen gevoelige gegevens raakt. Een shortcode, een blok, een tekst op de productpagina. Een fout hierin kan je site breken of een lek openen, dus laat iemand de controles hieronder doen.

Rood: niet met alleen AI. Alles met betalingen, inloggen of registreren, formulieren met persoonsgegevens, bestanden uploaden of de prijzen en de checkout van je webshop. Kies dan een bestaande, onderhouden plugin, of laat het bouwen en controleren door iemand die WordPress-code leest.

Vraag jezelf ook altijd af: bestaat dit al? Een onderhouden plugin met duizenden gebruikers is vaak veiliger dan je eigen versie, omdat iemand anders hem bijhoudt.

Stappenplan: zo maak je het, met wie-doet-wat

1. Jij: schrijf een korte opdracht. Wat moet het doen, voor wie, en wat mag het juist niet? Bijvoorbeeld: "Alleen beheerders mogen dit zien."
2. AI: maakt een plan en daarna de code. Vraag eerst om een plan, dan pas om code.
3. Jij: test op een lokale site of testsite. Nooit eerst op je live site.
4. AI: leest zijn eigen code na op beveiliging. Met een aparte prompt, zie hieronder.
5. Jij: draai Plugin Check. Plugin Check is een gratis plugin van WordPress.org die de controles uitvoert die ook gelden voor plugins in de officiële bibliotheek, waaronder beveiliging. Draai hem op je testsite.
6. Een mens: controleert de punten uit het volgende hoofdstuk. Jijzelf als je PHP kunt lezen, anders je bouwer.
7. Jij: back-up, live zetten en vastleggen. Noteer wat de plugin doet, waar de code staat en welke prompt je gebruikte.

Een prompt om te bouwen:

Maak een WordPress-plugin van één bestand die [functie]. Alleen gebruikers met de rechten [bijvoorbeeld manage_options] mogen [actie]. Gebruik een unieke prefix voor alle functies. Controleer rechten met current_user_can en gebruik een nonce bij elk formulier. Schoon alle invoer op met de functies van WordPress en escape alle uitvoer zo laat mogelijk. Gebruik $wpdb->prepare voor elke databasequery. Werkt op WordPress [versie] en PHP [versie]. Leg onder de code in gewone taal uit wat elk deel doet.

Een prompt om na te lezen, in een nieuw gesprek:

Je bent een kritische reviewer van WordPress-code. Hieronder staat een plugin. Zoek plekken waar invoer niet wordt opgeschoond, uitvoer niet wordt geëscaped, rechten of nonces ontbreken, databasequery's niet voorbereid zijn of geheimen in de code staan. Noem per probleem de regel, het risico en de oplossing. Zeg het als je iets niet zeker weet.

Een nieuw gesprek is geen detail. Een assistent die net code heeft geschreven, vindt die code vaak goed.

De controles die een mens doet voordat het live gaat

AI schrijft code die werkt. Of hij ook veilig is, moet iemand nagaan. Dit zijn de punten die ik altijd zou laten controleren.

1. Invoer opschonen en uitvoer escapen

Het beveiligingshoofdstuk van de WordPress-documentatie begint met twee regels: vertrouw nooit invoer van gebruikers, en escape zo laat mogelijk. Alles wat binnenkomt, uit een formulier, de adresbalk of de database, schoon je op of controleer je. Alles wat je op het scherm zet, escape je vlak voordat je het toont. WordPress heeft daar eigen functies voor, zoals sanitize_text_field() voor invoer en esc_html(), esc_attr() en esc_url() voor uitvoer.

2. Rechten en nonces

Een nonce is een eenmalige code in een formulier of link die bewijst dat een verzoek echt van jouw site komt. Hij beschermt tegen een aanval waarbij iemand een ingelogde beheerder ongemerkt een actie laat uitvoeren. Maar volgens WordPress vervangt een nonce nooit een controle op rechten. Daarvoor gebruik je current_user_can(). Een goed formulier in het beheerscherm doet dus allebei:

// Opslaan: eerst rechten, dan de nonce, dan opschonen
if ( isset( $_POST['gw_openingstijden'] ) ) {
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die( 'Geen toegang.' );
    }
    check_admin_referer( 'gw_openingstijden_opslaan' );
    $tekst = sanitize_text_field( wp_unslash( $_POST['gw_openingstijden'] ) );
    update_option( 'gw_openingstijden', $tekst );
}

// In het formulier
wp_nonce_field( 'gw_openingstijden_opslaan' );

// Op de site: escapen bij het tonen
echo esc_html( get_option( 'gw_openingstijden' ) );

Ontbreekt een van die stappen in je AI-code, dan is dat een reden om hem niet live te zetten.

3. Database en geheimen

Elke query die invoer gebruikt, gaat via $wpdb->prepare(). En er staan geen wachtwoorden of API-sleutels in de code. Moet je plugin met een AI-dienst praten, lees dan eerst WordPress AI-plugins beveiligen over waar je zo'n sleutel bewaart.

4. Werkt het straks nog?

WordPress raadt PHP 8.3 of hoger aan. Test je plugin op de PHP-versie van je hosting, en liefst ook op de volgende. Let ook op de editor: sinds WordPress 7.1 draait de editor voor alle thema's in een afgeschermd venster, en blokken die rechtstreeks in de editor ingrijpen, kunnen daardoor haperen. Code die een AI uit oude voorbeelden haalt, gaat daar soms van uit. Hoe je updates veilig doet en wat je na elke update controleert, staat in WordPress updaten zonder crash.

5. Weet je hoe je hem uitzet?

Breekt je plugin de site, dan stuurt WordPress meestal een mail met een link naar de herstelmodus. Komt die niet, dan zet je de plugin uit door zijn map te hernoemen. Hoe dat gaat, lees je in WordPress werkt niet meer. Zorg dat je dat weet voordat je iets live zet.

Wat AI goed doet en waar jij nodig bent

Je ziet het patroon: AI is snel in maken, een mens is nodig voor oordeel en verantwoordelijkheid.

Wie onderhoudt je plugin over een jaar?

Dit is de vraag die het vaakst wordt overgeslagen. Een plugin uit de officiële bibliotheek krijgt updates van zijn maker. Je eigen plugin krijgt alleen updates van jou. Jij bent nu de maker.

Over een jaar zijn er nieuwe versies van WordPress, PHP en WooCommerce. Misschien werkt je plugin dan nog, misschien niet. En de collega die hem in een middag met ChatGPT maakte, is er misschien niet meer. Leg daarom vast:

• wat de plugin doet en waarom je hem hebt;
• waar de code staat, liefst in versiebeheer, en niet alleen op de server;
• welke prompt en welke tool je gebruikte;
• wie hem controleert na grote updates;
• wanneer je hem weggooit, bijvoorbeeld als er een goede bestaande plugin komt.

Zet je eigen plugins ook op de lijst van je onderhoud. Een onderhoudspartij die niet weet dat ze er zijn, controleert ze ook niet. Wat goed onderhoud inhoudt en wat het kost, lees je in website onderhoud: kosten en wat erin hoort.

Checklist voordat je eigen AI-code live gaat

• De functie is klein, afgebakend en makkelijk uit te zetten.
• Er bestaat geen goede, onderhouden plugin die hetzelfde doet.
• De code is getest op een lokale site, Playground of testomgeving.
• Alle invoer wordt opgeschoond en alle uitvoer geëscaped.
• Elke actie controleert rechten met current_user_can, elk formulier heeft een nonce.
• Databasequery's gebruiken $wpdb->prepare.
• Er staan geen wachtwoorden of API-sleutels in de code.
• Plugin Check geeft geen fouten op beveiliging.
• Een mens die PHP kan lezen, heeft de code nagelopen.
• Er is een back-up en je weet hoe je de plugin uitzet als het misgaat.
• Er staat vast wie de plugin onderhoudt.

Bouw je met AI een app buiten WordPress, dan gelden andere controles. Die staan in vibe coding security.

Conclusie: snel gebouwd, zorgvuldig live

Een WordPress-plugin maken met AI is een prima manier om een kleine functie snel te krijgen. Telex is gestopt, maar met ChatGPT, Claude Code of WordPress Studio heb je in een middag iets wat werkt. Het verschil tussen handig en riskant zit in wat daarna komt: testen op een testsite, invoer opschonen en uitvoer escapen, rechten en nonces controleren, Plugin Check draaien, een mens laten meekijken en afspreken wie het onderhoudt.

Eigen code is maar één onderdeel van een veilige site. De tien maatregelen die elke WordPress-site nodig heeft, staan in WordPress beveiligen. Wil je weten wat een WordPress-website of onderhoud bij mij kost? Download de prijslijst.