- Заметки 47
- Комментарии 37
6 часов назад
Ну вот и правильная мысль, я же правильно понимаю, что все дополнения, что написаны на ms2 надо переписывать на ms3 многие авторы это не будут делать,...
MiniShop3 - 1.0.0-alpha 15
Вчера в 10:16
Посмотрел докумендацию Sendit.
и нашел то что искал, конечно надо будет писать побольше кода, но это то что надо, и очень гибко оказывается.
Спасибо...
Как кастомизировать сообщения после Регистрации на сайте? 3
28 ноября 2024, 18:01
Так делал на одном проекте, нужно было добавить поиск по полю pagetitle. Думаю, что можно и на TV переделать.
<?php
class myCustomFilter extends...
mFilter2 фильтрация tv 3
28 ноября 2024, 17:35
На ноде при запуске сервера можно большую часть проинициализировать. Например, прогрузить настройки, чанки и сниппеты в память и не лазить за ними в б...
Плюсы и минусы Vue и gtsAPI 18
27 ноября 2024, 19:13
Вообще можно завести допполе и при сохранении ресурса плагином писать в допполе разбирая pagetitle.
Модификатор сортировки pdoResources по pagetitle 7
27 ноября 2024, 12:36
Добрый день. Появилась новая ошибка: 27.11.2024 12:30:20 ERROR /www/site.ru/core/components/yasmartcaptcha/model/yasmartcaptcha.class.php 60
Reco...
YaSmartCaptcha - защитите ваши формы от спама умной капчей от Яндекс 6
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]] — Комментрарий
Это то, что я знаю. А вообще где-то это уже обсуждалось.