Een full-service bureau runnen betekent jongleren met projecten op het gebied van ontwerp, ontwikkeling en marketing. Elk hiervan heeft zijn eigen uitdagingen, maar klanten verwachten in elk geval dat ze naadloos samenwerken en snelle resultaten leveren.

Maar waar iets groeit, ontstaan er barsten. De ene klant wil een campagne die het liefst nog gisteren werd gelanceerd, een andere wil een integratie op maat en een derde verwacht vlekkeloze prestaties tijdens een verkeersgolf. Ondertussen stuitert je team heen en weer tussen testsites, updates en fixes die in stilte kostbare tijd opslokken.

De waarheid is dat wat bureaus vertraagt niet hun creativiteit of strategie is, maar de infrastructuur eronder. De juiste hostingpartner maakt van die onzichtbare laag een voordeel en helpt je vol vertrouwen te schalen, projecten in beweging te houden en consistente resultaten te leveren die klanten ook daadwerkelijk kunnen meten.

In dit artikel kijken we naar de grootste uitdagingen voor full-service bureaus en hoe de juiste hostingpartner ervoor kan zorgen dat groei veel natuurlijker aanvoelt.

De uitdaging van het schalen van een full-service bureau

Het afhandelen van een project van maar één klant is beheersbaar, omdat je alle tijd kunt besteden aan details, goedkeuring kunt krijgen en problemen kunt oplossen als ze zich voordoen. Als je datzelfde model gaat schalen over tientallen of zelfs honderden klanten, beginnen de barsten zichtbaar te worden.

Full-service bureaus voelen dit acuut omdat je niet slechts één soort service levert. Er wordt van je verwacht dat je webontwikkeling, prestatieoptimalisatie, creatieve campagnes en voortdurende marketingondersteuning verzorgt, vaak voor klanten met heel verschillende verwachtingen en technische stacks.

Die diversiteit is een waardevol iets, maar het vermenigvuldigt ook de operationele belasting. Ontwikkelaars zetten WordPress installaties op en jagen pluginconflicten op, marketeers wachten op fixes voordat ze campagnes lanceren en accountmanagers moeten klanten geruststellen als de prestaties afnemen of tijdschema’s in het gedrang komen.

Dit is hoe het in de praktijk werkt:

• Gefragmenteerde hostingsets: De ene klant zit op een betrouwbaar platform, de andere nog steeds op goedkope gedeelde hosting en weer een andere blijft vasthouden aan een verouderde stack. Je team wordt gedwongen om drie verschillende workflows te leren om de boel draaiende te houden.
• Chaos in campagnes: De Black Friday sales van een retailklant gaat van start en hun site crasht onder de enorme hoeveelheid verkeer. Ontwikkelaars worstelen om in realtime prestatieverbeteringen toe te passen, marketeers pauzeren campagnes halverwege de vlucht en de verkoop loopt met de minuut terug.
• Testomgevingen zijn traag: Je ontwerpteam levert een partij nieuwe landingspagina’s, maar de testsites zijn buggy of pijnlijk traag. QA duurt dagen, het testen van campagnes kan niet beginnen en de tijdlijnen voor lanceringen schuiven op. Klanten kunnen vertragingen ervaren, maar intern weet je team dat het de infrastructuur is die het probleem veroorzaakt.
• Verwachtingen van de klant versus bandbreedte van het team: De ene klant wil dagelijkse rapporten, de andere dringende checkout-fixes en weer een andere SEO-updates. Zonder gecentraliseerde tools verspillen accountmanagers uren aan het najagen van de basis.

Vermenigvuldig die problemen met tientallen accounts en een eenvoudige workflow wordt een constante brandoefening. Hoe groter je groeit, hoe scherper de afweging: of je voegt meer mensen toe of je accepteert dat je team evenveel tijd besteedt aan het oplossen van problemen als aan het creëren ervan. Geen van beide is duurzaam.

Schaalvergroting vereist een heroverweging van de ondersteuning achter het werk. Zonder een betrouwbare infrastructuur wordt van ervaren teams gevraagd om gewicht in de schaal te leggen dat ze niet zouden moeten dragen en dat vertraagt de groei meer dan een gemiste campagne ooit zou kunnen.

Daarom gaat de volgende uitdaging voor bureaus niet alleen over mensen of processen, maar over de WordPress infrastructuur waarop alles draait.

Waarom WordPress infrastructuur kritisch wordt op schaal

Het is gemakkelijk om je te richten op het ontwerp, de campagnes en de berichtgeving, omdat dit is wat klanten zien, maar de echte test voor het vermogen van een bureau om op schaal te leveren is de infrastructuur eronder.

Zodra je meerdere accounts met een hoge vraag beheert, wordt die onzichtbare laag het verschil tussen probleemloze lanceringen en constante brandjes blussen.

Voor bureaus is de kwaliteit van de infrastructuur geen hokje dat je kunt aanvinken. Het komt neer op vijf factoren die direct bepalend zijn voor de resultaten:

• Uptime: Het maakt klanten niet uit waarom een site down is gegaan; ze zien alleen verloren omzet en gemiste kansen. Zelfs een paar minuten offline tijdens een lancering kan betekenen dat er duizenden euro’s verloren gaan.
• Prestaties: Trage pagina’s doden conversies, verlagen de kwaliteitsscore van advertenties en de SEO. Een vertraging van twee seconden bij het afrekenen kan het achterlaten van een winkelwagentje verdubbelen.
• Beveiliging: Een enkele inbreuk treft niet alleen één klant; het schaadt het vertrouwen in je bureau als geheel.
• Schaalbaarheid: Campagnes leven of sterven door pieken in het verkeer. Infrastructuur die bezwijkt onder belasting dwingt je team in crisismodus in plaats van optimalisatie.
• Efficiënte workflow: Het gaat niet alleen om snelheid en uptime. Ontwikkelaars, marketeers en accountmanagers hebben testomgevingen, rolgebaseerde toegang en realtime analyses nodig om projecten in beweging te houden.

Als de infrastructuur tekortschiet, zijn de gevolgen duur. Ontwikkelaars patchen in plaats van te bouwen, marketeers vertragen campagnes en accountmanagers managen frustratie in plaats van groei. Aan de buitenkant ziet het eruit als een “technische hik”, maar aan de binnenkant zijn het verloren uren, gemiste inkomsten en een verzwakt vertrouwen.

Op schaal bepalen deze inefficiënties je plafond. Een zwakke infrastructuur beperkt het aantal klanten dat je kunt bedienen en het vertrouwen dat je kunt hebben in complexe projecten. Een sterke WordPress infrastructuur doet het tegenovergestelde en creëert een basis voor soepele samenwerking, betrouwbare resultaten en groei die moeiteloos aanvoelt.

Marketeers spenderen eindeloos veel uren aan het perfectioneren van advertenties, het finetunen van targeting en het bijschaven van teksten van landingspagina’s. Toch is er één stukje van de conversiepuzzel dat vaak over het hoofd wordt gezien: hosting.

Een snelle, betrouwbare website is niet alleen leuk om te hebben. Het beïnvloedt direct of klikken klanten worden. Google heeft aangetoond dat zelfs een vertraging van één seconde in de laadtijd conversies al met 20% kan verlagen. Dat betekent dat de infrastructuur van je website de ROI van je campagnes kan maken of breken.

Daarom werken toonaangevende bureaus zoals One18Media, Tao Digital Marketing en Torro Media samen met Kinsta. Door de knelpunten van trage of onbetrouwbare hosting weg te nemen, zijn ze in staat geweest snellere, betrouwbaardere sites te lanceren om elke euro die ze in marketing stoppen, te maximaliseren.

Wat marketeers meestal over het hoofd zien bij hosting

Voor veel marketeers voelt hosting als een “moetje”. Het wordt vaak beschreven als “waar je site woont”, een hokje dat je moet aanvinken als je een website lanceert. Zolang de site uiteindelijk laadt, wordt aangenomen dat de klus geklaard is.

De werkelijkheid is veel genuanceerder. Hosting speelt een directe rol in een aantal van de belangrijkste factoren die je marketingsucces bepalen:

• Laadsnelheid: Elke seconde telt. Een trage reactietijd van de server of een hostingplan met te weinig vermogen kan de laadsnelheid van pagina’s aanzienlijk beïnvloeden, waardoor conversies direct afnemen en bouncepercentages toenemen.
• Uptime en betrouwbaarheid: Zelfs de beste campagne kan geen resultaten opleveren als je landingspagina down is. Elke minuut downtime is verspild budget en gemiste verkoopkansen.
• SEO prestaties: Zoekmachines zoals Google gebruiken sitesnelheid en stabiliteit als rankingfactoren. Slechte hosting kan een lagere organische zichtbaarheid betekenen, waardoor het moeilijker (en duurder) wordt om verkeer te winnen.
• Advertentie kwaliteitsscores: Platforms zoals Google Ads houden rekening met de ervaring van je landingspagina. Als je site traag laadt, betaal je meer per klik voor dezelfde advertentieplaatsing.

Waarom wordt hosting dan over het hoofd gezien in marketing? In de meeste bedrijven zorgt IT voor de infrastructuur terwijl marketeers zich richten op advertenties en funnels. Maar als je verkeer op een trage of instabiele site terechtkomt, mislukken zelfs de beste campagnes.

Onze analyse van 2024 op Black Friday en Cyber Monday liet zien dat het verkeer 42% meer steeg dan normaal, met 24% meer kassamomenten op Black Friday.

Zonder betrouwbare hosting verdwijnen die conversies. Marketeers hoeven geen infrastructuurexperts te zijn, maar ze kunnen het niet overslaan, want hosting beschermt direct de ROI van campagnes.

 

LOS ANGELES — (BUSINESS WIRE) — Kinsta, een toonaangevende managed hosting provider voor WordPress, heeft Jon Penland benoemd tot Chief Executive Officer om het uitzonderlijke product en de bekroonde klantgerichte groeistrategie van het bedrijf verder uit te bouwen. Kinsta heeft ook Matt Reid, voormalig senior vice president bij BigCommerce, benoemd tot de nieuwe Chief Marketing Officer.

Kinsta heeft al meer dan tien jaar een staat van dienst als het gaat om het leveren van uitgebreide hostingdiensten met veel features en een buitengewone klantervaring. Penland en Reid zullen leiding geven aan de missie van het bedrijf om website-eigenaren en -ontwikkelaars te ondersteunen.

Penland begon ongeveer negen jaar geleden bij Kinsta als support Engineer en doorliep posities via een aantal functies in sales, operations en customer success, tot Chief Operating Officer voordat hij tot CEO werd benoemd. Hij gelooft sterk in Kinsta’s cultuur van het combineren van kwaliteit, service en waarde voor de industrie.

De overgang naar de CEO zal naar verwachting geen grote verschuivingen met zich meebrengen, omdat Penland al betrokken was bij het leiderschap van het bedrijf. De afgelopen zes jaar was hij als lid van de Raad van Bestuur nauw betrokken bij de belangrijkste beslissingen van Kinsta.

“Ik kwam negen jaar geleden bij Kinsta omdat ik onder de indruk was van de reputatie van Kinsta op het gebied van toonaangevende prestaties en hoogwaardige ondersteuning,” zei Penland. “We hebben sindsdien voortgebouwd op die kwaliteiten en zijn in de loop der tijd sterker geworden. Ik geloof dat we de beste ter wereld zijn in wat we doen. Maar we kunnen nog beter. Er is veel ruimte voor ons om te groeien. We zien enorme mogelijkheden om klanten te helpen zich aan te passen aan de enorme verschuivingen in de manier waarop de wereld webverkeer ontdekt, consumeert en aanstuurt. The sky is the limit.”

“Jon is de perfecte persoon om Kinsta te leiden in haar nieuwe groeifase. Hij kent het bedrijf als geen ander – hij heeft in de hele organisatie gewerkt om het op te bouwen tot wat het nu is,” zegt voormalig Kinsta CEO Mark Gavalda, die bij het bedrijf blijft als oprichter, voorzitter en bestuurslid. “Met Jon’s standvastige leiderschap zal Kinsta zich blijven inzetten om ervoor te zorgen dat onze stimulansen zijn afgestemd op het succes van onze klanten.”

Reid is aangenomen om zijn sterke achtergrond op het gebied van effectieve marketing naar kleine, zakelijke en bureau-klanten te brengen en om de groei en go-to-market strategie van Kinsta te versnellen. Hij heeft een unieke mix van ervaring met het bereiken van topbureaus en bedrijven van alle groottes.

“Ik vind het geweldig om bij Kinsta te komen werken in deze spannende fase van uitbreiding,” zei Reid. “De indrukwekkende staat van dienst van het bedrijf op het gebied van omzetgroei en winstgevendheid, service van wereldklasse en productinnovatie is een recept voor succes. Ik kijk ernaar uit om samen met het team onze wereldwijde impact nog verder te vergroten.”

“Matt’s diepgaande kennis van de hele funnel zal onze marketing- en samenwerkingsinspanningen een superboost geven,” zei Penland. “Ik ben benieuwd hoe hij Kinsta begeleidt terwijl we onze nieuwe groeifase ingaan.”

Over Kinsta

Kinsta is een premium managed hosting voor WordPress oplossing – ontworpen voor alle soorten bedrijven, bureaus en e-commerce winkels met veel verkeer. In zeer concurrerende markten heeft Kinsta de hoogste G2-score van alle oplossingen en is de algehele nummer 1 op het gebied van marktaanwezigheid en klanttevredenheid binnen meerdere industriecategorieën.

Kinsta levert aan kleine bedrijven tot Fortune 500 ondernemingen, ondersteunt meer dan 140.000 klanten in 128 landen en heeft alleen al in 2024 bijna 40.000 nieuwe sites opgeleverd. Kinsta biedt 365 dagen per jaar 24/7 ondersteuning – in tien talen – door een team van deskundige technici.

Ga voor meer informatie over Kinsta en om je aan te melden voor een risicovrije gratis proefperiode naar kinsta.com.

Deze content werd oorspronkelijk gepubliceerd op Business Wire.

Weet je niet zeker of je WordPress Multisite of losse WordPress installaties moet gebruiken?

Beide benaderingen kunnen haalbare oplossingen zijn als je meer dan één WordPress site moet maken. Elke aanpak heeft echter zijn eigen sterke en zwakke punten, dus het is belangrijk om de beste optie te kiezen voor jouw specifieke situatie.

In dit artikel helpen we je de juiste keuze te maken door alles te behandelen wat je moet weten over WordPress Multisite vs meerdere WordPress installaties, inclusief de voor- en nadelen van elke aanpak, een aantal vragen om je te helpen kiezen en een aantal praktijkvoorbeelden van wanneer je ze allebei moet gebruiken.

Hoe werkt WordPress Multisite?

Met WordPress Multisite kun je een netwerk van sites maken die allemaal aangedreven worden door een enkele WordPress installatie. Elke netwerksite deelt dezelfde set gebruikersaccounts en geïnstalleerde extensies (plugins/themes), wat in sommige situaties handig kan zijn.

Om je te helpen bij het beheren van je netwerk van sites, krijg je een speciale netwerkbeheerder gebruikersrol en dashboard. Je kunt ook verschillende gebruikers toewijzen als sitebeheerder voor specifieke sites in je netwerk.

Kan elke site in het Multisite netwerk zijn eigen domeinnaam hebben?

Met domain mapping kun je elke netwerksite zijn eigen unieke domeinnaam geven, zodat ze er van buitenaf als aparte sites uitzien.

In totaal heb je met Multisite drie opties om de URL’s van afzonderlijke netwerksites te beheren:

• Subdomein: Elke site krijgt zijn eigen subdomein op dezelfde domeinnaam, zoals site1.jouwsite.com, site2.jouwsite.com en site3.jouwsite.com.
• Submap: Elke site wordt in een submap op dezelfde domeinnaam geplaatst, zoals jouwsite.com/site1, jouwsite.com/site2 en jouwsite.com/site3.
• Domain mapping: Elke site kan zijn eigen unieke domeinnaam hebben, zoals site1.com, site2.com en site3.com.

WordPress is al lang niet meer alleen voor bloggers. Het is een flexibel, modern platform dat de marketingsites, helpcenters en afgeschermde content en producten van veel B2B SaaS bedrijven aandrijft.

Met de juiste hosting en configuratie geeft het teams de middelen om snel te reageren, met regelmaat te publiceren en vol vertrouwen op te schalen, of ze nu landingspagina’s lanceren, dashboards bouwen of gelokaliseerde microsites uitrollen.

Maar voor het benutten van dat potentieel is meer nodig dan een goed thema en een paar plugins. Voor échte groei heb je prestaties, beveiliging, schaalbaarheid en een duidelijk inzicht in je klanttraject nodig.

In deze gids laten we je zien hoe je WordPress kunt optimaliseren voor SaaS. Zowat alles valt hieronder, van caching en CDN gebruik tot het kiezen van de juiste architectuur, het beveiligen van je stack, het integreren van analytics en het bouwen van een setup die succes op de lange termijn ondersteunt.

Prestatie-optimalisatie voor SaaS waardige snelheid

Laten we eens kijken naar een aantal belangrijke optimalisaties die je WordPress site kunnen helpen sneller te laden en te presteren als een SaaS platform.

Statische paginacaching

Een van de eerste stappen is het instellen van statische paginacaching. Dit betekent dat je pagina’s vooraf worden gerenderd als HTML en worden afgeleverd zonder dat ze elke keer de database hoeven te bevragen.

Plugins zoals WP Super Cache doen dit goed op eenvoudigere sites, maar caching op serverniveau, zoals Kinsta biedt, levert betere prestaties met minder gedoe. Het weet wanneer het de cache moet wissen en regenereren op basis van siteactiviteit, dus je krijgt de snelheid zonder het onderhoud.

CDN integratie

Om een wereldwijd publiek te bereiken, moet statische cache worden gekoppeld aan een content delivery network (CDN). Een CDN verlaagt de latency door de bestanden van je site vanaf servers dicht bij je gebruikers aan te bieden.

Cloudflare is vooral populair voor SaaS sites omdat het zowel prestaties als bescherming biedt. De slimme caching en edge regels versnellen de levering van content terwijl ze ook veelvoorkomende aanvallen blokkeren.

Als je al host bij Kinsta, krijg je Cloudflare CDN-toegang op zakelijk niveau, geen installatie vereist.

Afbeeldingen optimaliseren

Afbeeldingen zijn een ander veelvoorkomend probleem. Veel SaaS teams uploaden te grote afbeeldingen zonder zich te realiseren hoezeer ze de boel vertragen. Het optimaliseren van afbeeldingen door ze te comprimeren en te converteren naar WebP vermindert de laadtijden aanzienlijk.

ShortPixel is hier een favoriet voor, omdat het automatisch de compressie en formaatconversie afhandelt. Jetpack biedt ook functies voor het optimaliseren van afbeeldingen, waaronder lazyloading, waarbij wordt gewacht met het laden van afbeeldingen totdat ze daadwerkelijk zichtbaar zijn in het browservenster. Het is een eenvoudige aanpassing die lange pagina’s veel sneller kan maken.

Object caching

Object caching is belangrijk voor dynamische inhoud zoals ingelogde dashboards of beheerinterfaces. Waar statische caching helpt bij openbare pagina’s, slaat object caching de resultaten van frequente databaseverzoeken op zodat ze niet elke keer opnieuw gegenereerd hoeven te worden.

Dit is vooral handig voor gepersonaliseerde inhoud, filters en interne tools. Redis en Memcached zijn hier de aangewezen technologieën.

Kinsta ondersteunt Redis en maakt het gemakkelijk om het direct in te schakelen vanuit het MyKinsta dashboard, geen sysadmin vaardigheden nodig.

Als je een eigen thema bouwt of met een childthema werkt, moet je misschien bepaalde stylingkenmerken verwijderen of verbergen, of het nu gaat om een los coreblok of een volledige thema-stijlvariatie.

Dit is niet alleen een kwestie van voorkeur. Het levert vaak praktische voordelen op, zoals betere prestaties, een consistenter ontwerp en een eenvoudigere gebruikersinterface.

De aanpak om deze doelen te bereiken varieert en is waarschijnlijk afhankelijk van je behoeften en vaardigheden. Voor de voorbeelden in dit artikel werken we met een childthema van Twenty Twenty-Five (TT5), een modern WordPress blokthema.

Verwijderen hangt af van hoe het is geregistreerd

Voor onze doeleinden maken we, wanneer we het hebben over het ongedaan maken van het registreren van een blok of thema stijlvariatie, onderscheid tussen volledige en gedeeltelijke verwijdering, en of de variatie volledig is verwijderd of slechts verborgen is in de interface. Het onderscheid is belangrijk.

Begrijpen hoe je een blok kunt de-registreren begint met weten hoe het is geregistreerd. Coreblokken die zijn geregistreerd met JavaScript kunnen bijvoorbeeld het beste in die taal worden uitgeschreven. Themastijlvariaties daarentegen zijn geregistreerd met PHP en daarom kan een andere aanpak op zijn plaats zijn.

Het ongedaan maken van custom blokken valt buiten het bestek van dit artikel en je aanpak hangt af van hoe die blokken oorspronkelijk zijn geregistreerd.

Wat is een stijlvariatie?

WordPress maakt onderscheid tussen variaties van blokstijlen en themastijlen. Blokstijlen zijn visuele alternatieven voor een specifiek blok, zoals de “vul” of “omlijn” stijlen van een knopblok. Stijlvariaties van blokken worden geregistreerd in core, theme.json, block.json (of in een plugin).

Thema stijlvariaties daarentegen zijn volledige visuele alternatieven die kleuren, typografie en layouts bevatten die zijn gedefinieerd in een uniek theme.json bestand. Hiermee kunnen gebruikers wisselen tussen verschillende looks (skins) voor een site zonder het thema te veranderen. TT5 wordt geleverd met acht stijlvariaties naast de standaardstijl.

De eerste stap: enqueue je scripts

Omdat we met een childthema werken, moet je ervoor zorgen dat je je scripts op de juiste manier enqueuet.

Deze installatie helpt je op weg, inclusief het enqueuen van ons aangepaste unregister-blocks.js bestand.

// Enqueue Parent and Child Styles
add_action('wp_enqueue_scripts', function () 
    wp_enqueue_style(
        'parent-style',
        get_template_directory_uri() . '/style.css'
    );

    wp_enqueue_style(
        'child-style',
        get_stylesheet_uri(),
        ['parent-style'],
        wp_get_theme()->get('Version')
    );
);

// Enqueue styles in the WordPress admin
add_action('admin_enqueue_scripts', function () 
    wp_enqueue_style(
        'child-admin-style',
        get_stylesheet_uri(),
        [],
        wp_get_theme()->get('Version')
    );
);

// Enqueue JavaScript for block editor
add_action('enqueue_block_editor_assets', function () 
    wp_enqueue_script(
        'unregister-core-blocks',
        get_stylesheet_directory_uri() . '/js/unregister-blocks.js',
        ['wp-blocks', 'wp-dom-ready', 'wp-edit-post'],
        null,
        true
    );
);

Zoals je kunt zien, hebben we een JavaScript-bestand op js/unregister-blocks.js, dat al onze scripts voor dit artikel bevat.

Gebruik niet get_template_directory_uri() voor het JavaScript-bestand, want dit verwijst naar het hoofdthema.

Timing is alles

Weten wanneer een hook afgaat is cruciaal bij het werken met PHP in WordPress. Je moet bekend zijn met de basis laadprocedure, die begint op wp-settings.php:

• Constants
• Globals
• Core componenten
• Plugins laden
• Thema laden

Uitzoeken op welk punt een custom functie moet worden uitgevoerd is een van de lastigste en meest frustrerende onderdelen van WordPress ontwikkeling.

Een blokstijl uit de core verwijderen

Laten we eens kijken naar een situatie waarin je de stijl van een coreblok wilt verwijderen. In dit geval willen we de contourstijl voor het Button blok verwijderen.

Omdat de stijlen voor vulling en omlijning van knoppen zijn geregistreerd in het theme.json bestand, gebruiken we JavaScript om het proces af te handelen.

wp.domReady(() => 
    if (wp.blocks && wp.blocks.unregisterBlockStyle) 
        wp.blocks.unregisterBlockStyle('core/button', 'outline');
    
);

Het resultaat is het verwijderen van de contourstijl in de werkbalk en zijbalk.

Blokthema’s vertalen WordPress anders dan een typische aanpak. Traditionele PHP templatebestanden met vertaalfuncties werken niet met HTML templates, blokken met JavaScript en de Site Editor. Deze verschuiving vereist dat je anders moet omgaan met de internationaliseringssystemen van WordPress blokken.

Deze gids biedt strategieën om je blokthema’s meertalig te maken. Je leert hoe je door de uitdagingen van het vertalen van blokthema’s navigeert, oplossingen toepast en integreert met vertaalplugins.

Waarom traditionele vertaalmethoden niet werken met blokthema’s (en hoe je het oplost)

Blokthema’s vervangen veel van de PHP-bestanden van WordPress door HTML-templates die blok-opmaak bevatten. Deze overstap brengt echter uitdagingen met zich mee, omdat HTML-templates geen PHP-vertaalfuncties kunnen uitvoeren zoals _() of _e(). Dit maakt de vertaalstrings die je al hebt volledig nutteloos in statische bestanden.

WordPress 6.8 brengt een aantal verbeteringen die de internationalisatie van blokthema’s vereenvoudigen. Thema’s met de juiste headers voor Text Domain en Domain Path hebben niet langer manual load_theme_textdomain() calls nodig.

In plaats daarvan laadt WordPress automatisch vertaalbestanden en geeft wp-content/languages/themes/ voorrang boven themamappen om de prestaties te verbeteren.

Om te beginnen stel je je thema in volgens de klassieke aanpak door metadata toe te voegen aan het style.css bestand.

/*
Theme Name: My Block Theme
Text Domain: my-block-theme
Domain Path: /languages
*/

Let op dat de kop Text Domain moet overeenkomen met de mapnaam van je thema (meestal in kebab-case) om ervoor te zorgen dat vertaalbestanden correct worden geladen in recente WordPress versies.

Net als bij style.css vereist je functions.php bestand minimale instellingen:

<?php
// Optional in WordPress 6.8+ but included for backward compatibility
function my_block_theme_setup() 
    load_theme_textdomain( 'my-block-theme', get_template_directory() . '/languages' );


add_action( 'after_setup_theme', 'my_block_theme_setup' );

// Register block scripts with translation support
function my_block_theme_scripts() 
    wp_enqueue_script(
        'my-block-theme-scripts',
        get_template_directory_uri() . '/assets/js/theme.js',
        array( 'wp-i18n' ),
        '1.0.0',
        true
    );

    wp_set_script_translations( 
        'my-block-theme-scripts', 
        'my-block-theme', 
        get_template_directory() . '/languages' 
    );


add_action( 'wp_enqueue_scripts', 'my_block_theme_scripts' );

Het belangrijkste verschil tussen klassieke en blokthema’s is hier dat de laatste de verantwoordelijkheid voor vertalingen splitst tussen server-side PHP en client-side JavaScript. Klassieke thema’s moeten daarentegen vertrouwen op PHP om de meeste vertalingen af te handelen.

Te veel bureaus besteden nog steeds uren aan dingen die automatisch zouden moeten gaan. Zaken zoals plugin-updates, voorbereiding van deployments en e-mails over de status van klanten. De lijst gaat maar door. Deze taken kunnen vervelend zijn en beslag leggen op je factureerbare tijd. Bovendien vergroten ze de kans op menselijke fouten.

Automatisering helpt je dat allemaal te voorkomen. Het bespaart tijd, vermindert fouten en maakt je team vrij om zich te richten op het échte werk voor de klant. Het maakt het ook gemakkelijker om op te schalen, omdat je niet telkens opnieuw processen hoeft op te bouwen als je een nieuwe site in gebruik neemt of een update live zet.

In deze gids behandelen we automatiseringsworkflows die speciaal zijn gemaakt voor WordPress bureaus. Hierin leer je hoe je:

• Git-gebaseerd versiebeheer kunt gebruiken, zelfs als je team niet vol zit met ontwikkelaars
• Testen en deployments kunt automatiseren
• Netjes van lokale ontwikkeling naar testen en productie gaat
• Updates, health checks en foutafhandeling kunt automatiseren met de Kinsta API
• Je workflow automatiseert met tools zoals projectmanagementsystemen
• Interne automatiseringen instelt die onboarding en publicatie afhandelen

Laten we beginnen met de basis van elke solide automatiseringsopzet: Git.

Op Git gebaseerde automatiseringsworkflows

Git zou standaard moeten zijn voor elk WordPress bureau, ongeacht hoe technisch je team is. Het houdt je code georganiseerd, maakt samenwerking strakker en geeft je een betrouwbare manier om terug te rollen als er iets kapot gaat.

Dankzij visuele tools zoals GitHub Desktop of GitKraken kunnen zelfs niet-ontwikkelaars volgen en bijdragen zonder de opdrachtregel te hoeven gebruiken.

Automatiseren met GitHub Actions of GitLab CI/CD

Versiebeheer is nog maar het begin. Als je Git eenmaal op zijn plek hebt, kun je automatiseringstools zoals GitHub Actions of GitLab CI/CD gebruiken om de repetitieve taken af te handelen.

Je kunt automatisch tests of kwaliteitscontroles uitvoeren elke keer als iemand code pusht. Je kunt ook deployments starten op basis van branch activiteit, zoals pushen naar main of het samenvoegen van een pull request.

Stel dat je assets wilt compileren of dependencies wilt installeren voordat code op een testomgeving komt. Je kunt simpelweg je composer install of npm run build stappen aan de pijplijn toevoegen. Dit elimineert zoveel mogelijk handmatige fouten, wat resulteert in snellere, betrouwbaardere en consistente deployments voor elk project.

Hier is een voorbeeld van een GitHub Action workflow die dependencies installeert, de kwaliteit van de code controleert en assets bouwt voor een WordPress project:

name: CI for WordPress

on:
  push:
    branches:
      - main
      - staging
  pull_request:

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          extensions: mbstring, intl, mysqli
          tools: composer

      - name: Validate composer.json and install dependencies
        run: |
          composer validate
          composer install --no-interaction --prefer-dist

      - name: Run PHPCS
        run: vendor/bin/phpcs --standard=WordPress ./wp-content/

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install and build frontend assets
        run: |
          npm ci
          npm run build

      # Optional: Add a deployment step here via SSH or Kinsta API/Webhook
      # - name: Deploy to staging/production
      #   run: ./deploy.sh

Kinsta compatibiliteit

Als je Kinsta gebruikt, heb je alles al wat je nodig hebt om in deze workflows te pluggen. SSH toegang is ingebouwd, dus je kunt direct vanuit je Git repo of CI/CD pipeline implementeren.

WP-CLI is ook beschikbaar, waardoor het eenvoudig is om taken na de deployment te scripten, zoals het flushen van de cache, het activeren van plugins of zelfs het uitvoeren van database-updates.

Git voegt structuur toe aan je workflow. Met automatisering er bovenop wordt het de ruggengraat van alles wat volgt.

Gutenberg heeft zich ontwikkeld tot een krachtige en zeer aanpasbare editor. Naast de robuuste out-of-the-box features kunnen WordPress ontwikkelaars tegenwoordig ook gebruik maken van een rijke set aan API’s om eenvoudig custom functies in hun websites te integreren. Deze uitbreidbaarheid maakt een hoge mate van ontwikkeling op maat mogelijk, waardoor ontwikkelaars zeer gepersonaliseerde en functierijke online ervaringen kunnen creëren.

In dit artikel worden twee minder bekende maar krachtige WordPress ontwikkelfuncties besproken: Stijlvariaties (ook bekend als blokstijlen) en Blokvariaties.

Hoewel hun nut in eerste instantie misschien onduidelijk lijkt, zul je verrast zijn hoe nuttig ze zijn en hoe je ze met een kleine tijdsinvestering naadloos kunt integreren in je workflow.

Aan de hand van een project uit de praktijk krijg je inzicht in wat ze zijn en hoe je ze kunt gebruiken. Je kunt dit project op je WordPress site implementeren door eenvoudigweg de code uit deze tutorial te kopiëren en te plakken en eventueel aanpassingen toe te voegen.

Laten we, voordat we in het project duiken, eerst de vereisten bekijken:

• Lokale WordPress ontwikkelomgeving: Hoewel de meesten voldoen, raden we DevKinsta, de lokale ontwikkelsuite van Kinsta, ten zeerste aan. Het is eenvoudig te gebruiken en biedt veel instellingen en tools om snel een lokale WordPress site te starten en te beheren.
• Node.js en npm: Deze zijn essentieel, omdat de Block Editor is gebouwd op React en een bouwproces vereist.
• Basis frontend ontwikkelingsvaardigheden: Het is handig om een basiskennis te hebben van Node.js, JavaScript (met React), PHP en CSS.

Hoewel dit project niet al te complex is, moet je bereid zijn om wat code te schrijven. De volledige code is ook beschikbaar op GitHub.

Tijd om te beginnen!

Blokstijlen versus blokvariaties

Blokstijlen en blokvariaties zijn twee krachtige WordPress functies voor developers. Hoewel hun namen erg op elkaar lijken, verschillen ze in doel en gebruik.

Blokstijlen, ook bekend als stijlvariaties, zijn kant-en-klare sets CSS stijlen waarmee je met één klik kunt veranderen hoe een blok eruit ziet. Nadat je een blokstijl hebt geregistreerd, verschijnt er een knop in de zijbalk van het blok waarmee je een kant-en-klare set stijlen kunt toewijzen aan het blok. Je kunt de stijlen in- en uitschakelen en een voorbeeld van het blok in de editor bekijken.

Stijlvariaties veranderen de attributen van het blok niet. Ze wijzigen alleen het uiterlijk van een blok door een CSS klasse toe te wijzen aan het wrapper element van het blok.

Blokvariaties zijn een krachtiger hulpmiddel omdat je hiermee een vooraf geconfigureerde versie van een blok kunt maken met attributen en binnenblokken. Ze verschijnen ook in de blok inserter applicatie van de editor. In wezen verschijnt een blokvariatie voor de gebruiker alsof het een op zichzelf staand blok is, volledig onafhankelijk van het blok waarop het is gebouwd.

Met blokvariaties kun je het uiterlijk, de begininstellingen en de structuur van een blok aanpassen.

Met dat alles in gedachten, laten we deze hulpmiddelen gebruiken om Gutenberg blokken naar een hoger niveau te tillen!