Das Wichtigste zuerst:
Wenn deine WordPress Seite eine HTTP 500 Fehlerseite auf Mobilgeräten ausliefert und wenn du das WP-Statistic Plugin installiert hast, prüfe einmal das Setting des PHP Memory Limits. Wenn es auf einen kleinen Wert wie 32 MB steht, dann erhöhe es auf eine angemessenere Größe wie 64, 96 oder 128 MB.
Aber jetzt zur Hintergrundgeschichte.
Als ich mir Gedanken über die Themen für diesen Blog machte, habe ich nicht erwartet, dass ich jemals mal einen Post über Webseitenerstellung oder Web-Programmierung erstellen werde. Aber auf Grund meiner kürzlich gesammelten Erfahrungen mit dem Erstellen dieser Webseite mit WordPress als kompletter Neuling in WordPress, möchte ich heute einmal ein paar Aspekte teilen. Dieser Post ist also leicht „off topic“.
Der Hauptgrund für diesen Post steht bereits im Titel. Meine Seite hat eine HTTP 500 Fehlerseite (Interner Server Fehler) ausgeliefert, wenn jemand mit einem Smartphone die Seite besuchte. Nach einem Neuladen der Seite funktionierte es dann aber. Aber nichts desto trotz sah der Besucher zunächst eine tote / kaputte / nicht verfügbare Seite. Das ist … vermutlich nicht so toll. 😉
Als erstes hatte ich dieses Problem selbst per Zufall entdeckt als ich das Aussehen auf Mobilgeräten prüfen wollte. Ich dachte es sei nur eine temporäre Sache bei meinem Hosting Provider. Obgleich das Merkwürdige war, dass die Seite mit jedem Browser von einem Desktop Computer aus funktioniert hat. Jedoch erfuhr ich einen halben Tag später, dass andere immer noch dieses Problem auf meiner Seite hatten, wenn sie diese mit dem Smartphone besuchten.
Also hatte ich schon fast ein Support Ticket bei meinem Hosting Provider eröffnet. Jedoch fand ich einen Hinweis im Netz, das neu installierte WordPress Plugins die Ursache für einen HTTP 500 Fehler sein können.
Ah, hatte ich nicht gerade erst gestern das WP-Statistic Plugin installiert, damit ich sehen kann, wie oft meine Seite besucht wird und welche Teile davon?
Nur mal so habe ich das Plugin deaktiviert und browste die Seite vom Smartphone aus an. Und siehe da: Alles wurde ohne Probleme geladen.
Um auf Nummer sicher zu gehen habe ich das Plugin wieder angeschaltet und was passierte? Richtig, der HTTP 500 Fehler war wieder da.
Also ist das Plugin der Verursacher? Ich begann zu zweifeln, denn es ist das am häufigsten installierte Plugin für Besucherstatistiken mit über 800k Installationen und meine Seite ist nicht sehr groß, komplex oder irgendwie speziell was Web-Programmierungs-Techniken betrifft.
Ich habe eine Weile gebraucht, aber dann bin ich über eine 2 Sätze lange Nachricht eines anderen Nutzers gestolpert, der ebenso einen HTTP 500 Fehler erwähnte und zusätzlich etwas von Erhöhen des PHP Memory Limits sagte.
Ok?!?!? Kann so eine Spezialität bei mir und meinem Standard und „ready-to-use“ Setup der Grund sein? Also habe ich mich daran gemacht herauszufinden wo man dieses Setting findet und verändern kann (An CPanel Nutzer: Es ist etwas mit PHPini im Namen).
Ich fand das Setting, sah, dass es auf unfassbar niedrige 32 MB stand (sind wir noch in den 90ern??) und erhöhte es auf unglaubliche 64(!) MB(!) (Wow, damit habe gerade meinen Speicher verdoppelt!!!).
Ich aktivierte das Plugin und alles hat funktioniert! Puuuhh!
Aber Moment mal…
Wir haben 2022.
Muss ich wirklich das Speicher Setup meiner Webseite per Hand konfigurieren? Mi einer Versuch-und-Irrtum Methode?
Ich denke, es gibt noch sehr viel Verbesserungspotential.
Und das deckt sich mit meinen Eindrücken zu dem ganzen Gebiet. Ich möchte es nicht dem WP-Statistic Plugin ankreiden. Es ist vielmehr bezogen auf die komplette Maschinerie.
Auf der einen Seite ist es wirklich genial zu sehen wie „plugin-fähig“ das gesamte WordPress Framework ist. Die Fähigkeiten der Plugins sind nahezu endlos, weil sie sich überall an alle Stellen mit allem Möglichen einklinken können. Und auch wie die verschiedenen Bestandteile (PHP, Datenbank, WordPress, etc.) einfach zusammenarbeiten und mit nur einem Klick nutzbar waren, ist absolut großartig.
Aber dann auf der anderen Seite ist alles sehr lose verbunden. Ein Plugin könnte ein anderes stören, einfach weil es sich auf eine Art und weise integriert, welche das andere Plugin zerstört und umgekehrt. Eines könnte ein neues Hauptmenü erzeugen, das andere könnte sich irgendwo anderes in ein Untermenü einnisten. Einige fügen der oberen Statusbar in WordPress komplett neue visuelle Gadgets hinzu, andere sogar eine halbe eigene Seite am unteren Ende der Edit-Ansicht der Seiten. Sie erzeugen sogar neue Spalten, Tabellen und Abfragen für die Datenbank, oder doppeln mal eben das interne Directory-Layout (z.B. für mehrsprachige Seiten).
Aber alles in allem bin ich sehr glücklich was man damit alles anstellen kann und die vorhandenen Sachen sind einfach unglaublich.
Wie auch immer, nach einiger Zeit wird man jedoch feststellen, das Sachen auftauchen, die man nicht mit den verfügbaren Optionen behandeln kann.
Zum Beispiel musste ich:
- Manuell das HTML anpassen (Meta tags im head Element hinzufügen, dabei wären gerade einmal 4 Strings in der Datenbank notwendig gewesen um es einfach zu handhaben.)
- Manuell PHP-Code anpassen um die letzte Zeile im Footer wie gewünscht zu verändern.
- Manuell CSS-Code anpassen (naja, die CSS Attribut-Hölle ist eine komplette eigenständige Geschichte. 😉)
- Custom Style Sheets hinzufügen um Stil-Settings zu überschreiben oder hinzu zu fügen.
- JavaScript Code modifizieren um das Syntax-Highlighting für TeaScript Code zu erhalten und das für C++ zu verbessern.
- …
Ich hatte vorher nicht damit gerechnet, dass ich so tief in so viele verschiedene Aspekte der Webprogrammierung einsteigen muss um meine eigene Seite mit dem gewünschten Look-and-Feel und der Funktionalität zu erhalten. Und ich habe ja gerade erst angefangen …
Na gut, wenn das so weiter geht, werde ich noch bald ein Web-Experte, obwohl ich mich hauptsächlich eigentlich auf C++ konzentrieren wollte. *lach*