🧠 Ausgangslage

Ich arbeite häufiger mit WordPress parallel auf:

• lokaler Entwicklungsumgebung
• Server-Instanz

Dabei sind über die Zeit typische Probleme aufgetaucht:

• inkonsistente Dateirechte
• FTP-Abfragen in WordPress
• unsaubere Synchronisation zwischen lokal und live
• Mischungen aus verschiedenen Benutzern und Ownerships

Ich habe kein „perfektes Setup“, aber ein funktionierendes, pragmatisches System entwickelt.

🚀 WP-CLI als zentrales Werkzeug

WP-CLI ist für mich der zentrale Baustein geworden, um WordPress nicht nur über das Dashboard, sondern über die Shell zu steuern.

Typische Befehle:

wp plugin list
wp theme list
wp db export
wp db import
wp search-replace

Damit verschiebt sich WordPress von:

klickbasiertem CMS
zu
skriptbarem System

🧱 Mein Setup (Server & lokal)

Ich arbeite mit einem relativ klar getrennten Setup:

• eigener Linux-User pro Projekt / Domain
• SSH-Zugang direkt auf diesen User
• Passwortloser Login über SSH-Keys
• kein permanentes Arbeiten als root

Login sieht dann z. B. so aus:

ssh fullstackdevelopment

Ich lande direkt im richtigen Kontext und arbeite dort weiter.

🔑 SSH-Key Setup

Ich nutze aktuell einen einzigen Private Key für meine Server.

Das ist für mein Setup ausreichend:

• ein Key lokal gespeichert
• Public Key auf dem Server hinterlegt
• Verbindung über SSH-Config vereinfacht

ssh-copy-id user@server

Für komplexere Umgebungen (z. B. mehrere Kunden) wäre eine Trennung pro Projekt sinnvoller, um Sicherheit und Übersicht zu erhöhen.

🔄 WordPress lokal ↔ live synchronisieren

WordPress ist kein reines Code-Projekt. Es besteht aus:

• PHP-Code (Themes/Plugins)
• Datenbank
• Uploads

Deshalb reicht Git alleine nicht aus.

Mein aktueller Workflow:

1️⃣ Code → Git

• Themes
• eigene Plugins
• Konfiguration

2️⃣ Datenbank → WP-CLI

wp db export
wp db import
wp search-replace "https://live-url" "http://local"

3️⃣ Uploads → rsync

rsync -avz user@server:/wp-content/uploads/ ./wp-content/uploads/

⚠️ Typische Stolperstelle: Dateirechte

Ein wiederkehrendes Problem bei mir war WordPress, das plötzlich nach FTP-Zugangsdaten fragt.

Das ist kein WP-CLI-Problem, sondern fast immer ein Rechte-/Ownership-Thema:

• Dateien gehören unterschiedlichen Usern
• gemischte Schreibrechte
• lokale Umgebung vs. Server-Verhalten unterschiedlich

Plesk löst solche Dinge auf dem Server oft automatisch über:

• PHP-FPM User-Zuordnung
• korrekte Ownership
• definierte Deploy-Umgebung

Lokal muss man das oft selbst sauber halten.

💡 Automatisierung (erste Schritte)

Sobald die Einzelbefehle funktionieren, lassen sie sich leicht kombinieren:

#!/usr/bin/env bash

wp db export live.sql

scp user@server:/path/live.sql .

wp db import live.sql

wp search-replace \
  "https://live-url" \
  "http://local.test"

Das ist für mich der Einstieg in:

• Deploy-Skripte
• Backup-Automatisierung
• lokale Entwicklungs-Workflows

🧠 Fazit

WP-CLI ist für mich weniger ein einzelnes Tool, sondern ein Einstieg in einen strukturierteren WordPress-Workflow.

Die wichtigsten Erkenntnisse:

• WordPress ist kein reines Git-Projekt
• Datenbank + Dateien müssen getrennt gedacht werden
• Rechte und Benutzer spielen eine zentrale Rolle
• WP-CLI macht viele Prozesse erst wirklich automatisierbar

Der eigentliche Mehrwert entsteht nicht durch die Installation, sondern durch die Kombination aus SSH, WP-CLI, Git und einem sauberen Rechtekonzept.