Drei Updates: CMS-Fehlerbehebung, Links- und Kontakt-Seite
Soeben wurden drei Updates durchgeführt, und zwar die folgenden:Inhaltsverzeichnis:
1. CMS-Fehlerbehebung – PHP-Warnungen bei 301-Weiterleitungen:
Eigentlich wollte ich heute um kurz nach 05:10 Uhr nur rein spontan einen Blick in die Error-Logfiles am Webserver werfen, was dann komplett ungeplant ad hoc Arbeiten bei meinem Flat-File-CMS, welches erst vor exakt zwei Wochen aktualisiert wurde, zur Folge hatte. In der heutigen Error-Logdatei gab's nämlich mehrere Einträge, dass das CSV-Array, woraus mehrfach Werte abgerufen wurden, nicht existierte. Das war ziemlich seltsam, da im Webbrowser ja einst nach dem Einspielen des Updates von vor zwei Wochen keine Warnungen oder Fehler angezeigt wurden. Und auch jetzt konnte ein Post korrekt und vollständig im Webbrowser aufgerufen werden. Sprich: Die notwendigen Werte wurden korrekt aus dem CSV-Array ausgelesen. Und trotzdem wurden heute u.a. folgende Einträge in die Error-Logdatei am Webserver – nicht in der Test-Umgebung – reingeschrieben:[Mon Jun 16 05:15:37.267963 2025] [proxy_fcgi:error] [pid […]:tid […]] [client 213.[…]:[…]] AH01071: Got error 'PHP message: PHP Warning: Undefined variable $csv in /var/www/vhosts/[…]/includes/posts-head.php on line 192; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 192; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 192; PHP message: PHP Warning: Undefined variable $csv in /var/www/vhosts/[…]/includes/posts-head.php on line 210; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 210; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 210; PHP message: PHP Warning: Undefined variable $csv in /var/www/vhosts/[…]/includes/posts-head.php on line 213; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 213; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 213; PHP message: PHP Warning: Undefined variable $csv in /var/www/vhosts/[…]/includes/posts-head.php on line 228; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 228; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 228; PHP message: PHP Warning: Undefined variable $csv in /var/www/vhosts/[…]/includes/posts-head.php on line 229; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 229; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 229; PHP message: PHP Warning: Undefined variable $csv in /var/www/vhosts/[…]/includes/posts-head.php on line 236; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 236; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 236; PHP message: PHP Warning: Undefined variable $csv in /var/www/vhosts/[…]/includes/posts-head.php on line 237; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 237; PHP message: PHP Warning: Trying to access array offset on null in /var/www/vhosts/[…]/includes/posts-head.php on line 237'
[Mon Jun 16 05:15:37.268289 2025] [proxy_fcgi:error] [pid […]:tid […]] [client 213.[…]:[…]] AH01071: Got error '; PHP message: PHP Warning: Undefined array key "" in /var/www/vhosts/[…]/includes/posts-body.php on line 31; PHP message: PHP Warning: Undefined array key "" in /var/www/vhosts/[…]/includes/posts-b'
[Mon Jun 16 05:15:37.268446 2025] [proxy_fcgi:error] [pid […]:tid […]] [client 213.[…]:[…]] AH01071: Got error 'ody.php on line 34'
Diesen Aufruf hier hatte ich selber basierend auf frühere gleichlautende Einträge initiiert gehabt, nur dauerte es etwas diese Zeilen zu finden, da ich versehentlich die gestrige Error-Logdatei geöffnet gehabt hatte. Naja, zumindest kam ich mit der Error-Logdatei alleine nicht weiter, weshalb ich auch einen Blick in die Access-Logdatei werfen musste. Nur gab's dort keine Einträge zu diesem Zeitpunkt. Natürlich nicht, weil ich Depp die Access-Logdatei für die unverschlüsselte Verbindung geöffnet gehabt hatte, und nicht jene für die verschlüsselte Verbindung. Also, hier sind nun die dazugehörigen Einträge, wobei ich auch hier die IPv4-Adresse meines Internet-Anschlusses und die Port-Nummern anonymisiert habe:
213.[…] - - [16/Jun/2025:05:15:37 +0200] "GET /forum/viewtopic.php?f=7&t=393&start=0 HTTP/1.1" 301 695 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" PHP-Handler:plesk-php83-fpm Remoteport(vom Nginx):[…]
213.[…] - - [16/Jun/2025:05:15:37 +0200] "GET /archiv.php?f=7&t=393&start=0 HTTP/1.1" 301 14011 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" PHP-Handler:plesk-php83-fpm Remoteport(vom Nginx):[…]
213.[…] - - [16/Jun/2025:05:15:37 +0200] "GET /news-i.php?t=393 HTTP/1.1" 200 5229 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" PHP-Handler:plesk-php83-fpm Remoteport(vom Nginx):[…]
213.[…] - - [16/Jun/2025:05:15:37 +0200] "GET /css/style.css HTTP/1.1" 200 388 "https://danielmayr.at/news-i.php?t=393" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" PHP-Handler: Remoteport(vom Nginx):[…]
213.[…] - - [16/Jun/2025:05:15:37 +0200] "GET /css/lightbox.css HTTP/1.1" 200 391 "https://danielmayr.at/news-i.php?t=393" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" PHP-Handler: Remoteport(vom Nginx):[…]
213.[…] - - [16/Jun/2025:05:15:37 +0200] "GET /images/feed-icon-16x16.png HTTP/1.1" 200 1214 "https://danielmayr.at/news-i.php?t=393" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" PHP-Handler: Remoteport(vom Nginx):[…]
213.[…] - - [16/Jun/2025:05:15:37 +0200] "GET /js/prototype.js HTTP/1.1" 200 404 "https://danielmayr.at/news-i.php?t=393" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" PHP-Handler: Remoteport(vom Nginx):[…]
213.[…] - - [16/Jun/2025:05:15:37 +0200] "GET /js/lightbox.js HTTP/1.1" 200 403 "https://danielmayr.at/news-i.php?t=393" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" PHP-Handler: Remoteport(vom Nginx):[…]
213.[…] - - [16/Jun/2025:05:15:37 +0200] "GET /js/scriptaculous.js?load=effects HTTP/1.1" 200 408 "https://danielmayr.at/news-i.php?t=393" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" PHP-Handler: Remoteport(vom Nginx):[…]
213.[…] - - [16/Jun/2025:05:15:37 +0200] "GET /js/effects.js HTTP/1.1" 200 402 "https://danielmayr.at/news-i.php?t=393" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" PHP-Handler: Remoteport(vom Nginx):[…]
213.[…] - - [16/Jun/2025:05:15:37 +0200] "GET /matomo/matomo.js HTTP/1.1" 200 405 "https://danielmayr.at/news-i.php?t=393" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" PHP-Handler: Remoteport(vom Nginx):[…]
213.[…] - - [16/Jun/2025:05:15:37 +0200] "GET /images/loading.gif HTTP/1.1" 200 394 "https://danielmayr.at/news-i.php?t=393" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" PHP-Handler: Remoteport(vom Nginx):[…]
213.[…] - - [16/Jun/2025:05:15:37 +0200] "GET /images/closelabel.gif HTTP/1.1" 304 294 "https://danielmayr.at/news-i.php?t=393" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" PHP-Handler: Remoteport(vom Nginx):[…]
Und was sagt uns das jetzt? Ich bin immer noch mit Windows 7 (64-Bit) und Mozilla Firefox 115 (i.d.F. die ESR-Version hiervon) unterwegs. Ja, das auch, ist hier aber unwichtig. Genauso, wie auch die letzten zehn Einträge in dieser Access-Logdatei gegenstandslos sind, da hier lediglich CSS, Bild- und JavaScript-Ressourcen korrekt abgerufen werden. Interessant sind hier nur die ersten drei Zeilen, wo es zwei Mal zu einer 301-Weiterleitung kommt. Diese 301-Weiterleitungen funktionieren auch genau so, wie sie sollten, nur rotzt es mir wegen diesen 301-Weiterleitungen seit der Umstellung auf PHP 8.3 von vor zwei Wochen auf einmal die Error-Logdateien mit Warnungen voll. Folglich durfte wieder einmal ChatGPT-4o herhalten, wodurch ich nun erstmalig darauf aufmerksam gemacht worden bin, dass die PHP-Funktion header() lediglich den HTTP-Header ändert, nicht aber auch gleich das PHP-Script an jener Stelle stoppt, wovon ich aber einst ausging.
Unter PHP 7.4 hatte es mir diese Warnungen nie in die Error-Logdateien geschrieben gehabt, sodass ich von diesem von mir verursachten Fehler aufgrund von Unkenntnis zuvor nicht aufmerksam gemacht werden konnte. Interessanterweise steht im deutschen PHP-Handbuch zur PHP-Funktion header(), dass man exit() unmittelbar danach aufrufen soll, damit das PHP-Script nicht weiter ausgeführt wird. Laut der Wayback Machine stand diese Info auch schon vor fünf Jahren dort. Okay… Reden wir einfach nicht mehr darüber. Ich habe dann auch noch mittels curl die Header- und Body-Inhalte vom Post #0 über die Archiv-, die Blog- und die internen News-Seite via CLI ab, nur passte dort alles. Aufgrund der 301-Weiterleitung wurden zu den beiden zuletzt genannten Seiten keine Body-Inhalte gesichert, da keine vom Webserver übertragen wurden, was jetzt aber irrelevant ist. Nachfolgend noch der besagte Befehl, den ich hierzu benutzt hatte:
Nachdem ich folglich nach über 1,5 Stunden die Ursache dieser zahlreichen PHP-Warnungen nun endlich herausgefunden hatte, fügte ich nun ab 06:42 Uhr auf der Archiv-Seite unmittelbar nach der PHP-Funktion header() einen Kommentar nebst anschließenden exit() ein, sodass diese PHP-Datei um 07:33 Uhr final war. Währenddessen holte ich noch weitere Infos von ChatGPT-4o ein und kümmerte mich z.T. auch schon um die "posts-head.php"-Datei, in der es zwölf solcher header()-Funktion-Aufrufe gibt. Die ersten fünf befinden sich in der 5-fach verschachtelten if-Abfrage betreffend der Validierung der über den URL-Parameter "t" eingegebenen Post-ID. Zur Erinnerung: Wenn diese zu hoch ist, erfolgt eine 302-Weiterleitung und keine 301-Weiterleitung, was in diesem Fall aber eh völlig nebensächlich ist, da der anschließende PHP-Code eh nur dann ausgeführt wird, wenn die Validierung erfolgreich war.
Auch die eigentliche Post-Anzeige über die "posts-body.php"-Datei erfolgt nur dann, wenn die Validierung der Post-ID erfolgreich war. Diese war im eingangs genannten Fall aber valide, weshalb es mit sieben weiteren header()-PHP-Funktionen in den Abschnitten "p3" und "p4" weiterging. Die erste hiervon entfernt alles bis auf den t-Wert, wenn ein "f"- oder "p"-URL-Parameter ebenfalls angegeben ist. Und da ich bei just jener PHP-Funktion keinen Kommentar vorangestellt habe – also eine Zeile darüber –, wurde dies im besagten Abschnitt "p3" in "posts-head.php" gleich noch nachgeholt. Und bevor ihr fragt: Ich unterteile abhängig der Funktions-Aufrufe bzw. Aktionen ein PHP- bzw. Bash-Script stets in mehrere Abschnitte, sodass ich später mittels "p1 -", "p2 -" usw. über die Such-Funktion schnell dorthin springen kann. Der Abschnitt "p3" in der Datei "posts-head.php" lautet übrigens "Weiterleitung bei f-/p-Werten und Min-Max-Bestimmung".
Bis zu diesem Zeitpunkt im PHP-Script wurde die CSV-Datei, in der ja die Post-ID; die Kategorie, das Veröffentlichungsdatum, die Post-Länge und der Post-Titel zu jedem Post hinterlegt sind, noch gar nicht geladen. Dies erfolgt nun zu Beginn des Abschnitts "p4", da dort nun die sechs Kategorie-basierten 301-Weiterleitungen definiert sind. Und genau hier wird unmittelbar vor der PHP-Funktion header() das CSV-Array mittels der PHP-Funktion unset() weggeschmissen. Und somit war nun endlich klar gewesen, wie es zu diesen zahlreichen PHP-Warnungen kam. Nachdem unterhalb aller zwölf header()-PHP-funktionen exit() (inkl. Kommentar natürlich) nachgetragen wurde, fügte ich unmittelbar oberhalb dieser sechs Kategorie-basierten 301-Weiterleitungen noch einen 13 Zeilen umfassenden Kommentar betreffend dieses Umstands hier hinzu, wofür auch die meiste Zeit draufging. Ich wollte hier nämlich keinen Blödsinn niederschreiben, da ich stets versuche alle Kommentare nahezu zu jener Aktion in einem PHP- oder Bash-Script so zu formulieren, damit ich auch in fünf oder gar zehn Jahren och weiß, warum ich was genau an dieser Stelle wie und warum gemacht habe. Das mag manchmal etwas ausarten, hilft aber ungemein. Nachfolgend besagter Kommentar als Fließtext.
2025-06-16, Erläuterung der Code-Anpassung wegen PHP-Update 7.4 -> 8.3 hinzugefügt. Die PHP-Funktion header() ändert den HTTP-Header, beendet allerdings nicht das PHP-Script. PHP führt das PHP-Script weiter aus und befüllt somit den PHP-Output-Puffer weiter an. Dieser PHP-Output-Puffer (inkl. HTTP-Header-Infos) wird an den Webserver gesendet. Der Webserver schickt dann den HTTP-Header gefolgt vom Body an den Client bzw. Webbrowser. Der Speicher für das große CSV-Array wird vor der HTTP-Header-Änderung freigegeben. Dies reduziert vorsorglich sogleich den Speicherbedarf dieses PHP-Scripts am Webserver. Diese Speicher-Freigabe würde allerdings auch durch die PHP-Funktion exit() initiiert werden. Ohne exit() werden in den restlichen PHP-Scripts bei korrekter Post-ID nicht (mehr) vorhandene Variablen abgerufen. Dementsprechende PHP-Warnungen sind wegen der 301-Weiterleitung nur in den Error-Logdateien am Webserver ersichtlich. Der Webbrowser führt die 301-Weiterleitung aus, ohne auf den Body zu warten. Weshalb die aktivierte PHP-Option "display_errors" hier nutzlos ist. Durch exit() wird das PHP-Script beendet und der bisherige PHP-Output-Puffer sofort an den Webserver gesendet.
So weit, so verständlich, oder? Zumindest war die "posts-head.php"-Datei um 08:33 Uhr finalisiert gewesen, sodass ich lediglich die in beiden PHP-Dateien gemachten Änderungen mehrfach kontrollierte. Denn auf eines hatte ich jetzt absolut keine Lust gehabt, und zwar das Ganze vorher in meiner Test-Umgebung in der Linux Mint 21-VM zu testen. Da im Prinzip an ganz bestimmten Stellen 13 Mal "exit();" hinzugefügt wurde, änderte sich an der eigentlichen Funktionsweise ja nichts, sodass ich mit diesen Änderungen heute um 08:55 Uhr gleich live ging. Zuvor wurden um 08:48 Uhr die Kontakt- und um 08:50 Uhr die Links-Seite um je vier code-Zeilen am Stand-PC reduziert, worauf ich nachfolgend noch eingehen werde, sodass ab 08:50 Uhr die Vorbereitung für die Veröffentlichung dieser internen News hier starten konnte. Da ich nicht nebenbei einfach so diese interne News niederschreiben konnte, wurden um Punkt 09:00 Uhr lediglich mal der Einleitungssatz nebst den drei Überschriften publiziert.
Am gesamten Text dieser internen News hier saß ich dann am Dienstag, dem 17. Juni 2025, von 05:00 bis 07:30 Uhr sowie am Folgetag von 07:00 bis 11:05 Uhr und nochmals einen Tag darauf von 07:35 bis 07:45 Uhr. Zudem wiederholte ich währenddessen die o.g. curl-Aktion und erweiterte zugleich noch in dieser internen News den o.g. Code-Block, sodass der sich darin befindliche Text nicht nur mittels der linken Maustaste, sondern auch zusätzlich mit der Leertaste markiert werden kann. Auch für diese kleine code-Erweiterung kam ChatGPT-4o zum Einsatz, da ich von JavaScript quasi absolut keine Ahnung habe. Hauptsache KISS. Zurück zum Thema: Da nach dem Upload heute um 08:55 Uhr diese PHP-Warnungen betreffend dem CSV-Array nicht mehr in die Error-Logdatei am Webserver geschrieben wurden – dies schließt die PHP-Warnungen bei Zeile 31 und 34 in der "posts-body.php"-Datei mit ein –, wurde die PHP-Option "display_errors" heute um 09:15 Uhr via CloudPit wieder deaktiviert. Und bevor die Frage auftaucht: Bei diesen beiden Zeilen handelt es sich um die echo-Ausgaben für den vorherigen und nächsten Post, die unterhalb eines Posts ersichtlich sind.