“Daar moet toch een plugin voor zijn.” Meestal is dat zo. En soms vind je er drie, die allemaal twintig dingen doen waarvan jij er één nodig hebt, met een abonnement erbij en voor het laatst bijgewerkt in 2023.
Dan is er een andere route: er zelf een laten maken. Sinds AI code schrijft is dat geen developer-project meer. Maar het is ook geen gratis lunch. De webknecht legt uit wanneer het slim is, en wat je dan moet controleren.
Eerst de vraag: plugin, snippet of niets?
Voordat je iets laat bouwen, kies je de vorm. Dat scheelt later veel ellende:
| Vorm | Wanneer | Nadeel |
|---|---|---|
| Bestaande plugin | Standaardklus, actief onderhouden, veel gebruikers | Vaak veel meer dan je nodig hebt |
| Snippet | Vijf regels, eenmalig, niet kritisch | Raakt zoek, niemand weet later waarom het er staat |
| Eigen mini-plugin | Specifiek voor jouw bedrijf, moet blijven werken | Jij bent nu de onderhouder |
| Niets doen | Als het probleem eigenlijk een procesprobleem is | Voelt als verliezen, is vaak winnen |
Die laatste rij is geen grap. Een kwart van de “we hebben een plugin nodig”-vragen lost op zodra iemand een werkwijze aanpast in plaats van software toevoegt. Elke plugin is code die je erbij neemt, en meer code is meer kans op de plugin-hel.
Waarom een mini-plugin beter is dan code in functions.php
Code in de functions.php van je thema lijkt handig en is het niet:
- Bij een thema-update kan hij verdwijnen
- Wissel je van thema, dan verdwijnt je functionaliteit mee
- Eén fout in dat bestand haalt je hele site onderuit
- Je kunt hem niet even uitzetten om te testen
Een eigen plugin lost alle vier op. Je kunt hem activeren en deactiveren, hij staat los van je design, en als hij stuk is zet je hem uit in plaats van je site te herstellen. Dat is bij foutopsporing goud waard.
Wat een plugin minimaal nodig heeft
Verrassend weinig. Een map in wp-content/plugins/ met één PHP-bestand, en bovenaan een kopblok waar WordPress hem aan herkent:
<?php
/**
* Plugin Name: Bedrijfsnaam Openingstijden
* Description: Toont openingstijden via een shortcode.
* Version: 1.0.0
* Author: Bedrijfsnaam
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
Die laatste drie regels zijn geen opsmuk. Ze zorgen dat het bestand niets doet als iemand het direct in de browser opvraagt. Staat dat er niet in, dan heb je een openstaand deurtje.
Verder wil je een eigen voorvoegsel voor je functienamen, bijvoorbeeld bn_. Twee plugins met een functie get_hours() geven een harde fout, en die zoek je een uur.
Vijf klussen waar een eigen plugin de beste keuze is
- Een shortcode met bedrijfsgegevens. Openingstijden of tarieven op één plek beheren en overal tonen.
- Een extra veld bij een formulier of bestelling. Bijvoorbeeld een projectnummer dat mee moet in de mail.
- Een koppeling met een dienst die jij gebruikt. Boekingssysteem, voorraad, planning.
- Een terugkerende beheertaak. Wekelijks een export, of een opruimactie.
- Kleine aanpassingen aan de beheeromgeving. Menu-items verbergen voor collega’s die erin verdwalen.
De veiligheidsvragen die je altijd stelt
Dit is het deel dat mensen overslaan omdat de code “werkt”. Werken en veilig zijn is niet hetzelfde. Laat je een plugin bouwen, vraag dan expliciet om dit, en vraag om uitleg per punt:
| Vraag | Waarom het uitmaakt |
|---|---|
| Wordt invoer van bezoekers opgeschoond? | Anders kan iemand code meesturen via een formulier |
| Wordt uitvoer ge-escaped? | Voorkomt dat opgeslagen tekst als script wordt uitgevoerd |
| Wordt gecheckt wie mag wat? | Zonder rechtencheck kan een abonnee beheerdersacties doen |
| Zitten er nonces op formulieren? | Voorkomt dat een andere site namens jou acties uitvoert |
| Praat hij met externe servers? | Dan gaat er data je site uit, en dat wil je weten |
| Staan er wachtwoorden of sleutels in de code? | Die horen in wp-config.php, niet in een plugin-bestand |
Een goede opdracht ziet er dus zo uit: “Bouw een plugin die openingstijden beheert via een instellingenpagina en toont via een shortcode. Gebruik een nonce en een rechtencheck op het formulier, schoon invoer op, escape uitvoer, en leg per onderdeel uit welke beveiliging je hebt toegepast.”
Dat laatste stukje, “leg uit”, is je controle. Je hoeft geen PHP te kunnen schrijven om te merken dat een uitleg ontbreekt.
Onderhoud: je eigen plugin is een huisdier
Een plugin die jij laat bouwen, krijgt geen updates van iemand anders. Dat betekent:
- Bij een nieuwe PHP-versie kan oude code gaan klagen
- Bij grote WordPress-versies verdwijnen soms functies
- Over twee jaar weet niemand meer wat hij doet, tenzij je het opschrijft
Doe daarom drie dingen: zet er een versienummer en een korte uitleg in het kopblok, bewaar de code ook buiten je site (bijvoorbeeld in een repository), en neem hem mee in je jaarlijkse onderhoudsronde. Test hem één keer per jaar bewust na een update.
Begin met iets kleins en nutteloos
Serieus. Laat als eerste een plugin bouwen die iets onbelangrijks doet, bijvoorbeeld een shortcode die je openingstijden toont. Dan leer je de route zonder risico: installeren, activeren, testen op preview, uitzetten als het misgaat.
Doe dat een keer en de drempel is weg. Daarna pak je pas de klus waar je echt iets aan hebt, met de veiligheidsvragen hierboven als vast lijstje. Dat lijstje is het verschil tussen een eigen plugin en een eigen lek.