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

Значит настраивать параметры Jevix нужно в наборе параметров Ticket. Остальные параметры будут игнорироваться.

Для комментариев используется набор параметров Comment.

joxi.ru/nAybzZ6fgRJEor

Эта настройка никак не влияет на теги. Верните обратно, чтобы проверить.

Так вы работаете с тикетами? Или только с Jevix?

На картинке же видно — сниппет Jevix.

Если работаете с тикетами, то нужно работать с набором параметров «Ticket».

joxi.ru/823zOJ8u9pvBvm

Ну если ничего не делать, то так и случится. Упорство Дмитрия должно послужить положительным примером.

Я бы на это сильно не рассчитывал. Узкое место MODX совсем не в загрузке классов.

Небезопасная вещь.

Ненавижу такие комментарии.

А под своими процессорами ты имеешь ввиду свои, но наследники modProcessor, или вообще свой механизм?
Просто ты ответил немного неопределённо —

Только 3й вариант, только свои процессоры.

То ли за третий, то ли за второй.

П.С. Надо было сделать четыре комментария с каждым вариантом и за них голосовать. Эмулировать опрос. Стормозил чутка.

* не вижу причины

Я тоже склоняюсь за третий вариант.

Боюсь большой объем работы просто застопорит все.

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

Думаю, это не очень правильный подход. Или одно или другое.

Потому что ты запрашиваешь объекты. И тебе выводятся поля из объекта.

Для понимания. Если ты создашь новый пустой объект и выведешь его

$resource = new modResource(...);
$resource->toArray();

то тоже получишь все поля, но пустые.

В твоём случае, ты инициализируешь указанные в select поля объектов данными из базы. Остальные поля — так называемые lazy. Они инициализируются из кэша. Если кэша нет, то делается запрос в базу и сохраняется в кэш.
Если нужно получить массив данных (что предпочтительней), то лучше делать так

$resources = [];
if ($c->prepare() && $c->stmt->execute()) {
    $resources = $c->stmt->fetchAll(PDO::FETCH_ASSOC);
}
foreach($resources as $resource){
    echo "<pre>".print_r($resource, true)."</pre>";
}

В этом случае получишь то, что запрашивал. И памяти меньше кушает.

А Slim рекомендует так

location ~ ^/api/ {
        try_files $uri /api/index.php$is_args$args;
    }

Какое решение лучше?

Про права я писал тут. Насчёт вызова событий нужно подумать. Это зависит от реализации.

Выскажу здесь своё никому не нужное мнение.

Интересная статья для размышления. Не хватает четвертого варианта, который описал Василий выше и который использую я при разработке RESTful API дополнения.
Первые два варианта из разряда «забить гвоздь телефоном». Результат маленький и большие накладные расходы.
Третий вариант — это взять маленький молоточек. Чтобы забить средние и большие гвозди придётся сильно попотеть.

Цикл статей, имхо, нужен только для понимания, что встроенные средства MODX мало пригодны. Только для исключительно простых целей. Как по мне, даже JSON:API спецификация с его include, fields, filter и sort неудобна. Мне как разработчику было бы проще послать POST запрос, в котором описать как положено select, where, limit и т.п. Да, это уже не REST, но возможностей гораздо больше.

Во-первых, это не готовое API, а инструкция по его созданию.
Во-вторых, про это уже говорили. Данное решение изучалось. Оно оказалось крайне ограниченное. Ничего кроме items/15 вы не получите.Т.е. статью с комментариями одним запросом никак не получить. И поля никак не указать. Так что на этом серьезное API не сделаешь.
В-третьих, сам Джейсон недавно в обсуждениях на Github писал, что делает API через Slim. Т.е. даже сам сапожник не носит свои сапоги.
В-четвертых, задача попробовать минимизировать зависимость от core-разработчиков.
И в-пятых, третья версия MODX планировалась на Slim 3. Возможно наше решение даст толчок для реализации этих планов.

Так что всё пока логично. А вас, товарищ, мы из групповухи вычеркиваем.)

которое, в принципе уже и так есть

API в студию!