Для разработчиков

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

Продолжая серию заметок @Николай Савин о нововведениях в miniShop2 Для MODX2, расскажу об изменениях в уведомлениях.

В серии коротких заметок расскажу и детально покажу что нового мы сделали для Вас в новой версии miniShop2 Для MODX2

На очереди информация для разработчиков об изменениях связи между объектами msOrder и msOrderAddress

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

В серии коротких заметок расскажу и детально покажу что нового мы сделали для Вас в новой версии miniShop2 Для MODX2

На очереди информация для разработчиков, касательно окончательного положения контроллеров.

В серии коротких заметок расскажу и детально покажу что нового мы сделали для Вас в новой версии miniShop2 Для MODX2

На очереди обновление связанное со статусами заказов.

В серии коротких заметок расскажу и детально покажу что нового мы сделали для Вас в новой версии miniShop2 Для MODX2

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

Приветствую! Я открыл для себя ещё один вариант использования компонента MIGX и хочу поделиться им с сообществом. Скорее всего, кто-то до меня так делал, но либо не делился, либо я не нашёл.
Для чего это нужно? На сайтах как правило есть несколько форм: обратная связь, подписка, отзывы и.т.д. Иногда формы эти содержат идентичный набор полей, но выглядят по-разному и располагаются на разных страницах. А ещё они могут отправляться на разные почты или наоборот все на одну. В общем, так или иначе это приводит к полному или частичному дублированию вызовов и к тому, что в случае необходимости внесения изменений, нужно править несколько файлов. Вот я и разработал несложную систему для упрощения управления формами.

Одна из проблем развития экосистемы MODX3 на текущий день — не очень большой объем доступной информации, инструкций. Официальный сайт только недавно начал выпускать справочные пособия на тему разработки MODX3.

Мне в свое время очень помогла в понимании работы компонентов, подготовленная @Василий Наумкин заготовка для создания компонентов modExtra. Я решил поднять это знамя и донести его до MODX3

Представляю вашему вниманию ModExtra3. Заготовка для создания компонентов и справочное пособие по MODX3.

Третьего дня Сергей Шлоков провёл новый тест скорости работы парсера MODX и шаблонизаторов Fenom и Smarty.

До Smarty мне дела нет, но с итоговыми выводами, что никакой разницы в скорости между синтаксисом MODX и Fenom не видно, я категорически не согласен.



Итак, что нужно прояснить. У оригинального парсера MODX modParser есть две, на мой взгляд, фундаментальные проблемы:

Во-первых, каждый тег при разборе превращается в PHP объект modTag и в нём запускается метод process. То есть, если в чанке указан просто [[+id]], то MODX вместо обычной замены его через str_replace будет создавать новый объект и парсить.

Во-вторых, из-за своей рекурсивной природы, MODX выполняет все условия в чанках. Он просто не знает, во что могут превратиться эти условия на пятой, например, итерации. Причём делает он это изнутри наружу.
То есть, если вы прячете какой-то кусок оформления для вывода только нужным пользователям за условиями в чанке — именно этот кусок и будет первым делом разобран, а потом MODX решит, нужно ли его выводить, когда проверит условие с юзером. Народ придумывает разные костыли для обхода этого момента, чтобы парсить только нужное, типа [[![[+user:is=`admin`:then=`auth`:else=`guest`]]]].