Mein Provider stellt auf PHP 5 um! WAS NUN?

Einklappen
Dieses Thema ist geschlossen.
X
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Mein Provider stellt auf PHP 5 um! WAS NUN?

    EDIT:
    fragen und diskussionen zu dem sticky können HIER geklärt werden.

    technische fragen zur umstellung auf PHP5, welche nicht in diesem sticky behandelt werden, können durch das erstellen einen neuen threads, hier im php-forum, geklärt werden. bitte wählt beim erstellen des threads PHP5 beim dropdown im betreff aus.

    und nun viel spass mit pekka ausführungen......

    by Abraxax (extended edit by TobiaZ)




    Mein Provider stellt auf PHP 5 um! Wird meine Site danach weiterlaufen? Was muß ich beachten?

    Als Allererstes: Keine Panik. Die Entwickler waren sich der Tatsache bewußt, daß die eine oder andere Site mit PHP betrieben wird und sind entsprechend Maßvoll mit gravierenden Änderungen umgegangen. Für die meisten Skripte dürften sich keine oder nur minimale Umstellungen ergeben.
    Es gibt jedoch einige syntaktische Änderungen, derer man sich bewußt sein sollte.

    Die "Ruhig schlafen"-Workarounds sind Vorschläge und vor allem für die armen Admins gedacht, die dafür sorgen müssen, daß irgendwelche 30.000-Zeilen-Monster, die von einem inzwischen nicht mehr erreichbaren Programmierer (Auf die Malediven ausgewandert; Im Knast; Auf der Strasse) erstellt wurden, weiterlaufen. Die meisten dieser Vorschläge sind keine Beispiele für sauberen Programmierstil. Es versteht sich von selbst, daß man solche Änderungen nicht in einer live-Umgebung durchführt und daß man davor Backups der Quelltexte zieht. Optimal sind natürlich umfangreiche Tests in einer nicht öffentlichen PHP-5-Umgebung.



    strrpos() and strripos() now use the entire string as a needle.
    Die Funktion strrpos (strripos gibt es erst seit PHP 5) suchte bisher nach dem letzten Vorkommen eines einzelnen Zeichens ("needle") in einem String ("haystack"). Wurde mehr als ein Zeichen als needle übergeben, wurde nur dessen erstes Zeichen verwendet, der Rest wurde einfach ignoriert. Seit PHP 5 wird nun die komplette Zeichenkette als needle verwendet.

    Mögliche Probleme: Fehlfunktionen könnte dies in altem Code verursachen, wenn aus Bequemlichkeit eine längere Zeichenkette als needle übergeben wurde (z.B. ":xyz", obwohl nur ":" relevant war).

    Ruhig schlafen: Skripte nach der Verwendung von strrpos() durchsuchen und prüfen, ob irgendwo als needle Variablen unklaren Inhalts durchrutschen könnten, die jetzt in PHP 5 in ihrer Gänze interpretiert werden. Sollten sich solche Konstellationen finden, beschneidet man die needle-Variable, beispielsweise mit substr($needle, 0,1).

    Illegal use of string offsets causes E_ERROR instead of E_WARNING.
    [COLOR=orangered](Mir ist nicht gelungen, einen "illegal use of string offsets" hinzukriegen, auch nicht mit $string[-1] oder $string[99999999999], deshalb weiß ich auch nix zu möglichen Problemen zu sagen. Weiß da jemand mehr?)[/COLOR]

    array_merge() was changed to accept only arrays. If a non-array variable is passed, a E_WARNING will be thrown for every such parameter. Be careful because your code may start emitting E_WARNING out of the blue.
    Wenn zwei Arrays mit array_merge() zu einem zusammengefügt wurden, machte es bisher nichts aus, wenn einer der Parameter kein Array war. Dies erzeugt jetzt eine Warnmeldung für jedes Nicht-Array-Element.

    Mögliche Probleme: Unerwünschte Warnmeldungen. Können header()-Ausgaben stören und sehen im Live-Betrieb ziemlich scheisse aus.

    Ruhig schlafen: Skripte nach Verwendung von array_merge() durchsuchen, alle dort übergebenen Parameter mit is_array() auf ihren Datentyp hin untersuchen und nur echte Arrays als Parameter für array_merge() weitergeben.


    The T_ML_CONSTANT constant is no longer defined by the Tokenizer extension. If error_reporting is set to E_ALL, PHP will generate a notice. Although the T_ML_CONSTANT was never used at all, it was defined in PHP 4. In both PHP 4 and PHP 5 // and /* */ are resolved as the T_COMMENT constant. However the PHPDoc style comments /** */ ,which starting PHP 5 are parsed by PHP, are recognized as T_DOC_COMMENT.
    [COLOR=orangered](Mit Tokenizer hab ich noch nie groß zu tun gehabt. Könnte hier jemand mehr zu möglichen Konsequenzen sagen?)[/COLOR]


    $_SERVER should be populated with argc and argv if variables_order includes "S". If you have specifically configured your system to not create $_SERVER, then of course it shouldn't be there. The change was to always make argc and argv available in the CLI version regardless of the variables_order setting. As in, the CLI version will now always populate the global $argc and $argv variables.
    Nur Interessant für PHP auf der Kommandozeile, im Normalfall also bei GTK-Anwendungen und Cron-Jobs. $argc und $argv bezeichnen, falls PHP im Kommandozeilenmodus ausgeführt wird, die Anzahl und die Werte der beim Aufruf übergebenen Parameter. Je nach variables_order-Einstellung konnten bisher die globalen Variablen $argc und $argv, die eigentlich immer die Kommandozeilenparameter enthalten sollten, durch andere Datenquellen überschrieben werden. Dies ist nun nicht mehr der Fall, $argc und $argv enthalten immer die Daten aus der Kommandozeile.

    Mögliche Probleme: In Skripten, in denen die Globalen $argc und $argv in einem anderen Kontext als dem Auslesen von Kommandozeilenoptionen verwendet wurden, könnte zu Kollisionen kommen.

    Ruhig schlafen: Skripte nach Variablenzuweisungen an $argc und $argv durchsuchen. Variablen in etwas unverfänglicheres umbenennen.

    An object with no properties is no longer considered "empty".
    Ein Objekt ohne Eigenschaften (also enthaltene Funktionen oder Variablen) wird nicht mehr als leere Variable betrachtet, im Beispiel

    PHP-Code:
    class objekt_ohne_alles {}
    $obj_objekt_ohne_alles = new objekt_ohne_alles(); 
    gibt die Abfrage
    PHP-Code:
    if ($obj_objekt_ohne_alles
    nun also true, anstatt wie bisher false, zurück.

    Mögliche Probleme: [COLOR=orangered]Mir fallen keine denkbaren Situationen ein, bei denen man gegen ein leeres Objekt vergleichen müsste, wenn man bei der Erstellung nicht total high war. Euch?[/COLOR]

    Ruhig schlafen: Siehe oben.

    In some cases classes must be declared before used. It only happens only if some of the new features of PHP 5 are used. Otherwise the behaviour is the old.
    Ignoriert, weil nur im Zusammenhang mit den neuen Features relevant

    get_class() starting PHP 5 returns the name of the class as it was declared which may lead to problems in older scripts that rely on the previous behaviour (the class name was lowercased). A possible solution is to search for get_class() in all your scripts and use strtolower().
    Die Funktion get_class() gibt jetzt exakt den definierten Namen der Klasse mit korrekter Groß-/Kleinschreibung zurück und nicht, wie bisher, eine kleinbuchstabige Variante.

    Mögliche Probleme: In Skripten, die die Ergebnisse von get_class()-Aufrufen mit im Code definierten Strings vergleichen, können die Vergleiche andere Ergebnisse liefern als bisher.

    Ruhig schlafen: Wie die offizielle Empfehlung schon sagt: Skripte nach get_class()-Aufrufen durchsuchen und durch strtolower(get_class()) ersetzen.

    ip2long() now returns FALSE when an invalid IP address is passed as argument to the function, and no longer -1.
    Die Funktion ip2long(), die eine sauber formulierte IP-Adresse in eine Zahl vom Typ LONG übersetzt, gibt bei einer ungültigen übergebenen IP-Adresse (etwa 999.122.55.33 oder 123.bbb.456.78) jetzt false statt -1 zurück.

    Mögliche Probleme: Das Abfangen von ungültigen IP-Adressen wird gestört, weil dies mit der bisher gültigen Methode (if ip2long() == -1) nicht mehr funktioniert. Mit unkalkulierbaren Folgen, weil ungültige Angaben durch die Prüfung rutschen und die weitere Verarbeitung beeinflussen könnten.

    Ruhig schlafen: Skripte nach eventuellen ip2long()-Aufrufen durchsuchen. Die Zeilen hinter gefundenen Aufrufen nach Abfangmechanismen mit Überprüfung auf -1 ($ergebnis = ip2long($variable); if ($ergebis == -1).....) durchsuchen und -1 durch false ersetzen.



    Neue reservierte Begriffe

    Mit den neuen Objektfunktionen von PHP 5 halten auch neue reservierte Begriffe Einzug. Klassen- und Funktionsnamen dürfen dann nicht mehr identisch mit diesen Begriffen sein.

    Mögliche Probleme: Syntaxfehler und Abbrüche in Skripten, die Klassen oder Funktionen enthalten, deren Namen mit diesen Begriffen identisch sind.

    Ruhig schlafen: Skripte nach solchen Klassen- und Funktionsnamen durchsuchen. Entsprechende Kandidaten umbenennen, etwa die Klasse "abstract" in "class_abstract". Diese Umbenennung muß natürlich in allen folgenden Instanzierungen und Aufrufen ebenfalls erfolgen.

    Die neuen reservierten Begriffe:
    public
    protected
    private
    final
    interface
    implements
    abstract
    Zuletzt geändert von TobiaZ; 08.08.2004, 22:33.

  • #2
    Teil 2 wegen 10.000-Zeichen-Grenze

    Mögliche (neue) serverseitige Problemquellen

    mail.force_extra_parameters in der php.ini

    Außerhalb des PHP Safe mode besteht beim mail()-Befehl die Möglichkeit, in einem fünften Parameter weitere Angaben direkt an das sendende Mail-Programm zu übergeben. Bei sendmail hilft beispielsweise ein "-f{email}" manchmal, Spam-Filter auf Empfängerseite zu umgehen. Seit PHP 5 gibt es nun in der php.ini die Möglichkeit, bei *jedem* Mail-Aufruf einen fünften Parameter zu erzwingen. Im Skript angegebene fünfte Parameter werden hierbei überschrieben und ignoriert.

    Mögliche Probleme: Bei Providern, die von dieser Einstellungsmöglichkeit aus welchen Gründen auch immer Gebrauch machen, könnten im Skript angegebene "fünfte Parameter" nicht mehr funktionieren.

    Ruhig schlafen: Bei Provider rückfragen, ob dieser Parameter verwendet wird bzw. via phpinfo() selber nachschauen. Falls ja: Skript nach mail()-Aufrufen und Parameter zählen. Falls der Fünfte verwendet wird, individuelles Workaround entwickeln.

    Neues Errorlevel E_STRICT

    Bei PHP 5 kommt ein neues Error-Reporting-Level hinzu: E_STRICT. E_STRICT ist dafür ausgelegt, Code auf seine Zukunftssicherheit zu überprüfen: So wird beispielsweise eine Meldung ausgegeben, wenn als veraltet deklarierte Notationen oder Funktionen verwendet werden. Ergo: In einer Produktionsumgebung hat E_STRICT nichts zu suchen; Es sei aber hier auf seine Existenz hingewiesen für den Fall, dass man einen übereifrigen IT-Administrator hat, der das einfach mal reingemacht hat - mit dem Ergebnis, daß man jetzt bei jedem 2. Skript mit mysteriösen Fehlermeldungen zu kämpfen hat.

    -------------------------------------------------------------------------------

    Dieser Text ist im Grunde eine erweiterte und kommentierte Version der offiziellen Übersicht (http://www.php.net/manual/de/migration5.php), von der auch die Zitate stammen .
    Wie in Diskussionsforen üblich, sind diese Hinweise nach bestem Wissen und Gewissen "as is" zusammengestellt. Es besteht kein Anspruch auf Vollständigkeit und Richtigkeit; Keine Haftung für aus der Umsetzung dieser Hinweise resultierende Probleme.

    Darüberhinaus ist Pekka nicht ab jetzt offizielle Anlaufstelle der PHP-Resource für Migrationsprobleme

    Zuletzt geändert von pekka; 04.08.2004, 21:50.

    Kommentar


    • #3
      Das ist jetzt der Vorschlag. Er ist nicht ganz vollständig, weil mir bei manchen Dingen nichts wirklich sinnvolles zu Sagen eingefallen ist. Bitte um Erweiterungsvorschläge + Hinweise was falsch ist oder vergessen wurde.

      Kommentar

      Lädt...
      X