Yurij Finiv

Всем, кто хоть раз пытался завести 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'))

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

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

Продолжаю разработку новой версии modstore.pro и хочу поделиться простым способом подключения своих модификаторов.

Обычный способ все знают: нужно создать сниппет, который будет принимать переменные $input и $options и вызвать его в чанке вот так:

{$variable | snippet}

Но

• Сниппеты бывают совсем небольшие и создавать их на каждый чих не хочется
• Вызов сниппета, это всё-таки дополнительная нагрузка
• Лично я уже полностью перешел на файлы, и создавать запись в БД для сниппета, только ради его связи с файлом мне совсем не хочется

То есть, я хочу просто вызывать некий код в качестве модификатора. И в этом мне поможет событие pdoToolsOnFenomInit, которое появилось в pdoTools 2.6.0 и мало кто это заметил.

Часто ли вам приходится расширять какие-то стандартные штуки в MODX или в компонентах для него? Мне вот часто! Поэтому, давно хотелось поделиться чем-нибудь интересным на этот счёт, что я собственно и сделал в статье Дополнительные поля профиля юзера, где описал, как можно расширить профиль юзера, чтобы всё выглядело натурально. На этот раз расскажу, как можно расширять компонент Collections, не прибегая к крайним мерам, вроде правки исходников приложения.

Сегодня я покажу, как быстренько модернизировать CustomExtra, чтобы объекты можно было связать друг с другом.



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

Разрабатываю проект, в котором необходимо было реализовать более простое редактирование дополнительных полей профиля, чем есть из коробки. К слову, неудобное редактирование — это не единственный минус нативного способа расширения профиля полями. Ни для кого не секрет, что фильтрацию по JSON полям нормально не осуществить, только костылями. Фактически, мне надо было получить решение, которое бы расширяло стандартный код MODX, не трогая исходники, дабы сохранить карму в порядке возможность обновления системы.
Пришёл к выводу, что буду расширять стандартную вкладку профиля «Общая информация». При желании можно чуть переписать код в событии OnUserFormPrerender и создать свою вкладку со своими полями.

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

Первый вариант (относительно сложный в реализации, но выигрывает по скорости при большой выборке ресурсов):

1. Заходите в phpmyadmin.
2. Выбираете таблицу modx_site_content
3. — Переходите в закладку «структура»
4. — Внизу открывшегося окна нажимаете ОК (Добавить 1 поле в конец таблицы)
   

   Имя: ticket_rating
   Тип: int
   Длина/значение: 10
   По умолчанию: Как определено (0)
   Null: галочка

5. Сохраняем

Таким способом мы расширили дефолтную таблицу MODX'a со списком ресурсов.

Всем привет. Часто встречается ситуация, когда на сайте при регистрации через Office пользователи указывают username вида "--- --", «валя краля», "___ __", «yesy@yesy.ru» и т.д. Хотелось бы, чтобы при регистрации использовали только английские буквы, тире, нижнее подчеркивание и цифры.

Приступим:

1. Создаем плагин с следующим содержанием:

<?php
if ($modx->event->name == 'OnBeforeUserFormSave') {
    if (!preg_match("/^[a-zA-Z0-9-_]+$/", $user->username)) $modx->event->output('Имя пользователя должно содержать английские буквы, символы "-", "_" и цифры');
}

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

Что обычно люди делают в таких случаях? Верно, редактируют ядро или нужный компонент, и больше их не обновляют. Но ведь это неправильно, и можно решить вопрос иначе.

Пишем обычный плагин, выставляем для него событие OnMODXInit и меняем модель для нужных классов системы или дополнений. Например, я добавил id менеджера в заказ miniShop2:

В MODX есть очень хорошая штука для хранения временных данных — объекты modRegistry. В народе их еще называют регистры, видимо из-за исторических параллелей.

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

Этот класс отлично документирован, но я хочу показать простой и понятный пример.