Дело в том, что массив $_POST заполняется только для Content-Type или application/x-www-form-urlencoded или multipart/form-data. А если ты посылаешь json или xml, то wrapper, который для нас разбирает данные формы и услужливо заполняет массив $_POST, уже не знает как распарсить эти данные. Поэтому придётся делать это самостоятельно:
Я сейчас плотно занят Laravel/Vue. Планы есть. Задачи в бэклоге тоже. Даже начал перевод под MODX3. Но времени катастрофически не хватает. ( И мотивации.
Ещё один наглядный пример того, что с этими людьми работать совместно крайне сложно. Главное достижение MODX3 — наличие композера. Но оунеры не были бы оунерами, если бы не разбавили эту фичу добрым половником известной субстанции. Композер есть, но работать с ним можно только через гит. Почему нельзя добавить его в инсталятор, вопрос в пустоту? Потому что! И у них всё так. Поэтому я давно принял решение не учавствовать в этом извращении.
Для сравнения, создай html файл (скопируй исходник основной страницы) в корне сайта и сравни заголовки ответа сервера в том и другом случае. Возможно, у тебя установлен какой-нибудь модуль для управления заголовком Last-Modified? Обычно, сервер в этом случае отвечает кодом 304.
от статичный чанк
{include 'scripts.tpl'}
как то кешируется.
Инструкция include никогда не кэширует чанк. Открой кэш страницы и посмотри, что у тебя указано в поле _content.
Хех, рассказываешь про Ctrl+F5, а лезешь в настройки MODX.
У тебя проблема с кэшированием браузера, вот и разбирайся с ним — смотри заголовки веб-сервера, которые отвечают за кэширование — всякие там cache-control, expires, pragma…
Для обычных хостингов можно использовать функцию dump из библиотеки modHelpers. Она использует тот же пакет var_dumper от Synfony, что и Ray из топика. Через неё также можно выводить любые данные с возможностью сворачивать/разворачивать как на видео выше.
Крутая вещь! Плюсую! Разработка на MODX становится более взрослой и современной. Хотя Джейсон мне как-то ответил, что MODX это CMS и не нужно тянуть в него фишки из фреймворков. Ребята из MODX LLC ещё те спецы по отбиванию желания работать на MODX. К сожалению.
Изучаю эту технологию и честно говоря, на мой взгляд, это очень небезопасная система.
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 отмечен крестиком? Указанные замечание датированы мартом 2021 года. Но я полгода назад выпустил адаптированную версию для MODX3. Стукни Марку, чтоб поправил.
Алексей выше правильно написал. Простые теги pdoTools заменяет значениями средствами PHP без парсинга.
Чтобы не беспокоить почитателей Василия, который написал интересную статью, только совсем про другое, напишу на своём сайте, в чём Fenom проигрывает стандартному парсеру. Тогда сразу будет понятно, почему я говорю, что тест Василия синтетический.
Сергей, я считаю вполне обоснованным «недопонимание» со стороны Василия, мне бы тоже не понравился упрёк в мою сторон
Наверно ты прав. Думаю, будет правильнее удалить это. Статья чисто техническая. И не хотелось бы придавать ей какую-то эмоциональную окраску. И у меня нет никакого упрёка или претензий ни к Василию как к разработчику, ни к pdoTools. Многие из нас участвовали в совершенствовании этой библиотеки. Поэтому знаем все её преимущества. А Василий потратил огромное количество своего времени на её развитие. Только неблагодарный может предъявлять какие-то претензии. Я точно к таким не отношусь.
А недопонимание объясняется легко. К сожалению, у нас с Василием давно уже нет взаимопонимания. И уважительного отношения на личностном уровне. Но я от этого не страдаю. Уверен, и он тоже. И в дальнейшем я не планирую повышать нулевой уровень нашего общения.
И в конце статьи тогда стоило бы уточнить про предустановку pdoTools
А бывают сайты без pdoTools? Лендинги наверно? Но про них говорить смысла нет. Просто я в статье закрепил то, о чем много раз говорил и в чатах и комментариях в ответ на вопросы типа насколько быстрее будет работать сайт, если в карточке товара заменить синтаксис MODX на Fenom. В одном из своих последних комментариев тут я как раз и писал, что главная причина ускорения сайта — это pdoTools.
Многие разработчики сами замечают, что после замены ничего не изменилось по скорости. Как и на не заметил прироста на своём сайте. В этой статье я объяснил почему. Да и сам Василий в своём сегодняшнем посте тоже. Цифры для pdoParser до 100 чанков. Большинство сайтов (может даже 90%) использует пагинацию и даже 100 чанков парсить в цикле не будет. Не у всех на каждой странице сайта 890 комментариев.
Для сравнения, создай html файл (скопируй исходник основной страницы) в корне сайта и сравни заголовки ответа сервера в том и другом случае. Возможно, у тебя установлен какой-нибудь модуль для управления заголовком Last-Modified? Обычно, сервер в этом случае отвечает кодом 304.
Инструкция include никогда не кэширует чанк. Открой кэш страницы и посмотри, что у тебя указано в поле _content.
У тебя проблема с кэшированием браузера, вот и разбирайся с ним — смотри заголовки веб-сервера, которые отвечают за кэширование — всякие там cache-control, expires, pragma…
А если у тебя украдут авторизационную куку?
Честно говоря, сомневаюсь в твоей оценке. Уверен, есть такие разработчики, но их количество резко сокращается с увеличением опыта. Особенно, когда они узнают про refresh token.
Наверно это те же «спецы».
Пополняешь список велосипедостроителей? Есть уже готовые стандарты — OAuth2 и OpenID Connect. Первый — это протокол авторизации. Второй — это надстройка над первым для аутентификации. Он позволяет использовать единый логин (SSO) для сервисов. Для всех языков есть библиотеки.
В id токене ты можешь хранить информацию о пользователе (его id, email или телефон). По нему ты можешь получить пользователя из БД, которого в крайнем случае ты можешь заблокировать. Это один из вариантов.
Кроме того, авторизационный сервер хранит access_token для клиента.
В комментарии всё не опишешь. Но в инете много информации по этому вопросу. Странно задавать его здесь.
2. Для более тонкой настройки расширить менеджера кэша, в котором изменить метод modCacheManager::generateResource, чтобы переопределять cacheKey ресурса. По-умолчанию он имеет значение «contextKey]/resources/[id]». Можно указать свой типа «web/$siteName/resources/$obj->id». $siteName определяете сами.
Чтобы не беспокоить почитателей Василия, который написал интересную статью, только совсем про другое, напишу на своём сайте, в чём Fenom проигрывает стандартному парсеру. Тогда сразу будет понятно, почему я говорю, что тест Василия синтетический.
А недопонимание объясняется легко. К сожалению, у нас с Василием давно уже нет взаимопонимания. И уважительного отношения на личностном уровне. Но я от этого не страдаю. Уверен, и он тоже. И в дальнейшем я не планирую повышать нулевой уровень нашего общения.
А бывают сайты без pdoTools? Лендинги наверно? Но про них говорить смысла нет. Просто я в статье закрепил то, о чем много раз говорил и в чатах и комментариях в ответ на вопросы типа насколько быстрее будет работать сайт, если в карточке товара заменить синтаксис MODX на Fenom. В одном из своих последних комментариев тут я как раз и писал, что главная причина ускорения сайта — это pdoTools.
Многие разработчики сами замечают, что после замены ничего не изменилось по скорости. Как и на не заметил прироста на своём сайте. В этой статье я объяснил почему. Да и сам Василий в своём сегодняшнем посте тоже. Цифры для pdoParser до 100 чанков. Большинство сайтов (может даже 90%) использует пагинацию и даже 100 чанков парсить в цикле не будет. Не у всех на каждой странице сайта 890 комментариев.