Forensoftware und PHP5

Im prinzip kannes ja jeder lokal selber testen!
http://www.apachefriends.org/de/xampp-windows.html
Dort die version mit php5.0.0 laden, installieren forum reinpacken, installieren und lostesten


mfg

Das halte ich für ein Gerücht, die meisten Hoster werden wie immer erstmal warten ob nicht noch ein Fehler drinsteckt, und da schon einer entdeckt wurden der für den normalen User zu Problemen führen kann, werden die meisten warten.

Einer meiner hat z.B. erstmal nur auf PHP 4.3.8 upgedatet.

Darüber hinaus gibt es bisher kaum Scripte für PHP5, und bis eine entsprechende Anzahl da ist, so dass die Benutzer nach PHP5 verlangen, dürfte noch einige Zeit vergehen.

WBB, WBB2, vB2, vB3 und phpBB2 setzen alle Klassen ein. Teilweise nur für den Zugriff auf die Datenbank (phpBB2 z.B. um eine einheitliche API für verschiedene Datenbanken zur Verfügung zu stellen), aber ein paar nutzen sie auch für andere Dinge (BBCode etc.).

Dennoch funktionieren diese Boards mit PHP5 zum größten Teil. Ich denke trotzdem es wird kein Drama. Ich persönlich benutze selber noch PHP4 aber ich werde es mal lokal testen wegen SQLite. Das gefällt mir nämlich sehr sehr gut.

Da gebe ich dir vollkommen Recht.

Das widerspricht sich doch? Die meisten User testen ihre Scripts auf dem Webspace, wieso sollten sie dann überhaupt Scripts basteln, die auf ihrem Webspace sowieso nicht laufen? Ich denke keiner bastelt Scripts, die er sowieso nicht testen kann (lokal mal ausgenommen), nur damit der Provider PHP 5 installiert.
Ich meiner eher, dass es umgekehrt laufen sollte. Die Webspaceanbieter installieren PHP 5, damit sie mehr Kunden bekommen (da die meisten User mangels der Anbieter noch keinen Zugang zu v5 haben) und ebendiese Kunden mit PHP 5 experimentieren können und schließlich Scripts basteln und Tutorials schreiben.

Und was die neuen OOP-Features angeht: Wieso sollte es da überhaupt groß Probleme geben? Konstruktoren funktionieren doch immer noch gleich und Methoden, Klassenvariablen haben sich doch auch nicht verändert. Einzig und allein die Zugriffsspezifier public, private und protected könnten Probleme verursachen, die man aber schnell beheben kann, da man meistens einfach nur ein Wort hinzufügen muss, nämlich public.


Ich persönlich habe mich eigentlich noch nicht mit PHP 5 beschäftigt, werde dies aber sicherlich demnächst tun.


Ich frage mich außerdem, wie man bei dem Funktionsboom von PHP überhaupt noch mithalten soll. Ich meine, wer kann schon behaupten, dass er PHP inklusive von dBase-, SQLite-, IMAP-, PDF- und XML-Funktionen (fast) vollständig beherrscht?
Ich jedenfalls nicht, auch wenn ich (mit ein wenig Stolz, aber ohne Arroganz) behaupten kann, dass ich nicht wenig beherrsche.
Ich wage auch zu behaupten, dass selbst die Entwickler des PHP-Teams nicht alles beherrschen (aber fast ).

Meine Idee wäre mal einen Codingcontest umzusetzen, um die wirklich besten PHP-Coder zu küren. Der Zend Coding Contest ist ja schon ein Schritt in diese Richtung.
Es wäre sicherlich mal interessant zu wissen, wie man selbst abschneidet.
Die Mitglieder des PHP-Teams müssten natürlich auch mitmachen.



Bis dann,

codethief

THWB hat bereits ein Update bekommen und ist nun PHP5 kompatibel

nächstes big realease folgt demnächst

Aber wenn das ThWb v5-kompatibel ist, dann ist es doch nicht mehr < PHP 5 kompatibel oder? Denn schließlich wurden dann doch neue Sachen implementiert...
Oder ist das nur ein "freiwilliges" Update, was sich jeder herunterladen und aufspielen kann, welches aber nicht in den kommenden Versionen enthalten ist (solange die Verwendung von PHP 5 seitens der User nicht steigt)?

Die meisten User benutzen Skripte, die sie nicht selbst geschrieben haben.
Und Du darfst die Bestandssoftware nicht vergessen. 99% der heute erhältlichen Skripte wurden auf Basis von PHP 4.x entwickelt. Viele, die nicht mehr aktiv entwickelt werden oder die der User nicht mehr updatet setzen auf PHP 4.1.x auf und benutzen damit potentiell die alte Methode, Parameter automatisch global zu definieren.

Hier sind alle Nicht-Rückwärtskompatiblen Änderngen aufgeführt (hoffe ich):

http://zend.com/manual/migration5.incompatible.php

Hinzu kommen eben noch die Sache mit den long_arrays ($HTTP_..._VARS) die man ja per ini-Befehl oder mit ein paar Zeilen Code wieder "reparieren" kann.

Das mit array_merge ist fies. Das war so schön praktisch...
Und die nicht-leeren Objekte werden auch einiges an Nacharbeit erfordern.

Und was machen Millionen von Webhosting-Kunden ohne eigenen Webserver? Jedenfalls keine Änderungen an der php.ini

Wer noch die $HTTP_..._VARS benutzt kann sie ja recht leicht wiederherstellen.
Ansonsten finde ich die Änderungen durchaus ok.
Von array_merge würde ich kein anderes Verhalten erwarten, als Arrays zu verbinden. Einen String kann man auch mit $array[] = $str; hinzufügen.
Das ein Objekt ohne Properties leer sein soll/war tut mich wunder. Ein Objekt ist ein Objekt, auch wenn's nichts machen kann und nichts aussagt.

Ich würde sagen, dass irgendwelche Workarounds verwendet wurden, um die Wirkung von (z.B.) strrpos sowohl unter 4.x als auch unter 5.0 gleich zu bekommen.

Hallo,

ich habe interessehalber mal bei all-inkl.com bzgl. PHP 5 Nachgefragt, die Antwort:

Ich werde mich demnächst mal mit PHP 5 beschäftigen, und meine Scripte, soweit es möglich ist, so programmieren, dass sie auch zu PHP 5 kompatibel sind

(Die Antwort von all-inkl.com kam übrigens innerhalb einer Minute)

@macs: Danke dir. Hast mir den Tag gerettet.
(Mail an all-inkl.com schicken geh)