Beiträge von b3317133

    Wenn Du das PHP Error Log anschaust solltest Du bei Deinem Code sowas finden, das hilft ggf. schonmal etwas:

    Code
    Parse error: syntax error, unexpected 'echo' (T_ECHO) ...


    Das [FONT=Courier New]echo[/FONT] hat dort nichts verloren.

    Eine richtigere Variante Deines Codes (aber nicht die wirklich gedachte Anwendung des Operators) wäre z.B.:

    Code
    echo function_exists('exec_sem_list') ? exec_sem_list() : '<h3>ERROR: Function not found!</h3>';


    Dann wird entweder der Rückgabewert Deiner Funktion oder Dein Fehlertext ausgegeben.

    Mehr zu diesem Operator siehe z.B. in der PHP Dokumentation, mit WordPress hat das gar nichts zu tun.

    ..wie es funktioniert auf einer Webseite dutzende Dummyseiten zu integrieren.
    GeneratePress ist nur ein Beispiel...ich weiß wie ich den Demo Content von GeneratePress in mein Theme importiere.


    Diese Art Demo Content für Generate Press bringt alles mit, den ganzen Website inkl. Dummyseiten, Einstellungen, Menüs, usw. daher sollte er wie im o.g. Link zur Dokumentation beschrieben ganz zu Beginn in einem leeren WordPress installiert werden:

    Zitat

    The demo content should only ever be imported on fresh website with no content.


    Um einzelne Seiten zu vervielfachen, wird oft das Plugin Duplicate Post verwendet.

    Bei vielen Themes gibts es Demoseiten, wo man das "Frontend" des Theme beispielhaft befüllt ansehen kann.

    Bei manchen Themes wird zusätzlich sog. "Demo Content" zur Verfügung gestellt den man in der Regel im "Backend" ganz zu Beginn importiert und dann nach eigenen Wünschen anpasst.

    Im Fall der o.g. Demoseite sieht das lt. zugehöriger Dokumentation so aus.

    Ändern Sie die MySQL Connection in der Konfigurationsdatei ...


    Bei WordPress ist das die Datei [FONT=Courier New]wp-config.php[/FONT]

    Überprüfen Sie, ob Ihre Scripte ggf. reservierte Wörter enthalten..


    WordPress ist kompatibel mit MySQL 5.6 oder höher. Wenn ein Plugin o.ä. nicht kompatibel ist, merkst Du das nach einer Umstellung durch Fehler/Probleme damit.

    Was hast du geändert?


    Nichts.

    Weisst du was du ändern solltest und wenn ja wie hast das geändert?


    Ich würde das Error Log lesen und dann die nötigen Änderungen wie Anpassungen bzw. Entfernen von Plugins o.ä. vornehmen.

    Kann ich den Alten DB einfach bei der neuen DB einspielen wie bei 1und1 auch beschrieben, .


    Die Anleitung sieht exakt das vor, einen Export der alten Datenbank und einen Import in die neue Datenbank.

    aber dort steht man soll das selber konfiguriren weil es sein kann das ja 5.7 was abderes hat.. ich weiss nur nicht was und wie habe sowwas noch nie gemacht.


    Selber konfigurieren musst Du die MySQL Zugangsdaten in [FONT=Courier New]wp-config.php[/FONT], siehe oben. Wenn Du unsicher bist, wende Dich an die Person, die Deinen Website eingerichtet hat oder suche Dir professionelle Unterstützung in Deinem Umfeld.

    Vielleicht ist es ja auch getan wenn ich einfach ein mysql DB 5.7 erstelle und die alte da rein importiere,


    Die Anleitung sieht exakt das vor, einen Export der alten Datenbank und einen Import in die neue Datenbank.

    Ich weiss nur nicht ob ich da drinnenn irgendwelche andere Spalten tabellen oder sonst was noch manuell eintragen müsste deshalb die Frage.


    Nirgends in der Anleitung steht etwas von Spalten tabellen ... manuell eintragen o.ä.

    Evtl. ist [FONT=Courier New]WP_DEBUG[/FONT] bei Dir auf [FONT=Courier New]true[/FONT] gesetzt, denn eigentlich sollten solche Hinweise und Warnungen standardmässig von WordPress nicht angezeigt werden. Versuche es mit [FONT=Courier New]false[/FONT] statt [FONT=Courier New]true[/FONT] falls das so eingestellt ist.

    Um anderweitig temporär wieder ins Backend zu kommen, kannst Du versuchen, per FTP die Datei [FONT=Courier New]/wp-content/mu-plugins/rms_unique_wp_mu_pl_fl_nm.php[/FONT] aus dem Ordner zu verschieben, z.B. einen Ordner höher in [FONT=Courier New]/wp-content/[/FONT] so dass sie WordPress nicht mehr findet. Das ist aber keine Dauerlösung, denn für irgendwas wird dieses "Must Use" Plugin sicherlich benötigt.

    Wende Dich ggf. an die Person, die den Website eingerichtet hat, die sollte wissen, wozu das Plugin dient bzw. woher es kommt.

    Laufen irgendwelche Optimierungs-Plugins, die z.B. Transients in der Datenbank beeinflussen?

    Der Fehler kann nach Blick in den Quellcode im Grunde nur daher kommen, dass [FONT=Courier New]$lock = get_transient( 'doing_cron' );[/FONT] keine Zahl beinhaltet, das triggert dann das Problem bei der Addition mit der WordPress Konstanten in Zeile 654.

    Oder hast Du z.B. in Deiner wp-config.php o.ä. die Konstante WP_CRON_LOCK_TIMEOUT selbst gesetzt, ggf. als String z.B. [FONT=Courier New]"300"[/FONT] statt als Zahl [FONT=Courier New]300[/FONT] o.ä.?

    Änderungen in WordPress Core Dateien sind (ausser ggf. zu temporärem Debugging) nie eine gute Idee.

    Vielleicht hast Du den Seobility Bot versehentlich ausgesperrt.

    Zudem ist die Seite derzeit vermutlich gehackt, nach Zufallsprinzip oder 1x pro IP oder ähnlich erscheinen im Footer unerwünschte Scripteinbindungen im Quelltext, von mir markiert mit [FONT=Courier New]=== hier ===>[/FONT], z.B.

    Die genannte Malware wird nach kurzer Google Analyse offenbar über eine wie auch immer geartete Lücke vermutlich in einem Plugin über persistent XSS hinterlegt, lädt dann bei jedem Seitenbesuch ein oder mehrere JavaScripts, wartet damit bis ein Admin sich anmeldet und baut dann über den WordPress Theme-Editor in die Datei header.php des Themes diverse Dinge ein, die im späteren Verlauf von aussen weitergenutzt werden können.

    Code
    view-source:ws.stiven fernando.com/kj.txt - online lt. Header Mon, 13 Apr 2020 17:01:36 GMT, base64encoded, führt u.a. zu
    view-source:ws.stiven fernando.com/stm?v=2.2.0 - diesen Mechanismus habe ich schon anderswo mal gesehen


    (ein Leerzeichen in den URLs ergänzt, damit das niemand aus Versehen klicken kann.)

    Die Erfahrung bei ähnlichen Dingen zeigt, bei unbequemen Fragen reagiert das wordpress.org Forum oft recht dünnhäutig.

    Bei einer Infektion mit dem ähnlichen Mechanismus war am Ende eine Vielzahl von Core-Dateien inkl. wp-config.php und auch weitere vorhandene Themes infiziert bzw. es wurden auch tief in Verzeichnissen extra Backdoors hinterlegt was ein Vergleich mit einer aus sauberen Quellen angelegten Dateistruktur mit exakt den gleichen Versionen von WordPress, Themes, Plugins sichtbar machen kann.

    Dein Log ist schwer zu deuten, entweder ist ein (ggf. versteckter) Benutzer vorhanden, oder eine Backdoor macht den Login zu Deinem Admin Nutzer o.ä., wenn das das Einfallstor wäre.