Magento Backend 404 pour toutes les étendues de configuration «Website» sauf deux

Dans notre configuration Multiwebsite / Multistore (voir) Magento 1.9.2.2, l'un des sites Web, y compris son magasin et sa vue de magasin, a dû être supprimé.

Bien que la suppression elle-même se soit bien passée (je l'ai déjà fait), je me suis retrouvé avec un backend de 404 si vous modifiez votre étendue de configuration actuelle en deux sites Web sauf deux.

La sélection d'une nouvelle étendue de configuration entraîne une demande de l'URL suivante (le chemin d'administrateur + la clé sont modifiés):

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

où <WEBSITE>est égal au codechamp du core_websitetableau.

Avec la connexion à la requête mysql, je vois que les deux sites Web qui peuvent être chargés avec succès ont ces requêtes en ce qui concerne la sélection du site Web / magasin:

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')

D'autres sites Web qui commencent par 404 avec la même première requête - mais bien sûr un scope_id différent, mais dans la deuxième requête, Magento pense qu'il doit chercher une portée storeviewau lieu de website! Il semble en fait essayer deux fois.

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

Ma table core_website ressemble à ceci:

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 = ceux-ci se chargent OK, failing_xxx = ceux-ci donnent un 404 / essaient de sélectionner un store_id inexistant.

Ma table core_store ressemble à ceci: (code + nom supprimé car non pertinent)

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

Et voici 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

J'ai comparé ces trois tableaux à ma copie de sauvegarde de la base de données avant de supprimer le site Web / magasin et, à l'exception de la suppression dudit site Web / magasin, tout a exactement la même apparence. Mêmes identifiants, mêmes codes, etc.

Autant que je sache, ces trois tableaux sont les seuls qui sont vérifiés par Magento pour le code de magasin / site Web et les identifiants.

En ce qui concerne le dépannage, j'ai fait ce qui suit: Pour garantir qu'aucun cache avec l'ancienne configuration ne soit laissé: var / cache vidé, caches vidés, réindexé, redémarré le serveur, etc., tout cela en vain.

Même avec toutes les connexions php / magento, le mode développeur, etc., je n'ai aucun indice sur la raison pour laquelle cela se produit. Aucune exception n'est enregistrée.

Les deux questions sont donc les suivantes: pourquoi Magento essaie-t-il de sélectionner une étendue de vue de magasin inexistante au lieu de l'étendue du site Web et comment y remédier?

Mise à jour 1 / solution de contournement

Après une longue journée de dépannage, y compris, mais sans s'y limiter, l'outil magento-db-repair, recréant les tables core_store, core_store_group et core_website, avec tous les sites Web originaux et les vues de magasin, j'ai finalement remarqué ce qui suit:

Pour tout website_idce chargement, il y en a un store_idavec le même numéro. website_id 1et 4se chargent comme prévu, et en effet il y en a (sans rapport) store_id 1et 4définis.

Pour website_id 3, 6, 7, 8et 9il n'y a pas store_idle même numéro.

Cependant, une fois que j'ai créé une fausse entrée store_id, par exemple 3, le chargement de la portée de configuration de a website_id 3recommencé à fonctionner.

Donc, alors que j'ai réussi à mettre en place une solution de contournement, je me suis retrouvé avec un site Web supplémentaire (désactivé) et 5 vues de magasin (désactivées) ....

Pour être sûr que ce n'était pas un problème auparavant, je suis allé sur l'une des anciennes copies de notre site que je garde sur mon serveur de développement (magento version 1.9.1.0).

Ici, tout fonctionne parfaitement, c'est-à-dire des website_id 6charges sans avoir besoin d'un store_id 6dans le core_storetableau.

J'ai eu un problème similaire sur la boutique à site Web unique et j'ai résolu la question suivante.

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;