Deutscher Backend-Login & CLI-Tools

Hallo,

 

leider geht mein deutscher Backend-Login nicht mehr - der englische hingegen schon und auch problemlos. Alles Caches geleert usw.

Die Fehlermeldung wenn ich mich auf Deutsch anmelden, nach dem erfolgreichen Login:

Chrome:

Fehlerinformationen
Modul: Shopware.apps.Index
Pfad der Anforderung: /backend/Index/load/
Art des Fehlers: SyntaxError
Fehlermeldung: Invalid or unexpected token

SyntaxError: Invalid or unexpected token
    at http://www.meinedomain.de/engine/Library/ExtJs/ext-all.js?201607041559:21:5361
    at Object.Ext.globalEval (http://www.meinedomain.de/engine/Library/ExtJs/ext-all.js?201607041559:21:5369)
    at success (http://www.meinedomain.de/backend/base?file=bootstrap&loggedIn=1467987983:477:5)
    at Object.callback (http://www.meinedomain.de/engine/Library/ExtJs/ext-all.js?201607041559:21:67496)
    at constructor.onComplete (http://www.meinedomain.de/engine/Library/ExtJs/ext-all.js?201607041559:21:422670)
    at constructor.onStateChange (http://www.meinedomain.de/engine/Library/ExtJs/ext-all.js?201607041559:21:422314)
    at XMLHttpRequest. (http://www.meinedomain.de/engine/Library/ExtJs/ext-all.js?201607041559:21:17406)

Firefox:

Fehlerinformationen
Modul: Shopware.apps.Index
Pfad der Anforderung: /backend/Index/load/
Art des Fehlers: SyntaxError
Fehlermeldung: unterminated string literal


Ext.globalEval

 


 

Nun wollte ich in der Shell via CLI-Tools mal alle Caches leeren usw. - vllt. hilft es ja was, dann bekam ich direkt folgende Meldung:

 

root@server /var/www/vhosts/meinedomain.de # php5 httpdocs/bin/console
PHP Parse error: syntax error, unexpected 'finally' (T_STRING), expecting catch (T_CATCH) in /var/www/vhosts/meinedomain.de/httpdocs/engine/Shopware/Components/DependencyInjection/Container.php on line 180

 

Shopware ist auf der neuesten Version (5.2.1). Wisst ihr hier einen Rat?

Die Meldung im Backend wird in der Regel durch ein fehlerhaften Textbaustein erzeugt - vor allem da es in englisch ja funktioniert. Hast du da denn etwas geändert?

1 „Gefällt mir“

Dank dir für den Tipp, habe die fehlerhafte Zeile in der Datenbank durch das Änderungsdatum aus dem Log gefunden und konnte es korrigieren. Backend-Login auf Deutsch geht nun wieder.

 

Das CLI-Problem besteht leider immer noch. Weiß da noch jemand Rat? Ich habe auch alle (!) Dateien bis auf die config.php und den Recovery-Ordner durch die Dateien aus einer frischen ZIP der Komplettinstallation überschrieben, trotzdem blieb der Fehler bestehen.

Das CLI-Problem könnte mit der PHP-Version zuammenhängen

Hmm, läuft mit PHP 5.6.23, Ioncube etc. - im Backend wird auch alles als Okay beim Test bewertet (grün), PHP7 könnte ich zwar auch testen, geht aktuell leider nur noch nicht, da Ioncube dafür noch nicht verfügbar ist und drei PlugIns dies benötigen.

Die Version ist auch in der Shell?

1 „Gefällt mir“

Oh, gute Idee! Die Shell läuft tatsächlich regulär unter 5.4.45

Für Leute, die auch einen Plesk-Server mit verschiedenen PHP-Versionen einsetzen und die CLI mit der PHP-Version ihrer Domain ausführen wollen:

Die PHP-Versionen/Handles anzeigen lassen:

/usr/local/psa/bin/php_handler --list

Beispielausgabe:

root@server ~ # /usr/local/psa/bin/php_handler --list
                  id: display name: full version: version: type: cgi-bin: php-cli: php.ini: custom: status:
                  cgi 5.4.45 by OS vendor 5.4.45 5.4 cgi /usr/bin/php5-cgi /usr/bin/php5 /etc/php5/cgi/php.ini false enabled
              fastcgi 5.4.45 by OS vendor 5.4.45 5.4 fastcgi /usr/bin/php5-cgi /usr/bin/php5 /etc/php5/cgi/php.ini false enabled
                  fpm 5.4.45 by OS vendor 5.4.45 5.4 fpm /usr/sbin/php5-fpm /usr/bin/php5 /etc/php5/fpm/php.ini false enabled
               module 5.4.45 by OS vendor 5.4.45 5.4 module /usr/bin/php5-cgi /usr/bin/php5 /etc/php5/apache2/php.ini false enabled
      plesk-php56-cgi 5.6.23 5.6.23 5.6 cgi /opt/plesk/php/5.6/bin/php-cgi /opt/plesk/php/5.6/bin/php /opt/plesk/php/5.6/etc/php.ini true disabled
  plesk-php56-fastcgi 5.6.23 5.6.23 5.6 fastcgi /opt/plesk/php/5.6/bin/php-cgi /opt/plesk/php/5.6/bin/php /opt/plesk/php/5.6/etc/php.ini true enabled
      plesk-php56-fpm 5.6.23 5.6.23 5.6 fpm /opt/plesk/php/5.6/sbin/php-fpm /opt/plesk/php/5.6/bin/php /opt/plesk/php/5.6/etc/php.ini true enabled
      plesk-php70-cgi 7.0.8 7.0.8 7.0 cgi /opt/plesk/php/7.0/bin/php-cgi /opt/plesk/php/7.0/bin/php /opt/plesk/php/7.0/etc/php.ini true disabled
  plesk-php70-fastcgi 7.0.8 7.0.8 7.0 fastcgi /opt/plesk/php/7.0/bin/php-cgi /opt/plesk/php/7.0/bin/php /opt/plesk/php/7.0/etc/php.ini true enabled
      plesk-php70-fpm 7.0.8 7.0.8 7.0 fpm /opt/plesk/php/7.0/sbin/php-fpm /opt/plesk/php/7.0/bin/php /opt/plesk/php/7.0/etc/php.ini true enabled

In meinem Fall läuft die Zieldomain unter 5.6.23 mit fastcgi und Shopware 5.2 setzt auch mindestens 5.6.4 voraus. Also muss CLI mit der 5.6.23 asugeführt werden. Wir kopieren also aus der Spalte php-cli unseren Befehl. Nachfolgend der gesamte Befehl:

# /opt/plesk/php/5.6/bin/php /var/www/vhosts/meinedomain.de/httpdocs/bin/console

 

Vielen Dank für eure Hilfe! Manchmal steht man einfach auf dem Schlauch :slight_smile:

Ich sah mich gestern mit dem gleichen Problem konfrontiert und bin auf Grund der Fehlermeldung hier gelandet. Wie von Moritz Naczenski geschrieben lag es an einem fehlerhaften Textbaustein. Um anderen mit dem gleichen oder einem ähnlichen Problem zu helfen folgend mein Weg zur Behebung des Fehlers:

Der Mitarbeiter eines Kunden, der eigentlich nur Artikel anlegen sollte, fühlte sich zu mehr berufen und hat in den Textbausteinen alle die nach der Suche nach Copyright auftauchen geändert.

Wenn man nicht mehr ins Backend kommt lässt sich in der Datenbank in s_core_logs nachlesen, dass Textbausteine bearbeitet wurden und dann bei dem Mitarbeiter herausfinden welche bzw. was er gesucht hat.

Wer Deutsch als einzige Sprache für den Login im Backend aktiviert hat kann trotzdem in s_core_auth seinem Account als localeID 2 eintragen und zur Sicherheit noch disabled_cache auf 1 setzen.

Klappt der Login kann man entweder über Snippets oder wieder die Datenbank die geänderten Stellen suchen und am besten erstmal mit den Texten aus einer frischen Installation ersetzen. Bei mir war es so, dass der about/footer für  backend/index/controller/main  geändert wurde und dort  © Firma 2016  stand. Im Original war es aber:  Copyright © shopware AG. All rights reserved.  Nachdem  ©  durch ©  ersetzt worden war und ich bei der Gelegenheit auch eben den Cache gelöscht hatte funktionierte der Login auch wieder mit localeID 1 bzw. Deutsch.