Василий Наумкин

if ($modx->user->passwordMatches('0987654321')) {
	echo 'Верный пароль!';
}

github.com/modxcms/revolution/blob/master/core/model/modx/moduser.class.php

Третий топик на главной modx.pro/solutions/3942-dynamic-update-of-the-basic-basket/

Это даже pdoResources может, не говоря уже о собственном сниппете.

Подсказывать не буду, предлагаю самостоятельно прочитать про &class и &showLog.

Думаю, это можно сделать с помощью Tickets.

Только не спрашивай, как именно — читай сразу историю изменений с первой версии.

Да, opcache вшит в ядро.
Да, никакого отдельного обработчика у MODX для opcache нет, так что включать нечего.

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

Если на сайт ходит в сутки 1000 человек — что там кэшировать?

Нет не предназначены.

Если есть большое желание — исправляй родной javascript, чтобы работало, и присылай в репозиторий.

Никакой не нужно указывать.

Все версии MODX до 2.2.15 уязвимы.

Да и про 2.2.15 я совсем не уверен.

Наверное, можно, если сделать это самостоятельно.

Поиск возвращает набор id ресурсов, дальше можно узнать их категории и сортировать.

Видимо, ищут или по статьям или по товарам.

Я другого варианта не вижу, как вызвать mSearch2 2 раза.

Комменты привязываются к ветке комментов, а у неё просто должен быть уникальный &thread.

Короче, делай так:

[[!getComments?thread=`user-[[+user_id]]`]]

Где взять user_id — дело твоё.

Поиск и последующий фильтр — это именно что основное отличие mSearch2 от других решений. Вот, например, он у нас в сообществе работает.

Смотри документацию, тестируй, если понравится — покупай и настраивай.

Будут вопросы — пиши в техподдержку, там я помогу, если что.

Подразумевается, что стоимость этой работы ниже 1990р?

Иначе лучше сразу купить mSearch2.

Пока не практикую — некогда.

Нет, конечно.

Cannot redeclare class modtemplatevarinputrendertext

Это говорит о попытке 2 раза объявить один и тот же класс. У тебя, скорее всего, какой-то кастомный ТВ так барахлит.

Это не полумера, а топорное воплощение первого варианта, которое будет перезаписано при первом же обновлении компонента.

Тут дело не в выборке, а в том, какой реальный uri у документа.

Основных варианта 2:
1. Менять этот реальный uri при создании статьи на нужный — и тогда адрес документа везде будет без контейнера. Тут поможет параметр freeze_uri, автоматизировать можно написав плагин на сохранение.
2. Выводить ненастоящий адрес документа, а потом перенаправлять на него примерно так.

Выбирай.

P.S. Tickets умеет генерировать uri вложенных документов контейнера по шаблону, у Articles должно быть что-то подобное.

Поправил, спасибо.

Не нужно растраиваться, лучше поищи хостинг пошустрее — выбор богатый.

Нет, ни разу такого не видел.

Думаю, что дело всё-таки в сниппетах.