Magento Backend 404 для всіх, крім двох областей конфігурації "Веб-сайт"

У нашій конфігурації Multiwebsite / Multistore (перегляд) Magento 1.9.2.2 один із веб-сайтів, включаючи його магазин і перегляд магазину, потрібно було видалити.

Хоча видалення пройшло нормально (я це робив раніше), у мене закінчився бекенд 404, якщо ви зміните поточну область конфігурації на будь-яку, крім двох веб-сайтів.

Вибір нового діапазону конфігурації призводить до запиту наступної URL-адреси (шлях адміністратора + ключ змінено):

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

де <WEBSITE>дорівнює codeполі в core_websiteтаблиці.

Під час входу в систему mysql я бачу, що на двох веб-сайтах, які можна успішно завантажити, є ці запити щодо вибору веб-сайту / storeview:

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, починаються з того самого першого запиту - але, звичайно, з іншим domain_id, але у другому запиті Magento думає, що він повинен шукати область storeviewзамість website! Насправді, здається, намагаюся двічі.

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

Моя основна таблиця веб-сайтів виглядає так:

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 = ці завантаження добре, 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

Я порівняв ці три таблиці зі своєю резервною копією БД до того, як я видалив веб-сайт / storeview і -виключити видалення зазначеного веб-сайту / storeview - все виглядає точно так само. Ті ж ідентифікатори, ті ж коди тощо.

Наскільки мені відомо, ці три таблиці - це єдині, які Magento перевіряють на комерційний перегляд / код веб-сайту та ідентифікатори.

Що стосується усунення несправностей, я зробив наступне: Щоб не було кешів зі старою конфігурацією, де залишилось: випорожнено var / cache, розмиті кеші, перезавантажено, перезавантажено сервер тощо, все безрезультатно.

Навіть при вході в php / magento, режимі розробника тощо я отримую нульові підказки, чому це відбувається. Ніякі винятки не реєструються.

Отже, два питання: Чому Magento намагається вибрати неіснуючу область перегляду магазину замість області веб-сайту і як це виправити?

Оновлення 1 / Обхід

Після тривалого дня усунення несправностей, включаючи, але не обмежуючись цим, інструмент для відновлення magento-db, відтворення таблиць core_store, core_store_group та core_website, з усіма оригінальними веб-сайтами та переглядами магазинів, нарешті, я помітив наступне:

При всьому, website_idщо добре завантажує, існує store_idоднакова кількість. website_id 1і 4завантажуються, як очікувалося, і насправді вони є (не пов'язані між собою) store_id 1та 4визначені.

Чи не для website_id 3, 6, 7, 8і 9немає store_idз тим же номером.

Однак, як тільки я створив підроблений запис store_id, наприклад 3, завантажуючи Конфігураційну область website_id 3розпочатого знову.

Тож, поки я успішно поставив рішення, я створив один додатковий (відключений) веб-сайт і 5 переглядів магазинів (вимкнено) ....

Щоб переконатися, що це раніше не було проблемою, я перейшов до однієї із старих копій нашого сайту, яку я зберігаю на своєму сервер розробки (magento версія 1.9.1.0).

Тут все працює ідеально, тобто website_id 6завантажує, не потребуючи store_id 6в core_storeтаблиці.

У мене виникли подібні проблеми в магазині з однією веб-сторінкою, і я вирішив наступний запит.

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;