Наумов Алексей

Отличная работа!
Поставил для теста, вроде работает)))

В целом правильно… только вот вопрос, FormIt2db хранит данные не в json формате случайно? Поиск вы потом как будете по таблице делать?
Вместо скрытых полей — можно prehook сделать и добавлять к данным информацию о пользователе, текущем времени.

Есть в miniShop2 скрипт для импорта из csv

Он же умеет создавать ресурсы как при запуске из браузера, так и в режиме запуска из командной строки.

Или создавать документы через API, в целом это нормальный вариант, главное создать правильно (заполнить все поля имею ввиду) и проследить, чтобы были обработаны ситуации, если у вас плагины есть на события создания/редактирования документов. Ну и кеш там почистить потом.
Или же в скрипте залогиниться в админку под пользователем-админом (менеджером), что как бы не особо безопасно…
Или же настроить права так, чтобы аноним мог создать страницу, что тоже не гуд.

Можно почитать
modx.pro/solutions/22267

Самое простое сделать запрос в БД, примерно (! без проверки пишу) так:

$q = $modx->newQuery('ecMessage');
$q->where(array(
'thread' => 123, // id цепочки сообщения
'published' => 1,
'deleted' => 0,
'rating:>'  => 3,
));
$count = $modx->getCount('ecMessage', $q);

Добрый день, штатно нет.
Можно попробовать какой-нибудь плагин сделать на событие создания сообщения, но не уверен, что все получится 100% без вмешательство в ядро компонента

Может значение длинное получается? Ну где-нить ограничение стоит 256 или 100 символов?

Да как бы вообще проще простого:

{if $_modx->user.id > 0}
    {'!msOrder' | snippet}
{else}
    Вам нужно авторизоваться для оформления заказа.
{/if}

В общем да… в частном нет… к сожалению (
1. Проблемы безопасности, находят уязвимость, в старой версии (не важно чего, MODX или miniShop) никто исправлять не будет — обновляйте!
2. Проблема совместимости со сторонними компонентами. Подключен у нас модуль интеграции со СДЭК, обновили они свое API, компонент соответствующий для MODX обновился, но он теперь работает только на свежем miniShop, обновляйте!

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

Николай, добрый день! Раз уж мажорная версия, может быть стоит и вот с этим навести порядок сразу? modx.pro/help/21786
Не так давно я писал об этой неоднозначности с email и phone в miniShop2.

У кого-то здесь недавно была схожая проблема. Оказалось, что при переносе сайта не создались индексы в БД. Стоит посмотреть, есть ли они у используемых таблиц.

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

Привет, посмотри здесь:
modx.pro/howto/8889
modx.pro/help/1806

Я вижу «Результат 0.2634 s — Total Time» — если у вас в pdoMenu 200 элементов рендерится — выглядит приемлемым (ну может хостинг не самый быстрый).

Когда работает debugParser — считай видим результат без кеша. Вообще долго конечно, 0,7 с, но опять же… 200 элементов… При этом время на sql запросы маленькое, а вот парсинг долгий…
Ради прикола вызвал этот же код на одном из своих сайтов, где 25000 страниц, а при генерации меню с level=3 генерируется около 1800 пунктов в этом самом меню.

1й вызов (без кеша):

0.4623 s — Query Time — Shows how long MODx took talking to the database
1844 — Query Count -Shows how many database queries MODX made
0.8484 s — Parse Time — Shows how long MODX took to parse the page
1.3107 s — Total Time — Shows the total time taken to parse/ render the page
database — Source — Shows the source of page, whether is database or cache.

2 вызов (с кешем):

0.0041 s — Query Time — Shows how long MODx took talking to the database
21 — Query Count -Shows how many database queries MODX made
0.0325 s — Parse Time — Shows how long MODX took to parse the page
0.0366 s — Total Time — Shows the total time taken to parse/ render the page
cache — Source — Shows the source of page, whether is database or cache.

как видно, во втором случае все очень хорошо и быстро отрабатывает…
Может у вас плагины какие-нибудь висят или еще что-то подобное?

Чанк выглядит ужасно)
Оптимизируйте.
Во-первых, в чанке доступен Fenom, а у вас смесь из Fenom и родного парсера MODX.
И в этом вся проблема.
Если вы не знаете, то вот это

[[+template:is=`3`:then=`КОД 1`:else=`КОД 2`]]

и вот это

{if $template == 2}
КОД 1
{else}
КОД 2
{/if}

работает совершенно по разному!

В первом примере КОД 1 и КОД 2 все равно ВСЕГДА сначала выполняются (!), а только потом парсер показывает результат в зависимости от условия.
Учитывая, что у вас там внутри еще вызовы различных сниппетов…
А вот во втором примере все работает хорошо, сначала проверяется условие, и только потом выполняется КОД 1 или КОД 2.

Далее

<!-- [[pdoField? &id=`[[+id]]` &field=`pricetv`]] -->

это комментарий html! Код все равно выполняется!!!

ну и самый трэш здесь

[[+tv.imgTV:is=``:then=`
<img 
src="[[+tv.img:default=`[[!msGallery?tpl=`msGalleryCategory`&product=`[[+id]]`&limit=`1`]]`:phpthumbon=`w=200&f=webp&q=65`]]" 
data-img="[[+tv.img:default=`[[!msGallery?tpl=`msGalleryCategory`&product=`[[+id]]`&limit=`1`]]`:phpthumbon=`w=200&f=webp&q=65`]]" 
class="zerone lazy" 
alt="{$pagetitle}" />
`:else=`
<img src="[[+tv.imgTV]]" 
data-img="[[+tv.imgTV]]" 
class="zerone lazy" 
alt="{$pagetitle}" />
`]]

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

У вас большой

8.5561 s — Parse Time

нужно смотреть чанк msProduct

Ну и

751 — Query Count -Shows how many database queries MODX made

чет многовато)

в catalogItemTpl что?

Ну и 5 JOIN по tv полям… ну не самое классное, что можно придумать..., тем более, что tv хранятся как строки, а вы хотите их как number видеть… все это CAST лишние

Сортировка опять же по TV…
includeContent действительно нужен?

Хоть бы код посмотреть…
хотя что, пойду кофе налью, на гуще погадаю