Von wegen tot: So wurde PHP ultra schnell!

[U-Labs YouTube]

Antwort von @Ole-vu9yj:
@Kmonki In meiner Software habe ich keine Frameworks genutzt. Es ging eher darum ein längere Zeit nicht aktualisiertes z.B. Nextcloud auf den aktuellen Stand zu bringen. Da hat man halt relativ enge Versionsfenster.

[U-Labs YouTube]

Antwort von @Kmonki:
@Ole-vu9yj ach du meinst das du Anwendungen benutzt hast die in PHP geschrieben wurden... Ich dachte du hast selbst PHP geschrieben

[U-Labs YouTube]

Antwort von @Kmonki:
Wenn zB Nextcloud einen PHP Befehl benutzt der bei PHP 8.* Funktioniert aber in PHP 7.* Noch nicht vorhanden war, funktioniert nichts mehr, aber wenn du PHP 8.* auf deinem Server hast und Code mit PHP 1.0 ausführen willst ist das kein Problem... Am Ende sind die Updates des Programms das Problem


Aber wenn dich das so stört, schreib einfach selbst ein Nextcloud... So viel gehört ja nicht dazu, musst dir ein bisschen Zeit einplanen

[DMW007]

Hier wird verschiedenes in einen Topf geworfen, was so nicht stimmen kann. Erst ist von selbst geschrienem Code die Rede, der angeblich nach Monaten geändert werden musste. Bei der Nachfrage werden plötzlich Wordpress & Nextcloud daraus, also ein ganz anderes Thema. PHP hatte früher öfter nicht abwärtskompatible Änderungen. Alle paar Monate war selbst damals weitaus übertrieben, es war in anderen Dimensionen ein Thema. Das traf allerdings nur bis 5.x zu und ist schon sehr lange veraltet. Bei PHP 7 gab es letztmalig einen größeren Bruch. Dort wurden Funktionen wie mysql_* entfernt, die seit Jahren als veraltet markiert worden sind. Selbst da waren gerade die mysql-Funktionen bereits schlechte Praxis, weil z.B. Prepared Statements fehlten.

Wenn du dir anschaust, was in den Minor-Versionen von z.B. 8.x nicht mehr abwärtskompatibel ist, wird die Liste sehr überschaubar. Teilweise wurden auch dort unsaubere Konstrukte vereinheitlicht oder abgeschafft. Je nachdem was man wie nutzt, kann es bei einer Minor-Version kleinere Anpassungen geben. Die halten sich seit 7.x in Grenzen. Bei 8.x erschien jedes Jahr eine und jede wird 4 Jahre unterstützt. Wer 2022 PHP 8.2 Code geschrieben hat, bekommt noch bis Ende 2026 Sicherheitsupdates. Der kann sich also 4 Jahre Zeit lassen, um die Hand voll Änderungen auf den Nachfolger nachzuziehen. Oder direkt auf 8.5, trotz mehrerer Versionen dazwischen gibt es nur wenig nicht abwärtskompatible Änderungen.

Externe Anwendungen sind eine völlig andere Baustelle. Die können frei entscheiden, was sie wie lange unterstützen. Sowohl hinsichtlich der geforderten PHP-Version als Grundlage, als auch selbst geschaffene Befehle/Funktionen. Bei Nextcloud z.B. gibt es in der Tat OCC-Befehle, die entfernt wurden. Kann man doof finden, hat allerdings wenig mit PHP zu tun.

Das Problem dürfte im Vernachlässigen liegen. Anwendungen erfordern ein gewisses Maß an regelmäßiger Pflege, schon aus Sicherheitsgründen. Wird sich darum nicht gekümmert, ist der Aufwand um so größer. Gleiches Thema wie mit dem Haushalt: Kümmere dich einige Wochen um nix. Der Stau ist nicht mit 20 Minuten durch saugen erledigt. Sondern weitaus höher, als wie wenn man jede Woche aufräumt.

Eine gewisse Abwärtskompatibilität ist notwendig. Schließlich will niemand tatsächlich alle paar Monate die halbe Codebasis neu schreiben. Wenn ich aber Wordpress von 2003 im Jahr 2026 lese, scheint mir das eine unrealistische Erwartungshaltung zu sein. 23 Jahre sind eine lange Zeit in der IT. Insbesondere bei PHP. Das wurde 1995 mit ganz anderen Anforderungen entwickelt. Gerade deswegen war lange Zeit einer der größten Kritikpunkte an PHP die daraus entstandene mangelnde Konsistenz. Das kannst du nur mit einem Bruch besser machen. Den haben sie mit PHP 7 nach längerem zögern gewagt. Die Schattenseite davon ist, dass nachdem PHP aufräumt auch die Nutzer/Entwickler nachziehen müssen. Ähnlich wie bei Python von V2 auf V3, was Ewigkeiten dauerte.

Ich betreibe seit zig Jahren alle von dir genannten PHP-Anwendungen, habe diese teils erweitert (z.B. eigene WordPress Plugins/Widgets). Und unabhängig davon komplett eigenständige Anwendungen (z.B. U-News) entwickelt. Sicherlich lief im Detail mal was schief, z.B. hat der NC News Cronjob keine Feeds mehr abgefragt. Das kommt zu einem gewissen Grad überall mal vor, wobei wir hier von Drittanbieter-Anwendungen sprechen, also eben nicht PHP direkt. Bei PHP sehe ich den gemachten Schritt überfällig. Früher gab es aus historischen Gründen weitaus mehr Chaos, heute ist PHP professioneller & stabiler geworden. Eine ähnliche Transformation hat .NET (Core) hinter sich. Anfangs ein großes Durcheinander, in dem vieles gefehlt hat & Dinge ausprobiert wurden. Mittlerweile ebenfalls deutlich reifer.

Mit Java kann man sich anschauen, welche Konsequenzen extrem lange Unterstützungszeiträume haben. Java 8 LTS erschien 2014 und wird bis 2030 gepflegt, satte 16 Jahre. Das sorgt bei Entwicklern für Frust, weil die als Preis dafür auf dem Niveau von 2014 entwickeln müssen. Und das bei Java, einer Sprache, die C# lange Zeit hinterher hinkte. Aufgeblähter Code, schlechtere Effizienz und weitere Nachteile sind die Folge. Updates gibt es ja nicht, um alle zu ärgern. Sondern um Dinge besser zu machen. Meiner Erfahrung mit Java ist das nicht der bessere weg. Zumal auch hier gilt: Das betrifft lediglich die Sprache mit ihrem Standard-Framework. Dass die Anwendung selbst viel ändert, ältere Funktionen schnell abkündigt etc. kann dort ebenfalls passieren.

[U-Labs YouTube]

Antwort von @danielbaerchen:
Es ist Sache der Anwendung bzw. Client die PHP Ausgabe zu verarbeiten, kann html sein, aber auch xml, ein BIld, eine binäre Datei, kann auch garkeit Ausgabe sein und nur Verarbeitung vom Prozess. Im Video hastest kein HTML sondern Klartext.

[U-Labs YouTube]

Antwort von @Kmonki:
Der Client kann mit PHP nichts anfangen, PHP wir immer vom Server verarbeitet

[DMW007]

Das ist technisch im Detail falsch, weil der Client überhaupt nicht mit PHP in Berührung kommt. Wie im Beitrag erwähnt, kommuniziert der Client mit dem Webserver. PHP wird vom Webserver aufgerufen, der leitet die Antwort an den Client weiter. Das gilt analog für andere serverseitige Technologien. Der Webserver könnte auch z.B. einen Python-Interpreter aufrufen, oder was ganz anderes.

Korrekt ist, dass der Client diese Ausgabe verarbeiten muss. Kann prinzipiell auch was anderes sein. Über HTTP-Header teilt der Client dem Webserver mit, was er akzeptiert. Und der Webserver antwortet mit einem Mime-Type, etwa text/html. Deine Spitzfindigkeit zwischen Klartext und HTML zu unterscheiden interessiert HTTP nicht, weil beides identisch ausgeliefert wird. Und fürs Verständnis an dieser Stelle irrelevant ist. Eben so wie binäre Dateien, zu denen übrigens auch Bilder gehören.