Magento बैकएंड 404 सभी लेकिन दो "वेबसाइट" कॉन्फ़िगरेशन स्कोप के लिए

Question

हमारी मल्टीव्यू / मल्टीस्टोरी (दृश्य) में Magento 1.9.2.2 कॉन्फ़िगरेशन में से एक वेबसाइट, जिसमें यह स्टोर और स्टोरव्यू भी शामिल है, को हटाया जाना था।

जबकि निष्कासन अपने आप ठीक हो गया (मैंने पहले भी ऐसा किया है), मैंने एक बैकएंड के साथ समाप्त किया है कि 404 के यदि आप अपने करंट कॉन्फ़िगरेशन स्कोप को किन्हीं दो वेबसाइटों में बदलते हैं।

निम्न url के अनुरोध में एक नया कॉन्फ़िगरेशन स्कोप परिणाम का चयन करना (व्यवस्थापक पथ + कुंजी बदल जाती है):

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

जहाँ तालिका में फ़ील्ड के <WEBSITE>बराबर है ।codecore_website

Mysql क्वेरी लॉगिंग के साथ मैं देखता हूं कि जिन दो वेबसाइटों को सफलतापूर्वक लोड किया जा सकता है उनमें वेबसाइट या स्टोरेज को चुनने के संबंध में ये प्रश्न हैं:

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

अन्य वेबसाइटें जो 404 को एक ही पहली क्वेरी के साथ शुरू करती हैं - लेकिन निश्चित रूप से एक अलग स्कोप_आईडी, लेकिन दूसरी क्वेरी में मैगेंटो को लगता है कि इसके storeviewबजाय एक स्कोप की तलाश करनी होगी website! यह वास्तव में दो बार प्रयास करने लगता है।

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

मेरी core_website तालिका इस प्रकार है:

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 = ये लोड ठीक है, failing_xxx = ये 404 देते हैं / गैर-मौजूदा store_id को चुनने का प्रयास करते हैं।

मेरा core_store टेबल निम्नानुसार दिखता है: (कोड + नाम प्रासंगिक के रूप में हटाया गया)

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

और यह 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

मैंने इन तीन तालिकाओं की तुलना डीबी की मेरी बैकअप प्रति से पहले की है जब तक मैंने वेबसाइट / स्टोरव्यू को हटा दिया और -वैकल्पिक वेबसाइट को हटाने के लिए / स्टोरव्यू- सब कुछ बिल्कुल एक जैसा दिखता है। समान आईडी, समान कोड आदि।

जहां तक ​​मुझे पता है कि ये तीन टेबल केवल वही हैं जो मैगेंटो द्वारा स्टोरव्यू / वेबसाइट कोड और आईडी के लिए चेक किए गए हैं।

समस्या निवारण के लिए, मैंने निम्नलिखित कार्य किया है: पुराने कॉन्फ़िगरेशन के साथ कोई कैश को सुनिश्चित करने के लिए जहां छोड़ दिया गया है: खाली किया गया var / cache, flushed caches, reindexed, सर्वर आदि को रिबूट किया गया, जिसका कोई फायदा नहीं हुआ।

यहां तक ​​कि सभी php / magento पर लॉग ऑन, डेवलपर मोड आदि के साथ, मुझे शून्य सुराग मिलता है क्योंकि यह क्यों हो रहा है। कोई अपवाद लॉग नहीं है।

तो दो सवाल हैं: क्यों Magento वेबसाइट के दायरे के बजाय एक गैर-मौजूद स्टोरव्यू गुंजाइश चुनने की कोशिश कर रही है और इसे कैसे ठीक किया जाए?

अद्यतन 1 / समाधान

समस्या निवारण के एक लंबे दिन के बाद, लेकिन सभी मूल वेबसाइटों और स्टोर के विचारों के साथ core_store, core_store_group और core_website तालिकाओं को फिर से बनाना, मैगेंटो-डीबी-रिपेयर टूल तक सीमित नहीं है, जिनमें से मैंने निम्नलिखित पर ध्यान दिया है:

सभी के website_idलिए ठीक लोड एक store_idही नंबर के साथ है। website_id 1और 4अपेक्षा के अनुसार लोड हो रहे हैं, और वास्तव में (असंबंधित) store_id 1और 4परिभाषित हैं।

के लिए website_id 3, 6, 7, 8और 9वहाँ कोई है store_idही नंबर के साथ।

हालाँकि, एक बार जब मैंने एक नकली प्रविष्टि बनाई store_id, उदाहरण के लिए 3, website_id 3फिर से काम करना शुरू करने के कॉन्फ़िगरेशन स्कोप को लोड करना।

इसलिए जब मैंने अब सफलतापूर्वक जगह बना ली है, तो मैंने एक अतिरिक्त (अक्षम) वेबसाइट और 5 (अक्षम) स्टोर स्टोर के साथ काम किया ...

यह सुनिश्चित करने के लिए कि यह पहले कोई समस्या नहीं थी, मैं हमारी साइट की पुरानी प्रतियों में से एक पर गया था जिसे मैं अपने देव सर्वर (मैगेंटो संस्करण 1.9.1.0) पर रखता हूं।

यहां सब कुछ पूरी तरह से काम करता है, यानी टेबल में website_id 6बिना जरूरत के लोड होता है । store_id 6core_store

Comments

मुझे पूछना होगा कि क्या आपने सबकुछ बदलने पर URL अनुक्रमण किया है?

— एंथनी सिसचेली

अरे @AnthonyCicchelli, पूछने के लिए धन्यवाद। यह वास्तव में पहली चीजों में से एक था जिसे मैंने इस मुद्दे को हल करने की कोशिश की, लेकिन कोई फायदा नहीं हुआ :(

— ओटनटेट

यहाँ से यह बताना मुश्किल है कि बहुत सारे कारक हैं, क्या आपने अपने सभी URL को DB से निकाल दिया है और URL को फिर से चला रहे हैं। मेरे आधार पर जुड़े हुए लगता है। बहुत सावधानी से ऊपर की तरह DB के साथ सीधे काम कर रहे हैं। सुनिश्चित करें कि आपके पास एक बैकअप है अन्यथा यह सब कुछ तोड़ सकता है।

— एंथनी सिश्चेली

मुझे पूरा यकीन है कि यह "फ्रंटएंड" मुद्दा नहीं है (उदाहरण के लिए URL-index), लेकिन अधिक "बैकएंड" समस्या, कहीं मैगेंटो कोड में गहरी नहीं है। मेरे लिए ऐसा लगता है कि Magento वेबसाइट_id / store_id के एक निश्चित अनुक्रम / संयोजन की अपेक्षा करता है, जहां यदि आप कुछ id के "बीच में" हटाते हैं, तो magento उन वेबसाइट_id को मैच और लोड करने में असमर्थ है।

— ओट्टोनेट

Answer 1

मेरे पास एकल-वेबसाइट स्टोर पर समान मुद्दा था, और निम्नलिखित क्वेरी के साथ हल किया गया था।

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;