Да, планирую. Если парсер для страниц можно указать любой (в системной настройке) и отказаться от pdoParser'а, то чанки парсятся жестко только феномом на глядя на то, какой парсер указан в настройке. В принципе можно отключить феном для чанков (отдельной настройкой), то там другая засада — текущий парсер включится только если есть скобки [[. Т.е. ни смарти ни твиговские теги не распарсятся. Как-то так, если я ничего не путаю.
В общем, задача — чтобы pdoTools всегда использовал указанный в системной настройке парсер, который может быть pdoParser, SmartyParser (есть в ZoomX) или TwigParser (если такой будет).
Может я чего-то не понимаю, но получается совсем не короче. Этот путь из названия перемещается в параметр. Т.е. ещё нужно писать отдельный параметр. Что явно выглядит длиннее.
Ну теперь понятно. Только moderrorhandler — это замена PHP-шного обработчика ошибок и минишоп к нему никаого отношения не имеет. Он срабатывает, когда PHP спотыкается. А минишоп ругается через $modx->log().
И ещё, очень плохая идея держать лог ошибок в открытом доступе. Программистам по рукам давать надо.
И придётся придумывать всё то, что уже есть в сессии. Вообще, в чём проблема-то? В сессии эти данные занимают байты. Ну пусть для всех пользователей это будет килобайты. Ну если уж у тебя большой сайт, то десятки МБ. И то при условии, что все ломятся на страницу с формой. А у большинства это какая-нибудь страница с обратной связью.
Проблемы надо решать по мере их поступления. Вот Алексей споткнулся об гигабайтную таблицу и предложил решение. Но опять же, оно нужно не всем, а только тем, у кого аналогичная проблема. Остальным можно не париться.
Ну а отдельная таблица — это явный оверхед. Тогда уж лучше передавать в форму зашифрованные данные из параметров сниппета в скрытый инпут. В этом случае оверхеда будет гораздо меньше.
В сессиях обычно хранится уникальная информация пользователя.
Вот у меня только один вопрос — у Вас большой опыт программирования? Вы можете гарантировать, что в форме не будет уникальной информации, как написал Василий? Ой, это второй вопрос.
Т.е. если для 98% пользователей решение отлично подходит, но для 2-х% нет, то его нужно выбросить в пропасть. Ибо это оскорбляет эти 2%. Это не они должны адаптировать решение, а остальные 98%.
Можно было просто создавать записи в БД для группы пользователей, использование сессии здесь не нужно.
А ещё можно в догонку спросить? Сколько дополнений Вы создали?
Подойдёт. Таким образом есть понимание, где интерфейс, а где реализация (при DI). Но как правило, одновременно интерфейсы и абстрактные классы используют редко. Для проекта достаточно абстрактного класса, для библиотеки — интерфейса. В общих случаях. Ну и пространства имён никто не отменял (для одинаковых названий).
увидел ветку комментариев про хранение данных в сессии. Казалось бы, совершенно заслуженный камень в мой огород, как автора дополнения.
А вот спроси этого человека как сделать без сессий проще, лучше и чтоб работало из коробки у всех, ответит что-нибудь в духе «не моё дело, я с MODX не работаю». Главное сказать, что сессии — зло. Почему и чем так они страшны? Думаю, объективного ответа не дождёмся.
Сессии — это просто инструмент. Всё зависит от того, как им пользоваться. Вот из коробки в сессии пишутся группы ресурсов и группы пользователей. В итоге возникает проблема консистентности данных после изменения этих настроек. Это плохое использование сессий. А в ajaxForm использование сессий вполне обосновано.
И это глобально никак не влияет на разрастание таблицы сессий.
По большей части проблема или в неправильной настройке сборщика мусора (не зависит от MODX) или в ботах (о чём писал Алексей в своей статье), ибо каждый запрос бота вызывает создание новой записи в таблице. С гостями особой проблемы нет — запись создаётся только один раз и будет использоваться в течение 7 дней, потом будет удалена и создана другая (разговор про один браузер и стандартные настройки). Пример как игнорировать ботов и не создавать для них сессии есть у меня на сайте.
Правильный — да, реальный — нет. В двойку это не добавят, а тройка никогда не выйдет. Поэтому нужно рулить в рамках пакета.
П.С. К слову, я не сторонник С-ишных названий с префиксом I. Да и суффикс Interface, наверно, всё-таки лишний. По-современному должно быть так — интерфейс SessionHandler, а реализации — modSessionHandler, AntibotSessionHandler и т.п.
MODX не умеет очищать сессии, если используется иной, отличный от modSessionHandler класс.
Вот это шляпа. По хорошему нужно править это.
Самый простой выход — через js в админке менять хандлер у этого пункта меню, в котором указать свой процессор (поправленную копию системного процессора).
Скорее всего тег MODX с фильтром stripString перевели в тег Fenom, а фильтр указали как модификатор. Но у Fenom нет такого модификатора из коробки. Вот он и ругается. Используйте вместо stripString модификатор replace.
Theme.Bootstrap и pdoTools. Зачем они нужны в пакете совершенно не ясно. Но очевидно, что данный пакет выдернут из текущего проекта автора без какой-либо подготовки для универсального использования (что как бы подразумевается для пакетов). Даже айдишки жестко зашиты. Т.е. я не рекомендую использовать данный пакет (пусть простит меня автор за моё мнение). Я бы такой пакет не одобрил.
В общем, задача — чтобы pdoTools всегда использовал указанный в системной настройке парсер, который может быть pdoParser, SmartyParser (есть в ZoomX) или TwigParser (если такой будет).
И ещё, очень плохая идея держать лог ошибок в открытом доступе. Программистам по рукам давать надо.
Проблемы надо решать по мере их поступления. Вот Алексей споткнулся об гигабайтную таблицу и предложил решение. Но опять же, оно нужно не всем, а только тем, у кого аналогичная проблема. Остальным можно не париться.
Ну а отдельная таблица — это явный оверхед. Тогда уж лучше передавать в форму зашифрованные данные из параметров сниппета в скрытый инпут. В этом случае оверхеда будет гораздо меньше.
Т.е. если для 98% пользователей решение отлично подходит, но для 2-х% нет, то его нужно выбросить в пропасть. Ибо это оскорбляет эти 2%. Это не они должны адаптировать решение, а остальные 98%.
А ещё можно в догонку спросить? Сколько дополнений Вы создали?
П.С. Я спрашиваю абсолютно по-дружески. )
Сессии — это просто инструмент. Всё зависит от того, как им пользоваться. Вот из коробки в сессии пишутся группы ресурсов и группы пользователей. В итоге возникает проблема консистентности данных после изменения этих настроек. Это плохое использование сессий. А в ajaxForm использование сессий вполне обосновано.
И это глобально никак не влияет на разрастание таблицы сессий.
По большей части проблема или в неправильной настройке сборщика мусора (не зависит от MODX) или в ботах (о чём писал Алексей в своей статье), ибо каждый запрос бота вызывает создание новой записи в таблице. С гостями особой проблемы нет — запись создаётся только один раз и будет использоваться в течение 7 дней, потом будет удалена и создана другая (разговор про один браузер и стандартные настройки). Пример как игнорировать ботов и не создавать для них сессии есть у меня на сайте.
П.С. К слову, я не сторонник С-ишных названий с префиксом I. Да и суффикс Interface, наверно, всё-таки лишний. По-современному должно быть так — интерфейс SessionHandler, а реализации — modSessionHandler, AntibotSessionHandler и т.п.
Самый простой выход — через js в админке менять хандлер у этого пункта меню, в котором указать свой процессор (поправленную копию системного процессора).
Зачем? Теперь лишняя таблица в базе болтается. Для таких целей используют миграции. В MODX их нет, но можно расширить схему.
Писать в базу нефильтрованный USER_AGENT — это чтобы пощекотать себе нервы?
Ну и про наследование в ООП советовал бы почитать.
Режим «Николай Ланец» OFF. ))
А сам сниппет в 1 строчку