- Заметки 47
- Комментарии 37
1 час назад
Таки накосячил в myTpl :-). Надо так
{foreach $ress as $res}
<p> {$res.id} {$res.surname}</p>
{/f...
Модификатор сортировки pdoResources по pagetitle 4
Вчера в 17:14
В vesp долго переезжать. Нету модульности никакой и с авторизацией, в смысле с разграничением прав, там Василий особо не напрягался :-)
Плюсы и минусы Vue и gtsAPI 17
Вчера в 13:01
Забыл написать версия modx 3.0.5
И сама форма
<form data-si-form="FormSlider" data-si-preset="slider_form" data-si-event=&quo...
[SendIt 2.0.0] Пагинация и обновлённая загрузка файлов 20
Вчера в 09:34
В критерия должны передаваться параметры where это все что можно передать
т.е.
возможно только так
$criteria = array(
"article:LIKE =>...
Массовое удаление 7
25 ноября 2024, 22:34
Вдруг кому понадобится… Прописать TV параметр в источнике файлов для MIGX можно так (для примера TV `ln`):
[[!migxResourceMediaPath...
Источник файлов и migx 6
25 ноября 2024, 21:01
Привет
Подскажи, пжл как добавить поля из компонента msFieldsmanager?
Скрин
msPre - фильтры по опциям minishop2 11
25 ноября 2024, 20:03
А как добавить если чекбоксы?
msPre добавление кастомного поля (списка с автодополнением) 4
25 ноября 2024, 08:00
ну тогда groupby и having«query» принимает все параметры pdoFetch и в нем есть и groupby и having. Пример навскидку:
"query":{
&quo...
Кейс gtsAPI. CRUD пользователей на фронте 2
24 ноября 2024, 20:31
Правильный вариант из текущей документации такой:
{set $condition = 1}
{switch $condition}
{case 0, 1, 2}
сработае...
Конструкция switch case без break в Fenom 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]] — Комментрарий
Это то, что я знаю. А вообще где-то это уже обсуждалось.