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

Модификатор in, скорее всего, работает так из-за того, что он списан с аналогичного модификатора у родного парсера MODX.

Да.

github.com/fenom-template/fenom/blob/master/src/Fenom/Modifier.php#L175

Используйте параметр 'list':
github.com/fenom-template/fenom/blob/master/docs/ru/operators.md#%D0%9E%D0%BF%D0%B5%D1%80%D0%B0%D1%82%D0%BE%D1%80-%D0%BF%D1%80%D0%B8%D1%81%D1%83%D1%82%D1%81%D1%82%D0%B2%D0%B8%D1%8F

Возможно, вам лучше подойдет модификатор in.

github.com/fenom-template/fenom/blob/master/docs/ru/mods/in.md

{$pageId | url : ['scheme' => 'full']}

Можно ли отключать/подключать вкладку штатными средствами для конкретных шаблонов?

{$parent | url}

А вообще, если у вас жестко задана id категории, как в примере выше, то правильнее один раз вне msProducts определить url родителя, после чего в сниппет передавать уже готовый результат.

но для большинства (даже из этого сообщества) он всё же является больше CMS нежели CMF

И вы считаете, что это необходимо поощрять?

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

Однако это не отменяет того факта, что они делали дополнения и для широкого круга людей. Зачем например Василию понадобилось создать тот же Theme.Bootstrap, если любой и так может закинуть его на сайт за считанные минуты?

*пожал плечами* не знаю.

А вы не думаете, что чем больше таких заказчиков будет, тем больше у вас же будет работы впоследствии?

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

Вы можете взглянуть на другие технологии с высоким порогом вхождения — та же реактивность не становится из-за него менее актуальной. Другое дело, что не каждый готов её предложить.

Такие дополнения как например темы никому из программистов не нужны, у них другая целевая аудитория.

Как и у MODX-a.

Зачем популяризировать нашу систему?

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

Впрочем, неважно. Ваша позиция понятна, смело прохожу мимо.

Согласен, по объему кода компоненты ~сопоставимы.

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

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

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

Начну издалека: MODX, как бы многим не хотелось, в его текущей архитектуре и в планах о MODX 3 — это все-таки CMF. Дружелюбный для программистов и позволяющий сэкономить время готовыми решениями из ядра только на самых общих задачах (права пользователей, роутинг, древо ресурсов и тд).
Для реализации чего-либо вне вышеописанных рамок вам необходимы как минимум базовые знания js, php и прочего (об ExtJs умолчу, т.к. даже среди программистов сообщества с ним знакомы дай бог процентов 20-30).

Более того, паровозы MODX-a неустанно толкают вектор развития в сторону фреймворка — работа из IDE, файловые чанки и альтернативный шаблонизатор от Василия, эмулятор посредников Сергея Шлокова и интеграции с NodeJs и React-ом Николая Ланца и but1head'a.
Вы можете сказать, что есть еще масса других дополнений формата mSearch2 и minishop2, но они в своем большинстве, во-первых, позволяют сэкономить действительно значимый объем времени, а во-вторых, имеют большой запас для расширяемости.

Возвращаясь к сути — на мой взгляд, проблема дополнений формата «снег на сайт из коробки» не только в том, что это более медленное решение задачи (лишние запросы и подключаемый отдельно css/js), но и в том, что из-за них формируется неверное представление о самом MODX-e и программировании на нем.
Конечно, действительно хорошие программисты от этого только выиграют — больше сайтов уйдет к ним на последующую оптимизацию, но тенденция, как по мне, все равно печальная.

В конце концов, если вам жизненно необходимы пакеты на каждый чих — зачем использовать MODX, когда есть Wordpress и ему подобные?


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

Я ни в коем случае не против того, чтобы разработчики дополнений хорошо зарабатывали, но вы правда считаете, что если в один прекрасный день, допустим, Василий Наумкин взглянет на «снег на сайт за 290 рублей» (который, к тому же, сам по себе написан не разработчиком пакета) и решит, что раз такой чих стоит денег, то пора бы пересмотреть цену на minishop2 — сообществу станет лучше?

Не понимаю за что минусуют — тенденция перенести все «решения», гуглящиеся фразой «скрипты для сайта Ucoz», на MODX выглядит весьма сомнительно.

UPD: ну или можно пойти еще дальше, пройдясь сразу по всему codepen.io

Скорее ~85-90. Далее — уже шаманство и извращения.

надо лишь попросить у него готовый код

Это излишество — достаточно чуть-чуть погуглить и написать 4-6 строк для кастомного рендера:

var tvSuperSelect = function(value, metaData, record, rowIndex, colIndex, store) {
	if (value != '' & value != null) {
		//Тут, возможно, нужно будет дополнительно обработать входящее значение, вырезав из него лишнее
		var tags_list = JSON.parse(value);
	
		return tags_list.join(', ');
	}
}

лол)

Как-то так:

'tvFilters' => 'gamename===' ~ $_modx->resource.id,

Мои глаза…

<?php
	if (($modx->event->name == 'OnDocFormSave' && $mode == 'new') || ($modx->event->name == 'OnDocFormRender' && $mode == 'upd')) {
		switch ($resource->get('template')) {
			case 10:
			case 12:
			case 14:
				$source = 3;
				
				break;

			case 11:
				$source = 5;
				
				break;
				
			case 15:
				$source = 6;
				
				break;
		}
		
		if ($source) {
			$properties = $resource->get('properties');
			$properties['ms2gallery'] = array('media_source' => $source);
			$resource->set('properties', $properties);
		}
	}
	
	if ($mode == 'new') {
		$resource->save();
	}

Можете написать мне в скайп (justbekami) доступы.
Если никаких побочных проблем не возникнет — помогу бесплатно.

bezumkin.ru/sections/tips_and_tricks/2439/ — внизу лежит код готового сниппета для переключения языков.

Нужно:
1. подключить модель и все параметры вашего сниппета в вызов mFilter2
2. расширить метод фильтрации, чтобы mFilter2 научился фильтровать по вашим таблицам.

В стилях (подключенный файл с расширением .css) или напрямую в шаблоне страницы.

Смотрится следующим образом (если у вас хром):
1. нажимаете пкм на проблемный элемент (ваш селектор)
2. выбираете пункт «просмотреть код»
3. справа в появившемся блоке будут указаны стили элемента и место их подключения