Custom plug-ins · WooCommerce · REST API · Gutenberg-blokken
WordPress plug-in maken
Eén custom plug-in in plaats van vijf marketplace-add-ons die elkaar bijten. Schoon geschreven, veilig, update-proof en met code die je zelf in handen hebt.
- 25+ jr
- Web-ervaring
- PHP 8.3
- Modern & strict
- WP-CS
- Coding standards
- Semver
- Eigen updater
Waarom een goede plug-in developer
Een plug-in is makkelijk te maken — een goede plug-in maakt het verschil
Een WordPress-plug-in scaffolden kost een uur. Een plug-in die jaren meegaat, niet breekt bij WP-updates, veilig is, geen rem op de site zet en die een collega-developer over twee jaar nog snapt — daar zit het echte werk. Dat is waar een ervaren developer waarde toevoegt.
Eén plug-in in plaats van vijf
Niche-functionaliteit hoort niet over vijf marketplace-add-ons verspreid te zijn die elkaar bijten. Eén custom plug-in met heldere scope is sneller, veiliger en goedkoper in onderhoud.
Veilig volgens WordPress-standaarden
Nonces, capability checks, prepared statements, sanitization en escaping op de juiste plek — security is geen vinkje achteraf maar zit in de code-structuur.
Update-proof bij WP- en thema-updates
Hooks in plaats van core-files patchen, geen vendor-lock, semver met changelog en een nette deprecation-strategie. Updates van WordPress of het thema breken jouw plug-in niet.
Geen rem op de site
Lazy loading van assets, alleen laden waar nodig (per CPT, per pagina, per rol), object cache-vriendelijk en geen tien admin-ajax requests per pageview.
Beheer waar je team mee verder kan
Settings-pagina met logische labels, Gutenberg-blokken die marketing zelf snapt, WP-CLI commands voor sysadmins en logging die je in je hosting-dashboard terugziet.
Documentatie en kennisoverdracht
README, code-comments waar het ertoe doet, een korte handleiding voor de redactie en een Git-repo die je zelf in handen hebt. Geen 'zip-bestand op de FTP'.
Twijfel je of een custom plug-in in jouw geval het juiste is? Ik denk graag mee — gewoon Maarten zelf.
Hoe het eruit ziet
Schone PHP, modulaire opzet — geen spaghetti
Een custom plug-in hoort opgebouwd te zijn zoals moderne PHP-projecten: namespaces, autoloading, hooks, REST-routes en een nette test-setup. Niet één bestand van duizend regels.
Custom plug-in · PHP
eigen codeREST-route met validatie, action-hooks voor integraties en semver in een nette repo.
<?php
/**
* Plugin Name: Acme Lead Router
* Description: Routes form-submits naar de juiste accountmanager.
* Version: 1.2.0
* Requires PHP: 8.1
* Author: Maarten Soetens
*/
namespace Acme\LeadRouter;
add_action( 'rest_api_init', function () {
register_rest_route( 'acme/v1', '/lead', [
'methods' => 'POST',
'permission_callback' => '__return_true',
'callback' => __NAMESPACE__ . '\\handle',
'args' => [
'email' => [ 'required' => true, 'sanitize_callback' => 'sanitize_email' ],
'region' => [ 'required' => true, 'sanitize_callback' => 'sanitize_text_field' ],
'product' => [ 'required' => true, 'sanitize_callback' => 'sanitize_text_field' ],
],
] );
} );
function handle( \WP_REST_Request $req ): \WP_REST_Response {
$owner = route_to_owner( $req['region'], $req['product'] );
do_action( 'acme/lead/created', $req->get_params(), $owner );
// → HubSpot contact + deal, Slack-notify, GA4-event
return rest_ensure_response( [ 'ok' => true, 'owner' => $owner ] );
}Plug-in structuur
PSR-12Schone modulaire opzet — uit te breiden zonder spaghetti.
acme-lead-router/
├─ acme-lead-router.php ← plugin header + bootstrap
├─ composer.json ← PSR-4 autoload, PHP 8.1+
├─ readme.txt ← WP-style readme
├─ CHANGELOG.md ← semver-historie
├─ src/
│ ├─ Rest/Controller.php
│ ├─ Integrations/Hubspot.php
│ ├─ Integrations/Slack.php
│ └─ Admin/SettingsPage.php
├─ blocks/ ← Gutenberg-blokken
│ └─ lead-form/block.json
├─ bin/ ← WP-CLI commands
├─ tests/ ← PHPUnit + WP_Mock
└─ .github/workflows/ci.yml ← lint, tests, releaseBestaande plug-in die toe is aan een refactor? Ik denk graag mee — gewoon Maarten zelf.
Herkenbaar?
Plug-in problemen die ik vaak voorbij zie komen
Bijna elk plug-in-traject begint met een van deze klachten. Goede kans dat jij er ook minstens één herkent.
Plug-in-soep doet bijna wat je wil
Pijn: Drie marketplace-plug-ins doen samen 80% van wat je nodig hebt. De laatste 20% kost elk kwartaal frustratie, support-tickets en handmatig werk in de admin.
Aanpak: Eén custom plug-in die exact past — minder code, minder updates, geen conflicten. Vaak goedkoper op een termijn van twee jaar dan de licenties van wat hij vervangt.
Een functionaliteit zit verstopt in het thema
Pijn: Cruciale logica (formulieren, CPT's, integraties) staat in functions.php van het thema. Bij elke thema-wijziging breekt er iets, en bij een redesign moet alles opnieuw.
Aanpak: Logica los in een plug-in, presentatie in het thema. Thema kan vervangen worden zonder dat functionaliteit verdwijnt — en andersom.
Plug-in van een ZZP'er die niet meer reageert
Pijn: Ooit een 'maatwerk plug-in' laten bouwen, nu krijgt niemand er meer ondersteuning op. Geen repo, geen documentatie, geen update bij een nieuwe WP-versie.
Aanpak: Overname, refactor naar WP coding standards, in een Git-repo zetten, dependencies updaten en een nette release-flow inrichten. Daarna doorontwikkelen op een fundament dat van jou is.
Externe data moet de site in
Pijn: Producten uit een ERP, vacatures uit een ATS, woningen uit Realworks, evenementen uit een agenda-systeem — handmatig overtypen of een wankele import-knop op een willekeurig moment.
Aanpak: Custom plug-in met REST- of cron-sync, idempotente import, fouten-logging en een dashboard waar je per item ziet wat er waarom gebeurde.
WooCommerce mist net die ene logica
Pijn: B2B-prijzen per klant, staffelkortingen op productniveau, levertijd uit voorraad-API, betaalmethode beperken per land of per cart-totaal — standaard WooCommerce kan het bijna.
Aanpak: Gerichte WooCommerce-plug-in met de juiste hooks, gateway-uitbreidingen en cart-filters. Schoon, getest en zonder dat WooCommerce-updates 'm slopen.
Redactie moet vrij kunnen bouwen
Pijn: Marketing wil eigen landingspagina's bouwen, maar elke pagina-builder voegt 200KB JS toe en breekt het design. Of: alle pagina's zien er nét anders uit.
Aanpak: Eigen Gutenberg-blokken via een plug-in: vaste design-tokens, marketing-vriendelijke controls en lichte front-end output. Geen builder onder de motorkap.
Custom plug-in nodig of bestaande maatwerk-plug-in overnemen?
Eén ervaren WordPress-developer voor maatwerk plug-ins.
Een gesprek over wat de plug-in moet doen, welke risico's er zijn en hoe een aanpak eruit zou zien — concreet, geen sales-trechter.
Onder de motorkap
Veilig gebouwd en traceerbaar uitgerold
Security en release-discipline zijn standaard onderdeel van de bouw, niet iets dat 'later wel komt'. Zo weet je altijd wat er in welke versie veranderd is en waarom.
Security-checklist
hardenedStandaard onderdeel van elke plug-in — niet achteraf toegevoegd.
- Nonces op forms en admin-actiesok
- current_user_can() op endpointsok
- sanitize_* op alle inputok
- esc_html / esc_attr op outputok
- Prepared statements (wpdb->prepare)ok
- Geen eval / extract op user inputok
- Geen secrets in repo (wp-config)ok
- REST permission_callback gezetok
- Auto-update veilig (signed releases)ok
Releases · semver + changelog
traceableElke release reproduceerbaar — geen 'zip-bestand op de FTP'.
- 1.2.0Lead-routing per regio + productfeature
- 1.1.3Fix: dubbele Slack-notify bij retryfix
- 1.1.2WP 6.7 compat-checkcompat
- 1.1.1Security: extra escape in admin-tabelsec
- 1.1.0HubSpot deal-stage configurablefeature
- 1.0.0Initial releaserelease
Plug-in nu zonder Git en zonder changelog? Ik denk graag mee — gewoon Maarten zelf.
Wat het oplevert
Voorbeelden van plug-ins die het verschil maakten
Een custom plug-in hoort iets op te leveren — minder handwerk, meer leads, snellere site, schonere stack. Dit zijn voorbeelden van trajecten, als inspiratie voor wat in jouw situatie kan.
ERP-sync plug-in voor B2B-shop
Producten, voorraad en prijzen elke 15 minuten via REST uit Exact Online naar WooCommerce. Delta-sync, audit-log en alerts bij afwijkingen. Bespaarde de back-office 4 uur per week handmatig werk.
Lead-routing plug-in voor MKB-site
Formulier-submits routen op basis van product-interesse en regio naar de juiste accountmanager in HubSpot, met Slack-notificatie en GA4-event. Sneller opvolgen → 38% meer leads geconverteerd in maand 1.
Verzendlabel-plug-in WooCommerce
Eén klik vanuit het order-overzicht: label aanmaken bij Sendcloud, tracking terug naar order, klantmail met track & trace. Tijd per order van 4 min naar 20 sec — 92% minder handwerk.
FAQ-blok-plug-in met schema.org
Gutenberg-blok dat content-redacteurs zelf gebruiken en automatisch FAQPage-schema in de pagina injecteert. Organische zichtbaarheid op long-tail vragen +27% in een half jaar.
Custom auth-plug-in voor portaal
Inlog tegen externe IdP (Azure AD) met role-mapping naar WordPress, audit-trail en MFA-fallback. Geen kwetsbare third-party SSO-plug-in meer in de stack.
Cron-plug-in voor data-verversing
WP-Cron vervangen door system cron + WP-CLI, met heartbeat-monitoring. Geen 'verlopen aanbiedingen' meer omdat WP-Cron 's nachts niet triggert.
Multisite content-distributie
Plug-in waarmee één hoofdredactie content publiceert naar 40 regio-sites, met overrides per site. Vervangt handmatig copy-paste en losse exports.
Performance-plug-in voor uitgever
Eigen lichte alternative voor 6 traagheids-plug-ins (gallery, share, related, popup, cookie, tracking) — samen 380KB minder JS en 3,1× snellere LCP op mobiel.
WP-CLI commands voor migraties
Custom WP-CLI commands voor jaarlijkse content-migratie van legacy CMS — uren werk werd minuten, herhaalbaar en repeteerbaar in CI.
Welk voorbeeld lijkt het meest op jouw situatie? Ik denk graag mee — gewoon Maarten zelf.
Wat ik bouw
Soorten plug-in-onderdelen die regelmatig terugkomen
Custom plug-in op maat
PHP 8.x, namespaces, autoloading via Composer, PSR-12. Schoon en testbaar.
Custom Post Types & taxonomieën
CPT's met REST-support, eigen capabilities, archief- en single-routes.
REST API endpoints
Eigen routes onder /wp-json/jouw-namespace/v1/ met validatie en permissions.
WP-Cron & scheduled tasks
Imports, sync, cleanup-jobs met heartbeat en logging.
Gutenberg-blokken (React)
Eigen blokken met block.json, InnerBlocks en server-side render.
WooCommerce-extensions
Custom gateways, shipping methods, cart/product hooks, B2B-logica.
Integraties & webhooks
HubSpot, Mailchimp, Slack, Teams, n8n, Zapier — in- en uitgaand.
WP-CLI commands
Eigen commands voor sysadmins, migraties en bulk-operaties.
Security-hardening
Nonces, capability checks, sanitization, escaping, prepared statements.
Eigen update-server
Updater zoals marketplace-plug-ins, optioneel met licentiesysteem.
Roles & capabilities
Eigen rollen, fijnmazige permissies, audit-trail.
Settings & admin-UI
Settings-pagina via Settings API of React-admin met REST.
Specifiek onderdeel in je hoofd? Ik denk graag mee — gewoon Maarten zelf.
Koppelingen
Systemen waar ik plug-ins regelmatig mee verbind
Exact Online / AFAS / SnelStart
Boekhouding, facturen, voorraad.
HubSpot / ActiveCampaign / Mailchimp
CRM & marketing automation.
Mollie / Stripe / Adyen / MultiSafepay
Custom payment gateways.
Sendcloud / MyParcel / PostNL / DHL
Verzendlabels en track & trace.
Realworks / Pararius
Makelaars-feeds en woningimport.
Channable / ChannelEngine
Productfeeds en marketplaces.
Azure AD / Google Workspace / Okta
SSO en role-mapping.
n8n / Zapier / Make
No-code orchestratie via webhooks.
GA4 / GTM / Matomo
Server-side tracking en events.
Ander systeem? Vraag het even. Ik denk graag mee — gewoon Maarten zelf.
Hoe het werkt
Een plug-in-traject in 4 stappen
- 01
Scope & audit
Wat moet de plug-in doen, wat absoluut niet, welke hooks raken we, welke risico's zijn er.
- 02
Voorstel & architectuur
Concreet voorstel met scope, planning en technische opzet — geen vage uurschattingen.
- 03
Bouw op staging
In een Git-repo, met code-review-momenten, semver en changelog. Demo per milestone.
- 04
Release & overdracht
Live op productie, korte handleiding, documentatie en onderhouds-afspraak.
Klaar om de eerste stap te zetten? Ik denk graag mee — gewoon Maarten zelf.
Veelgestelde vragen
Wanneer is een custom WordPress plug-in slimmer dan een marketplace-plug-in?
Als je drie of meer plug-ins combineert om één eindresultaat te bereiken, als de plug-in niet update-vriendelijk is, als de functionaliteit kern-bedrijfsproces raakt (orders, klantdata, integraties) of als je elke maand handmatig werk doet dat een plug-in zou kunnen doen. Op die momenten verdient een custom plug-in zich vaak binnen een jaar terug.
Hoe voorkom je dat de plug-in breekt bij WordPress-updates?
Door hooks (actions/filters) te gebruiken in plaats van core-files te patchen, door geen private API's aan te roepen, door PHP-versies expliciet te declareren in plugin-header en composer.json, en door bij elke nieuwe WP-versie een korte regressie-test op staging te draaien voor we live updaten.
Krijg ik de broncode in eigen beheer?
Ja, altijd. De plug-in komt in een Git-repo (jouw GitHub/GitLab of die van mij — jij krijgt toegang). Geen vendor-lock, geen verborgen licentieserver verplicht. Je kunt op elk moment met de code naar een andere developer.
Kun je een bestaande maatwerk-plug-in overnemen?
Vaak wel. Eerst een korte code-audit: structuur, security, dependencies, deprecation-risico's. Daarna een plan om de plug-in te refactoren naar WP coding standards, in een nette repo te zetten en door te ontwikkelen — zonder dat de site offline gaat.
Bouw je ook Gutenberg-blokken als plug-in?
Ja. Eigen blokken in React met block.json, InnerBlocks, eigen controls en optioneel server-side render. Handig als je marketing-team zelf landingspagina's wil bouwen binnen vaste design-regels.
Werk je ook white-label voor bureaus?
Regelmatig. Design- of marketingbureaus besteden de plug-in-techniek uit en houden zelf het klantcontact. Code in jullie of mijn repo, demo's per sprint, communicatie via jullie project-lead.
Wat doe je aan security in custom plug-ins?
Standaard: nonces voor formulieren en admin-acties, capability checks op endpoints, sanitization van input, escaping van output, prepared statements voor database-queries, geen eval/extract op user input, en geen geheimen in de code (alles via wp-config of secrets-store).
Hoe regel je updates bij klanten?
Drie smaken: distributie via een eigen update-server (zoals marketplace-plug-ins), distributie via een private Composer-repo voor sites met CI/CD, of een handmatige release-flow voor één site. Welke past hangt af van hoeveel installaties er zijn.
Werk je ook met WooCommerce-specifieke plug-ins?
Ja, een groot deel van de plug-ins die ik bouw is WooCommerce-uitbreiding: custom gateways, shipping methods, B2B-logica, productfeed-koppelingen en cart-rules. WooCommerce heeft veel hooks — meestal is er een schone plek om in te haken.
Kan ik later zelf de plug-in uitbreiden?
Ja. Code volgt WP coding standards en PSR-12, met namespaces en autoloading. Inclusief README en code-comments waar het ertoe doet. Een andere PHP-developer kan er gewoon in werken — dat is een bewuste keuze.
Custom plug-in nodig of bestaande maatwerk-plug-in overnemen?
Eén ervaren WordPress-developer voor maatwerk plug-ins.
Een gesprek over wat de plug-in moet doen, welke risico's er zijn en hoe een aanpak eruit zou zien — concreet, geen sales-trechter.
