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` ASCMa 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 0working_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 1Et 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 31J'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.