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` ASCMoja 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 0working_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 1A 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 31Poró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.