Moderne WordPress-ontwikkeling is allang voorbij het tijdperk van handmatig geknutsel en rommelige deploys. Radicle combineert de ontwikkeltools van Roots en andere WordPress tools, zoals Bedrock, Sage en Acorn, in één starterstack.
Het resultaat? De elegante, productieve workflow van Laravel, maar dan gewoon in WordPress.
En door Radicle op Kinsta te draaien, benut je een hostingomgeving die perfect aansluit op deze moderne stack. Je krijgt SSH-toegang, WP-CLI integratie en de mogelijkheid om je document root te configureren.
Deze gids laat je zien hoe je Radicle instelt op Kinsta en hoe je zonder gedoe je deployment-workflow opzet.
Radicle en zijn componenten
Radicle combineert drie verschillende Roots projecten in een geïntegreerde ontwikkelomgeving:
- Bedrock levert de basis met zijn verbeterde mappenstructuur en op Composer gebaseerd dependency-beheer.
- Sage behandelt thema-ontwikkeling met Tailwind CSS integratie en Vite voor het bouwen van assets.
- Acorn slaat een brug tussen WordPress en Laravel door Blade templates, migraties, routing en meer in je WordPress projecten te brengen.
Dit type ontwikkelomgeving stelt je in staat om direct vanuit de project root te werken, in plaats van binnen de typische themamappen. Je templates staan in resources/views/ in de project root, terwijl de configuratie gebeurt via omgevingsspecifieke bestanden in de bedrock directory.
Composer beheert WordPress core, plugins en aangepaste afhankelijkheden via een enkel composer.json bestand. De stack vereist PHP 8.3 of hoger, samen met specifieke extensies. Je hebt ook Composer nodig voor het beheer van afhankelijkheden en WP-CLI voor opdrachtregelbewerkingen.
Radicle vs. traditionele WordPress
Standaard WordPress installaties (d.w.z. alles in de wp-content directory plaatsen) kan versiebeheer bemoeilijken en het moeilijk maken om consistente installaties te onderhouden in verschillende omgevingen.
Radicle herstructureert dit echter zodat je versiebeheer kunt uitvoeren voor je applicatiecode zonder de WordPress core bestanden of geüploade media te volgen:
- WordPress core staat in de
public/wpmap, gescheiden van je applicatiecode. - De map
public/contentvervangtwp-contenten je custom themacode staat in de project root.
De Laravel-stijl configuratie gebruikt een .env bestand in plaats van databasegegevens en beveiligingssleutels in te sluiten in configuratiebestanden. Je definieert verschillende instellingen voor ontwikkel-, test- en productieomgevingen via aparte configuratiebestanden in bedrock/environments/.
Je versiebeheer-strategie profiteert hiervan omdat je alleen je applicatiecode en configuratie volgt. WordPress core updates vinden plaats via Composer, plugins dienen als dependencies en themawijzigingen worden opgeslagen in je repository.
Radicle configureren voor Kinsta
Bij het deployen naar Kinsta heb je SSH sleutel authenticatie nodig, die beschikbaar is via het MyKinsta dashboard.
Zoek je SFTP/SSH toegangsgegevens op in de sectie Info van de site en voeg je publieke SSH-sleutel toe als je dat nog niet hebt gedaan.
De infrastructuur van Kinsta komt overeen met de technische vereisten van Radicle. Het draait PHP 8.3, bevat Composer voor het beheer van dependencies en heeft WP-CLI voorgeïnstalleerd, zodat je WordPress direct vanaf de opdrachtregel kunt beheren.
In tegenstelling tot een traditionele WordPress installatie, gebruikt Radicle een release-gebaseerde mappenstructuur. Elke deployment creëert een release map met tijdstempel en een current symlink verwijst naar de actieve versie. De web root voor je applicatie moet worden ingesteld op public/current/public.
Configureer vervolgens je omgevingsvariabelen. Kopieer het bestand .env.example in je Radicle project root en hernoem het naar .env. Voeg vervolgens je databasegegevens en omgevingsinstellingen toe:
DB_NAME='your_database_name'
DB_USER='your_database_user'
DB_PASSWORD='your_database_password'
DB_HOST='your_database_host'
WP_ENV='staging'
WP_HOME='https://{kinsta-staging-url}'
WP_SITEURL="${WP_HOME}/wp"
Radicle installeert WordPress core in een /wp submap. Dit houdt de corebestanden gescheiden van je custom applicatiecode en ondersteunt een schonere, versiegestuurde structuur.
Staging-configuratie
Je configuratiemap bevindt zich in de root van je Radicle project, naast de mappen public en resources. Open bedrock/environments/staging.php om instellingen te definiëren die specifiek zijn voor je stagingomgeving. Dit bestand overschrijft waarden van bedrock/application.php wanneer het .env bestand WP_ENV op staging zet.
Stel de URL van je staging site in door de volgende constanten toe te voegen bovenaan staging.php:
<?php
define('WP_HOME', 'https://staging-url');
define('WP_SITEURL', WP_HOME . '/wp');
De staging URL volgt het patroon binnen de sectie Omgevingen van je site bij het selecteren van de staging-omgeving (testomgeving).
Je deploymentpad bepaalt waar bestanden landen op de Kinsta server. Noteer in MyKinsta het pad onder Omgevingsdetails. Dit pad is meestal /www/sitename/public en vertegenwoordigt je deployment-doel. Je deploymentscript synchroniseert hier bestanden en creëert een structuur zoals /www/sitename/public/releases/timestamp voor elke deployment, met /www/sitename/public/current symlinking naar de actieve release.
Het is ook een goed idee om de debug modus in te schakelen voor je testomgeving binnen bedrock/environments/staging.php. Daarnaast kopieer en stel je je database referenties in voor de testomgeving in je lokale .env bestand (dat niet moet worden vastgelegd voor versiebeheer). Je kunt deze ook configureren als omgevingsvariabelen op je deploymentserver. Kinsta genereert unieke referenties voor elke omgeving.
Productie-omgeving configuratie
Zodra je overschakelt naar je live omgeving vanuit het vervolgkeuzemenu in het MyKinsta dashboard, zal het configuratieproces de testomgeving weerspiegelen, maar productiespecifieke waarden en strengere beveiligingsinstellingen gebruiken.
Om dit te doen, open bedrock/environments/production.php in de bedrock directory van je project root en wijzig de productie URL:
<?php
define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', WP_HOME . '/wp');
Je productie foutafhandeling zal verschillen van de testomgeving. Het belangrijkste verschil is dat je debugweergaven uitschakelt terwijl je de foutregistratie behoudt:
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', false); Kopieer daarnaast de productiedatabasegegevens van MyKinsta’s Database toegang sectie terwijl je in je live omgeving bent. Deze referenties verschillen meestal van die van de testomgeving. De paden voor productie-deployment volgen echter hetzelfde patroon als staging, maar verwijzen naar de map van je live-omgeving. Het pad binnen MyKinsta’s Omgevingsdetails zal waarschijnlijk een andere (maar vergelijkbare) URL hebben. Je deploymentscript zal zich richten op dit pad voor productiereleases.
Deployment taken wijzigen
De standaard deployment van Radicle gaat uit van servercontrole die Kinsta niet biedt via managed hosting. Daarom moet je alle deployment taken verwijderen die server services proberen te beheren.
Als je Trellis gebruikt (Radicle’s standaard deployment tool), bewerk dan trellis/roles/deploy/hooks/finalize-after.yml en verwijder de Reload php-fpm taak helemaal. Kinsta beheert PHP-FPM herstart automatisch bij het detecteren van bestandswijzigingen.
Het wissen van de cache gebeurt ook via Kinsta’s API in plaats van via serveropdrachten, dus je moet elke servergebaseerde cacheverwijdering vervangen door een HTTP-verzoek naar Kinsta’s cacheverwijderingseindpunt. Je kunt deze taak toevoegen aan je deployment finalize hook zodra je een API sleutel hebt ingesteld:
- name: Clear Kinsta cache
uri:
url: "{{ site_env.wp_home }}/kinsta-clear-cache-endpoint/"
method: GET
Elke site heeft een uniek endpoint voor beveiliging, die je kunt krijgen van het supportteam van Kinsta.
Assetcompilatie wordt uitgevoerd vóór de deployment, niet op de server. Je lokale ontwikkelmachine of CI/CD pijplijn voert npm run build uit om JavaScript en CSS te compileren in de public/build map. Deze gecompileerde onderdelen worden samen met je PHP-bestanden ingezet.
De installatie van Composer dependencies gebeurt na bestandssynchronisatie met behulp van SSH om het volgende uit te voeren:
cd /www/sitename/public/current
composer install --no-dev --optimize-autoloader --no-interaction
De --no-dev flag sluit ontwikkelingsdepencies uit, zoals testframeworks en debugtools. De vlag --optimize-autoloader bouwt klassenkaarten voor sneller automatisch laden, waardoor de overhead van het lokaliseren van klassenbestanden tijdens aanvragen wordt verminderd.
De Kinsta MU plugin toevoegen aan Radicle
De Kinsta MU plugin maakt full-page caching, CDN-integratie en cachebeheer voor je site mogelijk via MyKinsta. Vanwege de niet-standaard mappenstructuur van Radicle moet je een aantal specifieke configuratieconstanten instellen, hoewel je de Kinsta MU plugin aan Radicle kunt toevoegen via Composer. Je kunt deze constanten toevoegen aan je bedrock/application.php bestand nadat je de plugin hebt geïnstalleerd:
/**
* Kinsta CDN fix for Radicle/Bedrock structure
*/
define('KINSTA_CDN_USERDIRS', 'app');
/**
* Fix Kinsta MU Plugins URL path with Radicle/Bedrock
*/
$mu_plugins_url = Config::get('WP_CONTENT_URL') . '/mu-plugins';
define('KINSTAMU_CUSTOM_MUPLUGIN_URL', "{$mu_plugins_url}/kinsta-mu-plugins");
De eerste constante specificeert je uploads directory in Bedrock’s app structuur. De tweede corrigeert de asset URL paden van de plugin zodat JavaScript en CSS bestanden correct worden geladen.
Zodra je de installatie van de plugin hebt gecontroleerd, kun je het wissen van de cache testen via het MyKinsta dashboard om te bevestigen dat de plugin goed communiceert met de infrastructuur van Kinsta.
Hoe geautomatiseerde deployments in te stellen
GitHub Actions is een eenvoudige manier om Radicle deployments naar Kinsta te automatiseren. Je kunt bijvoorbeeld een workflow bestand aanmaken in je repository op .github/workflows/deploy.yml. Deze workflow triggert op pushes naar specifieke branches, die assets bouwen en code deployen naar de corresponderende omgeving.
SSH secrets opgeslagen in je GitHub repository zullen veilige verbindingen met Kinsta’s servers mogelijk maken. Voeg hiervoor secrets toe voor je SSH privésleutel, Kinsta host, SSH poort en gebruikersnaam binnen GitHub.
Een deploymentscript orkestreert het bestandssynchronisatieproces. Dit script gebruikt meestal rsync om bestanden efficiënt over te zetten, stuurt alleen gewijzigde bestanden en houdt de juiste rechten bij. Je moet echter ontwikkelingsbestanden zoals node_modules, .git, en .env uitsluiten van de deployment om je productieomgeving schoon te houden.
Zodra je een succesvolle bestandssynchronisatie hebt, kunnen de cache-clearing en opschoningstaken worden uitgevoerd. Het proces houdt in dat het deploymentscript een verzoek indient bij Kinsta’s cache clear endpoint, wacht op bevestiging en vervolgens alle noodzakelijke opruimopdrachten uitvoert.
GitHub Acties configuratie
Je kunt je deployment automatisering definiëren in de root van het repository door een .github/workflows/deploy.yml bestand aan te maken. Dit zal het compileren van assets, het installeren van dependencies en het synchroniseren van bestanden naar Kinsta afhandelen.
Begin hier met branch-specifieke triggers die de staging branch uitrollen naar je staging omgeving en main branch naar productie:
name: Deploy to Kinsta
on:
push:
branches:
- staging
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '22'
- name: Install dependencies and build assets
run: |
npm ci
npm run build
Matrixstrategieën verwerken meerdere omgevingen zonder workflowcode te dupliceren. De omgevingsspecifieke variabelen die je toevoegt kunnen veranderen op basis van welke branch de workflow heeft geactiveerd:
strategy:
matrix:
include:
- branch: staging
ssh_host: ${{ secrets.KINSTA_STAGING_HOST }}
ssh_port: ${{ secrets.KINSTA_STAGING_PORT }}
ssh_user: ${{ secrets.KINSTA_STAGING_USER }}
deploy_path: /www/sitename_1/public
- branch: main
ssh_host: ${{ secrets.KINSTA_PRODUCTION_HOST }}
ssh_port: ${{ secrets.KINSTA_PRODUCTION_PORT }}
ssh_user: ${{ secrets.KINSTA_PRODUCTION_USER }}
deploy_path: /www/sitename_2/public
Asset compilatiestappen maken geoptimaliseerde JavaScript- en CSS-bestanden voordat ze worden ingezet. De workflow gebruikt npm ci in plaats van npm install voor reproduceerbare builds op basis van je package-lock.json bestand. Het npm run build commando voert je productie build script uit dat is gedefinieerd in package.json, waarbij meestal Vite of een andere bundler wordt uitgevoerd om assets te compileren en te minen.
Op dit punt kun je de Composer installatie toevoegen na de Node.js stappen:
- name: Setup PHP
uses: server/setup-php@v2
with:
php-version: '8.3'
- name: Install Composer dependencies
run: composer install --no-dev --optimize-autoloader --no-interaction
De workflow heeft nu gecompileerde assets en geïnstalleerde dependencies, klaar voor deployment op Kinsta.
Deployment script details
Bestandssynchronisatie via rsync zet alleen gewijzigde bestanden over, waardoor de deploymenttijd tot een minimum wordt beperkt. Om dit op te lossen, voeg je deze stap toe aan je GitHub Actions workflow na het bouwen van je assets:
- name: Deploy to Kinsta via rsync
env:
SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
run: |
mkdir -p ~/.ssh
echo "$SSH_PRIVATE_KEY" > ~/.ssh/deploy_key
chmod 600 ~/.ssh/deploy_key
rsync -avz --delete
--exclude='.git'
--exclude='node_modules'
--exclude='.env'
--exclude='trellis'
-e "ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no"
./ ${{ matrix.ssh_user }}@${{ matrix.ssh_host }}:${{ matrix.deploy_path }}/releases/$(date +%Y%m%d%H%M%S)/De rsync flags bepalen het gedrag voor de transfer:
-aschakelt archiefmodus in met behoud van permissies en tijdstempels.-vgeeft uitgebreide uitvoer voor debuggen.-zcomprimeert gegevens tijdens de transfer.
De --delete flag verwijdert bestanden van de server die niet meer bestaan in je archief, waardoor je deployment schoon blijft.
Uitsluitingspatronen voorkomen het overzetten van onnodige bestanden. Bovendien blijven Git metadata, ontwikkelingsdependencies, omgevingsbestanden en deploymenttools weg van de productieserver. De mapstructuur van de release maakt mappen met tijdstempels voor elke deployment om snelle rollbacks mogelijk te maken door symlinks te veranderen.
Symlink beheer verbindt je persistente gegevens met elke nieuwe release. Na het synchroniseren van bestanden kun je SSH-en naar de server en symlinks aanmaken:
- name: Create symlinks and update current
run: |
ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no
${{ matrix.ssh_user }}@${{ matrix.ssh_host }} << 'EOF'
cd ${{ matrix.deploy_path }}
# Link shared .env file
ln -nfs ${{ matrix.deploy_path }}/shared/.env
${{ matrix.deploy_path }}/releases/$(ls -t releases | head -1)/.env
# Link uploads directory
ln -nfs ${{ matrix.deploy_path }}/shared/public/content/uploads
${{ matrix.deploy_path }}/releases/$(ls -t releases | head -1)/public/content/uploads
# Update current symlink atomically
ln -nfs ${{ matrix.deploy_path }}/releases/$(ls -t releases | head -1)
${{ matrix.deploy_path }}/current
EOFHet bestand .env bevat omgevingsspecifieke configuraties die bij verschillende deployments blijven bestaan. Uploads die buiten de release map zijn opgeslagen voorkomen het verlies van mediabestanden wanneer oude releases worden verwijderd. De atomic symlink update (ln -nfs) zorgt voor nul downtime, omdat verzoeken nooit een half geïmplementeerde release raken.
Cleanup verwijdert oude releases na een succesvolle deployment om alleen de vijf meest recente te bewaren:
- name: Clean up old releases
run: |
ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no
${{ matrix.ssh_user }}@${{ matrix.ssh_host }} << 'EOF'
cd ${{ matrix.deploy_path }}/releases
ls -t | tail -n +6 | xargs rm -rf
EOFDeze opruimstrategie zorgt voor een balans tussen schijfruimtegebruik en terugdraaimogelijkheden. Vijf releases bieden meerdere terugdraaipunten terwijl oneindige opslaggroei wordt voorkomen.
Samenvatting
Radicle transformeert WordPress ontwikkeling door de verbeterde structuur van Bedrock, de moderne themaworkflow van Sage en de Laravel functies van Acorn te integreren in één stack.
Het deployen op Kinsta vereist een configuratie die verder gaat dan standaard WordPress hosting, maar levert voordelen op in beveiliging, onderhoudbaarheid en ontwikkelaarservaring die de installatie-inspanning rechtvaardigen.
Als je klaar bent om met vertrouwen moderne WordPress applicaties te deployen, ontdek dan Kinsta’s managed WordPress hosting en ervaar een hosting-infrastructuur die de door jou gewenste aangepaste ontwikkelworkflow ondersteunt.
