Magento Backend 404 para todos menos dos ámbitos de configuración de "Sitio web"


14

En nuestra configuración Multiwebsite / Multistore (ver) Magento 1.9.2.2, uno de los sitios web, incluida su tienda y la vista de la tienda, tuvo que eliminarse.

Si bien la eliminación en sí misma estuvo bien (lo he hecho antes), terminé con un backend que es 404 si cambia su Alcance de configuración actual a solo dos sitios web.

Al seleccionar un nuevo Ámbito de configuración, se solicita la siguiente URL (la ruta de administración + la clave se cambian):

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

donde <WEBSITE>es igual al codecampo en la core_websitetabla.

Con el inicio de sesión de consultas mysql, veo que los dos sitios web que se pueden cargar con éxito tienen estas consultas con respecto a la selección del sitio web / 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')

Otros sitios web que dan un 404 comienzan con la misma primera consulta, pero, por supuesto, un scope_id diferente, pero en la segunda consulta, Magento cree que debe buscar un alcance en storeviewlugar de website! En realidad parece intentarlo dos veces.

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

Mi tabla core_website tiene el siguiente aspecto:

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 = estos cargan OK, failing_xxx = estos dan un 404 / intente seleccionar un store_id no existente.

Mi tabla core_store tiene el siguiente aspecto: (código + nombre eliminado como no 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

Y este es 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

Comparé estas tres tablas con mi copia de seguridad de la base de datos antes de eliminar el sitio web / vista de la tienda y, excepto por la eliminación de dicho sitio web / vista de la tienda, todo se ve exactamente igual. Las mismas identificaciones, los mismos códigos, etc.

Hasta donde yo sé, estas tres tablas son las únicas que Magento verifica para ver el código de la tienda / sitio web y las identificaciones.

En cuanto a la resolución de problemas, he hecho lo siguiente: Para garantizar que no haya cachés con la configuración anterior donde se dejó: vaciado var / caché, cachés vacíos, reindexado, reiniciado el servidor, etc., todo fue en vano.

Incluso con todo el inicio de sesión de php / magento, el modo de desarrollador, etc., no tengo pistas de por qué sucede esto. No se registran excepciones.

Entonces, las dos preguntas son: ¿Por qué Magento está tratando de seleccionar un alcance de vista de tienda inexistente en lugar del alcance del sitio web y cómo solucionarlo?

Actualización 1 / Solución alternativa

Después de un largo día de solución de problemas, que incluye, entre otros, la herramienta magento-db-repair, recreando las tablas core_store, core_store_group y core_website, con todos los sitios web originales y las vistas de la tienda, finalmente noté lo siguiente:

Para todo lo website_idque carga bien hay un store_idcon el mismo número. website_id 1y 4están cargando como se esperaba, y de hecho los hay (no relacionados) store_id 1y 4definidos.

Para website_id 3, 6, 7, 8y 9allí no está store_idcon el mismo número.

Sin embargo, una vez que creé una entrada falsa en store_id, por ejemplo 3, al cargar el Alcance de configuración, website_id 3comencé a trabajar nuevamente.

Entonces, aunque ahora he implementado con éxito una solución alternativa, terminé con un sitio web adicional (deshabilitado) y 5 vistas de la tienda (deshabilitado) ...

Para asegurarme de que esto no era un problema antes, fui a una de las copias más antiguas de nuestro sitio que guardo en mi servidor de desarrollo (magento versión 1.9.1.0).

Aquí todo funciona perfectamente, es decir, se website_id 6carga sin necesidad de un store_id 6en la core_storetabla.


Tengo que preguntar, ¿has ejecutado la indexación de URL cuando cambiaste todo?
Anthony Cicchelli

Hola @AnthonyCicchelli, gracias por preguntar. Esta fue realmente una de las primeras cosas que intenté resolver el problema, pero fue en vano :(
Ottonet

Es difícil saber desde aquí, ya que hay muchos factores, ¿ha borrado toda su URL de la base de datos y ha vuelto a ejecutar la URL? Suena vinculado basado en mí. Sea MUY cuidadoso trabajando directamente con el DB como el anterior. Asegúrese de tener una copia de seguridad, de lo contrario podría romperlo todo.
Anthony Cicchelli

Estoy bastante seguro de que no es un problema de "interfaz" (por ejemplo, índice de URL), sino más bien un problema de "backend", en algún lugar profundo del código de Magento. Para mí, parece que Magento espera una cierta secuencia / combinación de website_id / store_id, donde si eliminas algunas identificaciones "en el medio", magento no puede hacer coincidir y cargar esas website_id.
Ottonet

Respuestas:


2

Tuve un problema similar en la tienda de un solo sitio web y lo resolví con la siguiente 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;
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.