WordPress kaputt machen

Nach meinem Beitrag über das Herunterfahren meiner Community-Tätigkeiten könnte der Titel womöglich in den falschen Hals kommen. 😉 Ich möchte auch WordPress nicht deaktivieren, was David in seinem Artikel experimentell ausprobiert. Nein, das Thema sind typische Support-Baustellen. Wie reagiert WordPress, wenn etwas so richtig schief gelaufen ist …

Um eine Fehlermeldung (oder Fehler generell) einschätzen zu können, muss ich sie am besten mal selber erlebt haben. Nun kann ich aber nicht jeden Fehler selber erlebt haben und daher rufe ich die Community auf, mir und den anderen Foren-Supportern zu helfen. Lasst uns gemeinsam eine Liste erstellen, was schief laufen kann, was dann passiert und wie es repariert werden kann.

Dazu reicht es ein Problem in die Kommentare zu werfen – was dann passiert und wie es wieder gerade gebogen werden kann, dass schaffe ich dann (hoffentlich) selbst. Wer diese Info mitgeben will – sehr gerne – das bedeutet weniger Arbeit für mich. 😉

Am Ende werde ich daraus einen Talk für das WordCamp Berlin bauen. So zumindest mein Plan. So können Supporter schneller erkennen, was für ein Problem vorliegt, was die Ursache ist und wie es gefixt werden kann.

Meine Ideen bisher:

  • WordPress auf PHP kleiner als 5.2 installieren
  • WordPress-Adresse mit www, Website-Adresse ohne www – oder umgekehrt
  • Falscher Editor für Änderungen an wp-config.php benutzt
  • Während Core/Plugin/Theme-Update das Internet kappen (oder Timeout erzeugen, durch manuelles Verändern der entsprechenden PHP-Variable)
  • (Extrem) kleine Werte für bestimmte PHP-Variablen einstellen. Wann entstehen welche Probleme?
  • Bulk Actions mit extrem hoher Anzahl an Beiträgen – welche Fehlermeldung kommt und warum?
  • .htaccess aus einer Unterordner-Installation auf Hauptdomain herüber kopieren/verschieben

Bitte postet so viele Ideen wie möglich in die Kommentare. Am besten immer eine Idee pro Kommentar. Vielen Dank!

Für ein paar typische Probleme mit Memory Limit, SSL-Verbindung, Background-Updates habe ich mir mal eine kleine Supporter-Linkliste angelegt. Wer da noch mehr Tipps für mich hat. Gerne hier oder direkt bei Github als Kommentar. Auch hier vielen Dank!

Nachtrag: Im Supporter-Handbuch gibt es dazu übrigens auch eine eigene Rubrik: Breakfix Lessons.

38 Antworten auf WordPress kaputt machen

  1. Ein Klassiker, der mir in letzter Zeit häufiger untergekommen ist: WordPress-Adresse und/oder Website-Adresse werden im Backend manuell (und falsch) angepasst und zum Beispiel auf einen nicht existenten Unterordner eingestellt. Das Frontend läd dann zwar in der Regel noch, aber es zerschießt die meisten Assets und Einloggen um es zu reparieren geht auch meistens nich.

  2. Ein Klassiker: „Ich habe zufällig/versehentlich/zum Ausprobieren die Website- und/oder WordPress-URL unter Einstellungen > Allgemein geändert.“

    ToDo: Einstellungen > Allgemein > Website-URL und/oder WordPress-URL in beliebigen Wert ändern, abmelden, wundern.
    Fix: in wp-config.php define(‚RELOCATE‘, true); einfügen, im Backend anmelden, schwachsinnige Änderung rückgängig machen.
    Bonus: Erkläre mir, wieso du dieses Änderung vorgenommen hast. 😉

    • Tja, warum? Weil WordPress als so „einfach“ wahrgenommen wird, dass sie wohl glauben mit dieser Änderung würde sich tatsächlich die Domain ändern …

  3. Ich stelle aktuell häufig fest, dass Website-Betreiber sich an der SSL-Umstellung versuchen, dann aber an „Mixed Content“-Meldungen scheitern.
    Hauptgrund: Sie richten ein SSL-Zertifikat für die Domain ein, stellen ggf. noch unter „Einstellungen > Allgemein“ die URLs um, jedoch ersetzen sie nicht die URLs an allen anderen Stellen der Datenbank. Dazu kommen dann noch Probleme mit Inhalten von externen Seiten (VG-Wort-Einbindung, YouTube und andere Streamingdienste, …).
    Für die externen Inhalte hilft nichts anderes, als per Developer Tools zu prüfen, welche externen Inhalte dafür verantwortlich sind und diese manuell zu ersetzen. Gute Testseite dafür: https://www.jitbit.com/sslcheck/

  4. Freitag wieder gehabt: Die URLs zu Artikel/Beiträgen/Posts zeigen den Artikel nicht, sondern eine andere WordPress-Seite (und nicht die 404). Ursache: Ein Plugin hat eine Rewrite-Rule mit einem Reserved Term [1] registriert.

    [1] https://codex.wordpress.org/Function_Reference/register_taxonomy#Reserved_Terms

    • Auf solche Perlen habe ich gewartet. 🙂
      Eine sehr schöne Variante für etwas, was kaputt geht und die Ursache nicht sofort auf der Hand liegt. Danke!

  5. Und überhaupt: Seite/Inhalt Xyz, der im Backend angelegt und sichtbar ist, zeigt im Frontend nicht sich selber sondern irgendwas anderes an. Tritt gerne auch, nachdem man Plugin aktiviert oder deaktiviert hat. Oft ist es dann nur nötig, die Rewrite Rules einfach nochmal zu speichern.

  6. Problem: Geplante Artikel gehen nicht zum geplanten Zeitpunkt online (und wenn überhaupt, dann sehr viel später).

    Das Problem taucht gerne auf, wenn die Cron-Queue zu voll ist. Das kann man als Anwender ohne Extra-Plugin (meines Wissens nach) leider nur sehr schwer prüfen. Vielleicht weis jemand hier ein bessere Lösung, als das, was ich sonst mache, nämlich direkt in der Datenbank schauen und erstmal löschen.

    Eine zu volle Cron-Queue kann latürnich auch noch andere unschöne Nebenwirkungen haben, oft insbesondere Synchronisierungen mit anderen Services.

    • Das Problem kann auch auftreten, wenn es keinen Visit gibt, der eine WP-Cron-Ausführung triggert… 😉

    • Ohne Extra-Plugin sehe ich da auch keine Möglichkeit. Aber Dank WP Crontrol kann das ja ganz gut geprüft werden. – Fehlender Visit ist beim internen „Cron“ tatsächlich manchmal ein Problem. Eigentlich sollte der erste Visit nach dem Cron dann den Schedule ausführen. Klappt aber nicht immer. Externer Cronjob ist da praktisch, kennen aber nicht alle. Und nicht alle Hoster bieten es in allen Paketen an.

  7. > Header information already sent.

    Irgendein Plugin hat nen Space vor dem öffnenden <?php

  8. .htaccess mit Windows Notepad öffen, sich wundern warum alles in einer Zeile steht und schön neu formatieren. Hochladen -> boom

    Problem: Zeilenenden LF (z.B. Linux) werden nicht richtig im Notepad angezeigt, und (zumindest mein) Apche mag kein CRLF (Windows).

    • Sehr schönes Beispiel! Line-Endings sind auch so ein Problem, an das der Laie nicht sofort denkt und was einem WP so richtig zerschießen kann. Danke!

  9. Einen Fehler 500 beim Hochladen von 40 Bildern (mit hoher Auflösung). Hatten wir erst heute bei uns im Online Spielemagazin. Da hat nur der harte „Stopp des Scripts“ durch den Serveradmin geholfen…

    Beim Basteln eines CPTs und benutzerdefinierten Rewrites, dann Beiträge aufrufen und einen 404 abbekommen. Lösung: Einfach die „Permalinks-Seite“ aufrufen.

    Coole Sache, Torsten!!!

    • Internal Server Error sagt ja noch nicht so viel aus. Bei 40 Bilder mit hoher Auflösung tippe ich da mal auf zu wenig Memory Limit. Und das wäre tatsächlich ein Klassiker …

      Rewrite Rules flushen nach dem Ändern von CPTs ist auch immer wieder in den Supportforen anzutreffen. Berühmt berüchtigt 😉

      Danke für die Beispiele!

  10. Problem: Formulare funktionieren nicht auf gecachten Seiten (bei als statische HTML-Dateien gecachten URLs).

    Möglicher Grund: Nonces.
    Formular-Plugin setzt eine Nonce mit Verfallsdatum. Nonce wird mit Verfallsdatum im HTML gecacht. Verfallsdatum wird erreicht, Nonce verfällt im Hintergrund, ist aber immer noch mit dem alten Wert im Quelltext präsent. Formular verweigert den Dienst.

    Lösung: Cache löschen.
    Bei Plugins, die das unterstützen: Verfallsdatum für den Cache auf einen kleineren Wert setzen, z.B. 10 Stunden.

    • Schon ein spezielleres Problem, aber sicher kein Edge Case. Caching ist bei vielen kaputten Features die Ursache. Warum ist die Adminbar plötzlich weg? Warum sehe ich plötzlich die Mobilseite? Nonces ist etwas, was im Hintergrund passieren sollte und es funktioniert einfach. Ein Laie ist schon vom Begriff überfordert (wer wäre es nicht?). Danke für das Beispiel!

  11. Problem: PageSpeed Insights, GT Metrix o.a. beanstanden fehlendes Browser-Caching.

    Möglicher Grund: false positive, ein Blick in die Details offenbart, dass die Beanstandung für Dateien gilt, die von externen Services (Google, Facebook, Instagram etc.) geliefert werden.

    Lösung: Bei Google, Facebook, Instagram anrufen und um Aktivierung des Browser-Cachings bitten.
    Nein, ernsthaft … 😉 Keine Lösung möglich, weil keine Kontrolle über die Server-Umgebung dieser Dateien. Beanstandung einfach ignorieren.

    Ähnliches gilt für Beanstandungen bezüglich fehlender Concatenation usw. von Dritt-Server-Dateien.

    • Das ist nichts, was WP direkt „kaputt“ machen würden, aber als typisches Support-Thema auch bei mir immer wieder gefragt. Leider.

  12. Problem: error 500.

    Möglicher Grund: Oldie, but goldie, PHP memory von 64M oder 96M.
    Für die meisten Setups sind 128M absolutes Minimum. Irgendwas mit WooCommerce und/oder ist eigentlich erst mit 256M auf der sicheren Seite.

    Lösung: define( 'WP_MEMORY_LIMIT', '256M' );
    Oder speziell nur fürs Backend: define( 'WP_MAX_MEMORY_LIMIT', '256M' );

    • Ein häufiger Problemfall, absolut. Aber ob mehr Speicher hier immer die Lösung ist? Manchmal lohnt sich auch ein Hinterfragen der genutzten Plugins … 😉

  13. Im Backend im Menü Design den internen Editor aufrufen, das Funktions-Template functions.php aufrufen und an beliebiger Stelle (aber außerhalb von Kommentaren) folgenden fehlerhaften Code einfügen: function(, Datei aktualisieren und dann wie ein König freuen, dass wegen einem Syntax Error nichts mehr läuft.

    Alter Hut, klar, wir empfehlen auch gefühlt seit dem Fall der Mauer, den internen Editor nicht zu verwenden, aber vielleicht sitzt ja doch jemand im Publikum, den du nachhaltig beeindrucken kannst. 😉

    • Für Einsteiger ist das sicher ein guter, wichtiger Punkt. Vor allem mit der exakten Erklärung. Dieses Problem landet ja meistens bei einem von uns, wenn dann zusätzlich die FTP-Zugänge beim verschollenen Webworker liegen …

  14. Vorfall: Plugin ist nach fehlgeschlagener Aktualisierung deaktiviert. Ein Blick in das Plugin-Verzeichnis zeigt, dass der Ordner des betreffenden Plugins zwar vorhanden, aber unvollständig oder gar leer ist.

    Problem: Webspace-Paket mit zu geringen Ressourcen (z.B. Strato). Der Server schafft es nicht, nach dem Download das Plugin-Archiv zu entpacken und vollständig in das Plugin-Verzeichnis zu kopieren. Passiert bei großen Plugins wie Toolset Types (gepackt 8 MB, entpackt 30 MB und 2.700 Dateien). Da hilft nur manuelles Update / Installation via FTP oder Wechsel zu einem anderen Webhoster.

    • Auch immer wieder im Supportforum anzutreffen. Vor allem bei den großen Plugins (z.B. Jetpack, BackWPup) mit vielen Dateien. Die spannende Frage ist: welche Ressource löst genau das Problem aus? Könnte man hier Werte vielleicht manuell erhöhen, um das Problem zu umgehen? Skript-Ausführungszeit?

      • Erhöhung der Ausführungszeit bringt zumindest bei o.g. Provider nichts. Und da du gerade BackWPup erwähnst: habe es bei diesem Provider bei diversen Websites noch nie geschafft, ein vollständiges Backup (DB + Dateien) zu erstellen. Betrifft also nicht nur entpacken sondern auch packen. Konnte aber bisher nicht herausfinden, welche Ressource dafür verantwortlich ist.

  15. Zwar nicht WordPress spezifisch, aber Sonderzeichen in Dateinamen (Uploads) sollten vermieden werden. Gerade wieder bei der Übernahme einer alten Installation gehabt. Alter (uralter) Server frisst Sonderzeichen in Dateinamen und zeigt alle Bilddateien problemlos an, aber der neue Server eben nicht. Watch out for Ümlaut, Baby!

    • Auch ein Supportklassiker. WordPress kriegt man damit wohl nicht richtig kaputt, aber nervig ist es allemal. Und wenn man die Ganze NFD-Geschichte mit berücksichtigt, dann ist das plötzlich ein ziemlich großes übergreifendes Problem. Danke für die Ergänzung!

  16. Einer meiner Lieblingsklassiker: WordPress-Update läuft nicht ganz rund und die .maintenance bleibt erhalten. Panische Fragen / Anrufe vorprogrammiert, weil kein Zugriff mehr aufs Backend. Lösung: Warten (waren das 10 Minuten bis WordPress die selber löscht?) oder per FTP löschen. Letzteres ist gerade für Personen mit One-Click-Installationen gar nicht so einfach.

  17. Kommt auch bald 😉 MySQL 5.7 haut dich für sowas, wenn nicht rauskonfiguriert:

    SELECT ID FROM (
    SELECT ID, post_title FROM wp_posts WHERE post_title LIKE ‚foo%‘
    ) ORDER BY post_title

    Es hätte gerne das alle Felder die einem Order folgen auch in einem Select sind. Findet sich das in WP irgendwo? 😉

    Und …

    – Weiße Seite = Theme weg
    – AJAX klappt nimmer? Seit WP 4.7 (oder 4.7.2) ist die Funktionssignatur von wp_die so anders, dass es weh tut.
    – Viele Queries / RAM voll = Datenbank mit Transients voll, die alle auf Autoload stehen.
    – WP auf HHVM – wie sehen die Fehler da aus?
    – Hat schon einer Dateirechte gesagt? ;D
    – export_wp mehrmals aufrufen ist seit 4.3 kaputt.

    Ich hatte irgendwo eine Kiste voll mit solchen Sachen. Mal gucken, ob die wiederfinde.

  18. Ich erinnere mich daran, dass früher wenn eine Site in einer Multisite ein selbst-signiertes SSL-Zertifikat hatte und man nach einem WP-Update die Netzwerk-Aktualisierung laufen ließ, der Prozess mit einem Fehler ausstieg und alle weiteren Sites nicht aktualisiert wurden.

    Alle Sites aus der Liste vor der „problem Stelle“ wurden aktualisiert. Sobald aber einer der Sites in dem 5-er Set nicht durch lief wurden alle folgenden Sets erst gar nicht versucht zu aktualisieren.

    Ich bin mir nicht sicher ob dies nicht inzwischen gefixt ist.

  19. Vielleicht auch noch interessant, aber fast ein Thema für sich: Der berühmte nichtssagende „HTTP error“ beim Versuch Bilder hochzuladen. Eine Google-Suche nach wordpress „http error“ liefert immerhin 356.000 Ergebnisse. Nur die Lösung ist leider nicht so eindeutig, wie bei anderen Themen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.