Wieder Ärger mit PHP //2675

Offenbar ist alle paar Jahre ein Update der PHP-Version meiner Website fällig. Mein Hoster hatte mich angeschrieben, dass ich die Version bis zum soundsovielten umstellen muss, sonst wird die Wartung kostenpflichtig.
PHP ist nicht die Sprache meiner Wahl. Für die Website gibt es aber keine andere Option. Ursprünglich hatte ich viel mit Server Side Includes gemacht, bis irgendwann PHP verfügbar war. Dies nutzte ich, um meine Website auszubauen. Nur dafür lernte ich PHP, bzw. was ich davon halt für die Website brauchte. Ich bin also bei weitem kein Experte, sondern wurschtle halt so herum. Trotzdem sind im Laufe der Jahre etliche PHP-Skripten mit teils umfangreicher Funktionalität entstanden.
Die Ankündigung des Hosters war also nicht erfreulich. Zwar hatte ich die Hoffnung, dass es einigermaßen glatt laufen könnte (d.h. fünf Minuten einloggen auf der Verwaltungsseite meines Hosters und ein paar Klicks für die Umstellung, und anschließend vielleicht eine halbe bis ganze Stunde, um meine Scripts auf ihre Funktionalität hin zu testen), aber ich befürchtete, dass der Zeitaufwand auch wesentlich höher sein könnte.
Also wartete ich zur Sicherheit, bis ich mir notfalls längere Zeit würde nehmen könnte, um dann zügig notwendige Änderungen durchzuführen, ohne gleich wieder unterbrechen zu müssen.
Vielleicht wäre es günstiger gewesen, wenn ich erst eine Zwischenversion gewählt hätte, aber ich wollte die Umstellung ein für alle Mal hinter mich bringen, ohne gleich wieder alles umändern zu müssen. So wählte ich das Update auf 8.1, bei dem ich dann wieder bis Ende 2024 meine Ruhe haben würde.
Nun ja, die Hoffnung, dass die Umstellung glimpflich abgehen würde, trog. Jede Menge Warnungen und Deprecated-Aussagen.
Ich googelte, ob ich online Hinweise finden würde, welche Änderungen ich bei PHP 8 besonders beachten müsste, fand aber nur Listen, welche tollen neuen Features jetzt vorhanden wären. Danke, aber diesen ganzen Schei? brauche ich nicht. Ich habe eine einfache Website, die nun wirklich nichts an besonders außergewöhnlichem PHP nutzt. Die soll einfach funktionieren.

Also eins nach dem anderen.
Als erstes fiel mir ins Auge, dass ich jetzt, wenn ich irgendwo nur das Datum abfrage, vorher die Zeitzone gesetzt haben muss. Sonst hässliche Meldung, die ich nur wegkriege, indem ich das Error Reporting stark reduziere (aus den Augen, aus dem Sinn), was aber auch nicht in meinem Sinne ist.
Während ich früher noch das Includen anderer URLS (nur von meiner eigenen Website) durch eine Änderung in der php.ini (in jedem betroffenen Verzeichnis extra, während die .htaccess-Dateien von Apache wenigstens auf alle Unterverzeichnisse rekursiv mitwirken – eine ganz andere Philosophie) erreichen konnte, meckerte der PHP-Interpreter es jetzt ständig an, so dass ich mich daran machte, stattdessen die PHP-Dateien vom Webspace zu inkludieren, was ein Riesenaufwand war, weil ich bisher den Datenaustausch über den Querystring* vorgenommen hatte, und jetzt erst umständlich $Variablen setzen musste.
Überhaupt – die Variablen. Umständlicher geht’s nicht. Auch wenn ich bestimmte Variablen (insbesondere Formulareingaben über $_POST oder $_GET – sh. Fußnote*) gar nicht brauche, bzw. die dann einfach leer sind, muss ich dauernd erst irgendwo abfragen, ob die überhaupt existieren und initialisiert sind. Dabei stelle ich, wenn es auf die Existenz dieser Variablen tatsächlich ankommt und sie nicht nur optional sind, anderswo sicher, dass sie vorhanden sind. Gerade bei meinen Honeypots ist das besonders ärgerlich, denn die sollen eigentlich gar keine Eingaben haben.
Davon abgesehen, dass diese ganzen zusätzlichen Abfragen auf die Performance gehen (was wenigstens zum Glück bei der Website kein Thema ist), blähen sie auch meinen Code auf, und machen ihn immer unübersichtlicher. Dazu kommt, dass ich gleiche oder ähnliche Codefragmente in mehreren Dateien nutzen muss, was die ganze Sache kaum noch wartbar macht. Nein – das Zeug lässt sich mit vernünftigem Aufwand auch nicht refaktorieren. Soweit möglich arbeite ich bereits mit Inklusion.
In einem Script baue ich auf Grundlage einer XML-Datei dynamisch ein assoziatives Array auf. Ich kann es ja verstehen, wenn man vor dem Lesen einer Variablen erst noch überprüfen muss, ob die Variable überhaupt da ist. Aber bei meinem Code ging es darum, neue Arrayelemente hinzuzufügen. Freilich gibt es den Key vorher noch nicht, weil ich den ja erst noch zur Laufzeit anlege. Jetzt musste ich das so ändern, dass aus einer vorher ausreichenden Zeile Code (gerade diese kompakte Syntax hatte ich immer für eine der wenigen Stärken von PHP gehalten) mehrere werden, weil ich jedesmal erst abfragen muss, ob das Array-Element bereits vorhanden ist, und falls nicht, es auf andere Weise hinzufügen. Die ganze Eleganz des Algorithmus‚ geht dadurch verloren.
Verkompliziert war das Ganze noch dadurch, dass ich aus historischen Gründen immer noch viele Server Side Includes habe, und das passt überhaupt nicht mit den PHP-Änderungen zusammen.

Fast drei Tage (mit ein paar unerlässlichen Unterbrechungen) war ich drüber, bis die Website wieder wie gewohnt funktionierte. Dabei kann ich noch nicht einmal ausschließen, dass bei einzelnen Seiten oder Queryparametern doch noch Probleme bestehen.
Nur um mal eine Größenordnung zu nennen: Ich habe dabei rund vierzig Dateien editiert und verändert. Die identischen php.ini-Dateien, die mehrfach vorkommen, sind da gar nicht mitgezählt. Auf meine Versionsverhaltung musste ich auch ein paar Mal zurückgreifen, als einzelne Dateien bei den Änderungen verhunzt worden waren.

Schei?-PHP! Was geht nur in den Entwicklern vor, die einfache Skript-Schreiber derart drangsalieren? Die so einen Blödsinn verzapfen, so dass man etliche Stunden braucht, eine gar nicht mal so umfangreiche Website wieder auf den aktuellen Stand zu bringen? Rückwärtskompatibilität – wo bist du geblieben?

Ich fürchte, im Laufe der Zeit ist ein ziemliches Flickwerk aus meiner Website geworden, bedingt auch durch die Kombination von PHP und SSI. Eigentlich wäre ein sauberes Neuaufsetzen geboten. Da ich die Website allerdings nur noch nebenbei nutze, und nicht mehr auf meine Selbständigkeit angewiesen bin, wird sie so bleiben müssen – wenigstens bis Ende 2024 das nächste PHP-Update unumgänglich sein wird.

*Fußnote:
Gegeben sei eine URL mit Querystring, also so etwas wie http­://example.com/index.php?key1=value1&key2=value2
Der Querystring ist dabei alles ab dem Fragezeichen, und besteht aus Schlüssel-Wert-Paaren, die durch Ampersands voneinander abgetrennt sind. Damit können sehr einfach Daten zwischen Browser und Webserver ausgetaucht werden.
Als ich irgendwann mit PHP angefangen habe, ließ sich über (o.B.d.A.) $key1 ganz einfach der Wert value1 abfragen.
Nach irgendeinem Update ging das nicht mehr. Den Wert von key1 erhielt man jetzt über $_GET[‚key1‘], was – wie man sieht – deutlich aufwändiger ist, mehr Zeichen benötigt, und insbesondere auch Sonderzeichen, die wesentlich länger zum Tippen brauchen. Das summiert sich schnell bei einem längeren Script, und ist auch anfälliger für Tippfehler.
Jetzt reicht auch dieses Vorgehen nicht mehr aus, denn key1 könnte ja gar nicht vorhanden sein, was früher nie ein Problem war, dann war es halt leer.
Ich muss also erst noch abfragen, ob es vorhanden ist, und falls nicht, selbst einen (Default-)Wert zuweisen. Das ist so lästig, und da so viel umständlicher auch schwerer überschaubar und somit fehleranfälliger.

Werbung

Über Anne Nühm (breakpoint)

Die Programmierschlampe.
Dieser Beitrag wurde unter Uncategorized abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

4 Antworten zu Wieder Ärger mit PHP //2675

  1. Plietsche Jung schreibt:

    Schrecklich.
    Ich hätte die Seite neu aufgesetzt, ein neues responsive Design für die ganzen Smartphone Jünger und dann auf das realisiert, was unbedingt sein muss.
    Das geht wahrscheinlich schneller, hat ein frisches Design und sieht moderner aus.

    Gefällt 1 Person

  2. Leser schreibt:

    PHP ist nervig, das kenne ich auch.
    Aber einmal hat es mir auch einen Witz erzählt – der verständlich ist, wenn man nebenbei auch Sprachen mag (keine Programmiersprachen):
    Auf der Website einer Hebamme ging nach einem PHP-Update das Kontaktformular nicht mehr.
    Stellte sich heraus, dass die Funktion zum prüfen, ob die E-Mail-Adresse korrekt ist, ihren Namen geändert hatte: Von ereg() zu preg(). Auf der Website einer Hebamme!
    Das hatte mir damals meinen tristen Arbeitstag versüßt… 😉

    Gefällt 1 Person

  3. Pingback: Tweets Numero m+5 //2778 | breakpoint

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s