Magento Backend 404 para todos, exceto dois escopos de configuração do "site"

Em nossa configuração Multiwebsite / Multistore (exibição) Magento 1.9.2.2, um dos sites, incluindo sua loja e visualização de loja, teve que ser removido.

Enquanto a remoção em si foi boa (eu já fiz isso antes), acabei com um back-end 404, se você alterar seu escopo de configuração atual para qualquer um, exceto dois sites.

A seleção de um novo escopo de configuração resulta em uma solicitação para o seguinte URL (caminho do administrador + chave são alterados):

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

onde <WEBSITE>é igual ao codecampo na core_websitetabela.

Com o log de consultas do mysql, vejo que os dois sites que podem ser carregados com êxito têm essas consultas em relação à seleção do site / visualização de armazenamento:

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

Outros sites que dão 404 começam com a mesma primeira consulta - mas é claro que um scope_id diferente, mas na segunda consulta o Magento acha que precisa procurar um escopo em storeviewvez de website! Na verdade, parece tentar duas vezes.

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

Minha tabela core_website tem a seguinte aparência:

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 = estes carregam OK, failing_xxx = estes fornecem 404 / tentam selecionar um store_id inexistente.

Minha tabela core_store tem a seguinte aparência: (código + nome removido como não relevante)

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

E este é o 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

Comparei essas três tabelas com minha cópia de backup do banco de dados antes de remover o website / storeview e, exceto pela remoção do referido website / storeview, tudo parece exatamente o mesmo. Mesmos IDs, mesmos códigos etc.

Até onde eu sei, essas três tabelas são as únicas que são verificadas pelo Magento quanto ao código de armazenamento / site e IDs.

Quanto à solução de problemas, fiz o seguinte: Para garantir que nenhum cache com a configuração antiga permanecesse: esvaziado var / cache, caches liberados, reindexado, reinicializado o servidor etc, tudo sem sucesso.

Mesmo com todo o logon do php / magento, modo de desenvolvedor etc., não recebo nenhuma pista sobre o motivo disso estar acontecendo. Nenhuma exceção é registrada.

Portanto, as duas perguntas são: Por que o Magento está tentando selecionar um escopo de storeview inexistente em vez do escopo do site e como consertar isso?

Atualização 1 / Solução alternativa

Após um longo dia de solução de problemas, incluindo, entre outras, a ferramenta magento-db-repair, recriando as tabelas core_store, core_store_group e core_website, com todos os sites originais e exibições de loja, finalmente observei o seguinte:

Para toda website_idessa carga fina, existe uma store_idcom o mesmo número. website_id 1e 4estão carregando conforme o esperado e, de fato, existem (não relacionados) store_id 1e 4definidos.

Por website_id 3, 6, 7, 8e 9não existe store_idcom o mesmo número.

No entanto, uma vez que criei uma entrada falsastore_id , por exemplo 3, o carregamento do escopo de configuração website_id 3começou a funcionar novamente.

Portanto, embora eu tenha implementado uma solução alternativa com êxito, acabei com um site extra (desativado) e 5 visualizações de loja (desativadas) ....

Para ter certeza de que isso não era um problema antes, fui a uma das cópias mais antigas do nosso site que mantenho no meu servidor de desenvolvimento (magento versão 1.9.1.0).

Aqui tudo funciona perfeitamente, ou seja, website_id 6carrega sem precisar de um store_id 6na core_storetabela.

Eu tive um problema semelhante na loja de site único e resolvi com a seguinte consulta.

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;