.avif)
WP-CLI-Befehlsgenerator für WordPress
Wählen Sie ein Szenario, füllen Sie die Felder aus — und Sie erhalten einen fertigen Befehlsblock in der richtigen Reihenfolge, mit Backup und Probelauf. Jedes Flag wird erklärt. Die Befehle entstehen in Ihrem Browser.
--path= hinzu. Leer lassen, um aus dem Site-Wurzelverzeichnis auszuführen.
--url= hinzu — für eine Multisite-Unterseite zwingend.
wp-config.php: $table_prefix.
--all belastet die Site vorübergehend mit dem Neuaufbau.
wp-content/themes/.
* angeben — die Shell löst es auf.
wp am Anfang: es und --url= werden automatisch ergänzt.
Wählen Sie ein Szenario und füllen Sie die Felder aus — die Befehle mit Erläuterungen erscheinen hier.
Die Befehle entstehen in Ihrem Browser — Domains, Logins und Passwörter werden nirgendwohin gesendet und nirgends gespeichert.
Die Reihenfolge der Befehle ist wichtiger als die Befehle selbst
WP-CLI fragt nicht nach und kennt kein Rückgängig. Deshalb ist jedes Szenario hier nach demselben Schema aufgebaut: zuerst das Backup, dann der Probelauf und erst danach der scharfe Befehl. wp db export — dauert Sekunden und rettet eine Stunde Arbeit. --dry-run in search-replace zeigt, wie viele Zeilen sich ändern würden, ohne etwas zu ändern. Diesen Schritt zu überspringen ist der teuerste Fehler im Umgang mit WP-CLI. --skip-columns=guid ist standardmäßig gesetzt: Die guid ist in WordPress ein unveränderlicher Bezeichner des Beitrags und keine Adresse. Ihre Änderung lässt RSS-Reader das gesamte Archiv als neue Veröffentlichungen anzeigen. --precise deaktiviert den schnellen Weg und zwingt WP-CLI, serialisierte Werte zu entpacken. Langsamer, aber genau das rettet Widgets und Theme-Einstellungen. --all-tables-with-prefix erfasst Plugin-Tabellen mit Ihrem Präfix, die die Standardersetzung nicht anfasst. Nach jeder Massenersetzung sind wp cache flush und wp rewrite flush nötig — sonst liefert die Site weiterhin die alten Werte aus dem Cache.
