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

Автор в постскриптуме указал почему. Плюс не очень удобно. Нужную настройку нужно обязательно удалить, иначе данный способ переопределения настройки не сработает. Т.е. придется лезть в админку.

В моем варианте можно переопределять любые системные настройки. Они сразу будут применены. Кроме того, новые файлы подключаются автоматом.

П.С. Файл конфига редактировать никто не запрещает. Он индивидуальный и его при обновлении никогда не трогают.

Посмотрел в код. Конкретно эту настройку через системные настройки не изменить. Нужно или прописывать в $config_options

$config_options = array (
   'cache_path' => 'path/to/cache/folder/',
);

или в своих коннекторах, где создается объект $modx указать параметры инициализации

<?php
// Boot up MODX
require_once dirname(dirname(__FILE__)) . '/config.core.php';
require_once MODX_CORE_PATH . 'model/modx/modx.class.php';
$modx = new modX('', ['cache_path' => 'path/to/cache/folder/',]);

Почему?

При всём уважении, делать так не нужно. Просто создайте php файлик со своими системными настройками и загружайте его на событие OnMODXInit /OnHandleRequest. И тогда не нужны все эти манипуляции и проблемы с обновлением MODX. Как это сделать я говорил ещё в 2016 году.

Достаточно большой и красиво оформленный пост. Что плохого в том, что человек наглядно демонстрирует возможности системы? Похоже на документацию, не похоже на документацию… Какая разница. Если твой пост про создание промокода больше 3-х предложений, то пиши, не стесняйся.

Этот сайт является частью самой большой MODX экосистемы в RU сегменте — modx.pro, modstore.pro и modhost.pro (хотя владельцы разные). Скорее даже самой большой в мире. Почему бы один ресурс не использовать для продвижения другого? А для удобства пользователей есть разделы. Хочешь, читай про дополнения, хочешь — про готовые решения. По моему, пост не нарушает никаких правил, ни описанных ни моральных. В отличие от поста с победными скидками. Вот там да, хочется сказать товарищу, что ошибся дверью.

Это мое мнение, которое может меняться в зависимости от настроения ))

Кстати, на чанки эта логика тоже не распространяется. Только наоборот. Они никогда не кэшируются не зависимо от того, указан! или нет.

Ну значит эта логика на файловые элементы не распространяется. Юзай modHelpers. Там этих проблем нет. Больше не знаю, что посоветовать.

Полностью согласен с ребятами. Это не твоя головная боль. Ты работу сделал — тебе должны заплатить. Что там с ней будет дальше тебя не должно волновать. Я понимаю, что легче сказать, чем сделать. Но нужно вырабатывать определенный уровень здорового цинизма. Нельзя за всё переживать. Особенно за то, что тебя не касается.
А если денег за работу не платят, то нужно работу менять. Но тут свои проблемы от объективных до субъективных.

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

Будешь смеяться, но так

{'@FILE !snippets/getFilters.php'|snippet}

Ну или используй функцию snippet из modHelpers.

[[!+modx.user.id:userinfo=`fax`:is=`123`:then=`да`:else=`нет`]]

Но я бы для таких целей посоветовал использовать Fenom.

{if ($_modx->user.fax == '123'}
да
{else}
нет
{endif}

Еще один вариант (по алгоритму Алексея)
1. Создаем сниппет, в котором формируем уникальный хеш файла.
2. Записываем в массив

['хэш строка' => 'путь/к/файлу']

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

{if $files?}
{set $files = array_chunk($files, 4)}
<div class="slider">
{foreach $files as $fileGroup}
    <div class="slide">
    {foreach $fileGroup as $file}
        {$file}
    {/foreach}
    </div>
{/foreach}
</div>
{/if}

Возможно придется включить php на страницt в настройках pdoTools.

Фильтры ввода/вывода для пользователя.

Я такого не говорил,

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

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

и

Я не слежу за количеством CMS

Это 2 соседних комментария. Наверно и тут можно выкрутиться, что там имел ввиду не это, а тут не то.

Ну началось, мерить скорость фреймворков — себя не уважать

Вон оно чё, Михалыч. Т.е. когда выбирают фреймворк под высокопосещаемый сайт, кидают кости или смотрят у кого строк в коде больше. Ух уж эти подлые манипуляторы. ))

у того же Laravel есть люмен

Я понимаю о чём ты говоришь. Но с формальной точки зрения Lumen — это не Laravel. Это микрофреймворк от того же автора. А я говорил именно о популярном Laravel.

Ладно, забей, далеко уже ушли от темы.

Или ты предлагаешь рассказывать людям работающим на modx как построить контейнеры способные держать 400 хостов в секунду в течении месяцев без перебоев?

Ну началось. То золотой век CMS прошел, то MODX плохой, потому что не может держать 400 запросов в секунду. Ну вечером в пятницу под пару кружек пенноого чая ещё сойдёт, но вроде серъёзные разработчики собрались, а разговоры как у прыщавых подростков.
Количество CMS множится, ибо инструментов стало столько, что народ начал придумывать что-то своё в различных комбинациях. Зайди на хабр, удивишься. Конкуренция растёт, поэтому популярность таких мамонтов как WP, Joomla, Drupal и остальных снижается. Вот и весь секрет.

А пенять на MODX, что он не может работать в высоконагруженной системе, это уж какой-то лужапук. Ну не предназначен он для этого. Высоконагруженные системы — это отдельный мир. Ты удивишься, но тот же Laravel имеет невысокие показатели среди других фреймворков по RPS (request per second). Зачем развотить холиварные темы?

А статья интересная, плюсанул. Пытаюсь побороть себя поставить на локалку с Windows основной вэб стек (Linux, MySQL, NGINX, PHP) в контейнере. Но времени нет.

Опытный разработчик найдёт много вариантов. Вот первые три
1. Использовать фильтр для тега link с заменой «glavnaja» на /. Только предварительно почитав документацию по инлайн чанкам.
2. Использовать отдельный шаблон для первой страницы

[[pdoResources?
    &useWebLink=`1`
    &resources=`-1`
    &tplFirst=`@INLINE <a href="/">1</a>`
    &tpl=`@INLINE <a href="[[+link]]">[[+id]]</a>`
]]

3. Почти тоже самое

<a href="/">1</a>
[[pdoResources?
    &useWebLink=`1`
    &resources=`-1`
    &tpl=`@INLINE <a href="[[+link]]">[[+id]]</a>`
]]

Расширить класс pdoFetch, исправить как нужно (заменить | на какой-нибудь неиспользуемый символ, например, #), указать в системной настройке новый класс.

Вполне возможен ещё один вариант. В админке у тикетов отключить Jevix, а в нужных шаблонах добавить вывод контента через сниппет Jevix. В этом случае тег [[~88]] должен распарситься до обработки Jevix и всё отработает как положено. Чисто в теории.
В этом случае, кстати, ты можешь динамически управлять поведением Jevix через параметры сниппета, в отличие от наборов параметров.

Небольшое уточнение. Согласно документации коду достаточно написать так

"a":{"title":"#text","href":"#text"}

Ибо по-умолчанию атрибуту href присваивается тип #link. А при указании в атрибуте тега MODX, он фильтрацию не проходит и тег a вырезается. Поэтому нужно указать другой тип. А чтобы foreach не сломался, нужно указать типы для всех атрибутов. Иначе выпадает ошибка, о которой ты писал выше.

Самое интересное, что ты можешь указать практически любое значение

"a":{"title":"#text","href":"#modx"}
"a":{"title":"#text","href":"#fuck"}

В этом случае Jevix не найдёт соответствующего фильтра и оставит значение без обработки. В случае же с типом #text, значение прогонится через функцию htmlspecialchars().

П.С. Вообще, у Jevix самый большой минус — это отсутствие документации. Не программисту разобраться тяжело.

Делаешь свой парсер по аналогии с pdoParser.