Yabba Dabba Doo, is Bedrock het WordPress van de toekomst?

Bedrock blaast een monolith uit het stenen tijdperk nieuw leven in!

WordPress is al jaren het populairste CMS ter wereld, maar qua development-workflow voelt het soms achterhaald aan. Veel ontwikkelaars die Laravel of andere moderne PHP-frameworks gewend zijn, missen een gestructureerde projectopzet, dependency management en betere beveiliging.

Ik schrijf al jaren over de mogelijkheden om Headless WordPress te gebruiken of juist, omgekeerd, WordPress te gebruiken als frontend voor andere headless applicaties. Een aardig voorbeeld is denk ik mijn recente artikel over Invoice Ninja als backend voor de facturering op je website.

Recentelijk kwam ik in aanraking met het ‘Bedrock’ project. Een veelbelovende ontwikkeling in het ‘anders’ kijken naar WordPress.

Bedrock, ontwikkeld door Roots, is een geavanceerde WordPress-boilerplate die de klassieke WordPress-structuur moderniseert en werkt met Composer, een .env-gebaseerde configuratie en verbeterde beveiliging. Dit zorgt voor een workflow die meer lijkt op Laravel dan op een traditionele WordPress-installatie. In deze blogpost duiken we diep in de mogelijkheden en voordelen van Bedrock en hoe je het kunt combineren met Laravel.

Wat is Bedrock en hoe is Bedrock anders dan WordPress?

Het installeren van WordPress is eenvoudig. Bij vrijwel iedere hosting partij kun je tegenwoordig met één druk op de knop WordPress installeren. Daardoor staan we er meestal niet bij stil, dat WordPress eigenlijk een heel rommelige en vooral kwetsbare bestandsstructuur heeft. De belangrijkste gegevens voor de toegang tot alles in je hele applicatie staan opgeslagen in een bestand wp-config.php wat direct in je ‘webroot’ staat. Met andere woorden, het bestand is direct toegankelijk vanuit de browser. Gelukkig zorgt de PHP compiler ervoor dat het bestand eerst ‘gecompileerd’ wordt, waardoor niemand de inhoud van het bestand direct kan zien, maar er zijn andere manieren om achter de inhoud van dat bestand te komen via de browser. Sommige editors laten namelijk een kopie bestand met een naam als wp-config.php~of wp-config.php.bk achter, wanneer de editor om de één of andere reden crasht. En dagelijks lopen duizenden, zo niet miljoenen scripts van hakkers site na site na, of er niet ergens één van de kopiebestanden te vinden is. Deze zijn namelijk wel zomaar te openen in je browser.

In Bedrock is dat allemaal wat anders opgezet.

Hieronder zie je de standaard WordPress folderstructuur

├── index.php
├── license.txt
├── readme.html
├── wp-activate.php
├── wp-admin
├── wp-blog-header.php
├── wp-comments-post.php
├── wp-config-sample.php
├── wp-content
│   ├── index.php
│   ├── plugins
│   └── themes
├── wp-cron.php
├── wp-includes
├── wp-links-opml.php
├── wp-load.php
├── wp-login.php
├── wp-mail.php
├── wp-settings.php
├── wp-signup.php
├── wp-trackback.php
└── xmlrpc.php

De structuur van Bedrock ziet er wat anders uit:

├── composer.json
├── config
│   ├── application.php     # Primary wp-config
│   └── environments
│       ├── development.php
│       ├── staging.php
│       └── production.php
├── vendor                  # Composer dependencies
└── web                     # Public document root
    ├── app                 # WordPress content dir
    │   ├── mu-plugins
    │   ├── plugins
    │   ├── themes
    │   └── uploads
    ├── wp-config.php
    ├── index.php
    └── wp                  # WordPress core

Is de folderstructuur echt van belang? Ja, dat is het zeker. Wanneer je bedenkt, dat in de bovenstaande layout de webroot de ‘web’ map is, en de cruciale veiligheidsgegevens niet in wp-config.php worden opgeslagen, maar de ‘config’ folder, dan begrijp je al, dat het ongeautoriseerd toegang krijgen tot gegevens al een stuk moeilijker is geworden.

Een tweede punt is de stabiliteit. Zoals ik al in eerdere blogposts heb opgemerkt, komt er samen met een plugin vaak een aantal ‘standaard libraries’ waar de plugin gebruik van maakt. Gewoontegetrouw worden die in de ‘vendor’ folder onder de folder van de plugin opgeslagen.

Versiebeheer

Wanneer je gebruik maakt van Bedrock dan betekent dat ook, dat je gebruik maakt van een aantal onmisbare tools voor versiebeheer:

• Composer package manager: Composer is een tool voor PHP package management. Dat wil zeggen, dat ieder package definieert welke andere packages er nodig zijn om te kunnen functioneren, en welke minimum- en maximum versie daarvan. Wanneer bijvoorbeeld één plugin aangeeft ‘MijnPackage’ 1.0 tot 2.1 nodig heeft, en een andere plugin aangeeft dat deze andere plugin alleen met ‘MijnPackage 1.8’ tot 2.0 wil werken, zal Composer ervoor zorgen, dat de grootst gemeenschappelijke versie geïnstalleerd wordt.
  Ook bij het updaten van plugins, zal rekening gehouden worden met de toegestane versies. Komen er tegenstrijdige versieregels, dan wordt een update geweigerd.
  De kans dat je te maken krijgt met conflicterende packages is een stuk minder geworden.
• Git/GitHub versiebeheer: Verander je iets, dan kan je altijd terug naar een vorige versie van de code.

Gedwongen staging

Staging is voor Bedrock geen optie, maar een vereiste. Een Bedrock implementatie kent drie ‘stages’, development, staging en production. Iedere verandering dient in development aan te worden gebracht, doorgegeven naar ‘staging’ voor het testen en indien de tests geaccepteerd zijn, dan pas gaat het door naar productie. Dit geldt letterlijk voor alles wat met code te maken heeft.

Een reden, dat het ook in productie niet mogelijk is plugins aan of uit te zetten. Het is ook een goede manier om een scheiding van functies aan te brengen. Een developer kan immers niet bij de productiedatabase, en heeft dus geen toegang tot de live data.

Stabiliteit

Bij ieder integratie initiatief tussen twee platformen is het altijd goed te kijken naar de ‘track record’ van de oplossing. De eerste stappen voor Bedrock zijn gezet in 2016. Bedrock is een door veel organisaties gebruikte oplossing om WordPress op een meer veilige manier te installeren.

Sinds Bedrock zijn er vanuit het project een aantal andere toevoegingen ontwikkeld, die er toe geleid hebben, dat Bedrock inmiddels de sporen verdient heeft in de WordPress Safety Rodeo.

Voor wie is Bedrock?

Laten we even duidelijk zijn. Bedrock is niet bedoeld voor de lokale ondernemer, die slechts een behoefte heeft aan een website van 5 pagina’s. Voor deze ondernemer is ‘Standaard WordPress’ prima geschikt. Het is bedoeld voor de ondernemer die verschillende toepassingen via of vanuit zijn website zo snel en veilig mogelijk beschikbaar wil stellen aan haar of zijn klanten. Wanneer je alleen een paar pagina’s en een blog hebt, is Bedrock overkill.

Enkele voorbeelden van websites waar Bedrock een goede oplossing zou kunnen zijn:

• Membership of abonnementsplatformen met een dienstverlening die niet via ‘standaard plugins’ wordt geboden.
  Het ontwikkelen van een WordPress plugin met uitgebreide functionaliteiten is een kostbare zaak. Om je een voorbeeld te geven, in de gemiddelde WordPress LMS plugin van enige kwaliteit zit meer dan 2 manjaren ontwikkeltijd. Eenzelfde functionaliteit kan je met Laravel / Filament in ongeveer een maand bouwen. (Geloof me, ik heb het al gedaan).
• Multi-site netwerken voor agencies of franchise bedrijven
  Bedrock biedt een veiligere structuur dan ‘Standaard WPMU’. Door de gedwongen staging is het voor de ‘subsites’ niet mogelijk plugins te gebruiken die niet eerst goed getest zijn in de bestaande omgeving. Om je een indruk te geven, WordPress.com is één van de grote sponsors van Bedrock, onder andere omdat zij de uitdaging van een Multisite situatie kennen als geen ander.
• WooCommerce webshops met aangepaste functionaliteiten
  Wanneer je in je WooCommerce webshop iets ‘anders’ wilt dan wat er via plugins wordt geboden, kan een Bedrock omgeving een veiligere omgeving bieden

In de rest van deze blogpost bespreek ik een aantal andere componenten van het Bedrock ecosysteem. Ieder component voegt nieuwe redenen toe, waarom Bedrock een goede oplossing zou kunnen zijn.

Bedrock : Een huwelijk tussen WordPress en Laravel!

Om Bedrock in het juiste perspectief te zien, moeten we een paar stappen naar achter doen en naar het hele Roots ecosysteem kijken, want ‘Bedrock’ is niet alles. Bedrock is de basis (het rotsbed) waar de rest van het ecosysteem op is gebouwd.

Binnen de Bedrock codebase is er alle ruimte om ook Laravel apps op te nemen. En dat leidt tot een aantal leuke andere opties. Maar laten we eerst eens kijken, wat dit hele Roots ecosysteem ons te bieden heeft. En dan zullen we al snel ontdekken dat Bedrock meer is dan een ‘slimmer ingedeelde bestandsstructuur voor WordPress.

Trellis – Alle software op een rijtje

Om een website goed te kunnen laten draaien, heb je natuurlijk ook bijpassende software nodig. ‘Trellis’ is een installatiescript om op de server waarop je Bedrock wilt laten draaien een perfect geoptimaliseerde omgeving te hebben. Trellis is een LEMP (Linux – NGIXN – MariaDB – PHP) stack. Je kan Bedrock prima zonder Trellis gebruiken, maar waarom zou je? Het scheelt je uren aan installatie- en configuratie.

Sage – Een interessant WordPress theming framework

Voordat er pagebuilders als Elementor waren, had vrijwel iedere serieuze webbouwer een ‘Theming Framework’ waar hij of zij het liefst mee werkt. Zelf werk ik nog steeds met het Genesis thema voor klanten die niet willen, dat er een pagebuilder wordt gebruikt.

Maar de meeste klassieke theming frameworks zijn gebouwd rond ‘hooks’. Het thema framework heeft standaard functionaliteiten en je moet kunnen programmeren om deze functionaliteiten te kunnen ‘overriden’.

Sage is een theming framework met een totaal ander uitgangspunt.

Zoals ik eerder al heb aangegeven, is er bij de ontwikkeling van Bedrock goed gekeken naar het Laravel ecosysteem. En een belangrijk onderdeel van dit ecosysteem is de template engine ‘Blade’.

In plaats van het ‘overschrijven’ van bestaande functionaliteit, zoals in de meeste klassieke frameworks, draait het in Blade allemaal om het ‘makkelijker te maken HTML te schrijven.

Om je een voorbeeld te geven. In standaard WordPress templates wordt gebruik gemaakt van PHP tags in de templates. Wanneer ik bijvoorbeeld een titel wil invoegen in een template wordt de code zoiets als:

<h1>
   <?php the_title()
   ?>
</h1>

Blade maakt dat allemaal een minder tikwerk. Daar is het

<h1>
   {{ the_title }}
</h1>

Ok, dat is niet echt een revolutionaire besparing. Maar Blade gaat een stapje verder met zogenaamde ‘components’. Ik kan in Blade components gebruiken. En die components kan ik zelf maken, of één of meer van de vele component libraries voor Blade downloaden.

Stel je voor, ik zou een ‘mycomponent’ library hebben gedownload met een coole layout voor een ‘kaart’.

Een van de dingen die ik hier zou kunnen doen is iets als onderstaande in te voegen:

<div class="cards">
   <x-mycomponent.card  :title="$title" :content="$content"/>
</div>

Ben je een WordPress professional die graag met DIVI of Elementor werkt en krijg je buikpijn van HTML, dan is Sage niets voor jou. Ben je een WP Professional die nog steeds templates complete uitcodeert, dan kan Sage je veel tijd besparen.

Ter informatie, Blade templates worden op de achtergrond gecompileerd naar PHP code, dus het eindresultaat is altijd ‘zo snel als menselijk mogelijk is’.

Om Sage te kunnen gebruiken, dienst NodeJs geïnstalleerd te zijn of te worden.

Acorn

Wanneer je Acorn gaat gebruiken in een WordPress toepassing verlaat je officieel het compatibility pad, ten gunste van je klant. Want hier ga je binnen WordPress een Laravel applicatie container laden. Deze applicatie container respecteert nog steeds de WordPress lifecycle en template hiërarchie, maar voegt wel een aantal belangrijke onderdelen van Laravel toe aan WordPress, die een groot aantal zaken makkelijker en robuuster maakt.

Wat dit allemaal is, kan je lezen op de Acorn pagina op de Roots website, maar in het kort komt het erop neer dat aan jouw WordPress website een groot aantal functies wordt toegevoegd, waaronder bijvoorbeeld een krachtig caching systeem, zonder de overhead van plugins, de mogelijkheid om bestanden in Amazon S3 op te slaan en een queueing systeem dat vele male sneller en krachtiger is dan WP Croun.

Het maakt het ook mogelijk om letterlijk honderden bestaande Laravel packages op te nemen in je WordPress applicaties.

Radicle

Radicle is de nieuwe loot aan de Roots stam. Het is een omgeving speciaal gericht op de ontwikkelaar. En van alle producten in het Roots ecosysteem is dit het enige onderdeel waarvoor betaald moet worden. Het is eigenlijk een combinatie van al het bovenstaande plus een aantal tools die het makkelijk maakt Bedrock websites uit te rollen. Het is een productivity tool voor ontwikkelaars.

Bedrock en Elementor

Mijn meest belangrijke vraag toen ik begon te experimenteren met Bedrock was natuurlijk of en in hoeverre Bedrock en Elementor samen willen werken. Wat hier belangrijk is, is dat je Elementor en Elementor Pro niet upload als plugin, maar via Composer. Gelukkig heeft Elementor een complete instructie voor je samengesteld hoe je Elementor en Elementor Pro via Composer kan installeren.

Bedrock en andere premium plugins

Voor alle plugins en thema’s uit de WordPress repository is er een installatie package beschikbaar via WPackagist. Wil je een plugin via WPackagist installeren, dan hoef je jouw composer file alleen te laten verwijzen naar de juiste packages gehost op WPackagist.

Voor wat betreft de premium plugins is het een ander verhaal. Een groot aantal plugins heeft net zoals Elementor Pro een Github of ander Git-compatible package wat je, door de juiste licentiecode mee te geven, kan installeren. Als het niet zo is, dan kun je nog steeds de plugin downloaden en deze opnemen in je eigen lokale Git installatie.

Heb je hulp nodig met het inrichten van Git, dan kan dit via de WordXPression support strippenkaart. Heb je sowieso enige andere hulp nodig bij het starten met je Bedrock implementatie, dan is dit ook mogelijk via dezelfde strippenkaart.

Samenvatting

Voor websites met een groot aantal bezoekers en ‘niet standaard’ functionaliteiten, kan het goed zijn om eens te kijken naar alternatieve mogelijkheden om WordPress te gebruiken. Bedrock tezamen met de andere modules binnen het Roots ecosysteem biedt een meer veilige en een meer (technisch) moderne oplossing voor het ‘werken met WordPress’.

Gezien de geschiedenis van Bedrock -in 2025 al 9 jaar in de race- mag verwacht worden, dat met betrekking tot de continuïteit niets gevreesd hoeft te worden.

Wil je starten met een grote WordPress toepassing?

WordPress is historisch het ‘goto’ platform wanneer je wilt starten met welk groter systeem dan ook. Door technische ontwikkelingen echter, kan voor sommige toepassingen ‘decoupling’, het loskoppelen van functionaliteiten, een oplossing zijn die vandaag de dag voor jou en jouw situatie van toepassing zou zijn.

Met WordXPression kan ik je helpen de juiste oplossing te kiezen voor jouw gewenste online ondersteuning voor de producten en diensten van jouw bedrijf. Hierbij wordt rekening gehouden met je huidige budget, jouw toekomstverwachtingen en de groeimogelijkheden van je dienstverlening.

Wil je een keer brainstormen over de mogelijkheden van jouw plannen, neem dan eens contact met mij op en in een telefonische of video conversatie van maximaal een uur leer ik graag jou en jouw wensen met je bedrijf kennen.

Dit blogartikel geeft een antwoord op de volgende vragen:

• Wat is Bedrock en hoe verbetert het de structuur van een WordPress-project?
• Hoe integreert Bedrock elementen van Laravel in WordPress-ontwikkeling?
• Welke voordelen biedt het gebruik van Bedrock voor ontwikkelaars en beheerders?
• Hoe verschilt de directorystructuur van een Bedrock-gebaseerde WordPress-installatie van een standaardinstallatie?
• Welke stappen zijn nodig om een WordPress-site te migreren naar een Bedrock-omgeving?