Александр Туниеков

Может так

[[!pdoPage?
        &parents=`4`
        &includeTVs=`rubrika`
        &where=`{"rubrika:LIKE":"%[[*option]]%"}`
        &tpl=`RowTpl`
]]

если значения rubrika меньше 10 должно ловить. Если больше 10, то на option=1 словит и 1 и 10 и 11 и т.д.

Не быстрее. Так только от 1 запроса на картинку избавишься. По идее самый быстрый вариант подцепить парент титле и картинку в pdoResource. На 99% уверен. Но, конечно, если гнаться за скоростью, надо тестировать все варианты и на практике смотреть уже.

Не знаю как в прошлый раз тестировал. Тогда в моем компоненте mapFilter загрузка с подсчетом результатов на 10т товавов в каталоге выдавало около 10с, а сейчас первая загрузка около 1,2с а вторая с кешем mysql 0.0769041: Total time. (В каталоге 10т. товаров — это самый большой каталог. Всего товаров на сайте 27т.). Правда сейчас я чуть подшаманил и запрос делаю только для 1 каталога.
А вот прокешированный mFilter2 на этом же каталоге при загрузке из кеша массива ids ресурсов тратит 1.7866640: Total time. И при выборе какого-то фильтра делает suggestions 25с.
mapFilter:

mFilter2:


То есть mapFilter работает все таки быстрее mFilter2. И имеет смысл его доделывать. То есть, я не буду выкладывать код. В течении 2-3 месяцев доделаю и буду продовать :-).

пс. Почему-то mFilter2 ошибочно считает suggestions. Для женщин он посчитал 31 кольцо, а на самом деле их 4082.

пс2.

в mFilter есть подсчёт результатов по каждому фильтру, но для фильтров из коробки я этого делать не планировал

На самом деле, если сделали фильтры как в mFilter2, то suggestions уже просто посчитать. В mFilter2 это 100 строк кода всего.

Да я про подсчет результатов. Почему-то называл всегда подсказками :-(

поэтому скидывайте кейсы

Сейчас код вне зоны доступа :-). Завтра скину

Может вы закрывающею } не скопировали???? Ошибка на это похожа.

Вообще у тебя в ms2Gallery 'limit'=>1 и 2 вариант будет не сильно быстрее. 2+1 простых запроса в базу против 1 более сложного на каждый вызов ms2Gallery. То есть на 1 картинку.
Если картинок много то лучше в основном pdoResources сразу и картинки и Parent подцепить join-ми. Тогда быстрее будет. 1 запрос на все против 3 запросов на каждый дочерний ресурс.
Примерно так:

{'!pdoResources' | snippet : [
    'parents'=>5,
    'tpl'=>'res_chunk',
	'loadModels'=>'ms2gallery',
	'leftJoin'=>[
		'File'=>[
			'class'=>'msResourceFile',
			'on'=>'File.resource_id = modResource.id and File.rank = 1 and File.path LIKE \'%small%\''
		],
		'Parent'=>[
			'class'=>'modResource',
			'on'=>'Parent.id = modResource.parent'
		],
	],
	'select'=>[
		'modResource'=>'*',
		'File'=>'File.url as file_url,File.name as file_name',
		'Parent'=>'Parent.pagetitle as parent_title',
	],
]}

res_chunk:

<div class="col-6 col-md-3 col-sm-6 gv-card">
	<div class="product-grid">
		<div class="product-image">
			<a href="{$id | url}" class="image">
				{if $file_url}
					<img src="{$file_url}" alt="{$parent_title}" title="{$file_name}">
				{else}
					<img src="assets/img/projects/v-1.png" alt="{$pagetitle}" title="{$pagetitle}"/>
				{/if}
			</a> 
			<div class="add-to-cart">
				<a href="{$id | url}">{$pagetitle}</a>
			</div>
		</div>
	</div>
</div>

Я бы так делал, если картинок много. И phpthumbon бы не стал использовать, а задал бы нужное превью в галерее. Интересно даже какая скорость будет во всех 3 вариантах.
пс. pdoResources наверно лучше кешировать.

Спасибо. Теперь более-менее понятно

Ну тут 2 варианта:
1) не очень хороший. В $file должно быть $file['resource_id'] и в alt="… ТО САМОЕ..." можно сделать так

alt="{($file['resource_id'] | resource: 'parent') | resource: 'pagetitle'}"

Но модификатор | resource ресурсо-затратный и если будет 100 картинок, то страница будет тупить.
2) В ms2Gallery сразу добавить запрос паджтитл родителей
{'!ms2Gallery' | snippet: [
'resources'=>$id,
'innerJoin'=>['Parent'=>['class'=>'modResource','on'=>'Parent.id = modResource.id'],
'select'=>['Parent'=>'Parent.pagetitle as parent_title'],
'limit'=>1,
'tpl'=>'ms2Gallery.mainpage.tpl'
]}

alt="{($file['parent_title']}"

Примерно так не проверял

$_modx->resource.id — выводит 1

Ну тут выдается главная страница. То есть код выполняется когда показывается главная. $_modx->resource это массив параметров страницы которая загружается показывается.
Ты на главной выводишь блок с ресурсами. Например:

{'!pdoResources' | snippet : [
    'parents'=>5,
    'tpl'=>'res_chunk'
]}

В res_chunk можно указывать:

{($id | resource: 'parent') | resource: 'pagetitle'}

И должно верно вернуть паджтитл ресурса родителя.
Но наверно ты в res_chunk еще вызываешь ms2Gallery c каким-то чанком. Например gallery_chunk и вот в нем уже $id вернет id файла (или 0 наверно). Чтоб получить id ресурса из res_chunk надо подумать как это сделать.
Но сперва скажи угадал? или у тебя что-то другое?

Я пробовал делать компонент замену mFilter2. Вместо связки значение фильтра — ids ресурсов в массиве, хотел сделать эту связку в базе прописать и вытаскивать ids отфильтрованных ресурсов запросами. Но если отфильтровывает быстро, то подсказки на 100к товаров отрабатывают за сек 10. И если в mFilter2 улучшить кеширование, то разницы в скорости работы особо нет.
Надеюсь понятно написал для тех кто в курсе как mFilter2 работает.

Ну я в курсе, что так заработает. Я не в курсе почему неожиданно сработало так, что переменная которая вроде не менялась изменилась?

вы же по сути ссылку делаете на значения.

Можно поподробнее. Вот ссылка на значение &$v1. И с ней ничего не делаем. Вот ссылка на на значение &$v2. Там меняем переменную. Икак происходит что изменилась переменная которую не трогал?
Нужный код я поправил, чтоб заработал. Хотелось бы понимание что происходит, чтоб не нарываться в будущем

А как там вконтакте уведомления? я там обычно с почты захожу.

В операционке? Это надо в гугл ключ брать и писать отправку уведомлений через гугл. Пока не до этого.

Чтобы сразу был открыт чат с каким-то определенным юзаром надо добавить в ссылку GET-параметр user_id. урл_страницы_мессенджера?user_id=20
Чтобы убрать поиск юзера, чатов и список чатов, надо скопировать чанк tpl.RealMessenger.outer закомментировать в нем панель ctrl-panel. Например my.b4.tpl.RealMessenger.outer

<div id="realmessenger" data-hash="{$hash}">
    <div class="row">
        {*<div class="ctrl-panel">
            {$search_contact}
            {$search_chat}
            {$chats}
        </div>*}
        <div class="mess-panel">
            {$messages}
            {$form}

        </div>
    </div>
</div>

Иназначить этот чанк сниппету:

{'!RealMessenger' | snippet :[
    'OuterTpl'=>'my.b4.tpl.RealMessenger.outer',
]}

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

А Штуковину для услуг можно применить и для новостей

А как одновременно и для услуг и для новостей?

Основных блоков же штук 40. Зачем их плодить для каждой темы?

В общем все что вы говорите про функционал — это почти все есть в пакете.

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

Походу темы для CMS дело не простое. Я програмист php и написать функционал мне просто, но я нефига не дизайнер и не верстальщик. Взять шаблон из инета и натянуть его могу, но то шаблоны не нравяться, то половины нужной верстки нет.
В общем мне бы пригодились темы для MODX, но с набором готовых красивых стилей, щелкнул 1 стиль — расцветка сайта одна, щелкнул другой цвета и оформление другое.
На мой взгляд, @Алексей Смирнов сделал темы для дизайнеров. В php разбираться не нужно, но в стилях и в дизайне нужно неплохую подготовку иметь, чтобы этими темами воспользоваться.
Второе, что не очень понятно по видео, как устроены штуковины. Хотелось бы чтоб был набор готовых стандартных блоков, к которым можно применить разные стили раз. Два это возможность вставлять их в разные места сайта без их дублирования. Три штуковину услуги можно было сделаль универсальной. Не только для услуг, но и для новостей, популярных товаров например.
В общем, мне эти темы не подходят, а чтоб подходили, думаю, надо их значительно доработать.
Я бы кстати поучаствовал. Только в vue не разбираюсь :-(

Портал modx.pro к магазину не относится.

Здесь есть описание и комментарии к компонентам в магазине. Так что думаю портал к магазину относиться. Второе отзывы с модсторе давно убрали. Ругать авторов Делиться впечатлениями об компонентах больше негде.
Третье. Задержка выдачи страницы больше, чем на секунду не допустима. Любой компонент, что подобное вообще допускает бесполезен.
И четвертое. В жизни бывает всякое. Бывает и нужно поругаться. Конечно не доводя до «ты дебил», но слишком благостным быть не стоит. Это не жизнеспособно, на мой взгляд. Вообщем сообществу, на мой взгляд, нужно уметь разрешить конфликты, а не гасить из в зародыше и тем самым переводя конфликты в тихую но злобную :-) фазу.

Автор в ответе за то что он написал. В описании ни слова о таких задержках. И это его косяк.