Türkei (Türkisch)
Germany (German)
Worldwide (English)
QuellwebsiteWordPress Gesundheit und WP-CLI
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
WP Toolkit kombiniert Klonung und Smart Update-Operationen zu Datei-Kopien, einen temporären Datenbankbenutzer, Such- und Ersetzungsoperationen, einen WordPress-Health-Check, und Bildschirmaufnahmetests. Es kann aufgrund von Festplattenspeicherplatz, WP-CLI-Zeitüberschreitung, Malware, Trigger-DEFINER oder Ziel-Kollisionen angehalten werden.
WP-CLI command has not finished working in 60 seconds
WP Toolkit was not able to finish an operation in 1800 seconds
Unable to import database
The user specified as a definer does not exist
WordPress instance is brokenKlonierung ist nicht nur Dateikopie. WP Toolkit erstellt das Ziel-Domain- und Datenbankobjekt, überträgt die Quelldaten, ändert die URLs und bestätigt, dass WordPress funktioniert. Smart Update testet auch die Aktualisierung auf dem vorübigen Klon.
60-Sekunden-WP-CLI-Timeout zeigt an, dass der Befehl nicht innerhalb der erwarteten Zeit abgeschlossen wurde. Malware, korrupte wp-config.php, schwere Plugins oder externe Verbindungswartezeit können die Ursache sein.
Das allgemeine Timeout von 1800 Sekunden kann aufgrund eines großen Medienindex, langsamer Festplatte, Ressourcenlimit oder hängender Datenbankimport auftreten.
Fehlschlag der Datenbankimportierung und DEFINER-Fehler, die Benutzerdefinition in der Trigger-/Ansichtsobjekt kann mit dem temporären Importbenutzer von WP Toolkit kompatibel sein.
Smart Update ersetzt kein Backup. Vor der Aktualisierung muss ein separates Plesk-Backup erstellt werden und ausreichend Speicherplatz für eine vollständige Kopie am Ziel vorhanden sein.
Das Zwingen des Überschreibens im Ziel der Klonierung kann die bestehenden Site-Dateien und Datenbankinformationen unwiderruflich ändern. Das Ziel-Domain- und Pfad-Objekt sollte nicht ohne Pröfung leere Leerzeichen enthalten.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: Der WP-CLI-Unterprozess ist nicht abgelaufen.
Mögliche Ursache: Malware, beschädigter Config, langsames PHP oder externe Dienst.
Bedeutung: Die allgemeine Zeitgrenze für Klonierung oder Aktualisierung wurde überschritten.
Mögliche Ursache: Große Daten, langsame IO, festgefahrene Importierung oder geringe Ressourcen.
Bedeutung: Ein SQL-Dump kann nicht auf die Ziel-Datenbank angewendet werden.
Mögliche Ursache: DEFINER, SQL-Modus, Paketgröße, Verbindung oder beschädigter Dump.
Bedeutung: Trigger/View verwendet fehlenden MySQL-Benutzer als Definer.
Mögliche Ursache: Benutzer wurde gelöscht oder entspricht nicht dem temporären Importbenutzer.
Bedeutung: WP Toolkit kann das WordPress-Core oder seine Verbindung nicht ordnungsgemäss erkennen.
Mögliche Ursache: Fehlende wp-config, falsche DB, fatal error oder Dateipfad.
Bedeutung: Im Copy bleibt die alte Site-URL oder Plugin-Redirect.
Mögliche Ursache: WP_HOME/WP_SITEURL, serialisierte Daten oder Cache.
Bedeutung: Für einen Testklon gibt es keine Fläche, um eine vollständige Website-Kopie zu erstellen.
Mögliche Ursache: Große Uploads, Sicherungen oder niedrige Festplattenreserve.
Bedeutung: Zeigt an, dass der Ziel-Pfad oder Datenbank vorhandenes Inhalt enthält.
Mögliche Ursache: Falsche Zielwahl oder alter Staging-Server.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
plesk ext wp-toolkit --list -format jsonListet die WordPress-Instanz-ID und die grundlegenden Status in JSON auf dem Server auf.
plesk ext wp-toolkit --info -instance-id 1Zeigt Registrierungs- und Statusinformationen für die angegebene WordPress-Instanz an.
plesk ext wp-toolkit --wp-cli -instance-id 1 -- core verify-checksumsWordPress vergleicht Kern-Dateien mit offiziellen Prüfsummen.
plesk ext wp-toolkit --wp-cli -instance-id 1 -- plugin listZeigt aktive Plugins und Versionen im Kontext von WP Toolkit.
mysql -NBe "SELECT TRIGGER_SCHEMA,TRIGGER_NAME,DEFINER FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA='wordpress_db';"Die Quell-WordPress-Listet Trigger-Definierungen in der Datenbank.
du -sh /var/www/vhosts/example.com/httpdocs
df -h /var/www/vhosts/example.com/httpdocsVergleichen Sie die für den Klon erforderliche Dateigröße mit der freien Speicherfläche des Ziel-Filesystems.
plesk ext wp-toolkit --clear-wpt-cacheWP Toolkit löscht den Cache; löscht die Daten der Quellsite nicht.
Überprüfen Sie die Quell-WordPress-Gesundheit, den Speicher, den Ziel, die Datenbank und den WP Toolkit-Prozess-Log separat.
Smart Update ist kein Backup. Sichern Sie Ihre Dateien und Datenbank mit Plesk Backup Manager in einem sicheren Ort.
Die Instance-ID, wp-config, der Core-Checksum und der WP-CLI-Zugriff werden überprüft.
plesk ext wp-toolkit --info -instance-id 1Ein vollständiger Klon erfordert mehr freien Speicherplatz als die Quellengröße und einen freien/sicheren Zielpfad.
Wenn ein Importfehler vorliegt, werden der erste SQL-Fehler und der DEFINER-Objekt gefunden; alle Trigger werden nicht zufällig gelöscht.
Die Unter-Kommandozeile, die den Timeout verursacht, kann über SSH ausgeführt werden, um Malware, externe Verbindungen oder PHP-Limits zu trennen.
Die Ziel-Website sollte nicht auf die ursprüngliche Domain ausgerichtet werden; Admin, Cron, Permalink und Zahlungs-/Formulareinreichungsflüsse sollten getestet werden.
WP-CLI Timeout, verdächtiger Code in wp-config und PHP-Handler-Kompatibilität werden überprüft.
Trigger/View-DEFINER, SQL-Modus, max_allowed_packet und Dumpfehler werden untersucht.
WP_HOME, WP_SITEURL, Cache- und Redirect-Plugins werden überprüft.
Dynamischer Inhalt, Cookie-Banner, Cache und zeitabhängige Komponenten können falsche Positivergebnisse erzeugen; ein manueller FunktionsTest wird durchgeführt.
Ein neuer Klon sollte einen anderen Subdomain/Path verwenden oder nachdem der Zielserver vollständig gesichert wurde, bewusst gelöscht werden.
Der WP-CLI-Befehl wird nicht innerhalb der Zeitbegrenzung abgeschlossen. Malware, beschädiger wp-config, PHP oder ein schwerer Plugin sollten untersucht werden.
Der allgemeine Klonierungs-/Update-Prozess wurde innerhalb von 30 Minuten nicht abgeschlossen. Disk IO, Datenmenge und angeschlagener Unterprozess werden untersucht.
Erstellt einen Testklon, ersetzt den normalen Backup jedoch nicht laut offiziellem Plesk-Dokumentation.
Der erste SQL-Fehler muss gefunden werden; insbesondere sollten die DEFINER- und Zielbenutzerberechtigungen für Trigger/Ansichten überprüft werden.
wp-config-Einstellungen, WordPress-Optionen, serialisierte Daten, Cache oder Redirect-Plugin, das möglicherweise die alte URL aufrechterhält.
Sie können die bestehende Datei und die WordPress-Daten auf dem Ziel ändern. Es sollten jedoch nur überprüfte Sicherungen und das richtige Ziel verwendet werden.
--clear-wpt-cache Löscht den eigenen Cache von WP Toolkit; WordPress-Cache-Plugin-Daten sind unterschiedlich.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.