الماجنتو مكسور تماما:استدعاء دالة العضو getCode() على القيمة المنطقية ولم يتم تكوين أو العثور على صفحة 404 CMS

Question

فجأة (دون أي تغييرات أو تحديثات) يبدو أن تثبيت الماجنتو الخاص بنا معطل تمامًا.

كل يوم نتلقى الآن بعضًا من هذه الأخطاء:

1. لم يتم تكوين صفحة 404 CMS أو العثور عليها عند الوصول إلى /index.
2. يظهر مثبت الماجنتو فجأة عند الوصول إلى /index
3. لا يظهر القالب (كما هو موضح في الصورة)

4. عمليات إعادة توجيه غريبة.عندما يبدو أن كل شيء يعمل (لا يوجد خطأ 404 سم، ولا توجد مشكلات في القالب) وأحاول زيارة أحد المنتجات، تتم إعادة توجيهي أحيانًا إلى الصفحة الرئيسية.

حسنًا، ما فعلته حتى الآن هو:

1. مسح مجلد ذاكرة التخزين المؤقت، مسح مجلد الجلسة
2. الجدول المقطوع core_url_rewrite

يبدو أن العمل.بعد إعادة الفهرسة (core_url_rewrite) بدا كل شيء معطلاً مرة أخرى لذا قمت باقتطاعه مرة أخرى.مع وجود core_url_rewrite الفارغ، بدا الأمر على ما يرام.ولكن في اليوم التالي تم كسره مرة أخرى.

حسنًا، اليوم هو نفسه مرة أخرى ولكن اليوم أيضًا هي المرة الأولى التي لا يعمل فيها مسح ذاكرة التخزين المؤقت والجلسات وcore_url_rewrite بعد الآن.

أوه وهذا يظهر في سجل أخطاء nginx الخاص بنا:

[خطأ] 11773#11773:*242799 تم إرسال FastCGI في stderr:"رسالة PHP:PHP خطأ فادح:استدعاء وظيفة العضو getCode() على المنطقي في /htdocs/seg_posorder/stage/app/code/core/Mage/Customer/Model/Session.php على السطر 71" أثناء قراءة رأس الاستجابة من المنبع، العميل:217.24.X.X، الخادم:www.example.com، اطلب:"الحصول على /index.php/customer/account/login/ HTTP/1.1"، المنبع:"fastcgi://unix:/var/run/php5-fpm.sock:"، المضيف:"www.example.com"، المُحيل:"example.com"

لكن متاجرنا تبدو أيضًا على ما يرام:

Answer 1

بعد اتحدث مع @moose لقد قررت نشر هذا كإجابة بنفسي.شكرا ل نيكزس لتوجيه @moose إلى كتاباتي، وبالتالي تغذية شهوتي النهمة للنجوم في مستودع جيثب الخاص بي.

يوجد خطأ أساسي في ذاكرة التخزين المؤقت لتكوين Magento والذي يتسبب في حدوث خطأ "لم يتم تكوين صفحة 404 CMS" أو - في حالات أخرى - خطأ "تكرار مطابقة جهاز التوجيه 100".يختفي الخطأ عند مسح ذاكرة التخزين المؤقت، ولكنه عادةً ما يظهر مرة أخرى بعد مرور بعض الوقت.

https://github.com/convenient/magento-ce-ee-config-corruption-bug

(يحرر:يمكن إضافة المزيد من التغييرات لمنع تلف التكوين: https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-2-further-improvements)

تكرار

تحقق من مستودع بلدي أعلاه.

لديه ملف 100-router-script.php والتي من شأنها أن تساعد في تكرار الخطأ لك عن طريق تشغيله في جذر موقع الويب الخاص بك.

التصحيح

أصدرت Magento تصحيحًا (SUPEE-4755) بناءً على كتابتي.

PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

هذا التصحيح هو نفس الإصلاح الذي قمت به والذي يمنحه بعض الصلاحية.

لم يتم سرد هذا التصحيح في أي مكان لأن Magento لا يفعل ذلك لأي شيء سوى تصحيحات الأمن لسبب ما.أعرف أن ملف التصحيح يقول EE_1.13.1.0 ، لكنني اختبرته على إصدار المجتمع 1.9 وتطبيقه بشكل جيد.

يمكنك الحصول على نسخة من التصحيح هنا:https://github.com/convenient/magento-ce-ee-config-corruption-bug/blob/master/PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

ولأسباب تاريخية أو في حالة حذف حساب جيثب الخاص بي

/**
* Initialization of core configuration
*
* @return Mage_Core_Model_Config
*/
public function init($options=array())
{
    $this->setCacheChecksum(null);
    $this->_cacheLoadedSections = array();
    $this->setOptions($options);
    $this->loadBase();

    $cacheLoad = $this->loadModulesCache();
    if ($cacheLoad) {
        return $this;
    }
    //100 Router Fix Start
    $this->_useCache = false;
    //100 Router Fix End
    $this->loadModules();
    $this->loadDb();
    $this->saveCache();
    return $this;
}

إذا لم يؤدي هذا إلى إصلاح مثيل Magento الخاص بك

سوف يحل ملف التصحيح هذا جميع مثيلات الفانيليا الماجنتو بشكل معقول (أي شيء يعيد تهيئة ذاكرة التخزين المؤقت للتكوين باستخدام init أو reinit طُرق).

إذا كان لديك أي رمز يستدعي loadDb وظيفة - مثل n98-magerun - فمن المحتمل أن تقضي وقتًا سيئًا وربما ينبغي عليك التفكير في إعادة صياغة التعليمات البرمجية الخاصة بك للاتصال reinit أو init على Mage_Core_Model_Config.

إذا كنت لا تزال تواجه مشكلة، أنصحك بقراءة كتابتي و

1. تنفيذ المنطق المذكور في تصحيح المشكلة قسم.
2. انتظر حتى تظهر بعض بيانات السجل.
3. اتصل بي!

نظرية حول سبب تفاقم الخطأ 6788

لقد نشرت هذا للتو في غرفة الدردشة وفكرت في وضعه هنا للأجيال القادمة.

شيء يجب تذكره هو أن Magento كان دائمًا هذا الخطأ في خلفيته.وهذا Supee 6788 قد جعلها شيء من المرجح أن يحدث

لقد ألقيت نظرة للتو على التصحيح 6788 لـ EE1.14 وهذه هي نظرية العمل الخاصة بي.

تم تصحيح Mage_Core_Controller_Varien_Router_Admin لتجاوز addModule وظيفة

الآن، لا أستطيع أن أتذكر تمامًا الترتيب الذي تحدث به الأشياء أثناء تهيئة طلب mage ولكن هذا التعديل يضيف الآن مكالمتين إلى Mage::getConfig()->getNode() في كل طلب على حدة، في وقت مبكر جدًا من التدفق.إذا كان هناك فشل في معلمة ذاكرة التخزين المؤقت للكائن مع useCache أثناء أي من هاتين الاستدعاءتين، فمن المحتمل أن يؤدي ذلك إلى تشغيل تكوين غير مكتمل يتم كتابته إلى ذاكرة التخزين المؤقت (يمكن لـ getNode تشغيل إعادة التهيئة، أثناء محاولته تحميل القيم من ذاكرة التخزين المؤقت، وعلى فشل التحميل، فسيقوم بإعادة تشغيل ذاكرة التخزين المؤقت للتكوين بالكامل وإعادة حفظها عبر وظيفة Reinit())

لذلك ربما مجرد إضافة هذين getnodes الإضافيين إلى جزء مبكر جدًا من الطلب ، عندما لا يتم تحميل التكوين الكامل ، يمكن أن يتسبب هذا الخطأ في حدوث في كلتا الحالتين ، ولن أتعرق بفهم كامل للمشكلة.سيكون الكثير من العمل لعدم وجود الكثير من المكاسب ، والبحث في mage_core_model_config :: loaddb (مع التركيز على التأثير الذي قد يكون له علامة usecache على ذلك) يمكن أن يقود رجل مجنون.

Answer 2

من المشاكل التي تصفها، فإن النقطة الوحيدة 2 مألوفة بشكل خاص، ولكن لما يستحق هذا هو كيفية حلها في علمنا:

هناك خطأ في مكتبة LIBXML في PHP - أعتقد أنه مما يعني أنه في بعض الأحيان فشل Magento في تحميل بعض ملفات التكوين الخاصة به.قد تجد أنه كان بعض التحديثات المنخفضة المستوى (PHP أو إحدى المكتبات التي تعتمد عليها) التي جلبت المشكلة في العراء.

حاول إضافة هذا السطر إلى index.php، بالقرب من البداية (أضعها بعد إصدار إصدار PHP):

giveacodicetagpre.

Answer 3

نيكزس (شريك استضافة Magento Platinum) وجهني إلى الحل الموجود على GitHub (مجد كبير لـ لوك رودجرز, ، مؤلف التصحيح)

خطأ Magento - ذاكرة التخزين المؤقت للتكوين تالفة

PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

هذا التصحيح هو نفس الإصلاح الذي قمت به والذي يمنحه بعض الصلاحية.

لم يتم سرد هذا التصحيح في أي مكان لأن Magento لا يفعل ذلك لأي شيء سوى تصحيحات الأمن لسبب ما.أعرف أن ملف التصحيح يقول EE_1.13.1.0 ، لكنني اختبرته على إصدار المجتمع 1.9 وتطبيقه بشكل جيد.

هذه الصفحة تمنحك شرح كامل والقدرة على إعادة إنتاج الخطأ عن طريق تشغيل 100-router-script.php من الدليل الجذر الخاص بك (وهذا أدى إلى تكرار المشكلة بالنسبة لي، المحاولة الأولى).

المأزق:

/**
* Initialization of core configuration
*
* @return Mage_Core_Model_Config
*/
public function init($options=array())
{
    $this->setCacheChecksum(null);
    $this->_cacheLoadedSections = array();
    $this->setOptions($options);
    $this->loadBase();

    $cacheLoad = $this->loadModulesCache();
    if ($cacheLoad) {
        return $this;
    }
    //100 Router Fix Start
    $this->_useCache = false;
    //100 Router Fix End
    $this->loadModules();
    $this->loadDb();
    $this->saveCache();
    return $this;
}

ويمضي في القول:

سيكون من السذاجة أن أؤمن بأن هذا سيحل تمامًا مشكلة إعداد Magento للجميع.إذا لم ينجح ذلك من أجلك ، فإنني أوصيك

• قم بتنفيذ المنطق المذكور في قسم تصحيح المشكلة.
• انتظر حتى تظهر بعض بيانات السجل.
• اتصل بي!

Answer 4

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

في index.php، قمت بتغيير:

giveacodicetagpre.

إلى:

giveacodicetagpre.

هذا هو الصغار ويعمل فقط لأن لدينا فقط متجر واحد.ولكن لا يزال، يبدو أنه يعمل الآن.