[Erledigt] Umstiegt von PHP 4 auf PHP 5 - Was beachten?

[Captain Ahab]

Hallo PHP.de-Gemeinde,

Domainfactory stellt die Server auf PHP 5 um. Vorher war alles noch auf PHP 4. Auch wenn eigentlich immer Zukunftsorientiert programmiert wurde, befürchte ich, dass es Komplikationen geben kann, vor allem bei älteren Scripten.

Nun ist meine Frage, wo sind die größten Umstiegsprobleme bzw. wonach sollte ich vor dem Wechsel noch schauen?

Viele Grüße
Captain Ahab

[cycap]

Ein herzliches Willkommen hier im Forum.

Ich hatte mal ein Problem mit Typo3 bei der umstellung auf PHP5. Und zwar war dort in einer Klasse (oder war es doch nur eine Funktionssammlung?) ein Funktionsparameter names $this. PHP4 ist damit klargekommen, PHP5 aber nicht. Hab die variable umbenannt und das Problem war gelöst.

Ansonsten hoffe ich das du register_globals sowieso nicht nutzt. Weitere Probleme gabs bei mir mit der Umstellung nicht.

[Captain Ahab]

Nein, Register_Globals nutze ich nicht, die wurden aber sowieso schon vor längerem deaktiviert.

Und Typo3 nutze ich auch nirgendwo im Produktivsystem.

[nikosch]

Ein paar neue reservierte Wörter können natürlich ebenfalls Probleme bereiten. Z.B. 'Exception' oder 'Interface'...

[cycap]

Jo da hat du recht, aber wer hat schon im Kopf welche Wörter man benutzt hat? Da hilft wohl nur testen und wenn das zu kritisch ist muss man halt wirklich den gesamten Code durchlesen, bzw. jede Menge Begriffe ins Strg+F hauen.

Oder man holt sich schnell ein XAMMP mit PHP5 und testet darauf, sofern möglich.

[nikosch]

Letzteres.

[Captain Ahab]

Oder man holt sich schnell ein XAMMP mit PHP5 und testet darauf, sofern möglich.

Hmm, ich denke bei der großen Anzahl von Projekten, die auf unseren Servern liegen wird das wohl nicht in Frage kommen.

Da setze ich einfach mal darauf, dass es alles gut gehen wird, und wenn dann ein Script nicht läuft, weiß ich ja in etwa wonach ich schaun muss.

Vielen Dank soweit.

[Chriz]

Pruef doch ganz einfach nach, ob register_globals aktiviert ist, wenn ja musst du die Skripte aktualisieren oder register_globals einfach wieder aktivieren (tja was solls).
Ob ihr zukunftsorientiert programmiert habt, seht ihr daran, ob neue Projekte nach 2002 nicht mehr auf register_globals gesetzt haben und ob das Error-Reporting auch damals schon hochgeschraubt war. Wenn nicht wars Schlamperei/Nachlaessigkeit.

Ansonsten kannst du natuerlich deine Skripte lokal auf einem XAMPP testen (hat mit groesse ja nichts zu tun, einfach DB umstellen, kopieren, VHost anwerfen, fertig), den Switch fuer PHP 4 gibts ja auch. Warten und hoffen ist dumm.

[cycap]

Pruef doch ganz einfach nach, ob register_globals aktiviert ist, wenn ja musst du die Skripte aktualisieren oder register_globals einfach wieder aktivieren (tja was solls).
Ob ihr zukunftsorientiert programmiert habt, seht ihr daran, ob neue Projekte nach 2002 nicht mehr auf register_globals setzt

Nein, Register_Globals nutze ich nicht, die wurden aber sowieso schon vor längerem deaktiviert.

Ansonsten kannst du natuerlich deine Skripte lokal auf einem XAMPP testen (hat mit groesse ja nichts zu tun, einfach DB umstellen, kopieren, VHost anwerfen, fertig), den Switch fuer PHP 4 gibts ja auch. Warten und hoffen ist dumm.

Oder man holt sich schnell ein XAMMP mit PHP5 und testet darauf, sofern möglich.

Hmm, ich denke bei der großen Anzahl von Projekten, die auf unseren Servern liegen wird das wohl nicht in Frage kommen.

[Chriz]

Ah register_globals hab ich ueberlesen, aber das mit dem XAMPP nicht - warum sollte ein groesseres Projekt nicht lokal testbar sein? Der Online-Server ist auch nur ein Apache; kocht sozusagen auch nur mit Wasser Das Argument wird doch nur benutzt, wenn man nicht weiss wie man das macht, und da sagte ich ja schon: DB umstellen, kopieren, Virtual Host, falls noetig.

[cycap]

Ah register_globals hab ich ueberlesen, aber das mit dem XAMPP nicht - warum sollte ein groesseres Projekt nicht lokal testbar sein? Der Online-Server ist auch nur ein Apache; kocht sozusagen auch nur mit Wasser Das Argument wird doch nur benutzt, wenn man nicht weiss wie man das macht, und da sagte ich ja schon: DB umstellen, kopieren, Virtual Host, falls noetig.

Naja mir würden einige Gründe einfallen, aber wenn ich meinen Webspace bei irgendeinem Webspace-Hoster hätte, dann gäbe es wirklich keinen Grund. Ich nutze einige shell-scripte etc. aber das fällt ja bei nem Webspace-Hoster weg.

[Chriz]

Was fuer Shell-Skripte benutzt du denn?

Ausserdem soll ja nur geschaut werden, was fuer grundsaetzliche Probleme auftreten. Die Website und ein paar Unterseiten testen reicht ja vielleicht schon.

[Captain Ahab]

Shell Skripte nutzen wir im PHP Bereich nicht, aber das Problem ist, dass es nicht nur ein paar Unterseiten sind, sondern rund 200 Projekte auf verschiedenen Domains und Servern.

Ich denke da wird es vom Kosten- / Nutzenfaktor schlauer sein abzuwarten und die eventuell auftretenden Probleme dann zu beheben als vorher schon Tage / Wochen zu investieren "auf blauen Dunst".

[cycap]

Shell Skripte nutzen wir im PHP Bereich nicht, aber das Problem ist, dass es nicht nur ein paar Unterseiten sind, sondern rund 200 Projekte auf verschiedenen Domains und Servern.

Ich denke da wird es vom Kosten- / Nutzenfaktor schlauer sein abzuwarten und die eventuell auftretenden Probleme dann zu beheben als vorher schon Tage / Wochen zu investieren "auf blauen Dunst".

Naja nen MySQL Dump und ne Kopie via FTP auf den localhost zu schmeissen und da dann zu testen sollte doch nicht lange dauern oder? Wie entwickelt ihr denn sonst? Auf den produktivsystemen?

[nikosch]

Vielleicht (und ausdrücklich vielleicht!) könnte man ja auch davon ausgehen, dass bei 200 Projekten ein Großteil auf dem gleichen Grundsystem aufsetzt (z.B. einem Framework, einem entwickelten CMS). Dann macht Testen dieser Komponenten schon Sinn. Bevor 150 Seiten plötzlich Fehler werfen, weil zufällig eine Basisklasse wie ein reserviertes Wort benannt ist...