Wat zijn WordPress shortcodes? Een praktische gids

WordPress shortcodes zijn korte tekst-snippets omsloten door vierkante haakjes (zoals [contact-form] of [gallery ids="1,2,3"]) die WordPress vervangt door dynamische content bij het renderen van een bericht of pagina. Ze werden geïntroduceerd in WordPress 2.5 (2008) en werden langer dan een decennium de dominante manier waarop plugins complexe output aan content toevoegden. Sinds de uitrol van de Gutenberg-blockeditor in WordPress 5.0 (2018) hebben shortcodes een opvolger: blocks. Maar shortcodes verdwijnen niet. Ze werken nog steeds, miljoenen sites zijn ervan afhankelijk, en veel plugins blijven ze leveren naast of in plaats van blocks.

Hoe ziet een WordPress shortcode eruit?

De basis shortcode is een naam tussen vierkante haakjes:

[gallery]

WordPress ziet dit in de inhoud van het bericht, zoekt de geregistreerde handler voor gallery op, voert de PHP-functie uit, en vervangt de tag door wat HTML de handler ook uitstuurt. De bezoeker ziet een galerij; de editor ziet [gallery].

Shortcodes kunnen parameters aannemen (attributen genoemd):

[gallery ids="42,43,44" columns="3" link="file"]

En ze kunnen content omsluiten (omsluitende shortcodes genoemd):

[highlight color="yellow"]Belangrijke tekst[/highlight]

De shortcode-handler ontvangt de attributen en de innerlijke content, verwerkt ze in PHP, en geeft de HTML terug om in te voegen in de pagina. De bezoeker ziet nooit de haakjes; ze zien de gerenderde uitvoer.

Wat is het verschil tussen een shortcode en een Gutenberg-block?

Beide produceren dynamische content; ze verschillen in waar en hoe die content wordt gegenereerd.

• Shortcodes zijn server-side. De tag tussen vierkante haakjes blijft in de berichtinhoud opgeslagen in de database. Wanneer de pagina wordt opgevraagd, parseert WordPress de content, vindt de shortcode, voert de PHP-handler uit, en vervangt de output. De editorweergave toont altijd de ruwe haakjes-syntax.
• Blocks worden opgeslagen als gerenderde HTML (met metadata-commentaren). Wanneer je een bericht opslaat in de blockeditor, genereert de block-plugin de uiteindelijke HTML en slaat deze op in de database. De editor toont een live preview van het gerenderde block, geen tag. Op de frontend draait geen PHP om de meeste blocks te renderen; de HTML wordt direct geserveerd.

Praktische gevolgen:

• Performance. Blocks zijn sneller op de frontend omdat er geen parse-en-vervang stap is. Shortcodes triggeren een regex-scan van elk bericht bij elke render.
• Bewerkingservaring. Blocks tonen hoe de gerenderde output eruit gaat zien terwijl je bewerkt. Shortcodes tonen alleen de tag; je previewt het resultaat.
• Portabiliteit. Als je de plugin deactiveert die een block levert, blijft de opgeslagen HTML meestal zichtbaar (bevroren op de versie van de laatste opslag). Als je de plugin deactiveert die een shortcode levert, blijft de tag tussen haakjes in de content als pure tekst staan, wat er meestal gebroken uitziet.
• Herbruikbaarheid. Shortcodes kunnen overal worden toegevoegd waar PHP draait, inclusief in widgets, templates en excerpts. Blocks zijn ontworpen voor het blockeditor-gebied, hoewel "Herbruikbare Blocks" en de FSE (full-site editing) beweging die kloof aan het dichten zijn.

Welke ingebouwde WordPress shortcodes worden nog steeds geleverd in core?

WordPress core heeft historisch een handvol shortcodes geleverd. Per 2026 zijn dit de overlevers in de codebase:

• [gallery] — Afbeeldingengalerij. Nog steeds gebruikt door de klassieke editor en als fallback wanneer het Galerij-block wordt geconverteerd.
• [caption] — Omsluit een afbeelding met een bijschrift. Grotendeels vervangen door het Image-block maar nog steeds uitgestuurd in sommige workflows.
• [audio] en [video] — Native HTML5-speler voor zelf-gehoste media.
• [embed] — Forceert dat een URL wordt ingebed via de oEmbed-handler. Zelden nodig omdat WordPress de meeste URLs auto-embedt.
• [playlist] — Audio- en videoplaylists. Nichegebruik.

De overgrote meerderheid van de shortcodes op een echte WordPress-site komt van plugins en thema's, niet van core.

Welke soorten plugins gebruiken shortcodes?

Vijf categorieën dekken bijna alle real-world shortcode-gebruik:

• Contactformulieren. Contact Form 7 ([contact-form-7 id="123"]), WPForms, Gravity Forms en Formidable stellen formulieren bloot via shortcodes. Zelfs wanneer deze plugins ook Gutenberg-blocks aanbieden, blijft de shortcode ondersteund voor backwards-compatibiliteit.
• E-commerce. WooCommerce gebruikt shortcodes voor Winkelwagen, Checkout, Mijn Account en productlijsten ([products limit="4"]). De blockeditor heeft nu equivalente blocks, maar shortcodes domineren nog steeds omdat de meeste thema's eromheen werden gebouwd.
• Page builders (in legacy modus). Oude Visual Composer, WPBakery en soortgelijke produceren massieve geneste shortcodes wanneer gebruikt in de klassieke editor. De page builder uitschakelen laat een muur van [vc_row][vc_column]...-tags als pure tekst achter in het bericht — een bekend lock-in probleem.
• Prijstabellen, sliders, accordeons. De meeste "content widget"-plugins (Soliloquy, Smart Slider, Easy Pricing Tables) werden historisch geleverd als shortcodes. Veel zijn nog steeds actief onderhouden maar hebben blocks toegevoegd.
• Membership- en leersites. MemberPress, LearnDash en soortgelijke beperken content met shortcode-wrappers zoals [restrict role="member"]...[/restrict].

Hoe werkt een shortcode eigenlijk onder de motorkap?

Drie regels plugin-code maken een shortcode. Dit minimale voorbeeld registreert een shortcode die een gele markering uitstuurt:

add_shortcode('highlight', function ($atts, $content = null) {
    $atts = shortcode_atts([
        'color' => 'yellow',
    ], $atts, 'highlight');

    return '<mark style="background:' . esc_attr($atts['color']) . '">' . do_shortcode($content) . '</mark>';
});

Wat er gebeurt wanneer WordPress [highlight color="pink"]Hallo[/highlight] rendert:

1. WordPress draait het filter the_content, dat do_shortcode() bevat.
2. do_shortcode() gebruikt een regex om shortcode-tags te vinden in de berichtinhoud.
3. Voor elke match roept het de geregistreerde handler aan met de attributen (['color' => 'pink']) en de innerlijke content ('Hallo').
4. De handler geeft een string terug, die de shortcode-tag in de uitvoer vervangt.
5. De berichtinhoud wordt dan gerenderd naar de browser met de tag vervangen.

De regex-parse bij elke berichtrender is de performance-kost. Op een site met duizenden berichten, zonder cache en met shortcodes in elk bericht, telt dat op. Een page cache (Redis, WP Super Cache) lost dit op door de uiteindelijk gerenderde HTML op te slaan en de parse over te slaan.

Wanneer moet ik shortcodes nog steeds gebruiken in 2026?

Drie legitieme gevallen:

• Backwards-compatibiliteit. Als je site al shortcodes gebruikt van Contact Form 7, WooCommerce of een gevestigde plugin, blijf ze gebruiken. Massaal oude berichten converteren naar blocks is een meerdaags project met weinig opbrengst.
• Buiten de blockeditor. Widgets (in klassieke widget-gebieden), excerpts, custom post type loops, page builder-content, en e-mails verzonden via Mailchimp-templates accepteren nog steeds shortcodes maar geen blocks. Shortcodes werken in elke context waar do_shortcode() kan worden aangeroepen.
• Templates en themacode. echo do_shortcode('[my-form id="3"]'); in een PHP-template plaatsen is een manier van één regel om plugin-output te injecteren. Blocks zouden server-side block-rendering vereisen, wat meer code is.

Voor echt nieuwe functionaliteit op een nieuwe site, geef de voorkeur aan blocks. Ze zijn de richting van het WordPress-core, hebben een betere bewerkingservaring, en vermijden de overhead van het parsen van shortcodes.

Wat is "shortcode bloat" en waarom is het belangrijk?

Shortcode bloat gebeurt wanneer een site afhankelijk is van tientallen shortcodes van inactieve of gedeactiveerde plugins. Twee faalmodi volgen:

• Plugin gedeactiveerd maar tags blijven. Je deactiveert een slider-plugin om iets te testen. Elke pagina die [slider id="3"] had, toont nu de letterlijke tekst "[slider id="3"]" in plaats van een slider. De oplossing is de plugin heractiveren of handmatig alle shortcode-tags uit de database verwijderen, wat omslachtig is.
• Page builder-migratie. Een site gebouwd in Visual Composer of WPBakery bevat geneste shortcodes zoals [vc_row][vc_column width="1/2"][vc_column_text]Hallo[/vc_column_text][/vc_column][/vc_row]. Van thema wisselen of de builder deactiveren onthult dit alles als pure tekst. Dit is de bron van het "ik kan mijn site niet migreren naar Gutenberg"-pijnpunt dat duizenden sites heeft gevangen.

De pragmatische preventie: kies plugins waar je je voor de lange termijn aan committeert, en geef voorkeur aan plugins die ook blocks ondersteunen zodat je geleidelijk kunt migreren. Voor sites gebouwd voor 2018, verwacht een echt migratieproject in plaats van een schone overstap.

Kan ik mijn eigen shortcode maken zonder een plugin te schrijven?

Ja, drie manieren:

1. In de functions.php van een child theme. Voeg de add_shortcode()-aanroep toe. De shortcode komt overal op de site beschikbaar. Werkt maar de shortcode is gebonden aan dat thema; wissel van thema en de shortcode verdwijnt.
2. In een custom mu-plugin. Maak wp-content/mu-plugins/my-shortcodes.php en zet je add_shortcode()-aanroepen daar. Overleeft themawisselingen en de meeste updates. De schonere oplossing.
3. Via een "Code Snippets"-plugin. Plugins zoals Code Snippets of WPCode laten je PHP toevoegen via de admin-UI. Handig als je geen bestanden kunt bewerken, maar voegt een admin-niveau afhankelijkheid toe voor code die idealiter in bestanden woont.

Wat zijn veelvoorkomende shortcode-fouten?

• do_shortcode() vergeten op innerlijke content. Als je shortcode content omsluit (omsluitende shortcode), zou je do_shortcode($content) moeten aanroepen op het innerlijke deel zodat geneste shortcodes werken. Zonder dat rendert [outer][inner][/outer] alleen de buitenste shortcode en laat [inner] als pure tekst achter.
• Echoen binnen de handler. Shortcode-handlers moeten hun output retourneren, niet echoen. Een ge-echo'de shortcode rendert vóór de content waarin hij is ingebed, en breekt de paginalayout op subtiele manieren.
• esc_attr() vergeten op attributen. Zonder escaping kunnen door gebruikers verstrekte attribuutwaarden uit de HTML breken en XSS-kwetsbaarheden creëren. Escape altijd wat je uitstuurt.
• Shortcodes in widgets die ze niet uitvoeren. Sommige klassieke widget-types (zoals de basis Text widget pre-WordPress 4.9) voeren shortcodes niet automatisch uit. Fix: add_filter('widget_text', 'do_shortcode');.
• Tags binnen andere tags die parse-verwarring veroorzaken. Een shortcode-attribuut dat een vierkant haakje bevat ([shortcode label="Click [here]"]) verwart de parser. WordPress handelt veel gevallen af maar niet alle; HTML-entiteiten gebruiken ([ en ]) is de veilige workaround.
• Shortcodes recursief toevoegen aan do_shortcode. Binnen een shortcode-handler do_shortcode() aanroepen op content die dezelfde shortcode bevat, creëert een oneindige loop. WordPress heeft beveiligingen ertegen maar het symptoom is een blanco pagina of een memory-exhaustion-fout.

Hoe vind ik elke shortcode gebruikt op mijn site?

Drie snelle benaderingen:

1. Database-zoekopdracht. Voer een SQL-query uit tegen wp_posts: SELECT DISTINCT REGEXP_SUBSTR(post_content, '\\[[a-z_-]+') FROM wp_posts WHERE post_status = 'publish';. Lijst elke shortcode-tag op die in gepubliceerde content verschijnt.
2. WP-CLI. wp shortcode list toont elke geregistreerde shortcode-handler. Vergelijk met de databaselijst om shortcodes te vinden die worden gebruikt maar geen actieve handler meer hebben (waarschijnlijk van een gedeactiveerde plugin).
3. De "Shortcode Cleaner"- of "Find My Blocks"-type plugins. Scannen content op shortcode- en block-gebruik. Nuttig voordat je een plugin deactiveert om te zien hoe wijdverbreid de shortcodes worden gebruikt.

Wat met beveiliging?

Shortcodes zelf zijn niet onveilig; de vraag is wat de handler doet met de attributen. Twee dreigingsmodellen:

• Een onbetrouwbare gebruiker dient content in met shortcodes. Als een bijdrager of abonnee berichten kan indienen en de shortcode draait server-side code (zoals [exec command="..."] van een dev-plugin), is dat een pad voor willekeurige code-uitvoering. WordPress-core strip shortcodes uit content ingediend door gebruikers met lage privileges standaard; maak deze bescherming niet ongedaan.
• Shortcode-attributen worden onveilig uitgestuurd. Een slecht geschreven shortcode kan [badge text="..."] rechtstreeks in de pagina echoen zonder escaping, waardoor een admin die een bericht bewerkt scripttags kan injecteren. Houd berichtbewerking alleen voor admins, en escape altijd attribuutwaarden bij het schrijven van custom shortcodes.

Wat InspectWP controleert

Shortcodes zijn niet direct onderdeel van een InspectWP-security- of performance-rapport, maar hun effecten verschijnen op verschillende plekken. Een site met shortcodes van gedeactiveerde plugins heeft doorgaans "gebroken layouts"-bevindingen (gerenderde tekst met vierkante haakjes). Een site met zwaar shortcode-gebruik zonder page cache verschijnt als traag TTFB. En een site waar Visual Composer- of WPBakery-shortcodes doorlekken naar de gerenderde HTML (omdat de page builder gebroken of gedeactiveerd is) verschijnt als render-fouten en accessibility-overtredingen. Het aanbevolen patroon in 2026 is om shortcodes te blijven gebruiken om legacy-redenen, blocks te verkiezen voor nieuwe content, en je site periodiek te auditen op shortcodes wier handlers niet meer geregistreerd zijn.