HTTP 500 Error

[Edition Steffan]

Hallo zusammen! Ich habe seit kurzem das Problem im Prestashop-Templates-Menü, dass ich die Logos nicht mehr verändern bzw. austauschen kann. Es erscheint beim Versuch, das neu hochgeladene Logo zu speichern, die globale Fehlermeldung HTTP 500 Error. Nachdem ich die Anzeige von Fehlermeldungen aktiviert habe, erscheint nun die ausführliche Anzeige:

 

Fatal error: Uncaught Error: Access to undeclared static property: Validate::$values in /mnt/web205/b2/09/537909/htdocs/shop/classes/controller/AdminController.php:1150 Stack trace: #0 /mnt/web205/b2/09/537909/htdocs/shop/controllers/admin/AdminThemesController.php(640): AdminControllerCore->processUpdateOptions() #1 /mnt/web205/b2/09/537909/htdocs/shop/classes/controller/AdminController.php(699): AdminThemesControllerCore->processUpdateOptions() #2 /mnt/web205/b2/09/537909/htdocs/shop/controllers/admin/AdminThemesController.php(2498): AdminControllerCore->postProcess() #3 /mnt/web205/b2/09/537909/htdocs/shop/classes/controller/Controller.php(171): AdminThemesControllerCore->postProcess() #4 /mnt/web205/b2/09/537909/htdocs/shop/classes/Dispatcher.php(373): ControllerCore->run() #5 /mnt/web205/b2/09/537909/htdocs/shop/admin4070/index.php(54): DispatcherCore->dispatch() #6 {main} thrown in /mnt/web205/b2/09/537909/htdocs/shop/classes/controller/AdminController.php on line 1150

 

Eigenen Recherchen zufolge könnte das mit dem php-Update auf 7.0 zu tun haben, zumindest trat der Fehler vor dem Update nicht auf. Kennt hier jemand das Problem und kann mir dabei weiterhelfen? 

Vielen Dank für die Unterstützung im Voraus.

 

Beste Grüße!

Manfred

(Edition Steffan)

[Claudiocool]

wirklich PHP 7.0.... oder eventuell die 7.1... ?

[Edition Steffan]

Hallo ClaudioCool,

 

installiert sind php 7.0.15, prestashop 1.6.0.5, mysql 5.5.52-log und Apache 2.2.31 Unix

 

... und offtopic: Was soll ich jetzt mit der Automobilzubehör-Webseite?

[Claudiocool]

Vermutlich sitzt da eine Deklaration bei den Publics oben falsch, also ohne "static" und irgendwo weiter unten wird das dann in der Abfrage verwendet (oder eben umgekehrt, keinne deinen Code nicht. Also suchen, was da jeweils aufgerufen wir und wie, dann schauen, wie die Variable deklariert ist. Das wäre mein erster Ansatz.

 

BTW: Wenn man hier fragt, sollte man schon genauere Infos posten....

[rictools]

installiert sind php 7.0.15, prestashop 1.6.0.5 ...

Bist du dir sicher, daß PHP 7 mit dieser älteren Prestashop-Version überhaupt funktioniert (es wird meist auch bei 1.6.1.x von PHP 7 abgeraten)?

 

... und offtopic: Was soll ich jetzt mit der Automobilzubehör-Webseite?

Das nennt sich Signatur und steht unter jedem Beitrag des Users, hat also nicht speziell etwas mit dir oder diesem Thread zu tun.

[Claudiocool]

PHP 7.0 funktioniert, erst bei 7.1x wirds kritisch, aber man kann hier durchaus mit ein paar kleinen Scriptänderung alles zum Laufen bekommen.

 

Pssssst.... jetzt kauft der Steffan nix bei mir

[Edition Steffan]

Vielen Dank erst mal für die kurzen Anregungen,

 

... und sorry, dass ich die Signatur in der ersten Antwort nicht sofort als solche wahrgenommen habe. 

 

Wir hatten vor einigen Wochen den Upgrade von php 5.6 auf 7.0 gemacht und es schien alles soweit glatt gegangen zu sein dabei. Erst bei den angedachten Versuchen, etwas im Bereich des Templates zu verändern (Veränderung Shop-Logo, Mail-Logo etc., wurden wir dann auf Fehler aufmerksam.

Ich habe mir die einzelnen Scripte im Controller- und Classes-Bereich dazu näher angesehen und kann auf den ersten Blicken noch keine relevanten Veränderungen aus dem Upgrade erkennen, die das Problem verursacht hätten können.

Ich bin hier also weiter für jede Unterstützung oder Hinweise dankbar.

[Claudiocool]

Mach dir doch als erstes eine info.php und lass dir damit deine Serversettings anzeigen, da siehst du dann, wie alles eingestellt ist und kannst eventuell da Ansätze erkennen, was geändert werden sollte.

Hoster haben oft die Intention, alles erstmal in Grundkonfiguration laufen zu lassen und zu schauen, ob die Kunden damit zufrieden sind....

 

Der Inhalt deiner info.php sollte sein:

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Server-Informationen</title>
</head>

<body>
<?PHP
phpinfo ();
?>
</body>
</html>

Dann ins Shopverzeichnis damit uund aufrufen.

[Edition Steffan]

Hallo claudiocool,

 

anhand der Hinweise konnte ich nun die Fehlerquellen eingrenzen und im Speziellen die classes/controller/admincontroller.php soweit bearbeiten, dass das Problem nun als gelöst bezeichnet werden kann.

 

Vielen Dank für die Unterstützung und die Tipps!

 

Beste Grüße!

[Claudiocool]

Für die Nachwelt wäre dein Lösungsweg sicher nicht uninteressant....

[Edition Steffan]

Mein Grundgedanke war ja, dass das beschriebene Hauptproblem mit dem Upgrade auf php 7.0 zusammenhängen müsste. Wahrscheinlich auch mit Inkompatibilitäten in Bezug auf die sonst unverändert gebliebenen Versionen des Prestashops und der Datenbanken. Deswegen habe ich mir dann mal die aktuelle Download-Version des Prestashops 1.6.1.11 mal zur Ansicht runtergeladen und im Bezug auf die erhaltenen Fehlermeldungen (siehe Ausgangspost) abgeglichen, ob an den jeweiligen Stellen im Vergleich zu meiner Version 1.6.0.5 relevante Befehle etc. verändert wurden. 

Ich machte also den Anfang mit der ersten Meldung:

/mnt/web205/b2/09/537909/htdocs/shop/classes/controller/AdminController.php:1150 Stack trace:

und suchte das entsprechende Gegenstück in der AdminController.php der neueren Prestashop-Version, Es gab darin Veränderungen, die ich in meine Version kopierte.

Es wurde daraufhin eine neue, veränderte Fehlermeldung ausgegeben, die auf die Zeile 3080 in der AdminController.php hinwies. Dort ging ich ebenfalls nach dem selben Schema vor und kopierte die scheinbar deutliche besser Validierungssequenz ...

 

        $insert = array();

        foreach ($assos_data as $id_shop) {

            $insert[] = array(

                $this->identifier => (int)$id_object,

                'id_shop' => (int)$id_shop,

            );

        }

        return Db::getInstance()->insert($this->table.'_shop', $insert, false, true, Db::INSERT_IGNORE);

    }

 

    /**

     * @param mixed $value

     * @param array $field

     * @return bool

     */

    protected function validateField($value, $field)

    {

        if (isset($field['validation'])) {

            $valid_method_exists = method_exists('Validate', $field['validation']);

            if ((!isset($field['empty']) || !$field['empty'] || (isset($field['empty']) && $field['empty'] && $value)) && $valid_method_exists) {

                $field_validation = $field['validation'];

                if (!Validate::$field_validation($value)) {

                    $this->errors[] = Tools::displayError($field['title'].' : Incorrect value');

                    return false;

                }

            }

        }

 

        return true;

 

in meine Version. Und damit konnte ich diese Fehlfunktion beheben.

 

Mit dem Hinweis bezüglich der selbst erstellten info.php kamen dann noch einige Fehlermeldungen in Bezug auf die googleusercontent/.....-php´s zu Tage. Als ich auch dort nach entsprechenden Veränderungen in der PS-Version 1.6.1.11 sehen wollte, stellte ich fest, dass es diese Dateien dort gar nicht mehr gibt. Ich entfernte die deswegen dann auch aus meiner PS-Version und die Fehlermeldungen blieben bei nicht schlechter gewordener Funktionalität aus. 

 

Vielleicht mag mein Vorgehen etwas "sehr pragmatisch" wirken, aber bei Sachen, die ich erst seit ein paar Monaten einfach nur nutze und nicht selbst geschrieben habe, gehe ich einfach gerne mal so vor. 

[Claudiocool]

Gut, bei PHP werden mit der Zeit Befehle rausgeschmissen, im Normalfall nicht unangekündigt, man kriegt dann bei eingestellten Fehlerinfos die entsprechenden Infos von PHP, dann hat man im Normalfall auch noch Zeit, die Sachen zu ändern. Bei selbsterstellten Scripts natürlich mehr als bei Fremdscripts, wo man sich ein wenig auf die ursprünglichen Programmierer verlässt