Максим Кузнецов

В «возможные значения» tv прописываем

@EVAL return $modx->runSnippet('любое_название_сниппета_который_есть_в_системе');

— к примеру, можно создать свой сниппет «customTvList» и запустить в нем wayfinder или любой другой подходящий для задачи сниппет:

$params = array();
		$params['tpl'] = "tpl.Custom.List";
		$result = $modx->runSnippet('wayfinder', $params);
		return $result;

Здесь же можно и ограничить вывод возможных значений.

Редактировать ext js, скорее всего.

Ну и как вариант, могу предложить такое решение (костыль):

Создаем плагин adminStyles, срабатывающим на событие OnManagerPageBeforeRender с последующим кодом:

<?php
	$modx->controller->addHtml('<link rel="stylesheet" type="text/css" media="screen" href="../design/admin.css" />');

Ну и добавляем по указанному адресу соответствующий css-файл с параметрами {display: none;} к соответствующему элементу.

pdoField docs.modx.pro/components/pdotools/snippets/pdofield должен помочь.

Выпадающий список данной структуры реализуется за счет тега optgroup. Пример:

<select>
  <optgroup label="Категория 1">
    <option value="1">Параметр 1</option>
    <option value="2">Параметр 2</option>
  </optgroup>
</select>

Т.е. нужно модифицировать формат вывода getResourse к данной структуре.

on.change при для нажатия на +- в корзине, + on.click на класс кнопок, добавляющих товар в корзину, а дальше — по id корзины проверять для каждой строки товара выполнение условия, и, если выполняется, ставить цену 2, а если нет — цену 1.

Чтобы не извращаться с поиском «новой цены», можно где-нибудь в невидимом блоке в корзине рядом с основной ценой ставить доп. цену и свитчить их при выполнении условия.

Ну и + все дополнительные места, которые могут повлиять на кол-во товаров, тоже зацепить скриптом.

Можно в ресурсах, которые собираешься выводить, в пункт «атрибуты ссылки» дописать что-нибудь в духе class=«icon-название» для каждого пункта, где требуется иконка и вывести в шаблоне (tpl) в нужном месте при помощи плейсходлера [[+attributes]].

Дальше — дело за css.

Первое — думаю, с друзьями проблем не будет — просто 1 доп.поле, где в массиве будут перечисляться id пользователей с последующим выводом через pdoTools

Второе — store.simpledream.ru/packages/users/socialtools.html не подойдет?

а) отключить проверку форм со стороны сниппета и подключить проверку со стороны яваскриптов

б) добавить 1 скрытое поле, на которую навесить проверку со стороны formlt + яваскрипт, который срабатывает на событие on.change нужных форм и заполняет/чистит поле валидации

в) написать свой сниппет для этого, благо функционал не сложный

По-настоящему «прямые» урлы генерируются только в случае, если добавлять в файловой структуре аналогичные элементы с желаемым названием, допустим, page23.html

У modx'a, если не ошибаюсь, для чпу в .htaccess прописано:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

+ опять же, если пользоваться встроенными в modx настройками чпу и определением «страниц» для генерации страниц красивых ссылок для страниц пользователя, то необходимо «создавать» такие страницы в желаемом разделе при регистрации пользователя, а это вытекает в

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

Да, именно.) Исключение, разве что медали, которые выдаются персонально за личные заслуги и не подвергаются систематизации.

Я все это, помимо прочего, написал ради отображения одного фактора. Т.к. задача действительно фундаментальная, при этом, на мой взгляд, не требующая глубинных познаний в modx'e, вероятно, есть причина, почему схожий по функционалу пакет до сих пор не появился: труднореализуемость настройки для коробки.

На мой взгляд, для отображения страницы пользователя можно применить 2 принципиально разных решения:
— динамичное получение данных логина или id пользователя из адресной строки с последующем отображением
— фиксированное создание страницы пользователя в нужном разделе

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

Поэтому выбрав пункт 1, мы автоматически очень сильно связываем себя с внесением записей в .htaccess, а значит все равно допиливать дополнение руками.

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

Ну и последнее и, пожалуй, самое главное: для удобной работы с дополнительными полями пользователя (медальки, карма) «не программисту» потребуется или написать фронтэнд-модуль или существенно изменить способ взаимодействия с ними через бэкэнд.

С вашего позволения, приведу сюда пример реализации большинства пунктов (не отрицаю востребованнось решения данных задач сразу из коробки, т.к. работы для реализации этих пунктов нужно сделать прилично):

Страницы пользователей с нормальными урл

1. Создаем страницу «профиль пользователя» (не путаем с личным кабинетом), выставляем ему псевдоним, допустим users, к которой будут обращаться в виде site.ru/users?profile=имя

2. Ставим дополнение pdoTools

3. Создаем сниппет user.Profile и добавляем его в шаблон вывода

<?php
	$count = $modx->getCount('modUser', array('username' => $_GET[profile]));
	if($count <= 0){
		echo'	<h2>
				<a>Ошибка</a>
			</h2>
			<div>
				Пользователя не существует.
			</div>';
	}
	else {
		$params = array();
		$params['users'] = $_GET[profile];
		$params['showBlocked'] = '1';
		$params['tpl'] = 'user.Profile';
		$params['prepareSnippet'] = 'user.Profile.Prepare';
		
		$result = $modx->runSnippet('pdoUsers', $params);
		
		if (!empty($result)) {
			return $result;
		}
		else {
			return '<h2>
					<a>Ошибка</a>
				</h2>
				<div>
					Что-то сломалось.. Сейчас починим.
				</div>';
		}

	}

— насколько я помню, сразу вызвать pdoUsers с параметром конкретного пользователя нежелательно, т.к. если пользователя не существует, он выдает по-умолчанию весь список пользователей. Возможно, сейчас что-то поменялось или это можно обойти — не проверял.

Для данного сниппета также можно дописывать условия, если пользователь не активирован и тд и тп. При помощи параметров tpl и prepareSnippet кастомизируем до нужного уровня.

4. Дописываем в .htaccess

RewriteRule ^users/([^/]+)$ /users?profile=$1 [L]

— чтобы ссылка приняла вид site.ru/users/Имя_пользователя

Возможность добавлять поля в профиль пользователя

При регистрации: дополнение login
Для редактирования пользователем (личный кабинет) — дополнение office

Возможность указывать шаблон для оформления страницы пользователя

1. Добавляем дополнительное поле в личный кабинет пользователя (шаблон отображения)
2. В шаблоне отображения профиля пользователя дописываем классы, завязанные на полученном значении (class=«userInfo-[[+tpl.style]]»)
2.А. Если необходимо менять структуру шаблона в зависимости от выбранного пользователя значением, то в сниппете в первой части дописываем до

$params = array();

получение extended-поля по id пользователя с вытекающими условиями if, внутри которых будет разный параметр $params['tpl']

Добавить «из коробки» дату регистрации и дату последней активности

Дату регистрации — сниппет логин и 1 доп. поле.
С датой последней активности сложнее, т.к. в таблицах Modx'a, насколько я помню, есть только поле последней авторизации. Возможно, нужно завязывать на сессии +временной промежуток.

Возможность сделать станицу пользователя общедоступной для просмотра

Аналогично пункту 2.А. в разделе «шаблона отображения»

Как функционал дополнения в копилку modx'a — очень даже. Думаю, многим порталам будет востребовано.

По поводу импорта такого функционала на данный сайт — спорно (имхо).

Может, я не совсем корректно уловил задачу, но, похоже, вам для данной задачи все равно потребуется использовать часть функционала pdoMenu, а именно — обратный цикл, чтобы определить уровень вложения.

Думаю, основной параметр для данной задачи — where +было бы на порядок проще, если бы нужные для вывода документы, помимо глубины, имели еще общие или справедливые только для них шаблоны — тогда весь вызов можно было бы ограничить только условием на соответствие этих шаблонов.

pdoMenu, pdoResources? docs.modx.pro/components/pdotools/

Странный подход, на мой взгляд modx намного больше cmf, чем cms — поэтому и воспринимается как платформа, в первую очередь, для программистов.

Готовое дополнение (без морфологии) — tagLister. Со всеми наворотами — разве что писать с нуля и, на мой взгляд, на порядок целесообразнее отдельным дополнением, т.к. те же теги потенциально пригодятся не только в тикетах (галереи, фото-видео и пр пр).

Ну, на мой взгляд, годные программисты и так стараются писать все дополнения под себя, за исключением pdotools, tickets и аналогичных, которые написаны слишком уж хорошо +на реализацию которых самим просто нет возможностей/времени.

ребята, которые строят хорошие «юзер-френдли» ресурсы, — оценивают это дополнение, как одно из самых удобных, функциональных и быстрых на фоне аналогов в друпале и вордпресе.

— к чему это сказано? С тем же успехом можно было сказать что-то в духе: «ребята, которые работают на битриксе, оценивают битрикс как один из самых удобных и быстрых функционалов», но вряд ли от их мнения он таким становится.

Ну и да, к слову: большого ума, как по мне, чтобы реализовать более быстрый аналог друпалу и вордпрессу в текущей их ипостасти и не требуется. Ровно до тех пор, пока легкие дополнения Modx'a не стали «универсальным решением на все случаи жизни из коробки для ленивых»

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

Да, это справедливо. Помнится, Agel Nash даже выявлял довольно неприятные уязвимости tv-полей.

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

Нормализация — тут уже придется подключать словари и не только. Вообще, если нужен будет морфологический анализ, имхо, это очень серьезный и сложный вопрос реализации, заслуживающий полноценного и отдельного дополнения.

А что имелось ввиду под «исключением тега»?

Могу ошибаться, но по-моему в нем где-то жестко использовался getResource в отображении, поэтому и написал свой модуль (повторяюсь, могу ошибаться — дело было давно) =)

Если честно, я и прелести tagLister'a не оценил — он уж на случай крайней лени, как по мне.

Вот как реализованы теги у меня (может, кому пригодится):

1. Дополнительное поле «tags»
Параметры ввода: Авто-метка (можно и простой строкой, по желанию)

2. Сниппет «tags», делающий теги ссылками (для последующего поиска по ним)

<?php
	if ($input == ''){
		return;
	}
	$tags = explode(',',$input);
	foreach ($tags as $key => $value){
		$output[] = '<a href="'.$modx->makeurl($tagsPage, '').'/'.$value.'" itemprop="keywords">'.$value.'</a>'; 
	} 
	return implode(', ',$output);

3. Вывод в чанке

[[*tags:notempty=`
<div class="tagList" itemscope itemtype="http://schema.org/CreativeWork">
	[[!tags? &tagsPage=`91` &input=`[[*tags]]`]]
</div>
`]]

— где &tagsPage — параметр, определяющий айди страницы поиска по тегам для формирования ссылки

Ну и дополнительно, для «полного спектра услуг»:

4. Создаем страницу "Поиск по тегам" с псевдонимом tag, где будем выводить все теги, удовлетворяющие запросу:

[[!pdoPage &parents=`0` &includeContent=`1` &where=`{"tags:LIKE":"%[[!GET? &get=`tag`]]%"}` &includeTVs=`tags` &limit=`10` &sortby=`createdon` &sortdir=`DESC` &depth=`1` &tpl=`tag.Item`]]

— где сниппет GET перехватывает выбранный тег в адресной строке.

GET

<?php
	return $_GET[$get];

5. Дописываем .htaccess, чтобы адресная строка поиска приняла вид site.ru/tag/Название_тега

RewriteRule ^tag/([^/]+)$ /tag?tag=$1 [L]