Hallo Shopware-Admins und -Supporter! Wir haben hier ein Problem. Während der Anpassung der eMail-Bestellbestätigung in Shopware 4 erhielten wir plötzlich während der Eingabe folgende Fehlermeldung: Ups! Ein Fehler ist aufgetreten! Die nachfolgenden Hinweise sollten Ihnen weiterhelfen. The identifier id is missing for a query of Shopware\Models\Shop\Locale in Doctrine/ORM/ORMException.php on line 150 Stack trace: #0 Doctrine/ORM/EntityRepository.php(116): Doctrine\ORM\ORMException::missingIdentifierField(‘Shopware\Models…’, ‘id’) #1 Shopware/Components/Model/ModelRepository.php(164): Doctrine\ORM\EntityRepository->find(NULL, 0, NULL) #2 Shopware/Plugins/Default/Backend/Auth/Bootstrap.php(290): Shopware\Components\Model\ModelRepository->find(NULL) #3 Shopware/Plugins/Default/Backend/Auth/Bootstrap.php(219): Shopware_Plugins_Backend_Auth_Bootstrap->initLocale() #4 Enlight/Event/Handler/Plugin.php(149): Shopware_Plugins_Backend_Auth_Bootstrap->onPreDispatchBackend(Object(Enlight_Event_EventArgs)) #5 Enlight/Event/EventManager.php(156): Enlight_Event_Handler_Plugin->execute(Object(Enlight_Event_EventArgs)) #6 Enlight/Controller/Action.php(122): Enlight_Event_EventManager->notify(‘Enlight_Control…’, Array) #7 Enlight/Controller/Dispatcher/Default.php(521): Enlight_Controller_Action->dispatch(‘indexAction’) #8 Enlight/Controller/Front.php(214): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp)) #9 Shopware/Bootstrap.php(79): Enlight_Controller_Front->dispatch() #10 Enlight/Application.php(192): Shopware_Bootstrap->run() #11 shopware.php(74): Enlight_Application->run() #12 {main} Seitdem ist es nicht mehr möglich, sich ins Backend einzuloggen. Das Frontend klappt allerdings trotzdem noch. Wie wir feststellen konnten, sind wir mit dem Problem zwar nicht allein, haben aber hier im Forum bisher keine Lösung gefunden. Unsere Debugging-Versuche haben bisher Folgendes ergeben: ORMException.php befindet sich im Verzeichnis /engine/Library/Doctrine/ORM/ Dort wird in Zeile eine Function namens missingIdentifierField($className, $fieldname) aufgerufen. Der className ist offensichtlich “id”. Diese Function missingIdentifierField wird von engine/Library/Doctrine/ORM/EntityRepository.php in Zeile 116 aufgerufen. Nach Auskommentieren der dort stehenden ORMException erhalten wir beim Login ins Backend die Server-Errormeldung: Fatal error: Call to a member function toString() on a non-object in /engine/Shopware/Plugins/Default/Backend/Auth/Bootstrap.php on line 293. Dort werden, wie es aussieht, Variablen für das Backend initialisiert. Der Fehler wird durch die Variable $locale ausgelöst, die entweder über $user->locale oder die Methode Shopware()->Models()->getRepository(…)->find($default) gesetzt wird. Anscheinend enthält $locale danach kein Object auf das die Methode toString() angewendet werden kann. - Vielleicht hilft es, das zu wissen. Wir haben diese Schiene jedenfalls nicht weiter verfolgt und die ORMException wieder entkommentiert. Stattdessen haben wir untersucht, was in EntityRepository.php ab Zeile 108 in der find-Methode eigentlich passiert. Das Array $this->_class->identifier enthält nur das Element [0] mit dem Inhalt “id”. Das wird als Key für ein weiteres Array namens $id benutzt. Leider enthält das Array $id zwar ein Element [‘id’], aber es hat den Inhalt NULL. Daher wird die ORMException ausgelöst. Hier haben wir jetzt erst einmal abgebrochen, die find-Methode weiter zu verfolgen, aber sie wird anscheinend bereits von /engine/Shopware/Components/Model/ModelRepository.php mit NULL aufgerufen. Als nächstes haben wir versucht, ob es was bringt, das Verzeichnis /cache/ neu anzulegen, nur mit den beiden leeren Unterverzeichnissen /cache/database/ und /cache/templates/. Leider brachte auch das keinen Erfolg. Wir hoffen inständig, dass uns hier jemand eine Lösungshilfe geben kann, und wären sehr dankbar! Viele Grüße Frank
Hallo, wir haben inzwischen noch weiter geforscht - und zwar hier: Shopware/Plugins/Default/Backend/Auth/Bootstrap.php function onPreDispatchBackend 219: initLocale(); // sh. Stack function initLocale 287: $default = $this->getDefaultLocale(); 288: $locale = Shopware()->Models()->getRepository( ‘Shopware\Models\Shop\Locale’ )->find($default); // find erzeugt letztlich den Fehler, also muss $default NULL sein. function getDefaultLocale 359: return !empty($default) ? array_shift($default) : array_shift($locales); // Gibt entweder 1. Element aus $default oder $locales zurück. // Da offensichtlich NULL zurückgegeben wird, muss entweder $default[0] // NULL sein, $default aber weitere Elemente enthalten oder, was // wahrscheinlicher ist, $default leer und $locales leer oder $locales[0] // NULL sein. 341: $locales = $this->getLocales(); // Hier wird $locales aus Config backendLocales gelesen und wahrscheinlich // ein leeres Array oder eines mit Element[0] = NULL zurückgegeben. Hier haben wir erstmal gestoppt, denn wir müssten das Skript ändern, um weiter vorzudringen. Aber wir wollen dem Support nicht dazwischen geraten. Da es bei dem ganzen Prozess um die Spracheinstellungen geht, ist mir eingefallen, dass wir die Spracheinstellungen im Backend ausprobiert haben. Dort gibt es ein Formular, das eine Combo-Box zur Sprachauswahl im Shop enthält. Dort haben nur Deutsch ausgewählt (es gibt noch keine englische Version des Shops). Dabei ist mir aufgefallen, dass das nur geht, wenn man Englisch in der Eingabezeile der Combobox, wo zuvor Deutsch und Englisch stand, löscht. Das Ganze war aber mehrere Stunden bevor plötzlich die Fehlermeldung erschien. Hätte Englisch als 2. Sprache möglicherweise dort stehen bleiben müssen? Wenn das der Fall ist: Wo kann ich das wieder korrigieren? Wir kommen ja nicht ins Backend. Das müsste eigentlich doch in der Datenbank stehen. Aber wo? (Wenn das wirklich die Ursache ist, sollte man die Combobox vielleicht besser in eine Selectbox ändern.) Viele Grüße Frank
Hi Frank, das Backend ist jetzt wieder erreichbar. Es war in den Grundeinstellungen ein falscher Wert für die Backend-Sprache ausgewählt. Wir haben den Wert resettet - danach kam die Login-Maske direkt wieder. Sollte also alles wieder laufen - schönes Wochenende Sebastian
Hallo Sebastian, vielen, vielen Dank für die Hilfe!!! Kannst Du vielleicht noch posten, wo diese Grundeinstellungen gespeichert sind – nur so für alle Fälle… Lag es wirklich daran, dass als Sprache nur Deutsch eingestellt war? Nochmals Danke und ein schönes Wochenende (Du hast mir meines jedenfalls gerettet.) Viele Grüße Frank
Guten Tag, wir haben genau das gleiche Problem. Ein Backend-Login ist derzeit nicht möglich. Wie können wir den Grundwert wieder zurück setzen? Vielen Dank.
Hallo, such mal in der Tabelle s_core_config_element nach dem “name” --> “backendLocales” Die ID kopieren und den Eintrag in der Tabelle s_core_config_values mit der Element-ID löschen. Danach sollte der Login wieder klappen.
Vielen Dank. Das war die Lösung. Es funktioniert wieder.
Kann es sein das mir dann die Sprachauswahl bei den Grundeinstellungen für das Backend fehlt? Weil die Auswahl fehlt nun in den Grundeinstellungen… Grüße
Hallo Community und Support-Team! Ich habe nach einem Update auch kein Login Formular mehr im Backend. Konsole sagt --------------------------------------------------- “NetworkError: 503 Service Unavailable - http://www…de/backend/base?file=bootstrap” base?f…otstrap “NetworkError: 503 Service Unavailable - http://www…de/backend/base?file=bootstrap” base?f…otstrap Error: Ext.Loader is not enabled, so dependencies cannot be resolved dynamically. Missing required class: Shopware.container.Viewport --------------------------------------------------- Ist hier auch der Eintrag backendLocales verantwortlich? Beste Grüße Frank
Hi Frank, was für ein Update hast du durchgeführt? Hast du eventuell ein Update übersprungen (4.0.4 auf 4.0.6)? Die Updates müssen der Reihe nach (also 4.0.4 -> 4.0.5 -> 4.0.6) durchgeführt werden. Hast du nach dem Update den Cache geleert? Also folgendede Ordner sollten geleert werden: /cache/database /cache/template /engine/Shopware/Proxies /engine/Shopware/Models/Attribute Es dürfen nur die Inhalte gelöscht werden. Nicht die Ordner selber! Du kannst das Update auch noch ein mal durchführen. Also erst noch einmal alle Daten in deine Shopinstallation kopieren und dann die SQL Query ausführen. Ein kurzes Feedback wäre nett. Gruß Patrick
Hallo Patrick, danke! Ein erneutes Update hat dann den erhofften Erfolg gebracht. LG Frank
Hallo nochmal, nach Umstellung auf die Hauptdomain (ich hatte zum Testen alles auf einer Subdomain geroutet) ist nun das Frontend nicht mehr erreichbar. „Fehler: Umleitungsfehler“ Trotz DB Änderung des Shop-Pfades unter s_core_shops und mehrmaligen löschen der üblichen Cache-Ordner komme ich nicht auf das Frontend. In der .htaccess kann ich auch keinen Fehler entdecken… [size=50]AddHandler php53-cgi .php
RewriteEngine on
#RewriteBase /shopware/
RewriteRule shopware.dll shopware.php
RewriteRule files/documents/.* engine [NC,L]
RewriteRule backend/media/(.*) media/$1 [NC,L]
RewriteCond %{REQUEST_URI} !(/(engine|files|templates)/)
RewriteCond %{REQUEST_URI} !(/media/(archive|banner|image|music|pdf|unknown|video)/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) shopware.php [PT,L,QSA]
</ifmodule># Staging-Rules start #SetEnvIf Host "staging.test.shopware.in" ENV=staging DirectoryIndex index.html DirectoryIndex index.php DirectoryIndex shopware.php # Disables download of configuration<files>
Deny from all
</files># Enable gzip compression<ifmodule mod_deflate.c>
# disable compression on iconset due to loading problems in google chrome on windows
SetEnvIfNoCase Request_URI icon-set.css no-gzip dont-vary
AddOutputFilterByType DEFLATE text/html text/xml text/plain text/css text/javascript application/json
ExpiresActive on
ExpiresDefault „access plus 1 month“
FileETag None
Header append Cache-Control „public“
Header unset ETag
# Disables auto directory index
Options -Indexes
Options -MultiViews
php_value memory_limit 128M
php_value max_execution_time 120
php_value upload_max_filesize 20M
php_flag phar.readonly off
php_flag magic_quotes_gpc off
php_flag session.auto_start off
php_flag suhosin.session.cryptua off
php_flag zend.ze1_compatibility_mode off
# AddType x-mapp-php5 .php # AddHandler x-mapp-php5 .php [/size] Hat Jemand vielleicht eine Idee, habe ich etwas übersehen oder vergessen? Schöne Grüße Frank
Hallo, hast du das hier schon gefunden bzgl. deines Umleitungsfehlers? post54788.html#p54788
Hallo & vielen Dank für die schnelle Antwort! Ich bekomme folgende Meldung Fehler SQL-Befehl: ALTER TABLE s_articles_attributes ADD FOREIGN KEY ( articledetailsID ) REFERENCES s_articles_details ( id ) ON DELETE CASCADE ON UPDATE NO ACTION ; MySQL meldet: Dokumentation #1452 - Cannot add or update a child row: a foreign key constraint fails (d01509a0., CONSTRAINT #sql-6fd_151f656_ibfk_2 FOREIGN KEY (articledetailsID) REFERENCES s_articles_details (id) ON DELETE CASCAD)
VG
Frank
[quote]Kann es sein das mir dann die Sprachauswahl bei den Grundeinstellungen für das Backend fehlt? Weil die Auswahl fehlt nun in den Grundeinstellungen… Grüße[/quote] Ich habe das selbe Problem. Hat jemand die Standart Werte für dieses Feld einmal zur hand, damit ich kein 2. System aufsetzen muss, nur um mir den Wert nochmals zu holen? Vielen Dank im Vorraus LG Léo
Hi, das ist der Default-Eintrag: INSERT INTO `s_core_config_elements` (`id`, `form_id`, `name`, `value`, `label`, `description`, `type`, `required`, `position`, `scope`, `filters`, `validators`, `options`) VALUES (887, 259, 'backendLocales', 'a:2:{i:0;i:1;i:1;i:2;}', 'Auswählbare Sprachen', NULL, 'select', 1, 0, 0, NULL, NULL, 0x613a323a7b733a353a2273746f7265223b733a31313a22626173652e4c6f63616c65223b733a31313a226d756c746953656c656374223b623a313b7d); Bitte nur den kaputten Eintrag in der „s_core_config_values“ löschen und nicht den in „s_core_config_elements“. Heiner
Vielen Dank Für die schnelle Antwort. Nach ein wenig Testen, habe ich auch festgestellt, wie der Fehler zu reproduzieren ist. Das hinzufügen einer weitern sprache für das Backend ist problemlos möglich über das dropdown feld. wenn man jedoch eine Sprache für das Backend entfernen will, darf man dies auch nur über das dropdown feld machen und nicht endem man das feld direkt editiert und die Sprache entfernt. Denn dann schreibt shopware den hier liegenden Strring in die Datenbank, die aber nur language ID’s erwartet. somit wird aaus der Value a:2:{i:0;i:1;i:1;i:2;} a:2:{“Deutsch (Deutschland), Englisch (Vereinigte Staaten)”} Es wäre praktisch, wenn ihr bei Shopware hier einen fix bietet, den die Eingaben des Users beschränkt, damit er das System nicht kaputt manchen kann 
Nochmal danke für die schnelle hilfe
[quote=„Heiner Lohaus“]Hi, das ist der Default-Eintrag: INSERT INTO `s_core_config_elements` (`id`, `form_id`, `name`, `value`, `label`, `description`, `type`, `required`, `position`, `scope`, `filters`, `validators`, `options`) VALUES (887, 259, 'backendLocales', 'a:2:{i:0;i:1;i:1;i:2;}', 'Auswählbare Sprachen', NULL, 'select', 1, 0, 0, NULL, NULL, 0x613a323a7b733a353a2273746f7265223b733a31313a22626173652e4c6f63616c65223b733a31313a226d756c746953656c656374223b623a313b7d); Bitte nur den kaputten Eintrag in der „s_core_config_values“ löschen und nicht den in „s_core_config_elements“. Heiner[/quote] ich habe den gleichen Fehler, komme aber nicht weiter: die Id des Eintrages s_core_config_elements ist 887. Diese ID finde ich nicht in der s_core_config_values. Welchen fehlerhaften Eintrag soll ich nun löschen??? Bitte um baldige Abhilfe! Danke im voraus. Danke, hat sich erledigt, auch wenn die Suche nach der ID 887 in der Tabelle nichts hilft: auf der zweiten Seite steht die ID. Es funktioniert jetzt wieder!