2つの「Webサイト」設定スコープを除くすべてのMagentoバックエンド404

Multiwebsite / Multistore（view）Magento 1.9.2.2の構成では、storeおよびstoreviewを含むWebサイトの1つを削除する必要がありました。

削除自体はうまくいきましたが（以前にこれを行いました）、現在の構成スコープを2つ以外のWebサイトに変更すると、404のバックエンドになりました。

新しい構成スコープを選択すると、次のURLが要求されます（管理パス+キーが変更されます）。

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

ここで<WEBSITE>、codeフィールドと等しいcore_websiteテーブルです。

mysqlクエリログオンを使用すると、Webサイト/ストアビューの選択に関して、正常にロードできる2つのWebサイトにこれらのクエリが含まれていることがわかります。

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

404を提供する他のWebサイトは、同じ最初のクエリから始まりますが、もちろんscope_idは異なりますが、2番目のクエリではMagentoはstoreview代わりにスコープを探す必要があると考えていますwebsite！実際には2回試行するようです。

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

私のcore_websiteテーブルは次のようになります。

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 =これらはロードOK、failing_xxx =これらは404を提供し、存在しないstore_idを選択しようとします。

core_storeテーブルは次のようになります：（コード+名前は関係ないため削除されました）

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

そして、これは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

ウェブサイト/ストアビューを削除する前に、これらの3つのテーブルをDBのバックアップコピーと比較しました。ウェブサイト/ストアビューの削除を除いて、すべてがまったく同じに見えます。同じID、同じコードなど

私の知る限り、これら3つのテーブルは、Magentoがstoreview / websiteコードとIDについてチェックする唯一のテーブルです。

トラブルシューティングに関しては、次のことを行いました：古い構成のキャッシュが残っていないことを確認するには：var / cacheを空にし、キャッシュをフラッシュし、インデックスを再作成し、サーバーを再起動します。

すべてのphp / magentoログオン、開発者モードなどでさえ、なぜこれが起こっているのかについての手がかりはゼロです。例外は記録されません。

2つの質問は次のとおりです。MagentoがWebサイトのスコープではなく、存在しないストアビュースコープを選択しようとするのはなぜですか？

アップデート1 /回避策

magento-db-repairツールに限らず、core_store、core_store_group、およびcore_websiteテーブルをすべての元のWebサイトとストアビューで再作成するなど、トラブルシューティングの長い日後に、私は最終的に次のことに気付きました。

すべてのwebsite_idロードにstore_id同じ数のがあります。website_id 1そして4期待通りにロードされており、実際に（無関係）store_id 1および4定義されています。

およびなしありwebsite_id 36789store_id同じ番号で。

ただし、たとえばに偽のエントリを作成すると、再び動作を開始する構成スコープが読み込まstore_idれます。3website_id 3

そのため、回避策を導入することに成功しましたが、1つの余分な（無効な）Webサイトと5つの（無効な）ストアビューができました。

これが以前は問題ではなかったことを確認するために、開発サーバー（magentoバージョン1.9.1.0）に保存しているサイトの古いコピーの1つに移動しました。

ここでは、すべてが完全に機能します。つまり、テーブルにwebsite_id 6aを必要とせずにロードstore_id 6しcore_storeます。

単一のWebサイトストアで同様の問題があり、次のクエリで解決しました。

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;