Василий Столейков

А я бы сделал немного по-другому.

1. Создаём сниппет date.

2. Вставляем в него код:

<?php
$d = $modx->getOption('d',$scriptProperties,0);
$format = $modx->getOption('format',$scriptProperties,'j F Y г.');
$translate = array(
    "Monday" => "Понедельник",
    "Tuesday" => "Вторник",
    "Wednesday" => "Среда",
    "Thursday" => "Четверг",
    "Friday" => "Пятница",
    "Saturday" => "Суббота",
    "Sunday" => "Воскресенье",
    "January" => "января",
    "February" => "февраля",
    "March" => "марта",
    "April" => "апреля",
    "May" => "мая",
    "June" => "июня",
    "July" => "июля",
    "August" => "августа",
    "September" => "сентября",
    "October" => "октября",
    "November" => "ноября",
    "December" => "декабря"
);
$date = strtotime("$d day");
$output = str_replace(array_keys($translate), array_values($translate), date($format, $date));
return $output;

3. Вызываем наш сниппет в 3-х местах с нужными параметрами:

дата сегодня — [[!date]] // выведет 15 ноября 2015 г.
дата через десять дней — [[!date?&d=`+10`]] // выведет 25 ноября 2015 г.
дата через 20 дней — [[!date?&d=`+20`]] // выведет 05 декабря 2015 г.

Можно и в другую сторону:

дата за десять дней — [[!date?&d=`-10`]] // выведет 5 ноября 2015 г.

Также можно менять формат вывода, по умолчанию j F Y г.:

[[!date?&d=`-10` &format=`j F Y года`]] // выведет 5 ноября 2015 года

Долго думал выбирать ли Semantic UI как основной фреймворк для разработки после бутстрапа, но отказался от него по той же монструозной причине.
В итоге перешел полностью на легковесный, но не менее крутой UiKit + выдернул нужный мне из Semantic UI шрифт для иконочных флагов стран.

В документации.

Насколько я понимаю, этот компонент тесно с ним связан, судя по предыдущей статье, где говориться про ресурсы с классом msProduct.
А по поводу смены версии — не думаю что этот пакет не работает с старой стабильной версией минишопа, который ещё не разветвлялся. И не думаю что он не будет работать с новой его версией.
P.S. В любом случае, это решение автора дополнения, я вообще тут случайно проходил… )))

Я же боюсь представить себе одно законченное решение, которое будет повторять то что умеют другие пакеты и будет иметь возможности на все случаи жизни… Вот это будет комбайн — Битрикс отдыхает! )))
Зачем утяжелять компонент тем, что есть в других? Тем более учитывая поднятую волну про копирование кода (а без этого не обойтись, если впихивать в этот пакет то, что есть в других).

В этом и суть любого Лего. Всё собирается по кусочкам в полную картину.

Спасибо за пример, он натолкнул меня в нужном направлении!
Я написал переходный сниппет-модификатор, подходит и для extended-полей.

Набросал свой сниппет-модификатор user_info (чтобы легче было перейти с MODX-модификаторов) по примеру выше.
Вполне себе рабочее решение как мне кажется:

<?php
$output = '';
$profile = $modx->getObject('modUserProfile', ['internalKey' => $input]);
if($profile) {
    if (strpos($options,'extended.') === false) {
        $output = $profile->$options;
    } else {
        $ext = explode(".", $options);
        $profile = $profile->get('extended');
        if(isset($profile[$ext[1]])) {
            $output = $profile[$ext[1]];
        }        
    }    
}
return $output;

Вызываю его так:

{$_modx->runSnippet('!user_info', ['input' => 2,'options' => 'extended.skype'])}

где в options вбивается поле пользователя или extended-поле через точку.

Спасибо тебе, Гвоздь, и Василию за примеры и пинки в нужном направлении!

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

{$modx->getObject('modUser', 2)->getOne('Profile')->email}

Решил следующим образом:
1. Включил MODX в Fenom (pdotools_fenom_modx)
2. Вызвал следующим образом:

{$modx->getObject('modUser', 2)->username} // где 2 - это ID нужного пользователя

Возможно есть и более удобный способ.

Да, сначала заметил в панели хостинга новые буковки «мес.», а потом заглянул сюда. Просто шикарные новости!

Хостинг какой? Проверьте воообще возможность отсылки писем с вашего сервера. Можете воспользоваться сниппетом quickEmail для проверки. Или настроить почтовый сервер.

В верхнем меню «Управление — Пользователи» в таблице первая колонка это ID.

А что мешает переименовать чанки в соответствии с языком и его подставлять?
Например чанки [[$enmenu]] и [[$rumenu]], а потом просто подставлять системный параметр:

[[$[[++cultureKey]]menu]]

Можно и по другим параметрам, но принцип ясен.

Идеально работает, спасибо! Вопрос решён.

Прости, снова моя невнимательность. Я почему-то зациклился на бесплатных тикетах и поэтому задал вопрос сюда, не подумав о платном mFilter2 и его поддержке…
А за &sortAliases — спасибо! То что надо!

Если требований — ноль, то можно вообще не усаживать админа вручную настраивать всё… Пускай себе крутится как getRelated решит… )))

Стоит ли и дальше искать варианты, или mFilter2 с тикетами не будет работать при множественной сортировке?

Если у заказчика есть конкретные требования к похожести товаров, то тогда нужно думать в сторону комментария выше.
В моей практике же было просто требование «Сделать похожие товары не важно как». В таком случае я использовал сниппет getRelated, но с ним прийдётся поиграться пока его правильно настроишь.

Вызов msProducts:

[[!msProducts? 
	&tpl=`tpl.msProducts.row.new`
	&limit=`3` 
	&parents=`2` 
	&resources=`[[getRelated?&fields=`pagetitle:2,content:1`&parents=`2`&limit=`0`&noResults=``&rowSeparator=`,`&tplOuter=`relatedOuter`&tplRow=`relatedRow`]]`
	&depth=`5` 
	&includeThumbs=`200x150`
	&showHidden=`1`
	&sortby=`RAND()`
]]

Смысл: нужно заставить getRelated выводить список id похожих страниц через запятую. Этот вызов вызывает 3 похожих товара в случайном порядке.

Создать чанки:
relatedOuter

[[+wrapper]]

и relatedRow

[[+id]]

Интересно! По сути, как я полагаю, можно будет очень просто создать свою админку для менеджеров прямо на сайте, не предоставляя им доступа в админку modx?