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

Решил глянуть как организована работа с сессией. И вот такое увидел в классе modUser в методе addSessionContext (другие не смотрел)

if (!isset($_SESSION["modx.{$context}.user.token"]) || empty($_SESSION["modx.{$context}.user.token"])) {

А вот так добавляются скрипты в классе modX

$this->sjscripts[count($this->sjscripts)]= $src;

У меня одного ощущение, что писал практикант? ))

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

Забанят нас тут ))

Для информации. В MODX есть специальный класс для работы с файловой системой. Он называется modFileHandler и работает с классами modFile и modDirectory. Реализация крайне убогая. Например самый первый пример из документации не работает. Т.е. создать папку у вас не получится. А как вы думаете сделано удаление директории? А вот так

$this->fileHandler->modx->getCacheManager();
return $this->fileHandler->modx->cacheManager->deleteTree($this->path, $options);

Т.е. не кеш-менеджер работает через файловый менеджер, а наоборот. Реакция одна — WTF. И подобного говнокода в ядре я встречал неоднократно. О некоторых моментах я уже писал раньше.
Если это понимаю я со своими средненькими познаниями, то что уж говорить про профи.

Заключение. Если вы ни слова не поняли, о чём тут написано, не расстраивайтесь. У вас ещё всё впереди. :)

Не корысти ради, просвещения для! :))
Ответ-то очевиден. Просто хотелось подискутировать и потихоньку придти к новости, что в MODX3 появился FlySystem.

Обращаюсь к разработчикам.
Друзья, ответьте мне на один вопрос — как вы считаете, это нормально для кэш-менеджера имплементировать данный функционал?

Выше приведенный метод использовать для отправки данных в sphinxQL именно по этому привел его в пример)))

Надеюсь, вы помните про обновление.

Андрей, всё гораздо проще. Если пользуетесь modHelpers, то там есть функция filter_data(). Можно фильтровать данные на событие onHandleRequest или непосредственно перед использованием.
В простейшем случае для getObject используйте преобразование типов и массив.

На самом деле это не бага, это фича ))
xPDO позволяет вставлять так называемые raw условия через массив со строкой аналогично методу whereRaw в Ларавел. И этим часто пользуются. Поэтому задача по безопасности ложится целиком не плечи разработчиков. Обязательно фильтровать данные, пришедшие от пользователя!

Я так понимаю, что в getCollection такая же бяда.

Решение — запретить неассоциативные массивы?

Интересно. А как же с ресурсами работать? Ставить какой-то ORM?

Мда. Вот тебе и пифагоровы штаны во все стороны равны.

А эволюшн xPDO использует или это счастье досталось только Revoлюционерам?

Тогда ждите ответа от автора дополнения.

Попробуйте указать текст

'body'=>'Текст для проверки', // тело письма

П.С. Лично мне кажется странным вот этот код

$user['email'] = 'a@b.ru';

Зачем создавать массив?
Да и вообще весь описанный код странный. Но это вопрос к автору кода.

Вы написали про «режет глаз». Я описал способ избавиться от этого. На будущее.

Или передайте в функцию $modx третьим параметром —

->each(function($user, $idx, $modx) {
	 if (is_email($user['email'])) {
           $queue_email = $modx->newObject('EmailQueueItem');

Статья устарела. Всё описанное работает из коробки.

Ну не знаю. Мне кажется, что у человека, столько лет работающего с MODX, вопросов быть не должно.На любой вопрос можно найти ответ в исходниках.

А официальная документация не устраивает?

И еще я не совсем понял, что значит «хранить в базе раньше было быстрее чем в файловой системе»?

Не быстрее конечно. Просто удобнее для реализации концепции параметров у сниппетов и чанков. Кстати очень удачная вещь получилась.Для плагинов — это события.Тоже очень удобная реализация интерфейса.