Magento Backend 404 für alle bis auf zwei Konfigurationsbereiche "Website"

In unserer Multiwebsite / Multistore (Ansicht) Magento 1.9.2.2-Konfiguration musste eine der Websites, einschließlich Speicher und Storeview, entfernt werden.

Während die Entfernung selbst problemlos verlief (ich habe dies bereits getan), habe ich am Ende ein Backend mit dem Wert 404 erhalten, wenn Sie Ihren aktuellen Konfigurationsbereich in eine andere als zwei Websites ändern.

Wenn Sie einen neuen Konfigurationsbereich auswählen, wird die folgende URL angefordert (Administratorpfad + Schlüssel wurden geändert):

/index.php/mymageadmin/system_config/edit/section/dev/website/<WEBSITE>/key/1221231/

wo <WEBSITE>ist gleich dem codeFeld in der core_websiteTabelle.

Bei der Anmeldung von MySQL-Abfragen stelle ich fest, dass die beiden Websites, die erfolgreich geladen werden können, diese Abfragen in Bezug auf die Auswahl der Website / Storeview haben:

SELECT `main_table`.* FROM `core_config_data` AS `main_table` WHERE (`scope` = 'websites') AND (`scope_id` = '4') AND (`path` LIKE 'dev/%')
SELECT `core_website`.* FROM `core_website` WHERE (`core_website`.`code`='working_store_code')

Andere Websites, die einen 404-Wert angeben, beginnen mit derselben ersten Abfrage - aber natürlich mit einer anderen scope_id. Bei der zweiten Abfrage muss Magento jedoch nach einem Bereich suchen, storeviewanstatt nach website! Es scheint tatsächlich zweimal zu versuchen.

SELECT `main_table`.* FROM `core_config_data` AS `main_table` WHERE (`scope` = 'websites') AND (`scope_id` = '3') AND (`path` LIKE 'dev/%')
SELECT `core_store`.* FROM `core_store` WHERE (`core_store`.`store_id`=3) ORDER BY `sort_order` ASC
SELECT `core_store`.* FROM `core_store` WHERE (`core_store`.`store_id`=3) ORDER BY `sort_order` ASC

Meine core_website-Tabelle sieht folgendermaßen aus:

website_id code           sort_order     default_group_id  is_default
0          admin          0              0                 0
1          working_one    1              1                 1
3          failing_one    2              4                 0
4          working_two    3              9                 0
6          failing_two    4              16                0
7          failing_three  5              15                0
8          failing_four   6              17                0
9          failing_six    7              18                0

working_xxx = diese laden OK, failing_xxx = diese geben einen 404 aus / versuchen eine nicht existierende store_id auszuwählen.

Meine core_store-Tabelle sieht folgendermaßen aus: (Code + Name als nicht relevant entfernt)

store_id website_id group_id sort_order is_active
0        0          0        0          1
1        1          1        0          1
4        3          4        1          1
5        3          4        2          1
10       4          9        0          1
19       7          15       0          1
20       4          9        1          1
21       4          9        2          1
22       4          9        4          0
23       6          16       1          1
24       6          16       2          1
26       4          9        4          1
28       7          15       0          1
29       1          1        2          1
30       8          17       0          1
31       9          18       0          1
32       9          18       0          1
33       8          17       2          1
34       8          17       3          1
35       8          17       4          1
36       4          9        10         1

Und das ist core_store_group:

group_id website_id name            root_cat_id default_store_id
1        1          working_one     50          1
4        3          failing_one     44          4
9        4          working_one     77          10
15       7          failing_two     70          19
16       6          failing_three   46          23
17       8          failing_four    50          30
18       9          failing_five    96          31

Ich habe diese drei Tabellen mit meiner Sicherungskopie der Datenbank verglichen, bevor ich die Website / Storeview entfernt habe, und - abgesehen von der Entfernung der Website / Storeview - sieht alles genau gleich aus. Gleiche IDs, gleiche Codes etc.

Soweit ich weiß, sind diese drei Tabellen die einzigen, die von Magento auf Storeview / Website-Code und IDs überprüft werden.

Was die Fehlerbehebung angeht, habe ich Folgendes getan: Um sicherzustellen, dass keine Caches mit alter Konfiguration übrig bleiben: geleerter var / cache, geleerte Caches, Neuindizierung, Neustart des Servers usw., alles ohne Erfolg.

Selbst wenn sich PHP / Magento anmeldet, der Entwicklermodus usw., bekomme ich keine Ahnung, warum dies geschieht. Es werden keine Ausnahmen protokolliert.

Die beiden Fragen lauten also: Warum versucht Magento, einen nicht vorhandenen Storeview-Bereich anstelle des Website-Bereichs auszuwählen, und wie kann dies behoben werden?

Update 1 / Problemumgehung

Nach einem langen Tag der Fehlerbehebung, einschließlich, aber nicht beschränkt auf das Tool magento-db-repair, beim erneuten Erstellen von core_store-, core_store_group- und core_website-Tabellen mit allen ursprünglichen Websites und Geschäftsansichten ist mir schließlich Folgendes aufgefallen:

Für all website_iddiese Ladung gibt es eine store_idmit der gleichen Nummer. website_id 1und 4laden wie erwartet, und in der Tat gibt es (ohne Bezug) store_id 1und 4definiert.

Für website_id 3, 6, 7, 8und 9es gibt keine store_idmit der gleichen Nummer.

Sobald ich jedoch einen gefälschten Eintrag erstellt habe store_id, um beispielsweise 3den Konfigurationsbereich von zu laden, wurde die website_id 3Arbeit wieder aufgenommen.

Während ich nun eine Problemumgehung erfolgreich implementiert habe, habe ich eine zusätzliche (deaktivierte) Website und 5 (deaktivierte) Store-Aufrufe erhalten.

Um sicherzugehen, dass dies vorher kein Problem war, habe ich eine der älteren Kopien unserer Site aufgesucht, die ich auf meinem Entwicklungsserver (Magento Version 1.9.1.0) gespeichert habe.

Hier funktioniert alles einwandfrei, dh es wird website_id 6geladen, ohne dass ein store_id 6in der core_storeTabelle steht.

Ich hatte ein ähnliches Problem im Laden mit nur einer Website und löste es mit der folgenden Abfrage.

SET SQL_SAFE_UPDATES=0;
SET FOREIGN_KEY_CHECKS=0;
UPDATE `core_store` SET store_id = 0 WHERE code='admin';
UPDATE `core_store_group` SET group_id = 0 WHERE name='Default';
UPDATE `core_website` SET website_id = 0 WHERE code='admin';
UPDATE `customer_group` SET customer_group_id = 0 WHERE customer_group_code='NOT LOGGED IN';
SET FOREIGN_KEY_CHECKS=1;
SET SQL_SAFE_UPDATES=1;