WordPress mit Bedrock auf Uberspace installieren

WordPress mit Bedrock installierst du auf Uberspace über Composer. Die Datenbankverbindung und die Website-URL stehen in einer .env-Datei; öffentlich erreichbar ist ausschließlich der Unterordner web. Plugins und WordPress-Versionen verwaltest du anschließend als Abhängigkeiten im Projekt.

Dieser Artikel erschien ursprünglich 2017. Am 5. September 2026 habe ich die Anleitung anhand der aktuellen Dokumentation von Uberspace und Roots überarbeitet. Die früheren Befehle für PHP 7.1, Composer 1 und die separate MariaDB-Einrichtung sind ersetzt. Die Anleitung gilt für eine Neuinstallation auf Uberspace 7, nicht für die Migration einer bestehenden Website. Sie ist mit den verlinkten Primärquellen abgeglichen; ein neuer vollständiger Installationstest auf einem Uberspace-Account steht noch aus.

Wann lohnt sich WordPress mit Bedrock?

Bedrock von Roots ist eine Projektvorlage für WordPress. Sie trennt öffentlich ausgelieferte Dateien von Konfiguration und Abhängigkeiten und macht Composer und Git zum Teil des Betriebs.

Das lohnt sich, wenn du Änderungen vor dem Ausrollen testen, Plugin-Versionen nachvollziehen und denselben Softwarestand auf mehreren Umgebungen installieren möchtest. Für einen Blog, dessen Erweiterungen ausschließlich im WordPress-Backend gepflegt werden sollen, ist die normale WordPress-Installation bei Uberspace oft der passendere Einstieg.

Bedrock nimmt dir die Wartung nicht ab. Jemand muss Updates prüfen, Backups überwachen und Deployments durchführen. Warum klare Zuständigkeiten dabei wichtiger sind als zusätzliche Werkzeuge, beschreibe ich in Softwarearchitektur in der Praxis.

1. PHP, Composer und Domain prüfen

Du brauchst SSH-Zugang, eine eingerichtete Domain mit HTTPS und eine freie Datenbank für diese Installation. Vor Änderungen an einem bestehenden Account sichere dessen Dateien und Datenbanken. Ein PHP-Wechsel betrifft auch andere PHP-Anwendungen desselben Accounts.

Die aktuelle Bedrock-Installationsdokumentation verlangt PHP ab 8.3. Das ältere PHP-8.2-Beispiel im UberLab-Guide reicht dafür nicht mehr aus. Prüfe die auf deinem Host angebotenen Versionen:

uberspace tools version list php
uberspace tools version show php
php --version
composer --version
uberspace web domain list

Wähle eine unterstützte PHP-Version, mit der auch deine Plugins und Themes kompatibel sind. PHP 8.4 ist ein Beispiel aus dem Uberspace-PHP-Handbuch:

uberspace tools version use php 8.4
php --version

Composer ist auf Uberspace bereits vorinstalliert. Ein heruntergeladenes Installer-Skript oder eine eigene Composer-1-Installation ist nicht nötig. Richte deine Domain und HTTPS vor dem WordPress-Assistenten nach der Uberspace-Dokumentation ein.

2. Eine eigene Datenbank anlegen

Der Uberspace-Guide für Bedrock empfiehlt eine separate Datenbank. Der folgende Befehl legt sie mit deinem Accountnamen als Präfix an:

mysql -e "CREATE DATABASE ${USER}_wp"

Existiert dieser Name bereits, verwende einen anderen Namen mit deinem Accountpräfix. Lösche keine vorhandene Datenbank, um die Anleitung fortzusetzen.

Deine MySQL-Zugangsdaten findest du gemäß Uberspace mit my_print_defaults client. Dieser Befehl zeigt das Passwort im Terminal an. Führe ihn nur in einer privaten Sitzung aus und kopiere die Ausgabe nicht in Tickets, Chatprotokolle oder Screenshots. Die Werte brauchst du gleich für die .env-Datei.

3. Bedrock mit Composer installieren

Wechsle in das Verzeichnis oberhalb des öffentlichen Webroots. Das Zielverzeichnis bedrock darf noch keine vorhandene Installation enthalten:

cd "/var/www/virtual/$USER/"
composer create-project roots/bedrock bedrock
cd bedrock
composer check-platform-reqs

Composer installiert die Abhängigkeiten einschließlich WordPress. Bei einer Fehlermeldung zu PHP oder Erweiterungen behebst du die genannte Voraussetzung. --ignore-platform-reqs würde das Problem nur bis zum Aufruf der Website verschieben.

Die wichtigsten Pfade sind:

composer.json: gewünschte Pakete und Versionsanforderungen.
composer.lock: konkret aufgelöste Versionen für reproduzierbare Installationen.
.env: Zugangsdaten und umgebungsspezifische Einstellungen.
web/wp: der von Composer verwaltete WordPress-Core.
web/app: unter anderem Themes, Plugins und Uploads.
web: der einzige Ordner, auf den der öffentliche Webroot zeigen soll.

4. Bedrock über die .env konfigurieren

Wenn Composer bereits eine .env angelegt hat, bearbeite diese. Andernfalls kopiere .env.example nach .env. Überschreibe keine bestehenden Zugangsdaten.

nano .env

Trage die Datenbankwerte und deine vollständige HTTPS-Adresse ein. Das Beispiel zeigt nur die relevanten Einstellungen; ersetze die Platzhalter und behalte die übrigen benötigten Einträge aus der Vorlage:

DB_NAME='DEINACCOUNT_wp'
DB_USER='DEINACCOUNT'
DB_PASSWORD='DEIN_DATENBANKPASSWORT'
DB_HOST='localhost'

WP_ENV='production'
WP_HOME='https://example.com'
WP_SITEURL="${WP_HOME}/wp"

WP_HOME ist die öffentliche Website-Adresse ohne abschließenden Schrägstrich. WP_SITEURL enthält zusätzlich /wp, weil dort der WordPress-Core liegt. Beachte bei Passwörtern mit Sonderzeichen die Syntax der .env-Datei; sie wird nicht als Shell-Skript ausgeführt.

Ersetze außerdem alle acht Schlüssel und Salts (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY sowie die entsprechenden _SALT-Einträge) durch individuelle Zufallswerte. Roots verlinkt dafür in seiner Installationsdokumentation einen Generator. Lass keine generateme-Platzhalter stehen.

Die .env gehört weder ins Git-Repository noch in den öffentlichen Webroot. Prüfe vor dem ersten Commit, dass sie ignoriert wird. Zugangsdaten und Backups gehören auch nicht in web.

Warum WP_ENV für SEO wichtig ist

Für eine öffentliche Produktionsseite setzt du WP_ENV='production'. Laut Roots-Dokumentation zum Deployment verhindert Bedrocks „Disallow Indexing“-Plugin die Indexierung, wenn die Umgebung nicht auf production steht.

Für eine Testumgebung sind staging beziehungsweise development sinnvoll. Eine Indexierungssperre schützt allerdings keine vertraulichen Inhalte vor Zugriffen; dafür braucht die Testumgebung eine Zugriffsbeschränkung.

5. Den Webroot auf web zeigen lassen

Dieser Schritt gilt nur für den noch unbenutzten Standard-Webroot einer Neuinstallation. Bei einer bestehenden Website oder einer gesonderten Domain-Zuordnung brauchst du einen geplanten Umzug mit Backup und Rückweg. Führe die Befehle dort nicht unverändert aus.

Prüfe zuerst das vorhandene Ziel:

ls -ld "/var/www/virtual/$USER/html"
ls -la "/var/www/virtual/$USER/html/"

Ist html ein normales, leeres Verzeichnis, kannst du es durch den Symlink ersetzen. Liegt darin ausschließlich die Uberspace-Startseite nocontent.html, entferne diese Datei erst nach Prüfung. Bei weiteren Dateien oder einem vorhandenen Symlink stoppe hier.

rmdir "/var/www/virtual/$USER/html" &&
  ln -s "/var/www/virtual/$USER/bedrock/web" "/var/www/virtual/$USER/html"

rmdir bricht bei einem nicht leeren Verzeichnis ab; durch && wird dann auch kein Symlink angelegt. Verwende kein rekursives Löschen, um diesen Schutz zu umgehen. Scheitert nach erfolgreichem rmdir das Anlegen des Links, kannst du das zuvor leere Verzeichnis mit mkdir wiederherstellen und die Ursache prüfen.

Öffne anschließend https://example.com/wp/wp-admin/ mit deiner tatsächlichen Domain und schließe den WordPress-Assistenten ab. Die Website liegt unter https://example.com/, das Backend unter /wp/wp-admin/.

6. Plugins und Themes mit Composer verwalten

Neue Bedrock-Projekte unterscheiden sich von älteren Anleitungen: Die aktuelle Roots-Dokumentation zu Composer nutzt WP Packages mit den Präfixen wp-plugin und wp-theme. Der UberLab-Guide zeigt noch WPackagist mit wpackagist-plugin und wpackagist-theme.

Prüfe bei einer bestehenden Installation die Repository-Konfiguration in composer.json. Tausche Präfixe nicht blind aus und installiere dasselbe Plugin nicht unter beiden Paketnamen. Für ein neues Projekt nach aktueller Roots-Vorlage ist beispielsweise dieser Befehl dokumentiert:

composer require wp-plugin/akismet

Das ist ein Paketbeispiel, keine Empfehlung, Akismet auf jeder Website einzusetzen. Prüfe vor der Nutzung Funktion, Lizenz und gegebenenfalls die Übertragung personenbezogener Daten. Nach der Installation aktivierst und konfigurierst du das gewünschte Plugin in WordPress.

Dass sich Code und Plugins in der Produktionsumgebung nicht wie gewohnt über das Backend ändern lassen, gehört zum vorgesehenen Workflow. Eigenen Theme-Code kannst du im Projekt versionieren; von Composer verwaltete Fremdpakete bearbeitest du nicht direkt.

7. Updates testen und reproduzierbar ausrollen

Führe Updates zuerst lokal oder in einer abgesicherten Testumgebung aus. Verschaffe dir einen Überblick:

composer outdated
composer audit

Für ein WordPress-Update dokumentiert Roots unter anderem:

composer require roots/wordpress -W

Dabei können sich auch abhängige Pakete ändern. Prüfe die Änderungen in composer.json und composer.lock und teste mindestens Anmeldung, Beiträge, Medien-Uploads, Permalinks, Formulare und wichtige Plugin-Funktionen. Ein sauberer composer audit ersetzt diese Funktionsprüfung nicht.

Versioniere den geprüften Softwarestand einschließlich composer.lock. Beim Deployment installierst du die festgelegten Versionen:

composer install --no-dev --optimize-autoloader
composer check-platform-reqs --no-dev

Ein ungezieltes composer update auf dem Produktionsserver würde dagegen neue Versionen auflösen. Halte vorher ein wiederherstellbares Backup von Datenbank, Uploads und Konfiguration bereit. Ein Git-Rollback allein macht Datenbankänderungen eines Plugins nicht rückgängig; plane auch die Wiederherstellung der zugehörigen Daten ein.

Vor dem Freischalten prüfen

Startseite, ein Beitrag, eine Mediendatei und /wp/wp-admin/ funktionieren über HTTPS.
Permalinks funktionieren beim direkten Aufruf einer Unterseite.
Der Webroot zeigt auf web, nicht auf das gesamte Projekt. Anfragen nach /.env oder /composer.json dürfen keine Dateiinhalte liefern.
Die öffentliche Seite nutzt WP_ENV='production'; auch die WordPress-Einstellung zur Suchmaschinen-Sichtbarkeit und die ausgelieferten Robots-Angaben erlauben die beabsichtigte Indexierung.
Backup und Wiederherstellung sind geprüft, und die Zuständigkeit für Sicherheitsupdates ist geklärt.

Bei Datenbankfehlern prüfe Datenbankname, Zugangsdaten und Host in .env. Bei Weiterleitungen auf eine falsche Adresse sind WP_HOME, WP_SITEURL und HTTPS die nächsten Prüfpunkte. Bei PHP-Fehlern helfen die ausgewählte Version und composer check-platform-reqs.

Danach kannst du die Meta Description in WordPress sauber pflegen. Wenn du die Nutzung der Seite messen möchtest, erklärt mein Vergleich von Webanalyse-Tools, welche Betriebs- und Datenschutzfragen vor der Toolwahl stehen.

Quellen und Geltungsbereich

Abgeglichen am 5. September 2026 mit dem Uberspace-Bedrock-Guide, dem Uberspace-PHP-Handbuch sowie den Roots-Dokumentationen zu Installation, Composer und Deployment. Die Versions- und Paketbeispiele dieser Quellen sind nicht überall synchron; bei Bedrock-Anforderungen und Paketpräfixen folgt dieser Artikel der aktuellen Roots-Dokumentation. Eine bestehende Installation aus der Zeit der ursprünglichen Veröffentlichung braucht eine gesonderte Migrationsplanung.