Welche Fehler mit PHP 5.6 kennt ihr?

[hbauer]

Da PHP 5.4 ja in wenigen Wochen keine Sicherheitsupdates mehr bekommt dies aber die offiziell unterstützte Version ist wird es langsam Zeit zu handeln.

Da Debian 8.0 mit PHP 5.6 ausgeliefert wird scheint ein update auf PHP 5.6 erst mal naheliegend da auch die Demoshops auf PHP 5.6 laufen.

Eine Testinstallation bei mir und Überprüfung der üblichen Aktionen eines Kunden und Shopadmins hat keine Probleme aufgezeigt.

Dabei gehe ich davon aus
- das "depricated Meldungen" im Error log ausgeschaltet sind.
- der Shop vor dem Update schon auf UTF 8 umgestellt war.

Ich würde gerne in diesem Thread echte bekannte Probleme oder gute Erfahrungen mit PHP 5.6 sammeln.

Also
- Welche Probleme hab Ihr identifiziert?
- Wer betreibt schon einen Shop auf PHP > 5.4

Gruß

Hagen

Linkback: https://www.modified-shop.org/forum/index.php?topic=33417.0

[ChristianRothe]

Meine Shops laufen komplett auf PHP 5.6.

Größte Probleme:
- preg_replace muss durch preg_replace_callback ersetzt werden, wenn bei einem Aufruf der Modifier "e" verwendet wird. Davon gibt es einige.
- Die Aufrufe von Funktionen aus MySQL-Bibliothek erzeugen eine Latte von Deprecated Warnungen. Es muss stattdessen MySQLi ("i" steht für "improved") verwendet werden. Dadurch muss alle Funktionsaufrufe "mysql_..." finden und ändern. MySQLi erwartet die Funktionsparamter auch in anderer Reihenfolge als die MySQL-Bibliothek. Außerdem gibt es in MySQLi einige Funktionen nicht mehr, so dass man für manche MySQL-Funktion selbst einen Ersatz nachbauen muss. Ist alles nicht schwierig, aber doch einige Fleißarbeit. Ich habe knapp 1,5 bis 2 Arbeitstage für den Umbau und fürs Testen verwendet.

Ansonsten erinnere ich mich eigentlich an keine größeren Probleme bei der Umstellung. UTF-8 ist nicht nötig, wenn man auf PHP 5.6 umstellt. In der .htaccess-Datei kann man ISO-8859-15 als Default Character Set definieren. Ich bin so von PHP 5.3 direkt auf PHP 5.6 umgestiegen.

[hbauer]

Hallo Christian

verstehe ich das richtig das Deine Umbauten nur für die Deprecated Warnungen notwendig waren? Warum hast Du die nicht einfach ignoriert? Nach meinem Verständnis sind das keine Fehler.

Gruß

Hagen

[ChristianRothe]

Meine Meinung zu den Deprecated-Meldungen und dem Error Reporting: Ein Shop sollte stets so sauber programmiert sein, dass diese Meldungen gar nicht erst auftreten. Alles andere halte ich für Pfusch bzw. das Abschalten der Warnmeldungen für das Zudecken von Pfusch.

Außerdem wird MySQLi eine bessere Performance als MySQL zugeschrieben, so dass sich ein Umstieg allein deshalb schon lohnt.

[hbauer]

Hallo Christian

diese Auffassung ist natürlich eine valide Einstellung. Aber für eine hoffentlich kurze Übergangszeit bis zu einer 2.0 könnte ich zu mindestens mit diesem "Pfusch" leben um Risiken und Aufwände zu minimieren.

Deswegen versuchte ich die Fehlerauflistung mit der Annahme das

- das "depricated Meldungen" im Error log ausgeschaltet sind.

etwas einzuschränken.

Aber ok. Ich halte fest. Bis hierhin noch keinen Fehler der die Funktion des Shops beeinträchtigen.

Wer hat sonst noch Erfahrungen?

[srerin]

bei Programmierung von Bewertungen ist mir auch aufgefallen, dass mysql_* depricated sind. Ich habe die Umstellung auf mysqli_ nicht getraut. Das Risiko ist sehr hoch, dass meine Änderungen bei einer nächsten Aktualisierung überschrieben werden....

Ich hoffe sehr, dass diese Sachen in der Version 2.0 behoben werden....

Ich betreibe den Shop nicht auf 5.6. Bei technischen Voraussetzungen ist doch die zulässigen PHP-Versionen vorgegeben: PHP ab 5.x bis PHP 5.4.x
https://www.modified-shop.org/download

Einsatz einer höheren Version kann meiner Meinung nach zu Problemen führen.

[hbauer]

@srerin

sorry aber ich habe explizit nach realen Erfahrungen und nicht nach persönlichen Meinungen gefragt

Gruß

Hagen

[Hetfield]

Viele unserer Kundeprojekte laufen bereits problemlos auf PHP 5.5 und 5.6. Allerdings haben auch wir einige Codeanpassungen vorgenommen (wie z.B. preg_replace mit preg_replace_callback ersetzen).

Auch unsere Testserver, auf denen wir die Kundenprojekte entwickeln, laufen mit PHP 5.5 und höher.

Probleme sind bis jetzt eigentlich nicht aufgefallen.

MfG Hetfield 

[hbauer]

Allerdings haben auch wir einige Codeanpassungen vorgenommen (wie z.B. preg_replace mit preg_replace_callback ersetzen).

Die Liste der Anpassungen ist doch mit Sicherheit professionell dokumentiert. Kannst Du die im Wiki bereitstellen?

[srerin]

@srerin

sorry aber ich habe explizit nach realen Erfahrungen und nicht nach persönlichen Meinungen gefragt

Gruß

Hagen

Hey, bitte nicht frech sein. Das steht zu diesem netten Profilbild nicht

Wenn du der Meinung bist, dass meine Antwort unpassend ist, kannst du sie einfach ignorieren.

Servus!

[Guenter59]

Das Thema ist auf jeden Fall hochinteressant.
Ich bin auch an Erfahrungen und evtl. Anleitungen zum Umbau interesiert.
GMS

[hbauer]

Hallo srerin

es gibt so viele Beiträge in denen von vermuteten, erwarteten, befürchteten Fehlern die Rede ist das ich hier wirklich den Fokus auf echten erlebten Fehlern halten möchte

Und damit sich das hier nicht fortführt wollte ich gleich zu Begin eine Bremse ziehen.

Gruß

Hagen

[ChristianRothe]

Wo PHP 5.6 auch genauer hinschaut als vorhergehende Versionen ist der statische Aufruf von Funktionen. Wird eine Funktion einer Klasse statisch aufgerufen "klasse::funktion($parameter)" dann wirft PHP 5.6 Warnmeldungen aus, wenn die Funktion nicht ausdrücklich innerhalb der Klasse als "static function" definiert ist. Die erfordert beispielsweise kleinere Anpassungen in der "helperFunctions.php" von den Sofortüberweisungs-Modulen. Ist kein ernsthaftes Problem, kostet aber etwas Zeit, bis man alle Stellen gefunden hat, an denen eine präzisere Funktions-Deklaration gemacht werden muss.

[hbauer]

So, jetzt habe ich mich etwas weiter in die Materie eingelesen und einige Tests durchgeführt.

Generell scheint es so zu sein das die Meldungen über depricated Funktionen zwar als "Fehlermeldung" im Log erscheinen aber eigentlich keine sind. Ich habe zwar keine "offizielles" Statement gefunden aber es scheint so zu sein das es eigentlich nur "Warnungen" sind das eine bestimmte Funktion in der nahen oder fernen Zukunft wegfallen wird. Bis dahin wird sie normal ausgeführt.

Schlußfolgerung 1: Es scheint kein Problem zu sein diese depricated Warnung auszuschalten.

Mittels PHP CodeSniffer (https://github.com/squizlabs/PHP_CodeSniffer) habe ich mal meinen aktuellen Shop auf "Probleme" zu PHP 5.6 geprüft. Das ist mit Sicherheit kein vollständiger Test aber es kamen im wesentlichen nur Warnungen zu mysql Statements. Warnungen zu "preg_replace()" kamen keine.

Diese habe ich mit grep gesucht und es scheint so zu sein das es nur eine Handvoll von Dateien gibt die den problematischen preg_replace Aufruf verwenden.

Mein recht umfangreiches kundenorientiertes Testszenario ist auch ohne Probleme durchgelaufen. Das beinhaltet (fast) alle Funktionen die ein Kunde machen kann plus die Funktionen die der Shopadmin zu Abwicklung der Bestellung braucht. Nicht enthalten in dem Test sind Verwalten der Produkte und alle andere Shopadmin Funktionen.

Das deckt sich auch mit dem bisherigen Feedback.

Schlussfolgerung 2: Im Prinzip sollte es also "einfach so gehen".

So, wie geht jetzt der Update. Ich verwende auf dem Server Debian 7. Eigentlich hatte ich vor direkt auf Debian 8 zu gehen und dabei PHP 5.6 zu bekommen. Dieser Artikel http://www.sysadminslife.com/linux/php-5-5-installation-unter-debian-wheezy-und-upgrade-von-php-5-4/ hat mich allerdings auf den Ansatz gebracht ein weiteres Repository einzubinden das es mir erlauben würde ohne große Probleme wieder auf PHP 5.4 zurückzugehen wenn notwendig.

Schlussfolgerung 3: Ich werde vermutlich mit dotdeb auf PHP 5.6 gehen und schauen was passiert.

Irgendwelche Kommentare oder andersartige Erfahrungen?

[web28]

Ich habe vorhin einen 1.06 SP2 auf meinem Server (PHP 5.6.4) installiert. Mit charset=iso-8859-15 gibt es Kodierungsprobleme da PHP 5.6 UTF-8 als Standard setzt:

default_charset string

    Von PHP 5.6 an ist der Vorgabewert "UTF-8", und dieser Wert wird als Standard-Zeichenkodierung für htmlentities(), html_entity_decode() und htmlspecialchars() verwendet, wenn der encoding Parameter ausgelassen wird. Der Wert von default_charset wird ebenfalls verwendet, um den Standard-Zeichensatz für iconv Funktionen festzulegen, wenn die iconv.input_encoding, iconv.output_encoding und iconv.internal_encoding Konfigurationsoptionen nicht gesetzt sind, und für mbstring Funktionen, wenn die mbstring.internal_encoding, mbstring.http_input und mbstring.http_output Konfigurationsoptionen nicht gesetzt sind.

Damit wieder ISO ausgeliefert wird muss diese Codezeile

Code: PHP  [Auswählen]

// set default charset
@ini_set('default_charset', $_SESSION['language_charset']);

in folgende Dateien eingefügt werden:

admin/includes/application_top.php (VOR der Zeile // include the language translations)

includes/modules/set_session_languages.php  (ans Ende aber vor dem ?>)

Bei einer Neuinstallation muss auch diese Datei  geändert werden:

_installer/includes/application.php

Code: PHP  [Auswählen]

// set default charset
  @ini_set('default_charset', $charset);

Obige Zeilen einfügen VOR dieser Zeile

Code: PHP  [Auswählen]

if (version_compare(PHP_VERSION, '5.1.0', '>=')) {

Ansonsten werden bei der Installation Sonderzeicheneingaben in den Inputfeldern falsch in die DB geschrieben (Shopname etc.). Das lässt sich aber auch im Backend aber nachträglich korrigieren.

Gruss Web28

EDIT: die depricated Meldungen kann man ignorieren, diese dürfen über das error Reporting aber auch nicht ausgeben werden, da die Fehlerausgabe dann echte Fehler erzeugen kann.