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


14

В нашей конфигурации 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таблице.


Я должен спросить, вы запускали индексирование URL, когда вы все изменили?
Энтони Чичелли

Привет @AnthonyCicchelli, спасибо, что спросил. На самом деле это была одна из первых вещей, которые я пытался решить, но безрезультатно :(
Оттонет

Отсюда трудно сказать, так как есть много факторов, вы сбросили весь свой URL из БД и снова запустили URL. Звуки связаны со мной. Будьте ОЧЕНЬ осторожны, работая непосредственно с БД, как описано выше. Убедитесь, что у вас есть резервная копия, иначе она может сломать все.
Энтони Чичелли

Я почти уверен, что это не проблема "внешнего интерфейса" (например, URL-индекса), а скорее проблема "внутреннего интерфейса", где-то глубоко в magento-коде. Мне кажется, что Magento ожидает определенную последовательность / комбинацию website_id / store_id, где, если вы удалите некоторые идентификаторы «посередине», magento не сможет найти и загрузить эти website_id.
Оттонет

Ответы:


2

У меня была похожая проблема в магазине с одним сайтом, и я решил следующий запрос.

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;
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.