Magento Backend 404 dla wszystkich zakresów konfiguracji „WWW” oprócz dwóch

14

W naszej Multiwebsite / Multistore (zobacz) Magento 1.9.2.2 jedna ze stron internetowych, w tym jej sklep i widok sklepu, musiała zostać usunięta.

Chociaż samo usunięcie poszło dobrze (robiłem to już wcześniej), skończyłem z backendem 404, jeśli zmienisz swój aktualny zakres konfiguracji na dowolne oprócz dwóch stron internetowych.

Wybranie nowego zakresu konfiguracji powoduje wysłanie żądania następującego adresu URL (ścieżka administratora + klucz zostały zmienione):

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

gdzie <WEBSITE>jest równe codepolu w core_websitetabeli.

Po zalogowaniu się do zapytania mysql widzę, że dwie strony internetowe, które można załadować pomyślnie, mają następujące zapytania dotyczące wyboru strony / sklepu:

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

Inne strony internetowe, które podają 404, zaczynają się od tego samego pierwszego zapytania - ale oczywiście innego scope_id, ale w drugim zapytaniu Magento uważa, że ​​musi szukać zakresu storeviewzamiast website! Wygląda na to, że próbuje się dwa razy.

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

Moja tabela core_website wygląda następująco:

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 = ładują się OK, failing_xxx = dają 404 / spróbuj wybrać nieistniejący identyfikator sklepu.

Moja tabela core_store wygląda następująco: (kod + nazwa została usunięta, ponieważ nie dotyczy)

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

A to jest 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

Porównałem te trzy tabele z kopią zapasową bazy danych przed usunięciem strony / widoku sklepu i - z wyjątkiem usunięcia tej strony / widoku sklepu - wszystko wygląda dokładnie tak samo. Te same identyfikatory, te same kody itp.

O ile wiem, te trzy tabele są jedynymi, które są sprawdzane przez Magento pod kątem kodu sklepu / strony internetowej i identyfikatorów.

Jeśli chodzi o rozwiązywanie problemów, zrobiłem następujące: Aby zapewnić brak pamięci podręcznej ze starą konfiguracją, w której pozostawiono: opróżnianie pamięci var / cache, opróżnianie pamięci podręcznej, ponowne indeksowanie, ponowne uruchamianie serwera itp., Wszystko bezskuteczne.

Nawet przy logowaniu się php / magento, trybie programisty itp. Nie mam żadnych wskazówek, dlaczego tak się dzieje. Nie są rejestrowane żadne wyjątki.

Więc dwa pytania brzmią: dlaczego Magento próbuje wybrać nieistniejący zakres widoku sklepu zamiast zakresu strony internetowej i jak to naprawić?

Aktualizacja 1 / Obejście

Po długim dniu rozwiązywania problemów, w tym między innymi narzędzia do naprawy magento-db, ponownego tworzenia tabel core_store, core_store_group i core_website, ze wszystkimi oryginalnymi stronami internetowymi i widokami sklepów, w końcu zauważyłem:

Dla wszystkich website_idładujących się dobrze jest store_idten sam numer. website_id 1i 4ładują się zgodnie z oczekiwaniami, i rzeczywiście są (niepowiązane)store_id 1 i 4zdefiniowane.

Na website_id 3, 6, 7, 8i9 tam nie jest store_idz tym samym numerem.

Jednak gdy utworzyłem fałszywy wpis store_id, na przykład 3ładowanie zakresu konfiguracjiwebsite_id 3 zaczęło działać ponownie.

Tak więc, mimo że z powodzeniem wprowadziłem obejście, skończyłem z jedną dodatkową (wyłączoną) witryną i 5 (wyłączonymi) widokami sklepu ....

Aby mieć pewność, że wcześniej nie stanowiło to problemu, poszedłem do jednej ze starszych kopii naszej strony, którą przechowuję na moim serwerze deweloperskim (magento wersja 1.9.1.0).

Tutaj wszystko działa idealnie, tzn. website_id 6Ładunki bez potrzeby store_id 6w core_storetabeli.

Ottonet
źródło
Muszę zapytać, czy indeksowałeś URL, kiedy wszystko zmieniłeś?
Anthony Cicchelli,
Cześć @AnthonyCicchelli, dzięki za pytanie. To była właściwie jedna z pierwszych rzeczy, które próbowałem rozwiązać, ale bezskutecznie :(
Ottonet
Trudno powiedzieć z tego powodu, ponieważ istnieje wiele czynników, czy opróżniłeś cały adres URL z bazy danych i ponownie uruchomiłeś adres URL. Dźwięki powiązane ze mną. Bądź BARDZO ostrożny, pracując bezpośrednio z DB tak jak powyżej. Upewnij się, że masz kopię zapasową, w przeciwnym razie wszystko może się zepsuć.
Anthony Cicchelli
Jestem prawie pewien, że nie jest to problem „frontendowy” (np. Indeks URL), ale bardziej problem „backendowy”, gdzieś głęboko w kodzie magento. Wydaje mi się, że Magento oczekuje określonej sekwencji / kombinacji id_partycji / id_sklepu, gdzie jeśli usuniesz jakieś identyfikatory „na środku”, magento nie będzie w stanie dopasować i załadować tych identyfikatorów.
Ottonet,

Odpowiedzi:

2

Miałem podobny problem w sklepie z jedną witryną i rozwiązałem następujące zapytanie.

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;
Ricardo Martins
źródło