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

Заглянул в код (кстати, ты бы мог сделать это сам). По поводу сохранения в БД измененного тикета беру свои слова обратно. В БД хранится исходный текст. Поэтому пересохранять ничего не нужно.

Теперь объясняю, почему тебе кажется, что не работает вывод через сниппет. На самом деле он работает. Просто работает 2 раза. Первый раз сниппет Jevix вызывается в классе Ticket, когда идет получение ресурса по алиасу. В этот момент отрабатывают опции Ticket сниппета Jevix. Тут и добавляется тег br. Второй раз он вызывается в шаблоне. Отсюда напрашиваются 2 вывода:
1. Достаточно отключить опцию cfgSetAutoBrMode в параметрах Ticket.
2. Выводить контент тикета через сниппет Jevix нет никакой необходимости.

Только это сделано на обычном ресурсе.

Ты где-то писал про тикеты? Прямо как маленький.

Тебе ниже уже написали про тикеты. Их надо заново пересохранить с отключенным Jevix. В противном случае изменённый джевисом тикет сохранится в БД уже с тегом br. Поэтому ты и не можешь его изменить через сниппет. Чтобы это стало возможным, нужно в БД сохранять исходный текст тикета.

s21923.h10.modhost.pro/manager
s21923
8GVLBfZco8xy

Только я вызываю сниппет с дефолтными параметрами.

Илья, я не понимаю, как у тебя это получается.
Вот не поленился и проверил (Спасибо огромное modhost.pro за механизм тестовых сайтов!). Всё работает!!!

Ну так измени это значение в дефольных параметрах сниппета. Я так подозреваю, что значение `0` является строкой, и если в сниппете оно не приводится к логическому типу, то получается всегда true. Хотя могу и ошибаться. Комп остался в Москве, а я сижу на даче, семью спасаю ))

Решения вижу 2.
1. Вызывай через феном синтаксис с указанием параметра

...
'cfgSetAutoBrMode' => false,
...

2. Скопируй сниппет Jevix и в нем приводи к булеву типу этот параметр.

&cfgSetAutoBrMode=1

Я уже давно не пишу через синтаксис MODX, поэтому могу ошибаться, но разве без обратных кавычек можно указывать параметры?

Если тебе не нужно переключать этот параметр в разных местах вызова, то измени его в дефолтных параметрах сниппета.

А что, сейчас параметры сниппета не работают?

Можно и так

$parent = $resource->Parent;

Боюсь тебя разочаровать — я не занимаюсь разработкой сайтов.
Я не совсем понимаю, что ты понимаешь под сервером разработки. Для разработки в IDE по-любому закачиваешь проект на локалку. Тут же можешь поднять встроенный в PHP вэб-сервер. Лично я использую XAMPP. Там уже всё есть. В идеале, конечно, докер нужно осваивать. Но мне пока это не нужно.
В твоём случае, насколько я понимаю, тебе нужен механизм деплоя, а не контроля версий.

Прикольно. Один разраб сделал чек-аут на дев-сервере и у другого синхронизация на локалке все сломала.

А теперь просто попробуй представить, как будет работать совместная работа на одном сервере разработки. Все одновременно будут править одно ядро? И как в этом случае разработчик должен тестировать своё творчество? Это его баг или другой разраб сейчас чего-то пилит?

Данное решение проигрывает связке PHP+Javascript. Уверен, Вы в курсе, что тайм лимит есть ещё у веб-сервера. И что при разрыве связи с клиентом (даже при включенном ignore_user_abort(true)) переадресация не сработает, как и любой вывод в браузер.

htmlspecialchars($_GET['offset'])

Тут можно только пожать плечами.

А что тут можно посоветовать? Наверно, учить PHP.

Самое простое решение через сниппет

$arr = explode(',', $list);
$arr = array_map(function($val){return trim($val);}, $arr);
shuffle($arr);
$output = array_intersect_key($arr, array_flip(array_rand($arr, (int) $number)));

return implode(',', $output);

И вызывать сниппет так

[[!RandomValues? list=`один, мотор, кровать, солнце, 11, 55, привет, ёу` &number=`2`]]

Да что за бзик с этими зависимостями. Почти все популярные композер пакеты и npm имеют те или иные зависимости. Это норма. Да, есть головняк с обновлениями. Не хочешь, пиши сам. Выбор простой.

Просто нет слов. Достойно рубрики «Курьёзы и юмор». А заказчика жалко.

Вообще не понимаю этой суеты с jQuery. Это просто синтаксический сахар над js.Вполне себе удобный. Почему-то с бутстрапами, Guzzle и ещё кучей библиотек такого кипиша не происходит. А тут прям холиварище.

Конечно, можно всё писать с нуля самому. Но в конечном счёте, всё равно хороший разработчик сделает для себя аналогичную библиотеку для удобства и простоты разработки. Каждый решает сам что лучше для него и легче — если проще писать с нуля и надоело в техподдержке решать вопросы совместимости, пиши с нуля. Удобно работать с jQuery, работай.

Для меня этот вопрос вообще не принципиальный. Мне нравится плагин dataTables. Круче него ещё не видел. И тут без jQuery не обойтись. Уверен, каждый найдёт много примеров нужных плагинов.
Но, другой вопрос, если для несложных манипуляций, легко решающихся нативным js тащить jQuery, то это конечно перебор.

П.С. А что такое МД?

Записал видео, в котором постарался всё объяснить.

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

Я ровно так и думал. ;) MODX отстаёт от сегодняшнего уровня разработки во всём. В том числе и в поддержке REST архитектуры. Так как я на некоторое время погружался в эту тему, то с определённой долей уверенности могу это утверждать. Я даже нацарапал статейку про «недоRESTfull API» в MODX.

Общепринятым форматом для описания REST API на сегодняшний день является OpenAPI, который также известен как Swagger.

Согласно ему твой запрос должен выглядеть так

GET https://shopname.com/rest/catalogs/13/products

А аргументы используются для дополнительных действий типа "?search=телевизоры". Хотя тут больше свободы. В итоге у тебя есть готовый эндпойнт, для которого автоматом пишется документация.

Конечно, никто не заставляет под дулом пистолета следовать OpenAPI. То же самое можно сказать и про стандарты PSR. Но считается дурным тоном им не следовать. Поэтому я считаю, что делать что-то новое нужно с учетом текущих требований.

Представь, как было бы удобно, если бы у всех платформ API следовали бы единому стандарту, а не так как сейчас

https://api.vk.com/method/users.get?user_id=210700286&v=5.52
https://api.ok.ru/api/friends/get
https://graph.facebook.com/{page-id}/conversations?fields=id,messages{message,from}

Это как единый стандарт разъема для телефонов.