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

Однако, порой при разборе встроенных или сторонних модулей (почему-то не нашелся внятный ман для OpenCart по этой теме), не удается изъть код, который решает некоторые, казалось бы, элементарные вещи, на самой ранней стадии разработки модуля.

Именно этим мы и займемся в данной статье или попытаемся :)

В статье рассмотрим как устроены ajax запросы в OpenCart, в том числе запросы через api OpenCart, познакомимся с новым понятием front controller и немного коснемся темы ajax REST API.

Разрабатывая модуль для OpenCart, в админке мне понадобилось использовать модальные окна для вывода определенной информации, а так же для показа формы. Мой опыт frontend на тот момент был так себе, однако коллега подсказал что в OpenCart используется jquery (2.1.1), а у этой библиотеки есть поддержка popup окон. Но не все так просто ...

Система событий в OpenCart достаточно интересна, она не является заранее предопределенным списком событий. Внутренность движка устроена таким образом, что почти каждый метод контроллера, который реагирует на определенный роут, загружает какие-то файлы (другие контроллеры, модели, представления, переводы).

Разрабатывая модуль для OpenCart, возникла необходимость сделать произвольное поле в карточке товара, которое должно быть видно только в админке. Это должно быть поле с логическим значением "маркирован товар или нет". Недолго поковыряв админку выяснил, что из коробки OpenCart не поддерживает кастомные поля, однако есть платные модули, например вот. Значит нужно сделать кастомное поле в OpenCart самому.

В общем задача звучала так: установить Redmine на сервер, где веб-сервер на nginx.

Так как Redmine написан на RoR, то необходимо иметь RoR среду, но проблема в том, что разные RoR приложения могут требовать разные версии окружения, а значит нужен менеджер версий, который будет разворачивать нужную среду в нужном месте.

RVM - менеджер версий сред ruby, начиная от версий интепретатора и заканчивая джемами. Нужен для того чтобы запускать разные RoR приложения на одном сервере, которые могут требовать разные среды исполнения.

Также хотелось классический вариант веб-сервера на nginx. Однако, nginx не знает как исполнять приложение, и в данном случае выступает в качестве прокси на исполняющий веб-сервер RoR приложения.

Unicorn - веб-сервер для Rack (и RoR в том числе) приложений. Почему-то мне не захотелось использовать passenger, наверное потому что nginx должен быть скомпилен с passenger, то есть не чистый nginx. А еще потому что Unicorn может быть свой для каждого RoR приложения, а не один глобальный.

Теперь задача становится более ясной: установить Redmine на сервер, развернув стек: RoR, Unicorn, Nginx, с автоматическим запуском.

У клиента сайт на wordpress + woocommerce, внутри множество модулей (которые в админке выдают уведомления разного рода notice - error. просто трэш) среди которых модуль интернет-эквайринга от одного известного банка. Наш модуль реагирует на хуки woocommerce и осуществляет на основании этого свою работу. Однако, логика модуля зависит от того, как отработает модуль эквайринга ... и как следствие все работало не так как надо.

Доступа к ЛК клиента экваринга банка нет, так же нет доступа по ftp и к базе данных сайта клиента, однако, есть наш модуль на сайте клиента, который может обновляться, и есть доступ к админке.

На протяжении всего процесса решения проблем включили не раз проверенный метод отладки print_r/file_put_contents, из-за чего выкатили 15 патчей за 2 дня (на самом деле их было больше, потому что иногда забывали обновлять патч-версию, в следствии чего приходилось переустанвливать модуль).

Задача: программно запускать безголовый браузер, и получать из него данные. Все просто, за исключением некоторых мелочей. Сделать это все надо в linux.

Для этого использовал fork, pipe, waitpid.

Концепция кажется мутной только с первого взгляда, на самом деле выглядит просто.

На новой работе одной из первых крупных задач была разработка модуля фискализации продаж для движка 1С-Битрикс. Спустя месяц работы (не только над модулем) он был сделан и залит в маркетплейс, однако по некоторым причинам модерация происходила около месяца, а общение с модераторами оставляло желать лучшего, но все-таки получилось :)

На момент написания статьи, официальной документации очень не хватает, и данная реализация взаимодействия клиентской части с модулем посредством ajax во многом была собрана по крупицам из статей/форумов интернетов (источники описывали не весь механизм взаимодействия, поэтому появилась эта статья). Только дока по BX.ajax была доступна, но это не совсем то что нужно, потому что в этом случае:

* необходимо самостоятельно следить за безопасностью

* самому подключать ядро движка

* при ajax запросах нужно указывать относительный адрес (в общем-то нормально, но ... можно лучше)