Результаты домашней страницы 404 после обновления
Мы недавно обновили версию с 1.10 до 1.13, и у нас возникли некоторые проблемы с нашей домашней страницей. Все остальные страницы cms функционируют должным образом, но домашняя страница постоянно возвращает cms 404. Неважно, какую страницу cms мы выберем в качестве домашней страницы, она всегда возвращает 404.
Представление магазина настроено правильно, URL-адрес домашней страницы установлен на cms, и я не могу найти никаких записей в core_url_rewrite с пустым полем request_path.
Все работало прекрасно в нашей среде разработки.
В качестве исправления пробелов до тех пор, пока мы не найдем реальное решение, у нас есть страница 404 magento, настроенная для загрузки страницы cms, которая должна использоваться на реальной домашней странице. Пользователи не замечают разницы, но главная страница нашего сайта по-прежнему технически выдает 404.
Есть какие-нибудь мысли о том, что здесь происходит?
РЕДАКТИРОВАТЬ
Виновником был продукт с пустым URL-ключом. До сих пор в нашей загрузке продукта было несколько случаев рабочий процесс, в котором продукт будет добавлен в magento из нашей erp-системы до того, как у него появится имя. URL-ключ генерируется на основе названия продукта, поэтому у этих продуктов нет URL-ключа. В 1.10 это, по-видимому, не было проблемой. 1.13, однако, рассматривает это так, как если бы мы ввели корень документа в качестве URL-ключа. Поскольку перенаправления URL-адресов продуктов заменяют перенаправления cms, magento пытался указать на этот продукт. Он возвращал 404, потому что продукт был помечен как "не видимый индивидуально".
4 answers
Вы не выберетесь из этого без небольшой отладки. Следующее относится к Magento CE, но должно иметь отношение к Magento EE. Кроме того, в этом посте обобщен большой материал, найденный в моей серии рассылок Magento. Если вы хотите действительно заняться отладкой снизу вверх, начните с этого.
Для начала, большинство проблем Magento, которые я вижу, сводятся к "Я действительно был уверен, что эта вещь была X, но на самом деле это было Y". Даже если вы абсолютно уверен в том, что я говорю вам проверить, убедитесь, что вы действительно это проверили.
Маршрутизация домашней страницы Magento обрабатывается объектом Mage_Core_Controller_Varien_Router_Standard
. Первая ключевая часть - это эта строка
#File: app/code/core/Mage/Core/Controller/Varien/Router/Standard.php
$p = explode('/', $this->_getDefaultPath());
Метод _getDefaultPath
проверяет конфигурацию вашего магазина Magento на наличие установленного значения.
protected function _getDefaultPath()
{
return Mage::getStoreConfig('web/default/front');
}
Какая конфигурация соответствует
System -> Configuration -> Web -> Default Pages -> Default Web URL
Трижды проверьте, что это значение равно строке
`cms`
И что ваш core_config_data
таблица
select * from core_config_data where path = 'web/default/front';
Не содержит никаких неожиданных значений области действия.
Как только вы сделаете вышесказанное, добавьте некоторый временный отладочный код, чтобы взглянуть на значение $p
после этого вызова.
$p = explode('/', $this->_getDefaultPath());
var_dump($p);
//or
Mage::Log($p);
//or
file_put_contents('/tmp/test.log',"$p\n",FILE_APPEND);
Вы должны увидеть вывод примерно такого
array (size=1)
0 => string '' (length=0)
array (size=1)
0 => string 'cms' (length=3)
Причина, по которой у вас сбрасываются/регистрируются два элемента, заключается в том, что метод match
совместно используется маршрутизатором администратора и стандартным объектом маршрутизатора. Если второй элемент не является массивом из одного элемента с cms
, это ваш проблема. Выясните, чего этого не происходит, и вы будете на пути к решению проблемы.
Предполагая, что проблема не в этом, Magento теперь должен отправить метод indexAction
в файле IndexController.php
в модуле Mage_Cms
. Убедитесь, что это так, добавив следующие две строки в начало indexAction
#File: app/code/core/Mage/Cms/controllers/IndexController.php
public function indexAction($coreRoute = null)
{
$pageId = Mage::getStoreConfig(Mage_Cms_Helper_Page::XML_PATH_HOME_PAGE);
if (!Mage::helper('cms/page')->renderPage($this, $pageId)) {
$this->_forward('defaultIndex');
}
}
Вы должны увидеть Mage_Cms_IndexController::indexAction
, сброшенный в окно браузера. Если этого не произойдет, значит, в вашей системе есть что-то, что мешает стандартной маршрутизации используется - вернитесь к методу match
и выясните, почему $controller
, $controllerClassName
, $controllerInstance
, и переменные $action
не указывают на метод indexAction
в файле IndexController.php
в модуле Mage_Cms
. (Если это так, скажите об этом в комментариях, и я предоставлю для этого отладочный сканер обновлений)
Предполагая, что вы направляетесь к этому файлу контроллера и действуете правильно, удалите
var_dump(__METHOD__);
exit;
И вместо этого добавьте новый var_dump
$pageId = Mage::getStoreConfig(Mage_Cms_Helper_Page::XML_PATH_HOME_PAGE);
var_dump($pageId);
Magento позволяет настроить идентификатор страницы, которая должна использоваться в качестве домашней страницы. Mage_Cms_Helper_Page::XML_PATH_HOME_PAGE
должно соответствовать пути конфигурации хранилища web/default/cms_home_page
, который соответствует
System -> Configuration -> Web -> Default Pages -> CMS Home Page
Раздел. Здесь вы указываете Magento, какую страницу CMS вы хотите использовать в качестве своей домашней страницы. Вы должны увидеть что-то вроде
string 'home' (length=4)
Или
string 'about-magento-demo-store' (length=4)
Или и т. Д. Сбрасывается на ваш экран. Это идентификатор домашней страницы CMS. Если вы устанавливаете неожиданное значение, попробуйте запустить следующий
select * from core_config_data where path = 'web/default/cms_home_page';
Для проверки значений области действия. Независимо от того, какой у вас идентификатор домашней страницы CMS, проверьте наличие страницы с помощью следующей инструкции SQL (при условии, что значение home
).
select * from cms_page where identifier = 'home';
Если Magento не сможет найти настроенную страницу в вашей системе, он переадресует ее на страницу 404. Вы можете увидеть это с помощью следующего кода в indexAction
if (!Mage::helper('cms/page')->renderPage($this, $pageId)) {
$this->_forward('defaultIndex');
}
Если renderPage
возвращает false
, то мы перенаправляемся в метод defaultIndexAction
, который отображает 404 страница.
public function defaultIndexAction()
{
$this->getResponse()->setHeader('HTTP/1.1','404 Not Found');
$this->getResponse()->setHeader('Status','404 File not found');
$this->loadLayout();
$this->renderLayout();
}
Этого должно быть достаточно, чтобы найти 90 % ваших проблем "нет пути на домашнюю страницу" и указать вам направление отладки для остальных 10 %.
Я столкнулся с той же проблемой с пустым ключом URL для неактивной категории. Он не появлялся, пока я не протестировал переиндексацию в EE 1.13.0.0 после обновления. Та же сделка, 404 на главной странице.
Я, вероятно, сильно упрощаю детективную работу Алана, но в итоге я просто запросил новую таблицу enterprise_url_rewrite для пустого пути request_path.
SELECT * FROM `enterprise_url_rewrite` WHERE request_path = '';
Соответствующий target_path подсказал мне запрос, который перехватывал домашнюю страницу. Затем я исправил указанную категорию и все было хорошо.
Это известная ошибка из Magento - Рекомендуется выполнить следующее:
УДАЛИТЬ ИЗ enterprise_url_rewrite, ГДЕ request_path = ";
Кроме того, в каталоге оболочки есть ряд новых сценариев (пожалуйста, прочитайте примечания к выпуску)
Вероятно, эта проблема здесь.. Проверьте импортированные идентификаторы групп http://blog.chapagain.com.np/magento-solution-to-error-404-not-found-in-admin-login-page/