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

Для несложный сайтов конечно лучше CMS. MODX одна из лучших. У него только одна беда — он не развивается. У нас в компании есть проекты на MODX и на Битрикс. По сравнению с последним MODX — это глоток чистого воздуха.

Дело в том, что массив $_POST заполняется только для Content-Type или application/x-www-form-urlencoded или multipart/form-data. А если ты посылаешь json или xml, то wrapper, который для нас разбирает данные формы и услужливо заполняет массив $_POST, уже не знает как распарсить эти данные. Поэтому придётся делать это самостоятельно:

$_POST = json_decode(file_get_contents('php://input'), true);

Ты случаем данные не в json передаёшь?

Я сейчас плотно занят Laravel/Vue. Планы есть. Задачи в бэклоге тоже. Даже начал перевод под MODX3. Но времени катастрофически не хватает. ( И мотивации.

Неа. Я сейчас с MODX практически не работаю. А в ишу на гитхабе особо важного ничего нет.

За кадром осталось как ты создаёшь таблицу. Каким инструментом? Схема нужна только для того, чтобы по ней создать PHP структуру.

Ещё один наглядный пример того, что с этими людьми работать совместно крайне сложно. Главное достижение MODX3 — наличие композера. Но оунеры не были бы оунерами, если бы не разбавили эту фичу добрым половником известной субстанции. Композер есть, но работать с ним можно только через гит. Почему нельзя добавить его в инсталятор, вопрос в пустоту? Потому что! И у них всё так. Поэтому я давно принял решение не учавствовать в этом извращении.

В параметрах сниппета отключи кэш

{'!pdoSitemap' | snippet : [
   ...
  'cache' => false
]}

Саш, ну ты же понимаешь, что делает Ctrl+F5?

Для сравнения, создай html файл (скопируй исходник основной страницы) в корне сайта и сравни заголовки ответа сервера в том и другом случае. Возможно, у тебя установлен какой-нибудь модуль для управления заголовком Last-Modified? Обычно, сервер в этом случае отвечает кодом 304.

от статичный чанк
{include 'scripts.tpl'}
как то кешируется.

Инструкция include никогда не кэширует чанк. Открой кэш страницы и посмотри, что у тебя указано в поле _content.

За это отвечает веб-сервер.

Хех, рассказываешь про Ctrl+F5, а лезешь в настройки MODX.

У тебя проблема с кэшированием браузера, вот и разбирайся с ним — смотри заголовки веб-сервера, которые отвечают за кэширование — всякие там cache-control, expires, pragma…

Прямо на страницу. Семён, насколько я знаю, даже модификатор dump добавляет в шаблонизатор. Т.е. можно и в шаблоне вызывать.

Для обычных хостингов можно использовать функцию dump из библиотеки modHelpers. Она использует тот же пакет var_dumper от Synfony, что и Ray из топика. Через неё также можно выводить любые данные с возможностью сворачивать/разворачивать как на видео выше.

Крутая вещь! Плюсую! Разработка на MODX становится более взрослой и современной. Хотя Джейсон мне как-то ответил, что MODX это CMS и не нужно тянуть в него фишки из фреймворков. Ребята из MODX LLC ещё те спецы по отбиванию желания работать на MODX. К сожалению.

JWT обычно используют для API. Если тебе нужно использовать его на сайте, то пихай его в куки. Можно использовать пакет jwtSession.

Изучаю эту технологию и честно говоря, на мой взгляд, это очень небезопасная система.

Web — это вообще небезопасная сфера.

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

А если у тебя украдут авторизационную куку?

Не говоря уже о том, что большинство разработчиков не ставят время жизни в 10 минут, а ставят 12 часов а то и больше

Честно говоря, сомневаюсь в твоей оценке. Уверен, есть такие разработчики, но их количество резко сокращается с увеличением опыта. Особенно, когда они узнают про refresh token.

кто то даже хранит их (access token) в базе

Наверно это те же «спецы».

Изобретаю механизм межсерверной аутентификации.

Пополняешь список велосипедостроителей? Есть уже готовые стандарты — OAuth2 и OpenID Connect. Первый — это протокол авторизации. Второй — это надстройка над первым для аутентификации. Он позволяет использовать единый логин (SSO) для сервисов. Для всех языков есть библиотеки.
В id токене ты можешь хранить информацию о пользователе (его id, email или телефон). По нему ты можешь получить пользователя из БД, которого в крайнем случае ты можешь заблокировать. Это один из вариантов.
Кроме того, авторизационный сервер хранит access_token для клиента.

В комментарии всё не опишешь. Но в инете много информации по этому вопросу. Странно задавать его здесь.

1. Переопределить настройку для переноса всего кэша

$modx->setOption('cache_path', 'новый путь к папке кэша');

2. Для более тонкой настройки расширить менеджера кэша, в котором изменить метод modCacheManager::generateResource, чтобы переопределять cacheKey ресурса. По-умолчанию он имеет значение «contextKey]/resources/[id]». Можно указать свой типа «web/$siteName/resources/$obj->id». $siteName определяете сами.

В оф. репозитории последняя версия pdoTools 3.0.0-beta от декабря.

Почему pdoTools отмечен крестиком? Указанные замечание датированы мартом 2021 года. Но я полгода назад выпустил адаптированную версию для MODX3. Стукни Марку, чтоб поправил.

Алексей выше правильно написал. Простые теги pdoTools заменяет значениями средствами PHP без парсинга.

Чтобы не беспокоить почитателей Василия, который написал интересную статью, только совсем про другое, напишу на своём сайте, в чём Fenom проигрывает стандартному парсеру. Тогда сразу будет понятно, почему я говорю, что тест Василия синтетический.