Neu Ist JTL-Shop 4.06.9 für PHP 7.1 resp. 7.2 freigegeben?

[Der Konnektor]

Hallo community,
auf der Seite von PHP Supported Versions
habe ich soeben festgestellt, dass PHP 5.6 und 7.0 zum Ende des Jahres auslaufen.
Im JTL-Guide (und in der Readme) finde ich leider keine Angaben, dass JTL- Shop 4.06.9 für die Versionen 7.1 oder gar 7.2 freigegeben ist.
Wann wird das der Fall sein?
Oder funktioniert das schon und nur der Guide ist nicht aktuell?

Gruß
Konrad

 

[hula1499]

7.2 funktioniert - du musst jedoch auch auf deine PLUGINS! achten, viele SP finden es nicht der Mühe wert (auch Zahlungsplugins) upzudaten.

 

[Der Konnektor]

Hallo hula,
als Plugins benutze ich nur die von JTL mitgelieferten (also die mit jtl_ im Namen beginnen)
Ausnahme: agws_ts_features.
Gruß
Konrad

 

[hula1499]

Verwenden keine agws Plugins mehr, kann dir daher nichts dazu sagen.

Also die mitgelieferten sind kein Problem, ich hatte erst vor 2-3 wochen mit der 4.06B5 auf 7.2 umgestellt (ohne jegliche Plugins), ging alles problemlos (seiten, cms, admin, bestellen, paypal etc).
Erst bei 2 Plugins ist dann alles steckengeblieben -> also ich würd mal - sofern du kein DEV System hast - eine Kunden"freie" Zeit abwarten, schnell bei deinem Provider auf 7.2 umstellen und mal mit dem trustedshops plugin testen (unbedingt auch testbestellungen machen, varianten auswählen (sofern vorhanden)).
Shop technisch, gibts mit 7.2 - meines wissens nach - kein Problem (plugins nicht berücksichtigt!).

 

[Der Konnektor]

Hallo,
ich bin mal mit grep schnell durch die "deprecated" functions der Versionen 7.1 und 7.2 gegreppt.
Zwei Functions, die als deprecated markiert sind werden an verschiedenen Stellen benutzt:
parse_str() ohne zweites Argument in eos.php
each() u.a. in class_image.php
__autoload in autoload.php, drupal.php und PHPMailerAutoload.php

Technisch und inhaltlich fehlt mir die Qualifikation dies einschätzen zu können
und eigentlich wollte ich nicht irgendwas testen sondern lediglich ein OK von JTL. Schließlich haben wir für die Shopsoftware bezahlt.
Gruß
Konrad

 

[david]

Shop 4.06.9. läuft prima unter PHP 7.2 oder PHP 7.1.
In der Entwicklung wird gegen verschiedene PHP-Versionen entwickelt und getestet.
Erfahrungsgemäß ist es problematischer, für Shop 4 noch die Kompatibilität zu den längst überholten Versionen PHP5.4 oder 5.5 zu halten

@Der Konnektor du scheinst in deinem Shop noch ältere Dateien rumliegen zu haben. eos.php gibt es in 4.06 nicht mehr, PHPMailerAutoload.php hatte ich auf die Schnelle auch nicht gefunden.
__autoload wird noch vom KCFinder genutzt (wird u.a. zum Upload von Mediendateien im Backend genutzt). Hier steht also definitiv noch eine Änderung/Upgrade an, aber prinzipiell funktioniert der KCFinder trotz der deprecated-Funktion auch in 7.2 noch.

 

[css-umsetzung]

Shop 4.06.9. läuft prima unter PHP 7.2 oder PHP 7.1.
In der Entwicklung wird gegen verschiedene PHP-Versionen entwickelt und getestet.
Erfahrungsgemäß ist es problematischer, für Shop 4 noch die Kompatibilität zu den längst überholten Versionen PHP5.4 oder 5.5 zu halten

Ich hab mich letztens auch gefragt ob 7.2 nun bereits geht, es wäre wichtig wenn das irgendwo dann dokumentiert ist, bis zum 4.05er Shop hatte ich mal so eine tabellarische Dokumentation gefunden, aber auch die ist leider verschwunden.

 

[Der Konnektor]

Hallo david,
vielen Dank für die Rückmeldung.

Shop 4.06.9. läuft prima unter PHP 7.2 oder PHP 7.1.
In der Entwicklung wird gegen verschiedene PHP-Versionen entwickelt und getestet.

Darf ich dies als offizielles Statement seitens JTL verstehen, dass die Version JTL-Shop 4.06.9 für 7.1 und 7.2 freigegeben ist?

if (true) {
    update_guide();
} else {
    talk_to_relesaemanager($today);
}

Erfahrungsgemäß ist es problematischer, für Shop 4 noch die Kompatibilität zu den längst überholten Versionen PHP5.4 oder 5.5 zu halten .

Darum geht es auch nicht, sondern um die aktuellen PHP-Versionen 7.1 und 7.2, die JTL-Shop laut Guide nicht unterstützt.

1. PHP-Version: JTL-Shop 4.00 benötigt mindestens PHP 5.4, empfohlen: PHP 7.0

siehe Systemvoraussetzungen
Die PHP-Versionen 5.4 und 5.5 haben Ihr EOL Mitte 2015 bzw. 2016 erreicht.
Ich habe keine Lust ein ähnliches Desaster zu erleben wie vom Wechsel von shop 3 auf 4.0. als ich 19 Fehlermeldungen zu dieser Zeit schreiben musste. Das hat uns das gesamte Frühjahr 2017 verhagelt.

@Der Konnektor du scheinst in deinem Shop noch ältere Dateien rumliegen zu haben. eos.php gibt es in 4.06 nicht mehr, PHPMailerAutoload.php hatte ich auf die Schnelle auch nicht gefunden.
__autoload wird noch vom KCFinder genutzt (wird u.a. zum Upload von Mediendateien im Backend genutzt). Hier steht also definitiv noch eine Änderung/Upgrade an, aber prinzipiell funktioniert der KCFinder trotz der deprecated-Funktion auch in 7.2 noch.

Das ist gut möglich, denn ich habe immer die notwendigen Updates seit der 4.0 vorgenommen wie in Eurem Guide beschrieben. Dort sollen immer nur Dateien überschrieben werden, aber von Löschen ist dort nie die Rede.
Abgesehen davon: ich habe das grep auf die Dateien aus dem aktuellen zip der Version 4.06.9, heruntergeladen aus dem Kundencenter am 21.09.2018, frisch ausgepackt, laufen lassen.
der Mailer z.B. befindet sich unter ./includes/vendor/phpmailer/phpmailer/PHPMailerAutoload.php des genannten zip's. und eos.php lümmelt irgendwo unter ./includes/modules/ herum. OK, das Modul benutzen wir nicht, aber immerhin... es ist dabei.

 

[david]

Danke für dein Feedback und den Pseodo-Code, so wird`s gemacht
Wir warten aktuell noch auf die Freigabe unseres Hostings für die Konstellation Shop 4.06.9 unter PHP 7.2 inkl. diverser Scripts, Tools und Plugins.
Wenn das durch ist, dann gibt es die ganz offizielle Freigabe inkl. Guide-Update. Wenn du ein eigenes Hosting mit PHP7.2 hast und deine Shop-Plugins ebenfalls kompatibel sind, dann würde ich dir jetzt schon diese Version empfehlen.

 

[farina]

Ich habe schon länger die 4.06-x auf PHP 7.2 umgestellt, ohne Probleme. Meine Drittanbieter-Plugins sind auch alle für 7.2 einsetzbar.

Mich würde eher interessieren, wann der Shop mal nativ sauber mit nginx funktioniert bzw. ordentliche Dokus dazu kommen.

 

[ab2211]

Ich habe hier einen 500er Fehler im Frontend. Hosteurope hat heute auf PHP7 umgestellt. Backend geht. Version ist 4.05.

 

[css-umsetzung]

drei Sachen

Plugins deaktivieren wenn du welche hast die Ioncube verschlüsselt sind
bei HE die PHP Version 7.0 auswählen (das geht noch)

Schnellstmöglich auf SHOP 4.06 gehen da HE auch 7.0 zum Ende des Jahres killen wird (meine Information).

 

[ab2211]

Ok, merci!

Bei mir wars "ComInsNetz Cookie Hinweistext". Wenn ich das wieder aktiviere geht die die Site nicht. Da brauche ich einen Ersatz.

 

[css-umsetzung]

Es ist immer com-in-netz
nein...quatsch es gibt diverse Plugin Anbieter die noch mit Ioncube arbeiten und da benötigst du dann immer das Plugin für die gerade verwendete PHP Version.

Also auch bei com-in-netz bekommst du den Cookie Hinweis für deine 7.0er PHP Version, die ziehst du dir kopierst die über das vorhandene und dann sollte das gehen.

 

[ab2211]

Besten Dank, genau so habe ich gemacht und es geht alles. Bin gleich auf PHP 7.2.

 

[Roddi]

Shopversion 4.06 (Build: 9) bei 1und1 auf 7.2 umgestellt und läuft ohne Probleme.
Hier noch die Plugins und Versionsnummern die bei mir laufen ohne Probleme:
Hinweis Fenster 1.08
JTL Recht auf Vergessenwerden 1.00
JTL Widgets 1.00
Preloader 1.00
Visitmedia - Cookie Acceptor 1.00

 

[Der Konnektor]

Hi, community
ich habe nun endlich eine 7.2 Testumgebung.
Beim ersten Aufruf sowohl des Backends als auch des Frontends sehe ich eine makellos weiße Seite. Sonst nichts.
Bei der Suche in den JTL-docs bin ich im Zusammenhang mit plugins auf LOG-LEVEL Einträge gestossen, die in der config.JTL-Shop.ini.php eingetragen werden sollen.

//backtrace bei SQL-Exceptions auslösen
define('NICEDB_EXCEPTION_BACKTRACE', true);
//Backtrace ggf. via echo im Frontend ausgeben
define('NICEDB_EXCEPTION_ECHO', true);
//alle durch PHP verursachten Fehler, Warnungen und Hinweise im Frontend anzeigen
define('SHOP_LOG_LEVEL', E_ALL);
//alle Fehler, Warnungen und Hinweise bei Wawi-Abgleich anzeigen
define('SYNC_LOG_LEVEL', E_ALL);
//alle Fehler, Warnungen und Hinweise im Backend anzeigen
define('ADMIN_LOG_LEVEL', E_ALL);
//alle Fehler, Warnungen und Hinweise in Templates anzeigen
define('SMARTY_LOG_LEVEL', E_ALL);
//Smarty-Templates bei jedem Seitenaufruf neu kompilieren (Work-around für Smarty 3.1.27 bei aktiviertem OpCache)
define('SMARTY_FORCE_COMPILE', true);
//Fallbacks für alte Templates deaktivieren
define('TEMPLATE_COMPATIBILITY', false);

Leider sehe ich bei erneutem Aufruf weiterhin lediglich eine weisse Seite (OK Weiterhin makellos, aber komplett ohne Inhalt der irgendeinen Rückschluss auf den Fehler geben könnte)
Auch im Errorlog des Servers herrscht absolute Stille.
Warum sehe ich keine Fehlermeldung? Was mache ich da falsch?
Gruß
Konrad

 

[css-umsetzung]

Hast du alle Plugins deaktiviert?
Es liegt eigentlich immer an mindestens einem Plugin,

 

[Der Konnektor]

Hallo css-umsetzung,
Ziel der Frage ist eigentlich:
Wie kann ich den Fehler genau eingrenzen. Es geht hier nicht um das aktivieren oder deaktivieren. Ich möchte gerne irgendwo - am liebsten im Browser, ggf. auch im errorlog - eine Fehlermeldung sehen und nicht eine weisse Seite.
Also: Warum sehe ich keine Fehlermeldung, obwohl ich die DEBUG-Einträge in der config gemacht habe.

Gruß
Konrad

PS:
Nein, es liegt nich am plugin.
Die korrekte Fehlermeldung müsste lauten:

Parse error: syntax error, unexpected 'kaese' (T_STRING), expecting case (T_CASE) or default (T_DEFAULT) or '}' in ./admin/index.php on line 112

Ich habe nämlich in der genannten Datei in Zeile 112 bewusst das Wörtchen case gegen kaese ausgetauscht um auf jeden Fall einen Fehler zu produzieren.

 

[css-umsetzung]

Hallo css-umsetzung,
Ziel der Frage ist eigentlich:
Wie kann ich den Fehler genau eingrenzen. Es geht hier nicht um das aktivieren oder deaktivieren. Ich möchte gerne irgendwo - am liebsten im Browser, ggf. auch im errorlog - eine Fehlermeldung sehen und nicht eine weisse Seite.
Also: Warum sehe ich keine Fehlermeldung, obwohl ich die DEBUG-Einträge in der config gemacht habe.

Gruß
Konrad

Wenn eines der Plugins, wie ich es immer öfter sehe, einfach ein error_reporting(0); macht, kannst du in deiner Konfig eintragen was immer du möchtest.
Daher ist der erste Weg immer, das man alle Plugins deaktiviert und am besten auch nur das Standard Template aktiviert.

Erst dann kannst du einen Fehler wirklich eingrenzen.