могу посоветовать еще один проект оркестратора docker warden.dev

Полностью согласен, кому нужно те уже давно нашли способ обойти проблему.

Stripe может работать с российскими банками, payworks может работать со страйпом.
Думаю такое решение вполне может подойти и для российских магазинов

Так вопрос импорта все равно остается открытым. Есть сотня xls файлов разной структуры. И это все вручную заносится контент-менеджерами в вашу систему?

Использую данное устройство для TimeMachine. Вещь отличная.
Была только одна проблем. Стоял transmittion, все прекрасно работало до очередного обновления ПО.
После обновления transmittion перестал работать, хотя в системе остался. Попытка переустановить привела к окирпичиванию устройства.
Пришлось разбирать и доставать хард, чтобы восстановить

Бывает конечно и хардкод, но в основном (то что я встречал) именование блоков остается неизменным. Поэтому к ним не составит труда обратиться через layout.
Буду ждать новые статьи. Всегда интересно пообщаться с единомышленниками

Коль речь зашла о правильности использования ивентов вместо рерайтов, то логичнее добавить колонку в грид через ивенты.
Для этого достаточно добавить observer на core_block_abstract_prepare_layout_after или core_block_abstract_prepare_layout_before и в методе обсервера проверять тип блока.

if ($_block->getType() == 'adminhtml/sales_order_grid') {}

Есть второй способ — это добавление колонок через layout
Для этого достаточно добавить в файл layout:

<adminhtml_sales_order_grid>
        <reference name="sales_order.grid">
            <action method="addColumnAfter" translate="header">
                <columnId>COLUMN_ID</columnId>
                <arguments>
                    <header>HEADER</header>
                    <index>COLUMN_INDEX</index>
                    <filter_index>FILTER_INDEX</filter_index>
                    <type>TYPE</type>
                    <renderer>CUSTOM_RENDERER_BLOCK</renderer>
                </arguments>
                <after>AFTER_COLUMN_ID</after>
            </action>
        </reference>
    </adminhtml_sales_order_grid>

filter_index используется при поиске если поле фильтруемо. Здесь необходимо указать значение. которое будет подставляться в sql запрос. Например, main_table. is_exported
renderer — Указываем блок, который будет отвечать за рендеринг. Данные поля являются необязятельными.

Было бы здорово еще несколько локализация добавить

Я вам говорю про то что мы имеем с коробки. А с коробки мы имеем валидатор, который оперирует css селекторами элементов.
Про то что делают другие разработчики я не говорю, и глубоко уверено, что если разработчики пытаются изобретать велосипеды не посмотрев, что уже есть и чем можно воспользоваться — это плохой разработчик стиль кодирования. А код смотреть нужно для того, чтобы сказать так ли необходимо было изобретать новые валидаторы или достаточно было воспользоваться стандартным прототайповским.

:) Не буду что-либо оспаривать и доказывать не посмотрев кода.

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

Данный вариант использования RDBMS был введен начиная с Magento CE 1.6 / EE 1.11
Начиная с этих версий конечно же предпочтительно использовать подобный стиль.
Но в предыдущих версиях приходилось пользоваться run.
Кстати начиная с 1.6/1.11 так рекомендовано ресурсные модели перенести из папки Mysql4 в директорию Resource

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

Подход к решению достаточно изящный
Наверняка почерпнуто из inchoo.net/ecommerce/magento/track-validation-errors-on-magento-forms-using-google-analytics/

Полностью согласен

Мне жаль, что вам не понятны эти куски кода…
На счет local.xml вы правы, это я не доглядел в статье. Он грузится из папки app/etс дважды, дабы магазин работал всегда. Обусловлено это тем, что все грузиться в единую древовидную структуру.
Увидим ли мы ваши статьи с «красивыми сиквенс диаграммами» и прочими красотулями?

А чем ваши этапы отличаются от тех, что были описаны мной?
Я расписал процессы, Вы указали пункты… Смыслы то не поменялся.

Да, со второй версией тоже уже игрался, и думаю ее тоже освещать буду

На самом деле вы правы только в том, что больше информации можно получить только из исходников.
Если внимательно пройтись по коду, а еще лучше дебагером, то можно заметить что метод init вызывается только в 3 случаях:
github.com/LokeyCoding/magento-mirror/blob/magento-1.8/cron.php#L67
github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/App.php#L270
github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/Config.php#L370
Первый случай вообще рассматривать не будет, т.к. это процесс запуска по крону. (Причем для cron.php init запустится дважды)

Для второго случая метод github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/App.php#L258 вызывается в двух случаях:
1) github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/Mage.php#L615 — вызывается только если свойсто app не определено (в случае cron.php это будет первый запуск)
2) github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/Mage.php#L640

В случае запуска страницы в браузере 1 сразу исключается т.к. github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/Mage.php#L669 свойсто не будет равно null
2 будет отрабатывать только если массив $modules будет пустым

reinit тоже расписывать не буду когда и как вызывается.

В заключении можно сказать, что указанный вами метод init вызывается только при вызове Mage::app() или Mage::init с пустым массивом $modules
Эти методы обычно используются при написании сторонних php скриптов, запускающихся из терминала, либо кроном.

Я же в статье рассматрива метод run из index.php (т.е. стандартного метода запуска магазина), который запускает всю цепочку.