Support » Allgemeine Fragen » Weisse Seite nach Umzug (Debug kein Effekt!)

  • Gelöst hessi2

    (@hessi2)


    Hallo Leute,

    bin heute Morgen aus Wut über meinen Hoster und seine wiederholte Unfähigkeit aus eigenen Fehler lernen zu können, überstürzt zu einem anderen Hoster gewechselt.

    DBs und htmldocs kopiert.

    Domains transferiert.

    Dumps (angepasst auf neue Datenbank) und Docs auf neuen Webspace kopiert.

    wpconfig.php an neue Zugangsdaten angepasst.

    Aufruf meiner Site generiert eine (übliche) weiße Seite.
    Selbst mit define(‚WP_DEBUG_DISPLAY‘,true) bleibt die Site weiß.

    Und um noch genauer zu sein: Sie bleibt auch weiß, wenn ich falsche SQL-User-Zugangsdaten eingebe. Das ist für mich nicht nachvollziehbar.

    Es ist der korrekte Server (DNS stimmt), denn ich kann zum Beispiel
    https://www.hessburg.de/VR-Touren/02.04.2020-a/ aufrufen – ein Marzipano-Ordner, der eigenständig läuft.

    Was läuft das schief? Ist die Site bei Euch auch weiß?

    Danke im Voraus
    Michael

    Edit: Ich scheine auch keinen Zugriff auf die Serverlogs zu haben, das ist ja blöd. Eine testweise händisch installierte WP-Site läuft problemlos.

    Edit 2:

    Ist das ein Scherz? Hat die wpconfig.php in einer neuen WP-Inst tatsächlich im Default 666? Häh? Das sagt der WebFTP des Hosters.

    Edit 3:
    Ich habe alle gelöscht und entpacke gerade das Backup. Währenddessen bleibt die Site weiterhin weiß, es scheint also irgendein Fehler beim Hoster zu sein?

    • Dieses Thema wurde geändert vor 6 Monaten, 1 Woche von hessi2.
    • Dieses Thema wurde geändert vor 6 Monaten, 1 Woche von hessi2.
    • Dieses Thema wurde geändert vor 6 Monaten, 1 Woche von hessi2.
    • Dieses Thema wurde geändert vor 6 Monaten, 1 Woche von hessi2.

    Die Seite, für die ich Hilfe brauche: [Anmelden, um den Link zu sehen]

Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 15)
  • Hallo,
    da taucht ein Error 500 auf.
    Hilfreich könnte eine neue .htaccess sein:

    • verbinde dich mit deinem Server über FTP
    • suche die .htaccess-Datei in deinem Stammordner
    • lade eine Kopie der Datei auf deinen Computer (als Sicherung)
    • lösche die .htaccess-Datei von deinem Server, nachdem du eine Sicherungskopie auf deinem lokalen Computer hast.

    Um WordPress zu zwingen, eine neue, saubere .htaccess-Datei zu erzeugen:

    • gehe zu den Einstellungen > Permalinks in deinem WordPress Dashboard
    • unten auf der Seite klicken: auf Änderungen speichern (du musst keine Änderungen vornehmen – klicke einfach auf die Schaltfläche).

    Viele Grüße
    Hans-Gerd

    Thread-Ersteller hessi2

    (@hessi2)

    Hi HG,

    hast Du immer noch einen Error 500? Die Dateien sind nun fertig entpackt und ich habe die wpconfig angepasst.

    Die .htaccess ist leer.
    Die Rechte scheinen auch zu passen.
    Echt keinen Plan mehr.

    Gruß
    Michael

    Edit:
    Habe die Hosen runtergelassen:
    define(‚WP_DEBUG‘, true);
    define(‚WP_DEBUG_LOG‘, true);
    define(‚WP_DEBUG_DISPLAY‘, true);
    Sieht da jemand etwas?

    • Diese Antwort wurde geändert vor 6 Monaten, 1 Woche von hessi2.

    Hallo,
    du hast (verständlicherweise) jetzt die Seite in den Maintenance-Zustand versetzt. Ich gehe aber davon aus, dass du weiterhin den Error 500 hast.
    Du findest z. B. hier im Forum ein ähnliches Problem. In dem Beitrag wird für diesen Fall beschrieben, wie du das Problem evtl. beheben kannst. Hier auch ein Ansatz von @la-geek.
    Sonst würde ich oben bei der Suche auch mal „Error 500“ eingeben und du erhältst jede Menge Treffer zu dem Problem.
    Da die Ursachen unterschiedlich sind, muss man leider sehr viele Möglichkeiten prüfen, um diesen Fehler zu beheben.
    Viele Grüße
    Hans-Gerd

    Thread-Ersteller hessi2

    (@hessi2)

    Das ist ne einfache index.html. WP ist tot.
    Ich bekomme keinen Error 500, der kam vermutlich nur, weil Du die Site geöffnet hast, als der ZIP-Job noch lief.

    Siehe: https://hessburg.de/index.php

    Edit: Mist, mit dem Chromium bekomme ich ne 500er. FF geht mir langsam auf den Sack.

    • Diese Antwort wurde geändert vor 6 Monaten, 1 Woche von hessi2.
    Thread-Ersteller hessi2

    (@hessi2)

    Mal ne blöde Frage: Ich wollte den Theme-Ordner aus den Installationsdateien frisch machen. Dazu benannte ich meinen alten um, und erstellte einen leeren Themes-Ordner. Beim Kopieren der Dateien meckerte Nautilus, dass die Dateien bereits existieren würden. Erstellt WP im Fehlerfalle den Ordner mit Standard-Themes wirklich neu? Also… ist WP doch noch aktiv?
    Wenn dem so ist, wieso bekomme ich dann keine Debug-Infos angezeigt?
    define(‚WP_DEBUG‘, true);
    define(‚WP_DEBUG_LOG‘, true);
    define(‚WP_DEBUG_DISPLAY‘, true);
    Steht direkt über dem Edit-Hinweis, wo es hingehört.

    Auch die Dateirechte scheinen zu stimmen.
    Plugins sind weg (in DB und Files), Themes sind weg (Files und DB (active, template, stylesheet).

    Was mir noch auffällt:
    Es befinden sich noch einige Einträge mit dem absoluten Pfad in der DB. Der lautete früher:
    /var/www/vhosts/tellerrandforschung.de/httpdocs/hessburg.de
    Ich will jetzt nicht wüst alles ersetzen, aber kann es sein, dass diese Einträge relevant sind und nicht dynamisch ersetzt werden können?

    Es handelte sich bei dieser Installation um eine, die ich in Plex anstieß, weil die sich dann so nett über das Hoster-Backend integrieren liess.
    Dagegen spricht, dass ich die Site lokal via lampp auch mit diesen Einträgen an den Start bekomme.

    • Diese Antwort wurde geändert vor 6 Monaten, 1 Woche von hessi2.
    • Diese Antwort wurde geändert vor 6 Monaten, 1 Woche von hessi2.
    Thread-Ersteller hessi2

    (@hessi2)

    Okay, ich schreibe hier einfach mal, was ich nun gemacht habe, vielleicht hilft das den späteren Generationen.

    1.) Plugins deaktiviert (Files & DB)
    2.) Themeas ebenso deaktiviert
    3.) Dateirechte geprüft
    4.) Den alten absoluten Pfad zum WP-Verzeichnis in der Datenbank auf den neuen Pfad geändert.
    5.) Auch wenn die htaccess leer war, so meckerte das Log (endlich gefunden!) doch, dass der verf… Wordfence immer noch versuchte, den absoluten Pfad zu überprüfen. Also auch noch die .htaccess~ umbenannt.

    Jetzt bekomme ich einen php-Fehler:
    blah, blah, blah ‚PHP message: PHP Warning: Unknown: failed to open stream: No such file or directory in Unknown on line 0P blah, blah blah

    6.) Die user.ini (ja, die kommt auch von Wordfence, verdammtes Mistding) umbenannt.

    7.) Jetzt bleibt das Fehler-Log leer, aber ich habe immer noch keinen Zugriff, schlimmer noch: Auch unter Chromium habe ich nun eine leere weiße Seite.

    Wieso wird keine Debug-Info ausgegeben? WP scheint noch vor den Einträgen oder der wpconfig(?) die Hufe hochzureißen.

    Den alten absoluten Pfad zum WP-Verzeichnis in der Datenbank auf den neuen Pfad geändert.

    Wo hast du das eingetragen/geändert?
    Es gibt eigentlich keinen Grund, den Pfad zum WordPress-Verzeichnis anzugeben.

    Auch wenn die htaccess leer war, so meckerte das Log (endlich gefunden!) doch, dass der verf… Wordfence immer noch versuchte …

    All-in-One-Security-Plugins sind so eine Sache. Viele Anwender/-innen erliegen dem Trugschluss, alles für die Sicherheit ihrer Website getan zu haben, wenn sie brav alle Kontrollkästchen anhaken. Was das dann bewirkt und ob das ausreicht erzählt ihnen aber keiner. Spätestens wenn es bei der Website hakt, treten dann Probleme auf, wie wir hier schön sehen.

    Immerhin gibt es eine ausführliche Anleitung, wie sich Wordfence umständlich manuell entfernen lässt: Remove or Reset

    Der Webserver schreibt Fehlermeldung in einen eigenen Error-Log, den du entweder über das Kundenmenü deines Webhosters oder per SSH-Zugriff auf den Server auslesen kannst. Im Zweifelsfall solltest du den Webhoster um Hilfe bitten.

    Mit define('WP_DEBUG_LOG', true); schreibt WordPress Fehlermeldungen in einen eigenen Error-Log, den du in wp-content auslesen kannst. Das setzt aber voraus, dass WordPress überhaupt zur Ausführung kommt. Steigt der Webserver wegen eines Fehlers schon früher aus, bleibt der Error-Log leer.

    Ich würde bei diesen doch recht massiven Fehlern erst einmal mit einer neuen Datei phpinfo.php mit Inhalt <?php phpinfo(); anfangen, die du in das WordPress-Verzeichnis legst und dann im Browser mit https://example.com/phpinfo.php (natürlich mit deiner Domain) abrufst. Hier solltest du zumindest Informationen bekommen, welche PHP-Version du nutzt und wieviel Arbeitsspeicher (memory_limit) dir zur Verfügung steht.

    Die user.ini (ja, die kommt auch von Wordfence, verdammtes Mistding) umbenannt.

    In einer Testinstallation habe ich rasch Wordfence installiert, wobei allerdings keine user.ini angelegt wurde. Interessant wäre der Inhalt der Datei*. Beim Umbenennen solcher Dateien solltest du übrigens berücksichtigen, dass Dateien mit z.B. der Endung .txt oder .bak je nach Serverkonfiguration nicht vor Zugriffen geschützt sind und damit auch von Angreifern ausgelesen werden können.

    Jetzt bekomme ich einen php-Fehler:
    blah, blah, blah ‚PHP message: PHP Warning: Unknown: failed to open stream: No such file or directory in Unknown on line 0P blah, blah blah

    Sehr witzig. Was sollen wir jetzt damit anfangen?
    Du verschwendest damit nur unsere Zeit.

    WP scheint noch vor den Einträgen oder der wpconfig(?) die Hufe hochzureißen.

    Tipp: gewöhn dir an, Dateien wie wp-config.php oder functions.php richtig zu schreiben. Du wirst sonst irgendwann eine falsche Schreibweise verwenden und einen halben Tag damit verbringen, nach der Fehlerursache zu finden.

    * Nachtrag: Wordfence verwendet scheinbar auf manchen Servern doch eine user.ini:

    .user.ini is only used on some server configurations, but if it exists, Wordfence code is surrounded by the comments mentioned above

    Quelle: Optimizing The Firewall

    • Diese Antwort wurde geändert vor 6 Monaten, 1 Woche von Bego Mario Garde. Grund: Nachtrag
    Thread-Ersteller hessi2

    (@hessi2)

    Wo hast du das eingetragen/geändert?
    Es gibt eigentlich keinen Grund, den Pfad zum WordPress-Verzeichnis anzugeben.

    Überall dort, wo er in der DB eingetragen war.
    Ja auch ich dachte, dass es keinen Grund gäbe, aber im Error-Log des Webspaces wurde es als Fehler ausgegeben, der sich danach erledigte.

    All-in-One-Security-Plugins sind so eine Sache. Viele Anwender/-innen erliegen dem Trugschluss, alles für die Sicherheit ihrer Website getan zu haben,

    Ist mir klar, dass man Sicherheit nicht installieren kann. Den Hint für das manuelle Deinstallieren werde ich abarbeiten.

    Der Webserver schreibt Fehlermeldung in einen eigenen Error-Log,

    Daher habe ich doch die o.a. Fehlermeldungen.

    mit einer neuen Datei phpinfo.php mit Inhalt <?php phpinfo(); anfangen,

    Sinnlos, denn WP läuft natürlich prinzipiell problemlos. Manuell und über Plex habe ich Testinstallationen durchgeführt. Ist ja das Erste, damit ich sehe, ob es irgendwelche Seltsamkeiten im Vergleich gibt.

    PHP habe ich auf dieselbe alte 7.2er Version eingestellt, die auch auf dem alten Server am Start war, ist klar.

    keine user.ini angelegt wurde.

    Das muss man explizit anstoßen. Ich habe WF vor allem wegen der 2FA und den konfigurierbaren Login-Sperren installiert. Der Rest ist doch nur ne Bling-Bling-Show für Windows-User, die auf Schlangenöl stehen. Die weite Verbreitung und die Erkennung durch Complianz war für mich ausschlaggebend.

    Sehr witzig. Was sollen wir jetzt damit anfangen?
    Du verschwendest damit nur unsere Zeit.

    Sehr freundlich. Das soll uns sagen, dass der absolute Pfad immer noch irgendwo relevant zu sein scheint.

    Tipp: gewöhn dir an, Dateien wie wp-config.php oder functions.php

    Da ich mir angewöhnt habe, niemals auch nur irgendwas von einem System vorgegebenes händisch einzutragen/zu ersetzen, isses völlig wurscht, wie ich WpKoNfIG schreibe. 😉

    WF ist nun weg, das war ja nun echt alles andere als umständlich. Hat nichts gebracht, denn die Site, wie gesagt, funktioniert lokal quasi OOTB, was wohl bedeutet, dass irgendwo ein Pfad hinterlegt ist, dessen Rückmeldung einen Unterschied macht.

    Thread-Ersteller hessi2

    (@hessi2)

    Okay… also… das mit Wordfence KOMPLETT (auch in der DB!) weghauen hat DOCH was gebracht. Und zwar im Backend! Das hatte ich natürlich zuerst nicht ausprobiert.
    Dort musste ich die Permalinks wieder abnicken, damit WP die htaccess neu schreibt.
    Warum aber WF die Site nicht in der lokalen Installation blockierte… keine Ahnung. Ich werde nun aber zu einzelnen Plugins für 2FA und Login-Restictions greifen. Nase voll von Schlangenöl.

    Jetzt noch Themes und Plugins wieder aktivieren, dann sollte alles wieder funzen.

    • Diese Antwort wurde geändert vor 6 Monaten, 1 Woche von hessi2.
    • Diese Antwort wurde geändert vor 6 Monaten, 1 Woche von hessi2.
    Thread-Ersteller hessi2

    (@hessi2)

    Okay, alle rennt wieder so, wie es soll.
    Danke für Eure Mühen! Weiß ich sehr zu schätzen.

    Ich werde nun aber zu einzelnen Plugins für 2FA und Login-Restictions greifen. Nase voll von Schlangenöl.

    Das ist schon mal ein Schritt in die richtige Richtung, aber du kannst tatsächlich noch ein bisschen mehr für die Sicherheit deiner Website tun. WordPress hat zum Beispiel eine XML-RPC-Schnittstelle, damit du auch mit Apps auf die Website zugreifen kannst. Grundsätzlich eine schöne Idee, aber leider wird die Schnittstelle gerne missbraucht um Passwörter durchzuprobieren (Brute-Force).

    Torsten hat auf seiner Website vor ein paar Jahren einige Regeln für die .htaccess aufgeschrieben, mit denen du deine Website weiter absichern kannst – die Sperrung der XML-RPC-Schnittstelle ist auch dabei. Auch wenn der Beitrag etwas älter ist, haben die Tipps durchaus noch ihre Gültigkeit. Schau’s dir mal an:

    Mehr Sicherheit für WordPress per htaccess

    Das ging mir jetzt zu schnell auf gelöst, konnte gar nichts helfen.
    Dennoch ein Tipp für den nächsten Umzug: Duplicator!

    Thread-Ersteller hessi2

    (@hessi2)

    @bego Mario Garde: Das ist gut. Habe lieber 1.000 Zeilen in der .hataccess, als irgendwelche Schlangenöl-Tools, die wieder DSGVO-Recherche generieren.

    @pezi: Verstehe. Das tut mir leid. 😀
    Ich muss immer noch von der letzten Migration von vier Seiten (2xWP, 2xJ!–>WP) einige meiner Beitragsbilder per Hand anpassen, weil die wüst durcheinander gewürfelt wurden und sinngemäß Artikel 123 das Beitragsbild von Artikel 642 hatte.

    Solange das nicht gefixt ist, wollte ich den Umzug nicht automatisiert durchführen lassen. Nichtsdestotrotz bin ich ein Freund von verschiedenen Backups und hätte das auch noch zur Sicherheit angestoßen.

    Wie gesagt: Der Umzug war eine Kurzschlussreaktion und die Domains waren schneller neu registriert, als ich ein Backup im Backend hätte durchführen können. Früher dauert das etwas länger als zwei Minuten. So hatte ich keinen Zugriff mehr auf das Backend der alten Installation.

    Muss man nicht lesen, nur als Bericht aus der Realität mit Hostern:
    Kurzschluss warum? Weil der Provider keinen Support außerhalb der Geschäftszeiten gibt (nur gegen heftige Aufpreise), Matomo irgendwie komplett Amok lief und die Datenbank mit vielen GBs an Daten flutete, so dass die Website drei Tage down war. Die haben wohl keine Überwachung von solchen heftigen Auslastungen auf dem Userspace.

    Wohl aber bei der Auslastung des Webspaces. Dort hatte ich nur 20 GB. Mails sind da auch mit drin. Ich hatte ein Backup lokal und auf die Cloud angestoßen, und eingestellt, dass drei Backups bitte vorgehalten werden. Die Website ist Bilderlastig und hat so schon fast 7 GB belegt. 3×7 zzgl. Mails waren dann 23 GB. Das passierte nachts, ist klar. Kam auch ne Mail. So gegen 03:00 Uhr oder so. Montag Morgen war dann mein Account gesperrt. Website down, Mails down, kein Backendzugriff mehr auf einen Dateimanager, kein FTP-Zugriff mehr. Musste einen Call aufmachen und dann einige Stunden warten.

    Ja, wäre deren Schuld gewesen, hätten sie wieder freigeschaltet.

    Vor einigen Jahren hatte ich das so schon einmal erlebt und mir wurde gesagt, dass die dieses Fehlverhalten der Automatisierung beim Überschreiten der Grenzen sinnvoller konfiguriert hätten. Haben sie wohl nicht.

    Beim neuen Hoster habe ich für die Hälfte des Geldes 150 GB Webspace, vier de-Domains mit drin und auch für mich sinnfreie 50 Datenbanken. Dazu halt fette Grenze für den Upload von SQL-Dumps & Co. Schon nice.

    Wo Licht, da Schatten. Einiges gefiel mir im Kundenbereich des alten Hosters besser, aber das ist wohl Gewohnheit und dafür reißt der SSH-Zugriff und die Cron-Jobs echt vieles wieder raus.

    Das nur als Erklärung dafür, warum ich nicht ein Backup mit deaktivierten Plugins erstellte. Obwohl das auch in dem Falle nichts geholfen hätte. „Sicherheits-Tools“ als immer vor einem Umzug komplatt deinstallieren! Nicht nur deaktivieren.

    Interessanter Erfahrungsbericht. 👍🏻

    Da ich bei meinen Websites automatische Aktualisierungen laufen lasse und die Websites unbeobachtet aussteigen könnten, nutze ich zusätzlich phpServerMonitor zur Überwachung der Websites. Damit erhalte ich per Messenger einen Hinweis, wenn eine Website länger als eine Viertelstunde offline ist bzw. auf der Website ein bestimmter Text (z.B. „Datenschutzerklärung“ in der Fußzeile) nicht mehr abrufbar ist. Dank regelmäßiger Backups sollte die Website dann sehr schnell wieder herzustellen sein.

    Thread-Ersteller hessi2

    (@hessi2)

    Interessanter sollten nur meine Erfahrungen sein, die ich bei der Migration von vier Websites auf eine gemacht habe. Vor allem die Comments in Joomla sind ein echt trauriges Kapitel. 😀

    Mein Weg ist genau anders herum: Ich wollte nicht mehr vier separate Sites mit zwei versch. CMS verwalten müssen, auf denen auch noch unterschiedliche Erweiterungen liefen. Ich habe daher meine Site „containert“, was auch irgendwie bei Google geklappt hat, aber nicht ganz so, wie gedacht. Aber das ist egal. Ich mache die Site nicht für Reichweite. Ist nett, wenn es den Leuten hilft. Habe auch keine Ahnung, was so eine Site bringen „muss“. 😉

    • Diese Antwort wurde geändert vor 6 Monaten, 1 Woche von hessi2.
Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 15)
  • Das Thema „Weisse Seite nach Umzug (Debug kein Effekt!)“ ist für neue Antworten geschlossen.