Maarten
WordPress plug-in maken
Custom plug-ins · WooCommerce · REST API · Blokken
WordPress plug-in maken
Een WordPress plug-in laten maken voor functionaliteit die nu over losse add-ons verspreid zit, een koppeling met een extern systeem of een WooCommerce-uitbreiding: veilig, update-proof en met code in eigen beheer. Freelance, met 25 jaar ervaring, vanuit Nijmegen en remote door heel Nederland.
Eerder gebouwd voor Autovisie.
Eén ervaren freelancer
WordPress plug-in maken voor functionaliteit op maat
Een gesprek over wat de plug-in moet doen en wat niet, gevolgd door een heldere opbouw: eigen namespace, hooks in plaats van aanpassingen aan de kern, beveiliging in de structuur en code in een eigen repository. Vooraf is er een gesprek nodig om te weten wat er speelt, niet andersom.
- Scope en risico's vooraf afgebakend
- Veilig volgens de WordPress-standaarden
- Code en versiegeschiedenis in eigen beheer
- Direct contact, geen tussenlagen
Voorbeelden van opgeleverd werk
Het autoplatform voor een toonaangevend automerk
Website, abonnementsmodel en een prettige redactieomgeving, ontwikkeld op WordPress.
WordPress plug-in maken: waarom één eigen plug-in vaak beter werkt
Een WordPress-plug-in opzetten kost weinig tijd: een map, een PHP-bestand met de juiste kopregels, en WordPress herkent hem. Een plug-in die jaren meegaat, niet breekt bij een update van WordPress of het thema, veilig omgaat met invoer, de site niet vertraagt en die een andere developer later nog begrijpt, vraagt om meer. Daar zit het werk bij een WordPress plug-in maken: niet in het opzetten, maar in de opbouw die bepaalt of de plug-in over een paar jaar nog een aanwinst is of een risico.
Een eigen plug-in laten bouwen door een freelance developer betekent, in de praktijk, iemand die PHP, de hooks en API's van WordPress en de systemen rond de site kent. Vanuit Nijmegen wordt er gewerkt voor opdrachtgevers door heel Nederland, meestal op afstand. Vijfentwintig jaar ervaring met webontwikkeling betekent vooral: herkennen wanneer een eigen plug-in de beste oplossing is, en wanneer een goed onderhouden bestaande plug-in of een instelling in WordPress zelf volstaat.
Elk traject begint met afbakenen: wat moet de plug-in doen, en vooral wat niet? Welke gegevens komen erin en gaan eruit, welke gebruikers mogen wat, en welke bestaande plug-ins of thema-aanpassingen vervangt hij? Daarna volgt de opbouw: een eigen namespace, autoloading via Composer, logica verdeeld over losse klassen en communicatie met WordPress uitsluitend via hooks en publieke API's. Beveiliging zit in de structuur, met rechtencontroles, nonces, het opschonen van invoer en het escapen van uitvoer. De code komt in een Git-repository, met versienummers en een changelog, zodat altijd te zien is wat er in welke versie veranderde.
Voor wie dit werkt, loopt uiteen: een organisatie die drie add-ons combineert om net niet te krijgen wat nodig is, een site waarvan belangrijke logica in het functions.php van het thema zit en bij elke thema-wissel dreigt te verdwijnen, een webshop die WooCommerce net een stap verder wil laten gaan, of een bedrijf dat gegevens uit een ERP, CRM of vastgoedsysteem automatisch op de site wil hebben. Ook het overnemen van een bestaande maatwerk-plug-in van een onbereikbare vorige bouwer hoort erbij. In alle gevallen gaat het om hetzelfde: functionaliteit die precies past, los van het thema, in code die de opdrachtgever zelf in handen heeft.
Of een eigen plug-in de juiste keuze is, is zonder de situatie gezien lastig te zeggen. Daarom begint het meestal met een kennismakingsgesprek: een half uur om te horen wat de plug-in moet oplossen, gevolgd door een eerlijk beeld van de aanpak en de alternatieven. Geen verplichting, en geen maatwerk als een bestaande oplossing het net zo goed doet.
Gebouwd voor
Klaar voor een plug-in die precies doet wat nodig is?
Wat een eigen WordPress-plug-in oplevert
Een eigen plug-in is geen doel op zich; hij loont als hij iets vervangt dat nu wringt, zoals een stapel add-ons, logica in het thema of terugkerend handwerk. Een paar voorbeelden van wat er dan concreet verandert.
-
Eén plug-in in plaats van vijf
Nichefunctionaliteit die nu over meerdere add-ons verspreid zit, gebundeld in één plug-in met een duidelijke taak. Minder conflicten, minder updates en minder scripts op de pagina.
-
Functionaliteit los van het thema
Eigen contenttypes, formulieren en koppelingen verhuisd van functions.php naar een plug-in, zodat een nieuw thema de functionaliteit niet meeneemt.
-
Externe gegevens automatisch op de site
Producten, vacatures, woningen of evenementen uit een extern systeem via een geplande synchronisatie, met een logboek per item en een melding bij fouten.
-
WooCommerce met precies de juiste logica
Prijsregels per klantgroep, betaalmethoden per land of een eigen verzendmethode, via de hooks van WooCommerce, zodat updates de logica niet slopen.
-
Een maatwerk-plug-in die weer onderhouden wordt
Een plug-in van een vorige bouwer doorgelicht, in een repository gezet, bijgewerkt naar de huidige standaarden en voorzien van een nette releaseflow.
-
Advies over eigen plug-in of bestaand alternatief
Een eigen plug-in laten bouwen, een bestaande plug-in uitbreiden, of de functionaliteit toch met een instelling in WordPress zelf oplossen: een kort gesprek over wat de plug-in moet doen, maakt meestal al duidelijk welke route het meest oplevert.
Benieuwd of een eigen plug-in in jouw situatie loont?
Functionaliteit die thuishoort in een plug-in
Voor Autovisie, onderdeel van de Telegraaf Mediagroep (tegenwoordig Mediahuis), is het online autoplatform op WordPress ontwikkeld, inclusief abonnementenmodel en een prettige redactieomgeving. Dat project wordt hier niet als losse plug-in-opdracht gepresenteerd, maar het laat goed zien welk soort functionaliteit verder gaat dan een thema.
Een abonnementenmodel raakt aan toegangsrechten, betalingen, accounts en caching: onderdelen die moeten blijven werken als het ontwerp verandert. Precies dat is de vuistregel bij het maken van een WordPress-plug-in. Presentatie hoort in het thema, bedrijfslogica in een plug-in. Wie die scheiding aanhoudt, kan het thema vervangen of vernieuwen zonder dat abonnees ineens geen toegang meer hebben.
Bij grote bezoekersaantallen komt daar een tweede eis bij: de plug-in mag de site niet vertragen. Dat betekent scripts en stijlen alleen laden op de pagina's waar ze nodig zijn, zware berekeningen cachen, databasequery's beperken en taken die niet direct hoeven, zoals een synchronisatie of een e-mail, op de achtergrond uitvoeren.
Een WordPress-plug-in die veilig en update-proof blijft
Veel problemen met plug-ins ontstaan niet bij de bouw, maar een jaar later: een WordPress-update verandert iets, een PHP-versie wordt uitgefaseerd of een beveiligingslek blijkt lange tijd open te hebben gestaan. Een plug-in die daartegen bestand is, wordt vanaf het begin zo opgezet.
Dat begint bij de basis. Invoer wordt gecontroleerd en opgeschoond, uitvoer wordt ge-escaped, elke actie controleert of de gebruiker die mag uitvoeren, formulieren gebruiken nonces en databasequery's worden voorbereid in plaats van uit losse tekst samengesteld. Eigen REST-routes krijgen een echte rechtencontrole. Wachtwoorden en API-sleutels staan niet in de code, maar in de configuratie van de server.
Daarnaast de onderhoudbaarheid: minimale PHP- en WordPress-versies in de kopregels, geen interne functies van WordPress die ongemerkt kunnen verdwijnen, automatische tests waar het ertoe doet en een release met versienummer en changelog. Nieuwe WordPress-versies worden eerst op een testomgeving gecontroleerd, zodat de plug-in niet de reden is dat een update wordt uitgesteld.
Bestaande maatwerk-plug-in die aandacht nodig heeft? Een half uur meedenken helpt vaak al.
Plug-in-onderdelen die regelmatig terugkomen
Van eigen contenttypes tot een koppeling met een extern systeem: onderstaand de onderdelen die het vaakst terugkomen in een WordPress-plug-in, los of in combinatie, telkens toegesneden op de site en op wie ermee werkt. Alles wordt eerst op een testomgeving gebouwd en pas na controle live gezet.
Custom post types en taxonomieën
Eigen contenttypes zoals cases, vacatures of evenementen, met velden, archieven en ondersteuning voor de REST API.
REST API-routes
Eigen endpoints voor formulieren, apps of koppelingen, met validatie en een rechtencontrole op elke route.
Geplande taken en imports
Synchronisaties en opschoontaken via WP-Cron of een systeem-cron met WP-CLI, met logging en meldingen bij fouten.
Gutenberg-blokken
Eigen blokken met block.json, zodat de redactie de functionaliteit zelf in pagina's plaatst binnen het ontwerp.
WooCommerce-uitbreidingen
Eigen betaal- of verzendmethoden, prijsregels en winkelwagenregels via de hooks van WooCommerce.
Instellingen en WP-CLI-commando's
Een instellingenpagina met duidelijke labels voor de beheerder en commando's voor bulkacties en migraties.
- WordPress
- PHP
- WooCommerce
- WP-CLI
- WP All Import
- WordPress website maken
- Elementor
- Pararius
- Realworks
- n8n
- REST API
- Composer
Veelgestelde vragen
Een aantal vragen dat regelmatig terugkomt bij het laten maken van een WordPress-plug-in, van beveiliging en updates tot eigendom van de code. Staat je eigen vraag er niet bij, stel 'm gewoon in het kennismakingsgesprek.
Wanneer is een eigen plug-in slimmer dan een bestaande?
Als meerdere add-ons samen net niet doen wat nodig is, als de functionaliteit een kernproces raakt zoals orders, klantgegevens of koppelingen, of als er steeds handwerk nodig is dat een plug-in kan overnemen. Doet een goed onderhouden bestaande plug-in precies wat nodig is, dan is dat meestal de betere keuze, en dat wordt ook zo gezegd.
Hoe voorkom je dat de plug-in breekt bij een WordPress-update?
Door alleen hooks en publieke API's te gebruiken, zoals beschreven in het Plugin Handbook van WordPress, en geen interne functies of aanpassingen aan de kern. Minimale versies staan in de kopregels, en elke nieuwe WordPress-versie wordt eerst op een testomgeving gecontroleerd.
Hoe zit het met beveiliging?
Beveiliging zit in de opbouw: rechtencontroles op elke actie, nonces op formulieren, invoer die wordt opgeschoond, uitvoer die wordt ge-escaped en voorbereide databasequery's. De beveiligingsrichtlijnen voor plug-ins van WordPress zijn daarbij het uitgangspunt. Bij de start van een plug-in wordt daarom eerst afgebakend wie welke actie mag uitvoeren en welke gegevens van buiten de plug-in binnenkomen, bijvoorbeeld via een formulier, een REST-route of een externe koppeling; precies die plekken vragen om een rechtencontrole en om invoer die wordt gevalideerd voordat hij wordt opgeslagen. Wachtwoorden, API-sleutels en andere gevoelige gegevens komen in de serverconfiguratie terecht, niet in de broncode of in een instellingenveld dat zonder versleuteling wordt opgeslagen. Voor een plug-in die persoonsgegevens verwerkt, zoals klantgegevens uit een koppeling, komt daar een striktere logging en een kortere bewaartermijn bovenop, afgestemd op wat er wordt vastgelegd en waarom.
Krijg ik de broncode in eigen beheer?
Toegang tot de plug-in is er vanaf het begin, via een Git-repository, zonder verborgen licentieserver of afhankelijkheid van één developer. De rechten op het maatwerk gaan over na volledige betaling, zoals in de algemene voorwaarden staat. Daarna kan een andere PHP developer het werk op elk moment overnemen, en dat is ook de bedoeling.
Kun je een bestaande maatwerk-plug-in overnemen?
Meestal wel. Eerst een korte audit van structuur, beveiliging en afhankelijkheden, daarna een plan om de plug-in in een repository te zetten, bij te werken naar de huidige standaarden en verder te ontwikkelen, zonder dat de site offline gaat.
Hoe worden updates van de plug-in uitgerold?
Dat hangt af van het aantal installaties. Voor één site volstaat een gecontroleerde release vanuit de repository. Draait de plug-in op meerdere sites, dan kan een eigen updatekanaal of een private Composer-repository ervoor zorgen dat updates net zo werken als bij een plug-in uit de officiële bibliotheek.
Kan de redactie de functionaliteit zelf in pagina's plaatsen?
Ja, als dat nodig is. Een plug-in kan eigen blokken voor de blok-editor meebrengen, met vaste instellingen die passen bij het ontwerp. Zo zet de redactie bijvoorbeeld een vacatureoverzicht of aanmeldformulier zelf op een pagina, terwijl de logica erachter in de plug-in blijft.
Bouw je ook WooCommerce-plug-ins?
Ja, een groot deel van het plug-inwerk is een uitbreiding op WooCommerce: eigen betaal- of verzendmethoden, prijsregels, B2B-functionaliteit en koppelingen met productfeeds. WooCommerce heeft veel hooks, dus er is meestal een nette plek om in te haken.
Wat kost een WordPress plug-in laten maken?
Dat hangt af van de omvang: een afgebakende plug-in met één taak is iets anders dan een koppeling met een extern systeem. Een instellingenpagina met een paar eigen velden en één WP-CLI-commando is een kleiner traject dan een plug-in die dagelijks gegevens synchroniseert met een ERP of CRM, met foutafhandeling en logging erbij. Ook het overnemen en opschonen van een bestaande maatwerk-plug-in vraagt een andere aanpak dan iets vanaf nul bouwen. Na een eerste gesprek over de scope, wat de plug-in wel en niet moet doen, en welke systemen erbij komen kijken, ontstaat een concreet voorstel per uur of per fase. Je beslist vervolgens zelf of en hoe je verder gaat, zonder verplichting vooraf.
Plug-in op maat nodig?
Een half uur bellen over wat de plug-in moet oplossen, welke systemen erbij komen kijken en of maatwerk de logische route is. Geen verplichting, en ook geen voorstel voordat duidelijk is wat de plug-in wel en niet moet doen.
