…die gingen nicht ganz so reibungslos, wie ich das erhofft hatte.

Fangen wir mal vorne an…

Vor ein paar Tagen habe ich schon mal meine eigene Seite auf PHP 7.3 gebracht, was bisher immer ein guter Test das Forum war. Das hat auch ein paar Probleme gezeigt, beispielsweise dass die BBCode- und mailparse-Erweiterungen sich unter PHP 7.3 nicht compilieren lassen wollten.

Meine große Liebe zu PHP-Erweiterungen habe ich bereits mal erwähnt gehabt… vielleicht sogar mehrfach.
Ich brauche drei von der Sorte. Memcached, was zum Glück gepflegt wird. BBCode, seit Jahren schlecht gewartet. Mailparse, seit Jahren schlecht gewartet. Und mit "schlecht" meine ich "gar nicht".
Mailparse könnte ich los werden, das brauche ich "nur", um halbwegs nett zeigen zu können, dass beim Mailversand etwas schief gegangen ist - und was (den Inhalt der Fehlermeldung). Verzichtbar? Ja, aber…
BBCode ist unverzichbar, bis ich raus habe, wie ich das ersetzen kann, ohne Performance zu verlieren. Mein eigener Parser ist leider nur halb so schnell, und das ist eine der Stellen, bei denen Geschwindigkeit mal wichtig ist (die Funktion wird ein paar Millionen mal am Tag aufgerufen).

Aber das ließ sich lösen. BBCode habe ich selbst auf 7.3 gepatcht (danke, liebe PHP-Entwickler, für solche Beschreibungen:
Zitat:
„c. Protection from recursion during processing circular data structures was refactored.

HashTable.nApplyCount and IS_OBJ_APPLY_COUNT are replaced by single flag GC_PROTECTED. Corresponding macros Z_OBJ_APPLY_COUNT, Z_OBJ_INC_APPLY_COUNT, Z_OBJ_DEC_APPLY_COUNT, ZEND_HASH_GET_APPLY_COUNT, ZEND_HASH_INC_APPLY_COUNT, ZEND_HASH_DEC_APPLY_COUNT are replaced with GC_IS_RECURSIVE, GC_PROTECT_RECURSION, GC_UNPROTECT_RECURSION, Z_IS_RECURSIVE, Z_PROTECT_RECURSION, Z_UNPROTECT_RECURSION.”
Ich tu' das mal in meine persönliche Liste von miesen Namen).

Für Mailparse habe ich tatsächlich einen fertigen Patch im pecl-System gefunden (nur den Patch, nicht aber ein aktuelles Paket. Warum? Das weiß irgendjemand Anderes - vielleicht).

Aber nachdem das vorgestern abend erledigt war, lief meine Seite so wie sie sollte. Und das brachte mich gestern auf die tolle Idee, das Forum heute zu updaten.

Sollte ja alles glatt gehen - die PHP-Probleme sind bekannt und jetzt leicht lösbar, und das Datenbank-Update wird eine Kleinigkeit.

Richtig. *Die* PHP-Probleme waren schnell gelöst, und das Datenbankupdate war eine Freude (von der Kleinigkeit mal abgesehen, dass Postgres ein bisschen lange brauchte, um runter zu fahren, aber das hat nur ein paar Minuten gekostet, ist also insgesamt egal).

Und dann kam die Überraschung. Startseite aufgerufen, Fehlermeldung. Ein Datenbankfehler ist aufgetreten (an der Stelle mehr Informationen auszugeben verbietet sich, da könnten dann private Daten auf dem Bildschirm kommen - unwahrscheinlich, aber nicht auszuschließen).

Debug-Zeugs anzeigen. What the fuck? Wieso will das System am Samstag ein Bild der Woche wählen? Hat das System etwa alles vergessen, was seit Sonntag passiert ist?

Nein. Hat es nicht. Zum Glück. Obwohl ich Backups habe, ziehe ich es doch vor, die nicht zu brauchen.

Die Erklärung war eine Andere. In C war ich es gewohnt, time(NULL) oder auch time(0) zu schreiben - "liefere mir die Sekunden seit 1970, aber füll' mir keine uunötigen Daten in eine Struktur").

In PHP gibt es eine sehr ähnliche Funktion, nur dass die keinen Parameter erwartet. Aber bis PHP <7.3 hat sie irgendwelche Parameter einfach ignoriert. time(0) lieferte also die Sekunden seit 1970 - genau wie time(9999999) oder time(). Und das Gewohnheitstier in mir hat fleißig weiter time(0) geschrieben, ohne jemals darüber nachzudenken.

In 7.3 wurde das geändert. Seitdem liefert die Funktion einen leeren Wert und gibt eine Warnung aus ("time() expects exactly 0 parameters, 1 given in abc.php on line 9876").
Nun habe ich nichts gegen die Warnung, und auch wenig dagegen, dass sich das Verhalten ändert. Ich hab' da eine undokumentierte Eigenschaft der Funktion benutzt, und wer das tut, sollte sich nicht beschweren.

Aber es wäre schon schön, wenn solche Verhaltensänderungen dokumentiert würden. Das war sie nämlich nicht.

Und in den 24 Stunden, die meine Homepage mit praktisch derselben Software unter PHP 7.3 lief, ist dieser Fehler nicht einmal getriggert worden - wohl aber im Forum um die 250 mal in den 22 Minuten, die ich gebraucht habe, den Fehler zu beheben.

Seufz.

Sagte da jemand "PHP-Kompatibilitätsprüfung"? phan hat im Vorfeld nichts gefunden.
Und, nur am Rande bemerkt, ist phan unter 7.3 nicht installierbar, weil phar unter 7.3 nicht installierbar ist ("/tmp/pear/temp/phar/phar_internal.h:36:10: fatal error: zend_qsort.h: No such file or directory"). phpstan dürfte an demselben Problem scheitern.

Das ist irgendwo lächerlich.
Auch lächerlich: bugs.php.net ist fast immer down, wenn ich es brauche. Das ist fast wie Mozilla (der Bugtracker dort ist nicht so oft down, aber immer bereit, etwas wegzuwerfen, was ich schreibe - was auch nicht besser ist).


Falls noch jemand Probleme mit BBCode / mailparse unter PHP 7.3 hat:
Angehängt sind mein Patch für bbcode-2.0.1 (eine Überarbeitung vom pecl bbcode für PHP 7, von https://github.com/esminis/php_pecl_bbcode), und ein Patch für Mailparse, den ich auf bugs.php.net gefunden habe (vorgestern, als bugs.php.net mal nicht down war), und außerdem die Quellpakete.
Public Service oder so.

Gruß, Uwe