Shopsystem von PHP4 auf PHP5

A

amadeus

New Member
Ich habe ein extrem nerviges Problem:

Bei der Migration eines Shopsystem von meinem alten (PHP4) auf meinen neuen Server (PHP5) kommt es zu unzähligen Fehlermeldungen folgender Art:

*undefinded index
*undefined variable
*undefined offset

Ihh weiß mittlerweile glaube ich längst wo der Fehler begraben liegt:

Bei PHP5 muss wohl immer erst explizit geprüft werden, ob eine bestimmte Variable gesetzt ist (isset) bevor man die Variable, das Array, oder das Objekt anspricht. Das Problem ist nur, dass dieses Shopsystem eingekauft ist (ca. 6 Jahre alt) und aus unzähligen includes besteht, in denen ich mich natürlich nicht wie im Schlaf auskenne... leider handelt es sich zudem noch um eine Firma die es nicht mehr gibt (da von Adobe aufgekauft) und deren Support ich daher nicht mehr erreiche...

Für die Migration aller anderen Domains (auch älterer Websites) die ich sonst noch migriert habe, haben folgende Einstellungen in der vhost.conf vollkommen ausgereicht:

*register_long_arrays on
* register_globals on

nur bei diesem Shop reicht es wohl einfach nicht :( Gibt es

Die Sache ist die, dass ich momentan einen (nicht ganz billigen) Server am Laufen halte - nur wegen dieser Domain... *GRRRR

Da es in ca. 1/2 Jahr ohnehin ein neues Shopsystem geben soll, frage ich mich, ob es nicht doch noch irgendwelche Apache-Direktiven oder andere "globale" Lösungen gibt, die ich explizit für diese Domain verwenden kann, um sozusagen eine Umgebung zu erzeugen, die noch näher an PHP4 dran ist...

Ich bin mehr als dankbar für JEDE Hilfe....
 
Erst mal SUPERvielen Dank für die schnelle Rekation!

Aber lässt sich das Problem damit denn dann auch sicher aus der Welt schaffen? Damit meine ich, dass es ja nicht nur darum geht, dass keine Fehlermeldungen mehr angezeigt werden sollen - leider es gibt ja auch Fehler seitdem das System auf PHP5 läuft (z.B. wenn der checkout-Prozess eingeleitet wird)... ich dachte bisher es läge an undefinierten Variablen die in PHP5 eingach anders behandelt werden als in PHP5

BSP: Unter PHP 4 wird

if ($_GET['id'] =="") meines wissens nach auch dann als true zurückgegeben wenn die Variable gar nicht gesetzt ist...

unter PHP5 kommt aber eben "undefined index" und das Skript arbeitet demnach dann auch nicht korrekt weiter...

oder?
 
if ($_GET['id'] =="")
Click to expand...
Eine undeklarierte Variabe ist in allen mir bekannten Skriptingsprachen NULL wenn sie nicht existiert.
Da NULL aber in PHP solange du nicht mit "===" den identischen Typ erzwingst aber mit einem leeren String vergleichbar ist funktioniert es.

Die Fehlermeldung konntest du auch schon in PHP4 zeigen, sie war nur wahrscheinlich deaktiviert.
Deaktivieren kannst du sie unter PHP5.3 mit folgendem error_reporting Eintrag:
E_ALL & ~E_NOTICE
Ab PHP 5.3 solltest du zusaetzlich:
E_ALL & ~E_NOTICE & ~E_DEPRECATED
 
An Deiner Stelle würde ich erstmal, wie oben schon erwähnt, die E_NOTICE im error_reporting ausstellen:
Benachrichtigungen während der Laufzeit. Sie zeigen an, dass im Skript irgend etwas gefunden wurde, was einen Fehler verursachen könnte. Es ist aber genauso möglich, dass Benachrichtigungen im ordnungsgemäßen Ablauf eines Skripts ausgegeben werden.
Click to expand...

PHP: 
// Melde alle Fehler außer E_NOTICE
// Dies ist der Vorgabewert in php.ini
error_reporting(E_ALL ^ E_NOTICE);

Anschließend den Shop ausgiebig testen und Fehler bereinigen.

Problematisch ist natürlich der Sicherheitsfaktor, da Du register_globals wieder angeschaltet hast und Du ein (vermutlich) offenes Shop-System nutzt. Aber das war ja auch vorher schon problematisch.

Du kannst per Apache tatsächlich auch eigene php.ini-Konfigurationen für einzelne Webs anlegen. Das geht z.B. mit suPHP, was eh eine sinnvolle Installation für Dich wäre:
http://www.suphp.org/DocumentationView.html?file=apache/CONFIG

Beispiel Virtual Host mit suPHP:
Code: 
<VirtualHost xx.xxx.xxx.xx:80>
  ServerName web9.domain.de
  DocumentRoot /var/www/web9/html
  SuexecUserGroup web9 web9
  suPHP_ConfigPath /etc/apache2/custom_phpini/web9
  suPHP_UserGroup web9 web9
<Directory /var/www/web9/html>
Options Indexes
</Directory>
</VirtualHost>
 
Was spricht dagegen, das "alte" PHP4 in einem jailed/chrooted System und als CGI zu verwenden?
Dann könntest du deinen Shop weiter laufen lassen.

Ich denke, die Sicherheitsbedenken gegenüber einer lässig-bis-schlampig programmierten Shopsoftware sind höher zu bewerten als das veraltete PHP.
Ich bin sicher, in dem Shop werden sich einige SQL-Injections und XSS-Lücken finden lassen, wenn man jemand wirklich danach suchen lässt.
 
Vielen Dank für Eure Mühen und für Eure hilfreichen Tipps. Das error_reporting auf E_ALL zu stellen hat auf jeden Fall schon mal bewirkt, dass die Seite "schöner" aussieht ;) Allerdings haben sich die Probleme im Kern (wie ich mir schon dachte) nicht beheben lassen...

Langsam komme ich aber auf die Idee, dass vielleicht auch bei der Plesk-Migration von einem auf den anderen Server etwas schief gegangen sein könnte... weil irgendwo kann da im Innern des Systems was ganz und gar nicht stimmen... die Warenkorbfunktion hakt und ich kann mir irgendwie nicht vorstellen, dass das was mit der PHP-Version zu tun hat, da alle anderen "alten" PHP4 Systeme auf dem neuen Server mit register_globals und register_long_arrays funktionieren. In jedem Fall werde ich den Shop jetzt noch mal "von Hand" neu einspielen...

Kann mir jemand die maßgeblichsten Änderungen von PHP4 zu PHP5 nennen, da ich ehrlich gesagt auch überhaupt nicht weiß, wie ich den Fehler ganz genau lokalisieren soll!? Ich tippe bei meinem Shopsystem auf irgendeinen SESSION-Fehler, da das Problem immer dann auftritt, wenn man den Checkout-Prozess einleitet...

... ah da fällt mir noch ein @GwenDragon: Das wäre mir sowieso das liebste... aber ich habe keine Ahnung wie ich das unter Plesk aufsetze... ist das langwierig bzw. anspruchsvoll!? Letztendlich sollte es irgendwie eine "quick & dirty"-Lösung sein :) , da das Shopsystem in spätestens 4-6 Monaten nicht mehr existieren wird...
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top