Павел Гвоздь

Оплата заказов miniShop2 через платежную систему iPay.by. Оплата в системе производится картами, поддерживаются белорусские рубли, а точнее они установлены по-умолчанию.

В сообществе ни раз задавали вопрос про выгрузку заказов из MODX в CRM Битрикс24. Есть достаточно простой способ создавать лиды по старому протоколу. Делается это одним плагином на событие msOnCreateOrder. Да, функционал будет довольно ограничен, но с помощью него добавить лид вполне возможно, правда не прикрепляя к лиду товары. За то не нужно заморачиваться с созданием приложения, получения токена и т.д.

Всем, кто хоть раз пытался завести mFilter2 на большом кол-ве товаров и хотя-бы 10 опциях в фильтре, известно, что тормозов не избежать. Вот и мне попался на днях сайт, в котором, казалось бы, всего-то 7000 товаров и 10 опций на странице каталога. Однако сниппет фильтра отрабатывал за 3-4 секунды. Переписал на Fenom — стал отрабатывать за 2-3 секунды.
Не годится! Тем более, что у заказчика было требование: «Чтобы сайтом было комфортно пользоваться». Что-ж, взял задачу — надо решать!

Дебаг показал, что проблема в методе mse2FiltersHandler::getMsOptionValues, а именно в запросе (7k товаров!), который выглядит как-то так:

SELECT `product_id`, `key`, `value` FROM `modx_ms2_product_options` AS `msProductOption` 
WHERE (`msProductOption`.`product_id` IN (3394,3408,еще 7 тысяч ID)
AND `msProductOption`.`key` IN ('atr_n1','atr_n6','atr_n5','atr_n12','atr_n43','atr_n46','atr_n29','atr_n11','atr_n44','atr_n2'))

Возникла необходимость при помощи msOptionsPrice2 реализовать составной товар. Оказалось, что компонент не умеет прибавлять к начальной цене товара несколько цен из модификаций одной опции.
Например, есть опция Наполнители, у нее около 20 значений. На фронте, при выборе каждого из значений, цена товара должна увеличиваться на N рублей. Проблема заключается в том, что имена тегам чекбоксов мы даем в виде массива:

<input type="checkbox" name="cb[]">

Компонент, в свою очередь, с таким работать не умеет. Предлагаю решение в четыре простых шага!

В сообществе часто проскакивают вопросы про мультидоменность на одной копии MODX. А у меня, как раз, сайты демо версий компонентов реализованы таким образом. Думаю, информация будет полезной!

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

Пакет довольно прост и одновременно функционален. Выполняет систему рейтинга для любого объекта, по-умолчанию, для ресурсов. Чем-то напоминает систему лайков на YouTube, в частности, в пакете реализован оптимистичный интерфейс.


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

Список преимуществ:

1. Оптимистичный интерфейс,
2. Наиболее правильная формула вычисления рейтинга,
3. Работа с любыми объектами (modResource, modUser, кастомные объекты),
4. Голосование гостями,
5. Анимированное изменение полосы/числа рейтинга,
6. Событие плагина — xLikeOnVote.

После статьи о расширении профиля юзера правильными дополнительными полями мне посыпались вопросы о расширении нативной таблицы со списком юзеров. Мы знаем, что практически любой стандартный компонент системы, работающий на ExtJS, можно расширить не затрагивая исходника. Главное уметь пользоваться «методом тыка» понимать принцип того, что делаешь. Что-ж… давайте расширять нативную таблицу пользователей!
Сразу опишем задачу, которую реализуем в рамках статьи:

1. Убрать слева каждой записи ненужный чекбокс,
2. Добавить столбцы: Фото, Дата рождения, Страна, Город,
3. Добавить возможность отфильтровать пользователей по стране,
4. Заменить некрасивое поле поиска на симпатичное и компактное,
5. Подсветить заблокированных красным цветом.

Пакет позволяет создать некие области на карте, в пределах которых осуществляет доставку то или иное заведение.

Каждому заведению можно указать:

1. Свои почтовые ящики для уведомлений о новом заказе, которые заменят ящики из настройки ms2_email_manager,
2. Минимальную стоимость заказа для каждой области (каждого заведения).

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

Проверить, есть ли контейнер в списке родителей ресурса, можно разными способами:

• Можно сделать это используя карту ресурсов, которую MODX создаёт для каждого контекста после обновления кеша. Для этого необходимо воспользоваться методом $modx->getParentIds. Таким образом нагрузка и время затрачиваемое на проверку будет минимальным.
  
  
• Не заморачиваться и сделать всё исключительно на Fenom, без модификаторов. Тут мы тоже можем воспользоваться методом $_modx->getParentIds, который Василий услужливо вынес в список доступных в Fenom.
  
  
• Можно даже извратиться до того, что на каждую такую проверку получать объект через getObject('modResource') + получать объекты его родителей через getOne('Parent'). К слову, что будет в случае, если нам, к примеру, надо проверить 50 товаров на странице на вложенность в определённую категорию?
  Ради интереса, я воспроизвёл подобную ситуацию на тестовом сайте Modhost:
  
  1. Без каких-либо проверок 50 товаров в списке категории выводятся за 0,0282 сек.
  2. С подобной проверкой, за 0.1304 сек.
  3. С проверкой, которую мы рассматриваем в этом посте, за 0.0307 сек.
  
  А потом заказчики сходят с ума, почему их сайт так долго открывается...