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 code
polu w core_website
tabeli.
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 storeview
zamiast 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_id
ten sam numer. website_id
1
i 4
ładują się zgodnie z oczekiwaniami, i rzeczywiście są (niepowiązane)store_id
1
i 4
zdefiniowane.
Na website_id
3
, 6
, 7
, 8
i9
tam nie jest store_id
z 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
6
w core_store
tabeli.
źródło
Odpowiedzi:
Miałem podobny problem w sklepie z jedną witryną i rozwiązałem następujące zapytanie.
źródło