Die moderne WordPress-Entwicklung hat sich über manuelle Einstellungen und inkonsistente Bereitstellungs-Workflows hinaus entwickelt. Radicle kombiniert Roots und andere WordPress-Entwicklungstools wie Bedrock, Sage und Acorn in einem einzigen Starter-Stack.
Diese Integration bedeutet, dass du die Entwicklungserfahrung von Laravel direkt in WordPress nutzen kannst.
Außerdem bekommst du mit Radicle auf Kinsta eine Hosting-Umgebung, die die technischen Anforderungen dieses Stacks erfüllt. Du erhältst SSH-Zugang, WP-CLI-Integration und die Möglichkeit, deinen Document Root zu konfigurieren.
Dieser Leitfaden beschreibt den Konfigurationsprozess und die Einrichtungsschritte, die erforderlich sind, um Radicle in der Kinsta-Infrastruktur zum Laufen zu bringen.
Radicle und seine Komponenten
Radicle vereint drei verschiedene Roots-Projekte in einer integrierten Entwicklungsumgebung:
- Bedrock bildet die Grundlage mit seiner verbesserten Ordnerstruktur und dem Composer-basierten Abhängigkeitsmanagement.
- Sage übernimmt die Theme-Entwicklung mit der Tailwind CSS-Integration und Vite für die Asset-Erstellung.
- Acorn schlägt die Brücke zwischen WordPress und Laravel, indem es Blade-Vorlagen, Migrationen, Routing und vieles mehr in deine WordPress-Projekte einbringt.
Diese Art von Entwicklungsumgebung ermöglicht es dir, direkt im Stammverzeichnis deines Projekts zu arbeiten und nicht in den typischen Theme-Verzeichnissen. Deine Vorlagen befinden sich in resources/views/ im Stammverzeichnis des Projekts, während die Konfiguration über umgebungsspezifische Dateien im Verzeichnis bedrock erfolgt.
Der Composer verwaltet den WordPress-Kern, die Plugins und die benutzerdefinierten Abhängigkeiten über eine einzige composer.json Datei. Der Stack erfordert PHP 8.3 oder höher sowie bestimmte Erweiterungen. Außerdem brauchst du Composer für das Abhängigkeitsmanagement und WP-CLI für die Befehlszeilenoperationen.
Radicle vs. herkömmliches WordPress
Herkömmliche WordPress-Installationen (d.h. alles im Verzeichnis wp-content) können die Versionskontrolle erschweren und es schwierig machen, konsistente Installationen in verschiedenen Umgebungen zu erhalten.
Radicle hingegen strukturiert dies so um, dass du deinen Anwendungscode versionskontrollieren kannst, ohne WordPress-Kerndateien oder hochgeladene Medien zu verfolgen:
- Der WordPress-Kern befindet sich im Verzeichnis
public/wp, getrennt von deinem Anwendungscode. - Das Verzeichnis
public/contentersetztwp-content, und der Code deines benutzerdefinierten Themes befindet sich im Stammverzeichnis des Projekts.
Bei der Konfiguration im Laravel-Stil wird eine .env Datei verwendet, anstatt Datenbankanmeldeinformationen und Sicherheitsschlüssel in Konfigurationsdateien einzubetten. Du definierst unterschiedliche Einstellungen für Entwicklungs-, Staging- und Produktionsumgebungen über separate Konfigurationsdateien in bedrock/environments/.
Deine Versionskontrollstrategie profitiert davon, dass du nur deinen Anwendungscode und deine Konfiguration verfolgst. Aktualisierungen des WordPress-Kerns erfolgen über Composer, Plugins dienen als Abhängigkeiten, und Theme-Änderungen werden in deinem Repository gespeichert.
Konfigurieren von Radicle für Kinsta
Für die Bereitstellung auf Kinsta benötigst du eine SSH-Schlüsselauthentifizierung, die über das MyKinsta-Dashboard verfügbar ist.
Finde deine SFTP/SSH-Zugangsdaten im Abschnitt Info der Website und füge deinen öffentlichen SSH-Schlüssel hinzu, falls du das nicht schon getan hast.
Die Infrastruktur von Kinsta entspricht den technischen Anforderungen von Radicle. Es läuft mit PHP 8.3, enthält Composer für das Abhängigkeitsmanagement und hat WP-CLI vorinstalliert, sodass du WordPress direkt von der Kommandozeile aus verwalten kannst.
Im Gegensatz zu einer herkömmlichen WordPress-Installation verwendet Radicle eine releasebasierte Verzeichnisstruktur. Bei jedem Einsatz wird ein Ordner mit einem Zeitstempel erstellt, und ein Symlink current verweist auf die aktive Version. Das Web-Root für deine Anwendung sollte auf public/current/public gesetzt werden.
Als Nächstes musst du deine Umgebungsvariablen konfigurieren. Kopiere die Datei .env.example in das Stammverzeichnis deines Radicle-Projekts und benenne sie in .env um. Füge dann deine Datenbankdetails und Umgebungseinstellungen hinzu:
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 installiert den WordPress-Kern in einem Unterverzeichnis /wp. Auf diese Weise bleiben die Kerndateien von deinem benutzerdefinierten Anwendungscode getrennt, was eine saubere, versionskontrollierte Struktur ermöglicht.
Staging-Konfiguration
Dein Konfigurationsverzeichnis befindet sich im Stammverzeichnis deines Radicle-Projekts, neben den Ordnern public und resources. Öffne bedrock/environments/staging.php, um die Einstellungen für deine Staging-Umgebung festzulegen. Diese Datei setzt die Werte von bedrock/application.php außer Kraft, wenn die Datei .env WP_ENV auf staging setzt.
Lege die URL deiner Staging-Site fest, indem du die folgenden Konstanten am Anfang von staging.php hinzufügst:
<?php
define('WP_HOME', 'https://staging-url');
define('WP_SITEURL', WP_HOME . '/wp');
Die Staging-URL folgt dem Muster im Abschnitt Umgebungen deiner Website, wenn du die Staging-Umgebung auswählst.
Dein Bereitstellungspfad bestimmt, wo die Dateien auf dem Kinsta-Server landen. In MyKinsta findest du den Pfad unter Umgebungsdetails. Dieser Pfad lautet in der Regel /www/sitename/public und stellt dein Bereitstellungsziel dar. Dein Bereitstellungs-Skript synchronisiert die Dateien hier und erstellt für jede Bereitstellung eine Struktur wie /www/sitename/public/releases/timestamp, wobei /www/sitename/public/current mit der aktiven Version verlinkt wird.
Es ist außerdem ratsam, den Debug-Modus für deine Staging-Umgebung in bedrock/environments/staging.php zu aktivieren. Kopiere außerdem deine Datenbankanmeldedaten für die Staging-Umgebung in deine lokale Datei .env (die nicht in die Versionskontrolle übertragen werden sollte). Alternativ kannst du sie auch als Umgebungsvariablen auf deinem Deployment-Server konfigurieren. Kinsta generiert eindeutige Zugangsdaten für jede Umgebung.
Produktionskonfiguration
Sobald du über das Dropdown-Menü im MyKinsta-Dashboard zu deiner Live-Umgebung wechselst, wird der Konfigurationsprozess der Staging-Umgebung entsprechen, jedoch mit produktionsspezifischen Werten und strengeren Sicherheitseinstellungen.
Dazu öffnest du bedrock/environments/production.php im bedrock Verzeichnis deines Projektstamms und änderst die Produktions-URL:
<?php
define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', WP_HOME . '/wp');
Die Fehlerbehandlung in der Produktion wird sich von der in der Staging-Umgebung unterscheiden. Der Hauptunterschied besteht darin, dass du die Debug-Anzeigen deaktivierst und die Fehlerprotokollierung beibehältst:
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', false); Kopiere außerdem die Anmeldedaten für die Produktionsdatenbank aus dem Bereich Datenbankzugriff in MyKinsta, wenn du dich in deiner Live-Umgebung befindest. Diese Zugangsdaten unterscheiden sich in der Regel von denen für die Produktionsumgebung. Die Pfade für die Bereitstellung in der Produktionsumgebung folgen jedoch demselben Muster wie die Pfade in der Staging-Umgebung, verweisen aber auf das Verzeichnis deiner Live-Umgebung. Der Pfad in den Umgebungsdetails von MyKinsta wird wahrscheinlich eine andere (aber ähnliche) URL haben. Dein Deployment-Skript wird für Produktionsversionen auf diesen Pfad verweisen.
Ändern der Bereitstellungsaufgaben
Die Standard-Bereitstellung von Radicle geht von einer Serverkontrolle aus, die Kinsta über das Managed Hosting nicht bietet. Daher musst du alle Deployment-Aufgaben entfernen, die versuchen, Serverdienste zu verwalten.
Wenn du Trellis (das Standard-Deployment-Tool von Radicle) verwendest, bearbeite trellis/roles/deploy/hooks/finalize-after.yml und lösche die Aufgabe Reload php-fpm vollständig. Kinsta verwaltet PHP-FPM, das automatisch neu startet, wenn Datei-Änderungen erkannt werden.
Außerdem wird der Cache über die Kinsta-API und nicht über Serverbefehle geleert. Deshalb solltest du jede serverbasierte Cache-Löschung durch eine HTTP-Anfrage an den Cache-Clear-Endpunkt von Kinsta ersetzen. Du kannst diese Aufgabe zu deinem Deployment Finalize Hook hinzufügen, sobald du einen API-Schlüssel eingerichtet hast:
- name: Clear Kinsta cache
uri:
url: "{{ site_env.wp_home }}/kinsta-clear-cache-endpoint/"
method: GET
Jede Website hat aus Sicherheitsgründen einen eigenen Endpunkt, den du vom Kinsta-Support-Team erhältst.
Die Asset-Kompilierung erfolgt vor der Bereitstellung, nicht auf dem Server. Dein lokaler Entwicklungsrechner oder deine CI/CD-Pipeline führt npm run build aus, um JavaScript und CSS in das Verzeichnis public/build zu kompilieren. Diese kompilierten Assets werden zusammen mit deinen PHP-Dateien bereitgestellt.
Die Installation der Composer-Abhängigkeiten erfolgt nach der Dateisynchronisierung über SSH, um Folgendes auszuführen:
cd /www/sitename/public/current
composer install --no-dev --optimize-autoloader --no-interaction
Das --no-dev Flag schließt Entwicklungsabhängigkeiten wie Test-Frameworks und Debugging-Tools aus. Das --optimize-autoloader Flag erstellt Class Maps für schnelleres Autoloading und reduziert den Overhead beim Auffinden von Klassendateien bei Anfragen.
Hinzufügen des Kinsta MU-Plugins zu Radicle
Das Kinsta MU-Plugin ermöglicht Full-Page-Caching, CDN-Integration und Cache-Management für deine Website über MyKinsta. Aufgrund der nicht standardmäßigen Verzeichnisstruktur von Radicle musst du einige spezielle Konfigurationskonstanten festlegen, obwohl du das Kinsta MU-Plugin über den Composer zu Radicle hinzufügen kannst. Du kannst diese Konstanten nach der Installation des Plugins zu deiner bedrock/application.php Datei hinzufügen:
/**
* 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");
Die erste Konstante gibt dein Uploads-Verzeichnis in der app Struktur von Bedrock an. Die zweite Konstante korrigiert die Asset-URL-Pfade des Plugins, damit es JavaScript- und CSS-Dateien korrekt lädt.
Sobald du die Installation des Plugins überprüft hast, kannst du über das MyKinsta-Dashboard testen, ob das Plugin richtig mit der Kinsta-Infrastruktur kommuniziert.
So richtest du automatische Bereitstellungen ein
GitHub Actions ist eine einfache Möglichkeit, die Bereitstellung von Radicle auf Kinsta zu automatisieren. Du könntest zum Beispiel eine Workflow-Datei in deinem Repository unter .github/workflows/deploy.yml erstellen. Dieser Workflow wird bei Pushs zu bestimmten Zweigen ausgelöst, die Assets bauen und den Code in der entsprechenden Umgebung bereitstellen.
SSH-Geheimnisse, die in deinem GitHub-Repository gespeichert sind, ermöglichen sichere Verbindungen zu den Servern von Kinsta. Dazu fügst du in GitHub Geheimnisse für deinen privaten SSH-Schlüssel, den Kinsta-Host, den SSH-Port und den Benutzernamen hinzu.
Ein Bereitstellungsskript steuert den Prozess der Dateisynchronisation. Dieses Skript verwendet in der Regel rsync, um Dateien effizient zu übertragen, sendet nur geänderte Dateien und sorgt für die richtigen Berechtigungen. Du solltest jedoch Entwicklungsdateien wie node_modules, .git und .env von der Bereitstellung ausschließen, um deine Produktionsumgebung sauber zu halten.
Sobald der Dateiaustausch erfolgreich war, können die Aufgaben zum Löschen des Caches und zum Aufräumen ausgeführt werden. Dabei stellt das Deployment-Skript eine Anfrage an den Cache-Clear-Endpunkt von Kinsta, wartet auf die Bestätigung und führt dann alle notwendigen Aufräumarbeiten aus.
Konfiguration der GitHub-Aktionen
Du kannst deine Einsatzautomatisierung im Stammverzeichnis des Repositorys definieren, indem du eine .github/workflows/deploy.yml Datei erstellst. Diese übernimmt die Kompilierung der Assets, die Installation der Abhängigkeiten und die Synchronisierung der Dateien mit Kinsta.
Beginne hier mit zweigspezifischen Triggern, die den Staging-Zweig in deiner Staging-Umgebung und den main Zweig in der Produktion bereitstellen:
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
Matrix-Strategien handhaben mehrere Umgebungen, ohne den Workflow-Code zu duplizieren. Die umgebungsspezifischen Variablen, die du hinzufügst, können sich ändern, je nachdem, welcher Zweig den Workflow ausgelöst hat:
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
Die Asset-Kompilierungsschritte erstellen optimierte JavaScript- und CSS-Dateien vor der Bereitstellung. Der Workflow verwendet npm ci anstelle von npm install für reproduzierbare Builds, die auf deiner Datei package-lock.json basieren. Der Befehl npm run build führt dein Produktions-Build-Skript aus, das in package.json definiert ist, und lässt in der Regel Vite oder einen anderen Bundler laufen, um Assets zu kompilieren und zu minifizieren.
An diesem Punkt kannst du die Composer-Installation nach den Node.js-Schritten hinzufügen:
- 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
Der Workflow verfügt nun über kompilierte Assets und installierte Abhängigkeiten, die für die Bereitstellung auf Kinsta bereit sind.
Details zum Bereitstellungsskript
Bei der Dateisynchronisierung über rsync werden nur geänderte Dateien übertragen, was die Bereitstellungszeit minimiert. Füge diesen Schritt zu deinem GitHub Actions-Workflow hinzu, nachdem du deine Assets erstellt hast, um dies zu vermeiden:
- 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)/Die rsync-Flags steuern das Übertragungsverhalten:
-aaktiviert den Archivierungsmodus, wobei Berechtigungen und Zeitstempel erhalten bleiben.-vliefert ausführliche Ausgaben zur Fehlersuche.-zkomprimiert die Daten während der Übertragung.
Das --delete Flag entfernt Dateien vom Server, die nicht mehr in deinem Repository vorhanden sind, wodurch dein Einsatz sauber bleibt.
Ausschlussmuster verhindern, dass unnötige Dateien übertragen werden. Darüber hinaus werden Git-Metadaten, Entwicklungsabhängigkeiten, Umgebungsdateien und Verteilungswerkzeuge nicht auf den Produktionsserver übertragen. Die Release-Verzeichnisstruktur erstellt zeitgestempelte Verzeichnisse für jede Bereitstellung, um schnelle Rollbacks durch die Änderung von Symlinks zu ermöglichen.
Die Symlink-Verwaltung verbindet deine persistenten Daten mit jeder neuen Version. Nach der Synchronisierung der Dateien kannst du dich per SSH in den Server einloggen und Symlinks erstellen:
- 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
EOFDie Datei .env enthält die umgebungsspezifische Konfiguration, die über alle Einsätze hinweg bestehen bleibt. Uploads, die außerhalb des Release-Verzeichnisses gespeichert werden, verhindern den Verlust von Mediendateien, wenn alte Releases gelöscht werden. Die atomare Symlink-Aktualisierung (ln -nfs) sorgt dafür, dass es keine Ausfallzeiten gibt, da die Anfragen nie auf eine halb ausgelieferte Version treffen.
Die Bereinigung entfernt alte Versionen nach erfolgreicher Bereitstellung, so dass nur die fünf neuesten Versionen erhalten bleiben:
- 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
EOFMit dieser Bereinigungsstrategie wird ein Gleichgewicht zwischen Speicherplatznutzung und Rollback-Fähigkeit hergestellt. Fünf Versionen bieten mehrere Rollback-Punkte und verhindern gleichzeitig ein unendliches Speicherwachstum.
Zusammenfassung
Radicle verändert die WordPress-Entwicklung, indem es die verbesserte Struktur von Bedrock, den modernen Theme-Workflow von Sage und die Laravel-Funktionen von Acorn in einem Stack integriert.
Die Bereitstellung auf Kinsta erfordert eine Konfiguration, die über das Standard-WordPress-Hosting hinausgeht, bietet aber Vorteile in Bezug auf Sicherheit, Wartbarkeit und Entwicklererfahrung, die den Aufwand für die Einrichtung rechtfertigen.
Wenn du bereit bist, moderne WordPress-Anwendungen mit Zuversicht einzusetzen, solltest du das verwaltete WordPress-Hosting von Kinsta kennenlernen und eine Hosting-Infrastruktur erleben, die deinen gewünschten individuellen Entwicklungs-Workflow unterstützt.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
