В нашей конфигурации Multiwebsite / Multistore (view) Magento 1.9.2.2 один из сайтов, включая его магазин и магазин, должен был быть удален.
Хотя само удаление прошло нормально (я делал это раньше), у меня получился сервер 404, если вы измените свою Область текущей конфигурации на любой, кроме двух Веб-сайтов.
Выбор новой области конфигурации приводит к запросу на следующий URL (путь администратора + ключ изменены):
/index.php/mymageadmin/system_config/edit/section/dev/website/<WEBSITE>/key/1221231/
где <WEBSITE>
равно code
полю в core_website
таблице.
При входе в систему запросов MySQL я вижу, что два веб-сайта, которые могут быть успешно загружены, имеют эти запросы в отношении выбора веб-сайта / магазина:
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, начинают с того же первого запроса - но, конечно, с другим scope_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
Моя таблица 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 = эти загрузки в порядке, 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
Я сравнил эти три таблицы с моей резервной копией БД до того, как я удалил веб-сайт / магазин и, за исключением удаления указанного веб-сайта / магазина, все выглядит точно так же. Одинаковые идентификаторы, одинаковые коды и т. Д.
Насколько я знаю, эти три таблицы являются единственными, которые проверяются Magento на предмет просмотра магазина / кода веб-сайта и идентификаторов.
Что касается устранения неполадок, я сделал следующее: чтобы убедиться, что не осталось ни одного кэша со старой конфигурацией: очищенный var / cache, очищенные кэши, переиндексация, перезагрузка сервера и т. Д., Все безрезультатно.
Даже при всем входе в систему php / magento, режиме разработчика и т. Д., Я получаю ноль подсказок о том, почему это происходит. Никакие исключения не зарегистрированы.
Итак, два вопроса: почему Magento пытается выбрать несуществующую область просмотра магазина вместо области веб-сайта и как это исправить?
Обновление 1 / Обходной путь
После долгого дня устранения неполадок, включая, помимо прочего, инструмент magento-db-repair, воссоздание таблиц 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
, загрузка Scope Configuration website_id
3
снова начала работать.
Таким образом, хотя я успешно применил обходной путь, у меня появился один дополнительный (отключенный) веб-сайт и 5 (отключенных) просмотров магазина ....
Чтобы убедиться, что это не было проблемой раньше, я зашел на одну из старых копий нашего сайта, которую я храню на своем dev-сервере (magento version 1.9.1.0).
Здесь все работает отлично, т.е. website_id
6
загружается без необходимости store_id
6
в core_store
таблице.