Magento полностью сломан:Вызов функции-члена getCode() для логического значения & Не была настроена или найдена страница 404 CMS.

https://magento.stackexchange.com//questions/87164

13-12-2019
|

Вопрос

Внезапно (без каких-либо изменений или обновлений) наша установка magento кажется полностью сломанной.

Каждый день мы получаем некоторые из этих ошибок:

При доступе к /index не была настроена или найдена страница 404 CMS.
Установщик magento внезапно появляется при доступе к /index
Ни один шаблон не отображается (как показано на рисунке)

Странные редиректы.Когда кажется, что все работает (нет ошибки 404 cms, нет проблем с шаблоном), и я пытаюсь посетить продукт, меня иногда перенаправляют на домашнюю страницу.

Ну, что я сделал до сих пор:

очищенная папка кэша, очищенная папка сеанса
усеченная таблица 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.Х.Х, сервер:www.example.com, запрос:«GET /index.php/customer/account/login/HTTP/1.1», восходящий поток:"fastcgi://unix:/var/run/php5-fpm.sock:", хост:«www.example.com», реферер:"example.com"

Но с нашими магазинами тоже все в порядке:

Решение

После болтаю с @moose Я сам решил опубликовать это как ответ.Благодаря Нексесс за то, что указал @moose на мою статью и таким образом удовлетворил мою ненасытную жажду звезд в моем репозитории на GitHub.

Существует основная ошибка кэша конфигурации magento, которая вызывает ошибку «Страница CMS не настроена 404» или — в других случаях — ошибку «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-маршрутизатор-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

И по историческим причинам или на случай, если моя учетная запись GitHub когда-нибудь будет удалена.

/**
* 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

Этот файл патча решит все разумные экземпляры ванильного magento (все, что повторно инициализирует кеш конфигурации с использованием определенного init или reinit методы).

Если у вас есть код, который вызывает loadDb функция - нравится n98-magerun - тогда вам, вероятно, придется плохо, и вам, вероятно, следует подумать о рефакторинге вашего кода для вызова reinit или init на Mage_Core_Model_Config.

Если у вас все еще есть проблемы, я рекомендую вам прочитать мою статью и

Реализовать логику, упомянутую в Отладка проблемы раздел.
Подождите, пока появятся некоторые данные журнала.
Свяжитесь со мной!

Теория о том, почему supere 6788 усугубляет ошибку

Я только что разместил это в чате и решил разместить здесь для потомков.

Что -то, что нужно помнить, это то, что у Magento всегда была эта ошибка на своем фоне.И этот Supee 6788 только что сделал это чем -то, что с большей вероятностью произойдет

Я только что посмотрел патч supee 6788 для EE1.14. Это моя рабочая теория.

Mage_Core_Controller_Varien_Router_Admin был исправлен, чтобы переопределить addModule функция

Я не могу точно вспомнить порядок, в котором все происходит во время инициализации запроса мага. Но эта модификация теперь добавляет два вызова Mage::getConfig()->getNode() для каждого отдельного запроса, довольно рано в потоке.Если во время любого из этих двух вызовов происходит ошибка параметра кэша объекта с помощью useCache, это потенциально может привести к записи неполной конфигурации в кеш (getNode может инициировать повторную инициализацию, поскольку он пытается загрузить значения из кэша и неудачная загрузка, он повторно инициализирует весь кеш конфигурации и повторно сохранит его с помощью функции reinit())

Так что, возможно, просто добавив эти два дополнительных getNodes в очень раннюю часть запроса, когда полная конфигурация не может быть загружена, может привести к тому, что эта ошибка произойдет в любом случае, я бы не стал потеть полным пониманием проблемы.Это было бы много работы не для большого усиления, и изучение MAGE_CORE_MODEL_CONFIG :: LOADDB (с акцентом на то, на каком эффекте флаг USECACHE может иметь на него) может свести с ума человека.

Другие советы

Из проблем, которые вы описываете, только точка 2 особенно знакома, но для того, что это стоит так, как мы решили его в нашем случае:

Есть ошибка в библиотеке phpxml phxml - я думаю, что это это -Это означает, что иногда Magento не сможет загрузить некоторые из собственных файлов конфигурации.Вы можете обнаружить, что это было некоторое обновление низкого уровня (PHP или одно из библиотек, которые он полагается), который привел проблему на открытой.

Попробуйте добавить эту строку на index.php, прямо рядом с началом (я поставил его сразу после проверки версии PHP):

libxml_disable_entity_loader(false);

Nexcess (Magento Platinum Hosting Partner) указал мне в решение на Github (Big Kudos для Люк Роджерс , автор патча)

Magento Bug - поврежден Conture Cache

patch_supee-4755_ee_1.13.1.0_v1.sh

Этот патч точно такой же, как мое исправление, которое дает ему какую-то действительность.

Этот патч не публично перечислен в любом месте, потому что Magento не делает Это для чего-либо, кроме исправлений безопасности по какой-то причине. Я знаю то Патч-файл говорит, что EE_1.13.1.0, но я проверил его на сообществе Edition 1.9 И это применяется нормально.

Эта страница дает вам Полное объяснение И возможность воспроизвести ошибку, запустив HTTPS://github.com/ampersandhq//giteb.com/ampersandhq/magent-bug/blobfig-corruption-bug/blob/master/100-router-script.php "Rel="nofollow noreferrer"> 100-маршрутизатор-скрипт.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. Если это не работает для вас, то я Рекомендовать вас

.
реализуйте логику, упомянутую в отладке раздела проблемы.

ждать, пока некоторые данные журнала появляются.

Свяжитесь со мной!

Поскольку у меня нет никакого ответа надолго (а наш магазин в производстве для клиента) мне нужно было придумать свое собственное решение.Я поделюсь этим, может быть, это может помочь найти проблему:

в моем index.php я изменил:

/* Store or website code */
$mageRunCode = isset($_SERVER['MAGE_RUN_CODE']) ? $_SERVER['MAGE_RUN_CODE'] : '';

/* Run store or run website */
$mageRunType = isset($_SERVER['MAGE_RUN_TYPE']) ? $_SERVER['MAGE_RUN_TYPE'] : 'store';

Mage::run($mageRunCode, $mageRunType);

to:

$mageRunCode = 'default';
$mageRunType = 'store';

Mage::app()->setCurrentStore(1);
Mage::run($mageRunCode, $mageRunType, array('is_installed' => true));

Это жестко и работает только, потому что у нас просто есть один магазин.Но все же, похоже, сейчас работает.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с magento.stackexchange