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

[Der Konnektor]

Erst dann kannst du einen Fehler wirklich eingrenzen.

Leider nicht, das Verhalten ändert sich nicht.

 

[css-umsetzung]

Dann wirst du nicht drum herum kommen, jemanden schauen zu lassen der sich damit auskennt.

 

[Mirko.Schmidt User deaktiviert]

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

Hier fehlt das Anzeigen der Errors durch

ini_set('display_errors', 1);

erst danach werden die Errors auch angezeigt. Wenn aber ein Plugin wie css_umsetzung schreibt, dies wieder ausschaltet, dann müssen die alle einmal deaktiviert werden.

 

[css-umsetzung]

Stimmt das display_errors fehlte da auch.

Ich verweise und nutze am liebsten immer meinen Block in der config.JTL-Shop.ini.php wenn es Probleme gibt bei einem Kunden, der es ermöglicht schnell mal zwischen den error Anzeigen hin und her zu schalten.

$show_error=false;
$strong = false;
if($show_error) {
if($strong) {
    define('SHOP_LOG_LEVEL', E_ALL);
    define('SYNC_LOG_LEVEL', E_ALL);
    define('ADMIN_LOG_LEVEL', E_ALL);
    define('SMARTY_LOG_LEVEL', E_ALL);
    } else {
        define('SHOP_LOG_LEVEL', E_ALL & ~E_WARNING & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED);
        define('SYNC_LOG_LEVEL', E_ALL & ~E_WARNING & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED);
        define('ADMIN_LOG_LEVEL', E_ALL & ~E_WARNING & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED);
        define('SMARTY_LOG_LEVEL', E_ALL & ~E_WARNING & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED);
    }
    ini_set('display_errors', 1);
    ini_set('error_log',PFAD_ROOT. 'jtllogs/phperror_'.date("d-m-Y").'.log');
} else {
    //enables printing of warnings/infos/errors for the shop frontend
    define('SHOP_LOG_LEVEL', 0);
    //enables printing of warnings/infos/errors for the dbeS sync
    define('SYNC_LOG_LEVEL', 0);
    //enables printing of warnings/infos/errors for the admin backend
    define('ADMIN_LOG_LEVEL', 0);
    //enables printing of warnings/infos/errors for the smarty templates
    define('SMARTY_LOG_LEVEL', 0);
    //excplicitly show/hide errors
    ini_set('display_errors', 0);
}

$show_error= false -> ist der normale Modus den jeder Shop Besitzer im laufenden Betrieb nutzen sollte.
$show_error=true -> es werden Fehler angezeigt die unter anderem eine weiße Seite erzeugen würden.
$show_error=true & strong=true -> es wird schonungslos alles angezeigt was PHP zu bemängeln hat

Sobald die error Anzeige aktiviert wird, wird wenn der Server es zulässt auch ein errorlog mit dem aktuellem Datum in jtllogs/ angelegt, das ist für Webspaces gut wo man nicht so einfach an ein errorlog herankommt.

 

[Der Konnektor]

Hier fehlt das Anzeigen der Errors durch

ini_set('display_errors', 1);

erst danach werden die Errors auch angezeigt. Wenn aber ein Plugin wie css_umsetzung schreibt, dies wieder ausschaltet, dann müssen die alle einmal deaktiviert werden.

Liebe Leute ich bin doch nicht Medienmarkt
aber irgendwas fehlt, oder übersehe ich.

Das steht in meiner config drin (nach dem ganzen Datenbankgeraffel)

//backtrace bei SQL-Exceptions auslösen
define('NICEDB_EXCEPTION_BACKTRACE', true);
//Backtrace ggf. via echo im Frontend ausgeben
define('NICEDB_EXCEPTION_ECHO', true);
//enables printing of warnings/infos/errors for the shop frontend
define('SHOP_LOG_LEVEL', E_ALL);
//enables printing of warnings/infos/errors for the dbeS sync
define('SYNC_LOG_LEVEL', 0);
//enables printing of warnings/infos/errors for the admin backend
define('ADMIN_LOG_LEVEL', E_ALL);
//enables printing of warnings/infos/errors for the smarty templates
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);
//excplicitly show/hide errors
ini_set('display_errors', 1);

Und abschließend habe ich jetzt auch noch die Zeile

ini_set('error_log',PFAD_ROOT. 'jtllogs/phperror_'.date("d-m-Y").'.log');

hinzugefügt.

Weiterhin absolute Ruhe im Karton... und eine Datei wird auch nicht erzeugt (Schreibrechte für Verzeichnis sind OK)
Mich wundert allerdings die Ausgabe von phpinfo() direkt in der admin/index.php eingebaut ergibt u.a diese Ausgabe:

Directive Local Value Master Value 
display_errors    Off    On

Die Plugins (alle von JTL) sind auch aus. verzweifel...

Gruß
Konrad

 

[css-umsetzung]

Du bist was anstrengend

Nun will ich es wissen, schick mir deine Daten wenn du möchtest dann schaue ich mir das an.

 

[Der Konnektor]

Hier die Lösung:
Bei den managed vServern von HostEurope kann man das Logging zentral unterbinden.
Um das logging zu ermöglichen, muss im KIS die Einstellung unter

Skripte & Datenbanken - Skript-Einstellungen -> PHP-Errors" auf "php_flag"

gesetzt werden.
Dann funktioniert's auch mit dem logging!
Jetzt wird geloggt bis die SSD platzt.
Gruß
Konrad

 

[Xantiva]

Ich hänge mich hier mal dran, da ich nach einem Update von 4.05.9 auf 4.06.11 im Test- Shop auch PHP 7.2 aktiviert und bei den ersten Aufrufen der Pluginverwaltung auch diese Fehlermeldung erhalten habe (ist jetzt weg, evtl. ein Caching Problen). Es geht auch um die genannte PHPMailerAutoload.php:

AH01071: Got error 'PHP message: PHP Deprecated:  __autoload() is deprecated, use spl_autoload_register() instead in /var/xxx/includes/vendor/phpmailer/phpmailer/PHPMailerAutoload.php on line 45\n', referer: xxx/admin/pluginverwaltung.php

Shop 4.06.9. läuft prima unter PHP 7.2 oder PHP 7.1.
... 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.

Da ist die PHPMailerAutoload.php in der 4.06.11 z.B. noch drin: \includes\vendor\phpmailer\phpmailer und unter \includes\modules\eos gibt es auch noch die eos.php ...

@david : Was bedeutet das nun? Sind die Dateien versehentlich noch da drin? Oder ist die 4.06 dann doch noch nicht PHP 7.2 kompatibel?

Es wäre super, wenn Ihr künftig auch die "maximale PHP-Version" angeben würdet, bis zu der Ihr das System getestet habt. Also JTL Shop xy ist auch mit PHP 7.x getestet. Wenn die PlugIns das auch mitbringen würden - perfekt!

Ciao,
Mike