Я обновил оформительскую тему Infortis Ultimo и при включенном режиме денормализации стал получать сбой обновления расчётных таблиц разделов

Дмитрий, приветствую!

При обновлении расчётной таблицы произошёл сбой в расчетной таблице "Разделы". Текущее состояние "требует обновление". В ручную эффекта не дает. Так же не дало эффекта подбор параметра "максимальное количество символов для хранения значения свойства товара" в разделе Административная часть Российской сборки как было описано ранее в одной из тем. Что посоветуете сделать?

Ранее было сделано обновление до текущей версии Российской сборки 2.36.1

Заранее благодарен,
Игорь

Вероятно, причина сбоя указана в системном журнале Magento.

2014-07-27T11:56:41+04:00: Exception message: Notice: Undefined offset: 136 in ./includes/src/__adminhtml.php on line 149258
Отключал кэширование и компеляцию, не помогло. Какие ще варианты можно попробовать?
Спасибо.

Очевидно, некачественно отключили компиляцию, потому что данное сообщение не могло остаться при выключенной компиляции, и вместо него при выключенной компиляции должно было быть другое сообщение.

Дмитрий, данная запись приведена из файла exception.log в файле system.log только одна строка: 2014-07-24T15:27:46+04:00:Array()2014-07-24T15:27:46+04:00:

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

Очевидно, надо учиться качественно смотреть системные журналы.
В первую очередь в данной конкретной ситуации надо потратить время на обучение чтению файла exception.log, потому что он содержит гораздо больше информации, чем Вы сочли нужным здесь написать.

И компиляцию тоже надо всё-таки когда-нибудь научиться отключать, потому что в данный момент она не отключена.
Без качественного выполнения таких деталей проводить серьёзную диагностику невозможно.

Дмитрий, в настоящий момент на сервере кэширование и компиляция отключены. Проверял как настройки в административной панели так и в файле.
В настройкай системы System > Configuration > Catalog > Catalot оратил внимание что параметр Денормализовать таблицы товарных разделов? стоит в положении Нет. Что отличается от первоначальных. Вернуть в положение Да нет возможности.

Нужен ваш совет.

С Уважением,
Игорь

В файле exception.log повторяется ссылка на ошибку в файле /includes/src/__adminhtml.ph

2014-07-27T11:56:41+04:00: Exception message: Notice: Undefined offset: 136 in /var/www/*/includes/src/__adminhtml.php on line 149258
Trace: #0 /var/www/*/includes/src/__adminhtml.php(149258): mageCoreErrorHandler(8, 'Undefined offse...', '/var/www/dive.v...', 149258, Array)
#1 /var/www/*/includes/src/__adminhtml.php(148953): Mage_Catalog_Model_Resource_Category_Flat->_getAttributeValues(Array, '1')
#2 /var/www/*/includes/src/__adminhtml.php(149907): Mage_Catalog_Model_Resource_Category_Flat->rebuild()
#3 /var/www/*/includes/src/__adminhtml.php(134535): Mage_Catalog_Model_Resource_Category_Flat->reindexAll()
#4 /var/www/*/includes/src/__default.php(69093): Mage_Catalog_Model_Category_Indexer_Flat->reindexAll()
#5 /var/www/*/includes/src/__default.php(69141): Mage_Index_Model_Process->reindexAll()
#6 /var/www/*/app/code/core/Mage/Index/controllers/Adminhtml/ProcessController.php(182): Mage_Index_Model_Process->reindexEverything()
#7 /var/www/*/includes/src/__default.php(24334): Mage_Index_Adminhtml_ProcessController->massReindexAction()
#8 /var/www/*/includes/src/__default.php(41254): Mage_Core_Controller_Varien_Action->dispatch('massReindex')
#9 /var/www/*/includes/src/__default.php(40784): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#10 /var/www/*/includes/src/__default.php(43760): Mage_Core_Controller_Varien_Front->dispatch()
#11 /var/www/*/app/Mage.php(684): Mage_Core_Model_App->run(Array)
#12 /var/www/*/index.php(91): Mage::run('', 'store')
#13 {main}

Строка 149258 в файле __adminhtml.php:
$values[$row['entity_id']][$attributes[$row['attribute_id']]['attribute_code']] = $row['value'];

Что посоветуете предпринять?

Как я уже потратил время написать, при отключенной компиляции данное диагностическое сообщение невозможно.
При отключенной компиляции Magento не использует программный код из папки includes/src.
Дальнейшие логические выводы из этого неплохо бы уже делать самостоятельно.
Например, прийти к мысли, что значки 2014-07-27T11:56:41+04:00 в начале диагностического сообщения - это дата, и затем дальше прийти к мысли, что если диагностическое сообщение датировано утром вчерашнего дня, а компиляция отключена лишь вечером, то что-то не то. И т.п. Надо учиться делать выводы, это очень много времени экономит.

Говоря проще, Вы не то диагностическое сообщение здесь пишете.
После отключения компиляции надо аккуратно воспроизвести сбой и затем написать то сообщение, которое система записала в системный журнал именно после данного конкретного воспроизведения сбоя, а не первое сообщение наугад из сстемного журнала.

Дмитрий, признаю свою ошибку. Спасибо!

Аккуратно воспроизвел сбой при отключенной компиляции и привожу ниже сообщение из системного журнала exception.log в файле system.log собщений нет.

2014-07-28T10:22:49+04:00: Exception message: Notice: Undefined offset: 136 in /var/www/*/app/code/core/Mage/Catalog/Model/Resource/Category/Flat.php on line 833
Trace: #0 /var/www/*/app/code/core/Mage/Catalog/Model/Resource/Category/Flat.php(833): mageCoreErrorHandler(8, 'Undefined offse...', '/var/www/*...', 833, Array)
#1 /var/www/*/app/code/core/Mage/Catalog/Model/Resource/Category/Flat.php(528): Mage_Catalog_Model_Resource_Category_Flat->_getAttributeValues(Array, '1')
#2 /var/www/*/app/code/core/Mage/Catalog/Model/Resource/Category/Flat.php(1482): Mage_Catalog_Model_Resource_Category_Flat->rebuild()
#3 /var/www/*/app/code/core/Mage/Catalog/Model/Category/Indexer/Flat.php(260): Mage_Catalog_Model_Resource_Category_Flat->reindexAll()
#4 /var/www/*/app/code/core/Mage/Index/Model/Process.php(210): Mage_Catalog_Model_Category_Indexer_Flat->reindexAll()
#5 /var/www/*/app/code/core/Mage/Index/Model/Process.php(258): Mage_Index_Model_Process->reindexAll()
#6 /var/www/*/app/code/core/Mage/Index/controllers/Adminhtml/ProcessController.php(182): Mage_Index_Model_Process->reindexEverything()
#7 /var/www/*/app/code/core/Mage/Core/Controller/Varien/Action.php(418): Mage_Index_Adminhtml_ProcessController->massReindexAction()
#8 /var/www/*/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(250): Mage_Core_Controller_Varien_Action->dispatch('massReindex')
#9 /var/www/*/app/code/core/Mage/Core/Controller/Varien/Front.php(172): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#10 /var/www/*/app/code/core/Mage/Core/Model/App.php(354): Mage_Core_Controller_Varien_Front->dispatch()
#11 /var/www/*/app/Mage.php(684): Mage_Core_Model_App->run(Array)
#12 /var/www/*/index.php(91): Mage::run('', 'store')
#13 {main}

Очевидно, если подумать, что если раньше такого сбоя не происходило, а после установок сторонних модулей такой сбой сразу стал происходить, то можно прийти к мысли, что есть некая связь между сбоем и установленными модулем, а дальше можно подумать и прийти к мысли упомянуть о факте установки сторонних модулей.

Данный сбой стал возникать после обновления оформительской темы ThemeForest Infortis Ultimo

После обновления были сделаны корректировки описанных в соответствующих темах форума. За исключением
ThemeForest Infortis Ultimo: «Notice: Undefined property: Infortis_UltraMegamenu_Block_Navigation::$_tplProcessor» в связи отсутствием указаннай строки. Вероятнее всего выявленный сбой происходит по этой причине.

Заранее благодарен за помощь!

Я посмотрел программный код, сбой вызван именно обновлением оформительской темы Infortis Ultimo на низкокачественную версию, с дефектным модулем Infortis UltraMegamenu.
Что интересно, обратное обновление назад может не дать результата, потому что новая версия просто удалила из базы некоторые данные, и при обновлении назад эти данные ниоткуда назад не возьмутся.
Отсюда можно сделать несколько выводов:

• любые новые версии сомнительных модулей надо, очевидно, предварительно испытывать локально, на тестовом сайте, а не сразу портить основной магазин.
  
• когда СРАЗУ после обновления происходит сбой, то не надо запутывать следы, а надо прямо писать: "я только что установил (обновил) такой-то сторонний модуль, и у меня СРАЗУ ЖЕ стал происходить такой-то сбой"
  
• когда есть такая прямая очевидная связь между действием (установкой) и реакцией системы (сбоем), то не нужно даже тратить свое рабочее время на анализ программного кода (как пришлось делать мне из-за отсутствия информации о том, что делалось с сайтом), а можно сразу же сообщить о проблеме разработчику модуля (оформительской темы).
  В частности, по данному сбою можно им написать "I have upgraded Infortis Ultimo (указать с какой версии и на какаю), and rebuilding catalog category indices no longer works in flat mode because of error (Указать диагностическое сообщение из системного журнала).".

Этот сбой отлично воспроизводится на Magento Community Edition без Российской сборки Magento.
Для воспроизведения сбоя надо сначала установить прежнюю версию оформительской темы Infortis Ultimo, затем включить денормализацию, а затем обновиться на новую версию Infortis Ultimo.

Сейчас есть несколько способов устранения проблемы:

• Восстановить версию сайта до обновления и не обновляться (самое простое, если есть резервная копия)
  
• Установить с нуля новую версию оформительской темы (сбой происходит при обновлении старой версии на новую, а при установке новой с нуля не должен происходить, хотя в новой неизвестной версии могут быть другие дефекты)
  
• Отключить режим денормализации для товарных разделов (это будет тормозить работу системы).

При вариантах 1 и 3 имеет смысл параллельно решать проблему со службой поддержки, чтобы после ее решения всё-таки обновиться на новую версию.

С комментарием согласен, впредь учту и буду проводить эксперименты на локальном Zend. Разработчику информация выслана, по получению ответа, проинформирую здесь. Спасибо!

Я проанализировал данную проблему глубже.
Дефектен установочный скрипт app/code/local/Infortis/UltraMegamenu/data/ultramegamenu_setup/data-upgrade-1.0.0-1.1.0.php модуля Infortis UltraMegamenu оформительский темы Infortis Ultimo.

В этом скрипте дефектен участок кода

$installer->removeAttribute('catalog_category', 'umm_cat_block_proportions');
$installer->removeAttribute('catalog_category', 'umm_cat_block_top');
$installer->removeAttribute('catalog_category', 'umm_cat_block_bottom');
$installer->removeAttribute('catalog_category', 'umm_cat_block_right');

Установочный скрипт в начале своей работы отключает контроль ссылочной целостности методом Varien_Db_Adapter_Pdo_Mysql::startSetup, который устанавливает параметру foreign_key_checks СУБД MySQL значение 0.

При отключенном контроле ссылочной целостности вызывать метод Mage_Eav_Model_Entity_Setup::removeAttribute ошибочно, потому что тогда, удаляя свойство (в данном случае — свойство товарного раздела) СУБД MySQL не произведёт каскадное удаление относящихся к этому свойству данных из других таблиц, в частности, из таблицы catalog_category_entity_varchar, где ссылка на свойство описана как

FOREIGN KEY (`attribute_id`) REFERENCES `eav_attribute` (`attribute_id`) ON DELETE CASCADE ON UPDATE CASCADE

.

Таким образом, дефектный установочный скрипт app/code/local/Infortis/UltraMegamenu/data/ultramegamenu_setup/data-upgrade-1.0.0-1.1.0.php модуля Infortis UltraMegamenu оформительский темы Infortis Ultimo в результате своей работы приводит базу данных интернет-магазина в недопустимое состояние, что приводит к сбоям при перестройке расчётных таблиц, а также может привести к сбоям при выполнении других операций в интернет-магазине.

Теперь, когда база данных интернет-магазина повреждена, разумнее всего вернуться к версии до обновления оформительской темы (вручную исправлять базу данных может быть сложно), а также сообщить об этой проблеме разработчику оформительской темы.

Дмитрий, благодарю Вас. Разработчик пока не ответил но я ему ваши выкладки сообщу обязательно. Попробую воспроизвести этот сбой на локальной инстоляции. Это может быть связано с версией Magento?

Я предельно конкретно изложил причины и следствия сбоя, а также дал конкретные рекомендации по его устранению, потратив своё рабочее время. Если причины сбоя не понятны - значит, надо прочитать написанное мной повторно. Других причин нет. Тема закрыта.

Добрый день!
Разработчик оформительской темы Infortis Ultimo признал сущнествование данного дефекта и взыскал слова благодарности в Ваш адрес. Они прокомментировали, что использовали стандартный код Mаgento для удаления старых атрибутов в которых более нет надобности. На сегодняшний день у разработчика нет готового решения проблемы. При появление я сообщу.
Спасибо!

Это просто безмозглый автоответчик ответил, который не разбирается в теме, зато умеет автоматически писать "спасибо" на каждое обращение в службу поддержки.
На самом деле, как видно из причины дефекта, исправить конкретно этот дефект можно простой перестановкой вызова endSetup и блока из вызовов removeAttribute.
endSetup, в противоположность startSetup(), включает назад режим контроля ссылочной целостности, и тогда removeAttribute работает правильно, удаляя данные не только из таблицы свойств, но и все взаимозависимые от удалённых свойств товарных разделов данные, сохраняя базу данных интернет-магазина в корректном состоянии.
Другое дело, что Ваш магазин это уже всё равно не спасёт, потому что выполнять такую правку надо до обновления оформительской темы, а после обновления фоормительской темы править установочные скрипты уже бесполезно, потому что они работают только один раз и уже привели базуц данных Вашего магазина в некорректное состояние, второй раз, если их даже запустить вручную, они не вернут базу данных в корректное состояние, потому что свойства товарных разделов уже удалены, а автоматическое удаление зависимых от них данных запускается только при удалении свойства товарных разделов.

Российская сборка Magento, начиная с версии 2.39.1, способна давать администратору конкретные рекомендации по устранению сбоев, вызванных повреждением базы данных интернет-магазина в результате некорретной работы сторонних модулей или некорректных правок базы данных администратором.
При разработке данной функциональности я использовал в качестве одного из испытаний описанную в данной теме проблему оформительской темы Ultimo, и новая функциональность успешно помогает администратору в решении данной проблемы.