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

@Иван Бочкарев Давно уже напрашивается добавить в название сайта «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. Зачем они нужны в пакете совершенно не ясно. Но очевидно, что данный пакет выдернут из текущего проекта автора без какой-либо подготовки для универсального использования (что как бы подразумевается для пакетов). Даже айдишки жестко зашиты. Т.е. я не рекомендую использовать данный пакет (пусть простит меня автор за моё мнение). Я бы такой пакет не одобрил.

Вообще, хорошим тоном считается тянут как можно меньше зависимостей. А тут аж целый две лишних.

Вот простейший сниппет, который вызывается на странице modx.local/download?file=dl.txt

if ($modx->user->isAuthenticated('web')) {
    $file = basename($_GET['file']);
    if (!empty($file) && file_exists(MODX_BASE_PATH . "assets/files/{$file}")) {
        header("Location: http://modx.local/assets/files/{$file}");
        exit();
    } else {
        header($_SERVER['SERVER_PROTOCOL'] . ' 404 Not Found');
    }
} else {
    return 'Иди отседова.';
}

Скачивается только залогиненным пользователем. Гостю отворот-поворот.

А как можно увидеть прямую ссылку? Ты её формируешь на странице download. Пользователь её не видит. А когда файл отдаётся на скачивание, то ссылка тоже не светится.

Вот для примера файл лежит в modx.local/assets/files/.


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

Ясно. Тогда я бы сделал так — для проверенных пользователей выводил бы список файлов. Кликнул «скачать» — идёт переадресация на страницу site.ru/download?file=filename. На ней проверяются права, счётчик и идёт переадресация на статический файл. Nginx нужно настроить на скачивание файлов вместо отдачи. Таким образом, PHP не используется.
Проверил у себя на Apache, работает.

Вроде норм. Подсмотреть логику скачиваний можно в FileAttach.