Сергей Шлоков

Ну можно поступить проще — нажать сверху кнопочку «Поблагодарить автора» и угостить его хорошим кофе ;)

Да, планирую. Если парсер для страниц можно указать любой (в системной настройке) и отказаться от pdoParser'а, то чанки парсятся жестко только феномом на глядя на то, какой парсер указан в настройке. В принципе можно отключить феном для чанков (отдельной настройкой), то там другая засада — текущий парсер включится только если есть скобки [[. Т.е. ни смарти ни твиговские теги не распарсятся. Как-то так, если я ничего не путаю.

В общем, задача — чтобы pdoTools всегда использовал указанный в системной настройке парсер, который может быть pdoParser, SmartyParser (есть в ZoomX) или TwigParser (если такой будет).

Может я чего-то не понимаю, но получается совсем не короче. Этот путь из названия перемещается в параметр. Т.е. ещё нужно писать отдельный параметр. Что явно выглядит длиннее.

Ну теперь понятно. Только moderrorhandler — это замена PHP-шного обработчика ошибок и минишоп к нему никаого отношения не имеет. Он срабатывает, когда PHP спотыкается. А минишоп ругается через $modx->log().

И ещё, очень плохая идея держать лог ошибок в открытом доступе. Программистам по рукам давать надо.

А ещё интересно, какая связь между квадратными скобками для фронта и списком товаров в админке?

@Иван Бочкарев Давно уже напрашивается добавить в название сайта «Revolution». Или на логотип.

И придётся придумывать всё то, что уже есть в сессии. Вообще, в чём проблема-то? В сессии эти данные занимают байты. Ну пусть для всех пользователей это будет килобайты. Ну если уж у тебя большой сайт, то десятки МБ. И то при условии, что все ломятся на страницу с формой. А у большинства это какая-нибудь страница с обратной связью.

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

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

В сессиях обычно хранится уникальная информация пользователя.

Вот у меня только один вопрос — у Вас большой опыт программирования? Вы можете гарантировать, что в форме не будет уникальной информации, как написал Василий? Ой, это второй вопрос.

Т.е. если для 98% пользователей решение отлично подходит, но для 2-х% нет, то его нужно выбросить в пропасть. Ибо это оскорбляет эти 2%. Это не они должны адаптировать решение, а остальные 98%.

Можно было просто создавать записи в БД для группы пользователей, использование сессии здесь не нужно.

А ещё можно в догонку спросить? Сколько дополнений Вы создали?

П.С. Я спрашиваю абсолютно по-дружески. )

BaseSessionHandler?

Подойдёт. Таким образом есть понимание, где интерфейс, а где реализация (при DI). Но как правило, одновременно интерфейсы и абстрактные классы используют редко. Для проекта достаточно абстрактного класса, для библиотеки — интерфейса. В общих случаях. Ну и пространства имён никто не отменял (для одинаковых названий).

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

А вот спроси этого человека как сделать без сессий проще, лучше и чтоб работало из коробки у всех, ответит что-нибудь в духе «не моё дело, я с MODX не работаю». Главное сказать, что сессии — зло. Почему и чем так они страшны? Думаю, объективного ответа не дождёмся.

Сессии — это просто инструмент. Всё зависит от того, как им пользоваться. Вот из коробки в сессии пишутся группы ресурсов и группы пользователей. В итоге возникает проблема консистентности данных после изменения этих настроек. Это плохое использование сессий. А в ajaxForm использование сессий вполне обосновано.
И это глобально никак не влияет на разрастание таблицы сессий.

По большей части проблема или в неправильной настройке сборщика мусора (не зависит от MODX) или в ботах (о чём писал Алексей в своей статье), ибо каждый запрос бота вызывает создание новой записи в таблице. С гостями особой проблемы нет — запись создаётся только один раз и будет использоваться в течение 7 дней, потом будет удалена и создана другая (разговор про один браузер и стандартные настройки). Пример как игнорировать ботов и не создавать для них сессии есть у меня на сайте.

Правильный — да, реальный — нет. В двойку это не добавят, а тройка никогда не выйдет. Поэтому нужно рулить в рамках пакета.

П.С. К слову, я не сторонник С-ишных названий с префиксом I. Да и суффикс Interface, наверно, всё-таки лишний. По-современному должно быть так — интерфейс SessionHandler, а реализации — modSessionHandler, AntibotSessionHandler и т.п.

MODX не умеет очищать сессии, если используется иной, отличный от modSessionHandler класс.

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

А какое количество ресурсов возвращает первый сниппет? Максимально. Просто интересно оценить размер, так сказать, ущерба.

Выступлю в роли Николая Ланца… Идея отличная!!! Но к реализации очень много вопросов.

— для сессий создана новая таблица modx_smart_sessions, которая повторяет родную modx_sessions

Зачем? Теперь лишняя таблица в базе болтается. Для таких целей используют миграции. В MODX их нет, но можно расширить схему.

Писать в базу нефильтрованный USER_AGENT — это чтобы пощекотать себе нервы?

Ну и про наследование в ООП советовал бы почитать.

Режим «Николай Ланец» OFF. ))

будем благодарны вам за публикацию решения

Это баг и проявляется он только на сайтах с большим количеством товаров. Решение простое — править.

Скорее всего тег MODX с фильтром stripString перевели в тег Fenom, а фильтр указали как модификатор. Но у Fenom нет такого модификатора из коробки. Вот он и ругается. Используйте вместо stripString модификатор replace.

Хватит простого сниппета-обёртки

[[!ShowComments? &allowGuest=`1` &autoPublish=`0` &autoPublishGuest=`0` &allowGuestEdit=`0`]]

А сам сниппет в 1 строчку

return $modx->resource->parent == 236 ? $modx->runSnippet('TicketComments', $scriptProperties) : '';

Сниппет pdoResources никаким образом не добавляет указанные скрипты и стили от Tickets.

Бегло пробежался по коду. pdoTools подключается только для использования сниппета pdoMenu. Зачем нужно включать феном вопрос.

Theme.Bootstrap и pdoTools. Зачем они нужны в пакете совершенно не ясно. Но очевидно, что данный пакет выдернут из текущего проекта автора без какой-либо подготовки для универсального использования (что как бы подразумевается для пакетов). Даже айдишки жестко зашиты. Т.е. я не рекомендую использовать данный пакет (пусть простит меня автор за моё мнение). Я бы такой пакет не одобрил.