المنتج توجيه الحلقات

Question

لدينا الماجنتو موقع (1.6.2) على ليمب الخادم التي كان يعمل لأكثر من 2 سنوات.مؤخرا قمنا بعمل بعض التغييرات ؛

• تغيير الموقع بالكامل إلى HTTPS.
• أوجد جميع فئات جديدة و حصلت على التخلص من القديم منها ولكن تبقى نفس المنتجات

• إنشاء ملقم الموجهات في شكل من الأشكال ؛

  الموقع /هذا/old/الفئة { كتابة ^(هذا/old/الفئة)/?(.*)$ https://oursite.co.uk/new/category2 دولار دائم ؛ }

يعمل هذا لكل فئة صفحات أي من المنتجات داخلها و كنا نظن أننا الأفضل!

لكن جوجل WMT بدأت تظهر الكثير من الارتباطات عناوين لذا نحن التحقيق وجدت أن العديد من المنتجات التي يجري توجيهها بشكل غريب مما أسفر عن توجيه الحلقات.

في كروم علامة التبويب الشبكة أستطيع أن أرى ذلك عندما تذهب إلى عنوان URL القديم من بعض المنتجات الملقم إعادة توجيه الركلات في الحصول على الرد المناسب.ومع ذلك ، هناك ثم يلي (لانهائية على ما يبدو) الموجهات التي تأخذ شكل ؛

random/old/category/random/old/category/random/old/category/random/old/category/random/old/category/random/old/category/random/old/category/random/old/category/random/old/category/product-name

في الأساس فإنه يضيف "عشوائية/old/الفئة" مع كل طلب على.لدينا تستضيف ملقم مصرا على أنه هو هو) الماجنتو (لا مشكلة) و ب) يجب أن يكون السابق مائل.

أنا لا يمكن العثور على أي الإعدادات التي من شأنها أن تسبب هذا.

• "استخدام ملقم ويب إعادة توجيه" يتم تعيين إلى "نعم".
• لقد استخدمت "البقرى" على نص تفريغ قاعدة البيانات لدينا في محاولة العثور على أي قوع واحد من المتضررين من عناوين المواقع (مع عدم وجود الفرح, و أنا متأكد من أن هذا لن يكون الحال بسبب النقطة 1).
• كما يدويا من خلال منطقة مشرف مع غرامة toothcomb و لا يمكن أن نرى أي أسباب.

آمل أن يكون هذا هو ما يكفي من المعلومات.يمكن لأحد أن يقول لي أين إعادة توجيه يمكن أن يحدث خلاف على الخادم ؟

تحديث:

كما دوغلاس أشار يبدو الجديدة URL إعادة توجيه أيضا ولكن يجب التحقق .الملف conf الموقع (و غيرها) و لا توجد قاعدة والتي من شأنها أن تسبب هذا.

UPDATE2:

لقد كان طفيف اختراق.ويبدو أنه عندما الماجنتو لا يمكن العثور على المنتجات في فئة يتم توجيهك إلى ، وسوف يدور في حلقة.لماذا يفعل هذا بدلا من مجرد 404 هو لغزا بالنسبة لي حتى تساعد على أن تكون جيدة جدا!

UPDATE3:

3 سنوات خادم نقل الكثير من الخبرة و ترقية إلى CE 1.9.3.8 في وقت لاحق أعتقد أنني قد حققت تقدما!

وأنا أعلم الآن يقينا أن هذا هو الماجنتو التوجيه المشكلة ، كما عند إضافة die(); خط في index.php إعادة توجيه حلقة لا occurr.

أضفت هذا تسجيل كود (التي يمكن العثور عليها في العديد من الأماكن على شبكة الإنترنت) ، Mage_Core_Controller_Varien_Front الدرجة:

Mage::log('----Matching routers------------------------------');
Mage::log('Total ' . count($this->_routers) . ': ' . implode(', ', 
array_keys($this->_routers)));
while (!$request->isDispatched() && $i++<100) {
    Mage::log('- Iteration ' . $i);
    $requestData = array(
        'path_info' => $request->getPathInfo(),
        'module' => $request->getModuleName(),
        'action' => $request->getActionName(),
        'controller' => $request->getControllerName(),
        'controller_module' => $request->getControllerModule(),
        'route' => $request->getRouteName()
    );

    $st = '';
    foreach ($requestData as $key => $val) {
        $st .= "[{$key}={$val}]";
    }
    Mage::log('Request: ' . $st);
    foreach ($this->_routers as $name => $router) {
        if ($router->match($this->getRequest())) {
            Mage::log('Matched by "' . $name . '" router, class ' . 
    get_class($router));
            break;
        }
    }
}

من قليلا من البحوث وفهم التعليمات البرمجية في هذه الفئة ، الماجنتو يبحث عن الموجه من النظام (سواء الأساسية أو وحدات) على تحمل مسؤولية $request و مرة واحدة المباريات وسوف ترسل إرسال إشارة.

مع تسجيل رمز أعلاه لدي قائمة من أجهزة التوجيه ولكن لا معلومات في $requestData مجموعة مما يشير إلى أن جهاز التوجيه لم إيفاد.

في كل سرد التوجيه ذهبت إلى Controller/Router.php الملف وجدت match(Zend_Controller_Request_Http $request) الأسلوب.في السطور قبل هذا الأسلوب عاد صحيح (دلالة مطابقة) أضفت بسيطة صدى خط E. G:

echo "matched in the xxx module"; die();

هذا أدى إلى إيجاد جهاز التوجيه المسؤول وأنا المشتبه به أن لا يتم إرسال الطلب بعد مطابقة وبالتالي فإنه يبقى مجرد حلقات.وحدة مسؤولة MageWorx_SeoSuite, أعتقد أنه قد تم تعديلها من قبل طرف ثالث في الماضي منذ أن كنت يمكن أن تجد أي إشارات إلى هذا على الانترنت.المزيد من التحقيق اللازمة التي سأعمل بأسرع ما يمكن.

Answer 1

اتضح أن match(Zend_Controller_Request_Http $request) في MageWorx_SeoSuite كان جهاز التوجيه بيان التبديل الذي حل CMS, Rss, Category, Category_layer وغيرها من الطرق.

المشكلة كانت مع default (قراءة:المنتج) حالة استخدام رمز التبديل هذا البيان.كانت حالة فريدة من نوعها (وهو ما يفسر السبب في أنه يؤثر فقط على عدد قليل من المنتجات).

الأمر ؛

• تحقق مما إذا كان نهاية url (أنا.هـ:المنتج urlKey) كان كتابة ، إذا لم;
• تحقق مما إذا كان أدنى مستوى الفئة من قال المنتج كان كتابة ، إذا لم;
• تحميل المنتج من قبل معرف وجلب Url الكنسي من MageWorx_SeoSuite مساعد الطبقة ؛
• إرسال رسالة إعادة توجيه إلى Url الكنسي وتحديث رد باستخدام سابق تعريف HTTP رمز الاستجابة اعتمادا على إعدادات التكوين.
• exit();

إذا كان أي من الأولين عبارة شرطية كانت كاذبة;طريقة سوف return false; (I. E:جهاز التوجيه لا يطابق).ومع ذلك ، إذا كان كل من الأولين الشرطية تقييم true وبعض الضوابط الأخرى مرت (Url الكنسي لم يكن فارغا الخ) ؛ بيان من شأنه أن يبعث إعادة توجيه ثم ببساطة exit();.

أنا جديدة على التوجيه methology ولكن أنا أصدق أن هناك عدد قليل من الأشياء الخطأ في هذا ؛

1. الطريقة لم تعد منطقية لجميع طرق الشرطية (على سبيل المثال إذا كان المنتج هو imediate الفئة قد لا كتابة).
2. على طريقة أن "المباراة" ولكن لم يكن dispatchد'.
3. وهذا يستند إلى محدودة (البكالوريوس) المعرفة ولكن:هذا يبدو سيئا حقا تصميم البرمجيات.

من الجدير بالذكر في هذا الوقت ، لأنني لا أريد أن لائحة MageWorx دون الحقائق:أنا متأكد من أن هذه البرمجية قد تم تغييره في آخر 5 سنوات (حيث العديد من شركات الطرف الثالث يمكن أن يكون مسؤولا).

في ملخص:لقد علق بها default: بيان حالة في التبديل بحيث الماجنتو الأساسية ويتحمل المسؤولية.الجاني عناوين الآن الذهاب إلى 404, no-route الصفحة التي هي مثالية لأنها كلها قديمة غير موجودة مسارات.أنا في العادة لا يغير الوحدة البرمجية في هذه هاب الخطر الطريقة ولكن يجب توثيق هذا جيدا ونحن في وضع حسن الحظ أن النسخة الجديدة من موقعنا على الانترنت هو قيد التطوير ، وبالتالي فإن "الإصلاح" هو مؤقت.