Trong cấu hình Multiwebsite / Multistore (view) Magento 1.9.2.2 của chúng tôi, một trong những trang web, bao gồm cả cửa hàng và kho lưu trữ phải bị xóa.
Mặc dù việc gỡ bỏ đã diễn ra tốt đẹp (tôi đã thực hiện việc này trước đây), tôi đã kết thúc với phần phụ trợ là 404 nếu bạn thay đổi Phạm vi cấu hình hiện tại của mình thành bất kỳ ngoại trừ hai trang web.
Chọn Phạm vi cấu hình mới dẫn đến yêu cầu cho url sau (đường dẫn quản trị + khóa được thay đổi):
/index.php/mymageadmin/system_config/edit/section/dev/website/<WEBSITE>/key/1221231/
trong đó <WEBSITE>bằng với codetrường trong core_websitebảng.
Với đăng nhập truy vấn mysql trên tôi thấy rằng hai trang web có thể được tải thành công có các truy vấn này liên quan đến việc chọn trang web / repositoryeview:
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')
Các trang web khác cung cấp 404 bắt đầu với cùng một truy vấn đầu tiên - nhưng tất nhiên là một scope_id khác, nhưng trong truy vấn thứ hai, Magento nghĩ rằng nó phải tìm một phạm vi storeviewthay vì website! Nó thực sự dường như cố gắng hai lần.
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
Bảng core_website của tôi trông như sau:
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
work_xxx = những tải này OK, failing_xxx = những cái này cung cấp 404 / thử chọn một store_id không tồn tại.
Bảng core_store của tôi trông như sau: (mã + tên bị xóa vì không liên quan)
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
Và đây là 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
Tôi đã so sánh ba bảng này với bản sao lưu DB của mình trước khi tôi xóa trang web / repositoryeview và - ngoại trừ việc xóa trang web / repositoryeview nói - mọi thứ trông giống hệt nhau. Cùng một ID, cùng mã, v.v.
Theo như tôi biết thì ba bảng này là những bảng duy nhất được Magento kiểm tra về số lần xem trang web / mã trang web và ID.
Đối với việc khắc phục sự cố tôi đã thực hiện như sau: Để đảm bảo không có bộ nhớ cache với cấu hình cũ ở bên trái: làm trống var / cache, bộ đệm bị xóa, reindexed, khởi động lại máy chủ, v.v., tất cả đều vô ích.
Ngay cả với tất cả đăng nhập php / magento, chế độ nhà phát triển, v.v., tôi không có manh mối nào về lý do tại sao điều này xảy ra. Không có ngoại lệ được ghi lại.
Vì vậy, hai câu hỏi là: Tại sao Magento cố gắng chọn phạm vi kho lưu trữ không tồn tại thay vì phạm vi trang web và cách khắc phục điều này?
Cập nhật 1 / Giải pháp thay thế
Sau một ngày dài khắc phục sự cố, bao gồm nhưng không giới hạn ở công cụ sửa chữa magento-db, tạo lại các bảng core_store, core_store_group và core_website, với tất cả các trang web gốc và lượt xem cửa hàng, cuối cùng tôi cũng nhận thấy như sau:
Đối với tất cả các website_idtải tốt đó có một store_idcùng một số. website_id 1và 4đang tải như mong đợi, và thực sự có (không liên quan) store_id 1và 4được xác định.
Đối với website_id 3, 6, 7, 8và 9không có là store_idvới cùng một số.
Tuy nhiên, ví dụ , khi tôi tạo một mục giả mạo , tải Phạm vi cấu hình bắt đầu hoạt động trở lại.store_id3website_id 3
Vì vậy, trong khi bây giờ tôi đã đặt một cách giải quyết thành công, tôi đã kết thúc với một trang web bổ sung (bị vô hiệu hóa) và 5 lượt xem cửa hàng (bị vô hiệu hóa) ....
Để chắc chắn rằng đây không phải là vấn đề trước đây, tôi đã đi đến một trong những bản sao cũ của trang web mà tôi giữ trên máy chủ dev của mình (phiên bản magento 1.9.1.0).
Ở đây tất cả mọi thứ hoạt động hoàn hảo, tức là website_id 6tải mà không cần một store_id 6trong các core_storebảng.