- Заметки 47
- Комментарии 37
Вчера в 08:39
По-моему как раз когда икоки индивидуальные самое то делать через migx, так как там можно задавать любую конфигурацию полей, в том числе сделать отдел...
Как сделать проверку по нескольким полам 6
01 июня 2025, 18:37
Давай закроем эту тему. Я добавил версионирование. Остальные вопрос по компоненту задавай через техподдержку modstore.
ms_CDEK2 возвращается! 53
01 июня 2025, 13:02
Проблемы из-за неправильных настроек обязательно возникнут, на то они и неправильные.
Вручную сделать перевод 3
31 мая 2025, 16:11
Век живи, век учись. Спасибо большое за помощь
Fenom вывод ТВ множественный выбор, слипается, не разделяется 2
31 мая 2025, 12:39
Хорошая идея, так как я вижу по вебвизору на десктопе много людей смотрят сайт не кликая на закрытие плашки с уведомлением о куки. Т.е если с самого н...
Плашка о использовании cookie файлов на сайте 6
30 мая 2025, 19:57
Пишется небольшой сниппет, который получает список «непустых» категорий. Перечень ID кладем в плейсхолдер.
Запускаем сниппет ДО вызова pdoMenu
В pd...
Как скрыть пустые категории MiniShop2? 3
29 мая 2025, 16:19
Данная версия будет бесплатной всегда, задумывал ее как базовую версию. Я скоро выпушу платный вариант с расширенным функционалом, где будет возможнос...
IskWaf - Простой Web Application Firewall для MODX 3
1. естественно меняем класс обработчик фильтров. Идем в настройки системы и в настройках mSearch2 меняем параметр mse2_filters_handler_class на CustomFilter
2. теперь нам нужно создать сам класс. для этого создаем файл core/components/msearch2/custom/filters/custom.class.php с содержимым
осталось добавить в чанк вызова мфильтра строчку
вуаля — фильтр работает как нужно ;)
Создал плагин adminStyles на событие OnManagerPageInit
И в вышеописанном ксс-файле добавил строчку
Страницы пользователей с нормальными урл
1. Создаем страницу «профиль пользователя» (не путаем с личным кабинетом), выставляем ему псевдоним, допустим users, к которой будут обращаться в виде site.ru/users?profile=имя
2. Ставим дополнение pdoTools
3. Создаем сниппет user.Profile и добавляем его в шаблон вывода
— насколько я помню, сразу вызвать pdoUsers с параметром конкретного пользователя нежелательно, т.к. если пользователя не существует, он выдает по-умолчанию весь список пользователей. Возможно, сейчас что-то поменялось или это можно обойти — не проверял.
Для данного сниппета также можно дописывать условия, если пользователь не активирован и тд и тп. При помощи параметров tpl и prepareSnippet кастомизируем до нужного уровня.
4. Дописываем в .htaccess
— чтобы ссылка приняла вид site.ru/users/Имя_пользователя
Возможность добавлять поля в профиль пользователя
При регистрации: дополнение login
Для редактирования пользователем (личный кабинет) — дополнение office
Возможность указывать шаблон для оформления страницы пользователя
1. Добавляем дополнительное поле в личный кабинет пользователя (шаблон отображения)
2. В шаблоне отображения профиля пользователя дописываем классы, завязанные на полученном значении (class=«userInfo-[[+tpl.style]]»)
2.А. Если необходимо менять структуру шаблона в зависимости от выбранного пользователя значением, то в сниппете в первой части дописываем до
получение extended-поля по id пользователя с вытекающими условиями if, внутри которых будет разный параметр $params['tpl']
Добавить «из коробки» дату регистрации и дату последней активности
Дату регистрации — сниппет логин и 1 доп. поле.
С датой последней активности сложнее, т.к. в таблицах Modx'a, насколько я помню, есть только поле последней авторизации. Возможно, нужно завязывать на сессии +временной промежуток.
Возможность сделать станицу пользователя общедоступной для просмотра
Аналогично пункту 2.А. в разделе «шаблона отображения»
Вот такой вот нехитрый код:
будет приводить к вот такой вот ошибке (в modx-логе):
Дело в том, что такой вот унаследованный объект полученный методом $modx->getObject будет lazy (а вот через newObject всё хорошо). Не буду расписывать что это такое и почему. Факт в том, что сохраняться ничего не будет.
Чтобы всё работало как ожидается, надо в унаследованных классах переопределять метод set:
Либо перед изменением данных объекта делать
Тогда тоже будет хорошо, но это не удобно.
Лучше переопределить метод set и не заморачиваться. В этом случае $o->fromArray() тоже будет работать адекватно.
П.С. Файл должен быть в корне сайта. И не забудь изменить префикс в настройках core/config/config.inc.php
П.П.С. Только надо быть осторожным на рабочем сайте. Нужно проверить работу всех дополнений. Login, например, может глючить.
У меня примерно так было давно, на вызываемой странице сниппет.
Далее в коде делаем так (кэшируем состояние объекта xPDOQuery):
Тест (1 TV и 2 простых условия):
При первом выполнении (запрос строится с нуля): 0.005-0.007 сек
При последующих выполнениях (объект xPDOQuery восстанавливается из файлового кэша): 0.0007 сек (из них 0.0005 сек — чтение кэш-файла с состоянием xPDOQuery)
Разница: в 7-10 раз. И это только на простом запросе (1 tv и 2 условия).
Мой запрос с 30 tv-ками и кучей сложных условий готовится (без выполнения) 0.1 сек.
С кэшированием запроса вплоть до пагинации (до добавления limit/offset) — 0.0007-0.0010 сек
Разница: в 70-100 раз.
P.S. Кэширование запроса xPDOQuery совместно с его выполнением в режиме pdo может придать ему реактивные свойства. И переписывать запрос на чистый pdo не потребуется.
[[+address.receiver]] — Покупатель
[[+address.phone]] — Телефон
[[+user.email]] — Почта
[[+address.index]] — Индекс
[[+address.region]] — Область
[[+address.city]] — Город
[[+address.street]] — Улица
[[+address.building]] — Дом
[[+address.room]] — Квартира
[[+delivery.name]] — Способ доставки
[[+payment.name]] — Тип оплаты
[[+address.comment]] — Комментрарий
Это то, что я знаю. А вообще где-то это уже обсуждалось.