MODX_API_MODE и процессоры
В рамках выполнения одной хитрой задачи, потребовалось написать скрипт, который будет запускаться по cron и что-то делать с MODX.
Проблемы, в общем то нет, вопрос изучен, но выплыл интересный глюк.
А именно: не работали процессоры для создания/обновления ресурсов.
То есть, процессор для логина — нормально, контекст mgr — нормально, а при попытке создать ресурс — просто пустая error.
Выложил вопрос на официальном форуме и никто мне не ответил. Пришлось разбираться самостоятельно, глубоко копая исходники.
И вот, что выяснилось: при запуске MODX из консоли, в режиме MODX_API_MODE, переменная $modx->error->message является массивом, тогда как должна быть строкой. Через это процессор при проверке ошибок, в ходе создания ресурсов, считает, что есть сообщение об ошибке — и выводит его мне. А я ничего не могу понять, ибо там пусто.
Таким образом, вот верный способ работы в MODX_API_MODE:
Проблемы, в общем то нет, вопрос изучен, но выплыл интересный глюк.
А именно: не работали процессоры для создания/обновления ресурсов.
То есть, процессор для логина — нормально, контекст mgr — нормально, а при попытке создать ресурс — просто пустая error.
Выложил вопрос на официальном форуме и никто мне не ответил. Пришлось разбираться самостоятельно, глубоко копая исходники.
И вот, что выяснилось: при запуске MODX из консоли, в режиме MODX_API_MODE, переменная $modx->error->message является массивом, тогда как должна быть строкой. Через это процессор при проверке ошибок, в ходе создания ресурсов, считает, что есть сообщение об ошибке — и выводит его мне. А я ничего не могу понять, ибо там пусто.
Таким образом, вот верный способ работы в MODX_API_MODE:
<?php
// Подключаем
define('MODX_API_MODE', true);
require dirname(dirname(__FILE__)).'/index.php';
// Включаем обработку ошибок
$modx->getService('error','error.modError');
$modx->setLogLevel(modX::LOG_LEVEL_FATAL);
$modx->setLogTarget(XPDO_CLI_MODE ? 'ECHO' : 'HTML');
$modx->error->message = null; // Обнуляем переменную
// Логинимся в админку
$response = $modx->runProcessor('security/login', array('username' => 'admin', 'password' => '123456'));
if ($response->isError()) {
$modx->log(modX::LOG_LEVEL_ERROR, $response->getMessage());
return;
}
$modx->initialize('mgr');
// Создаем ресурс
$response = $modx->runProcessor('resource/create', array(
'pagetitle' => 'Имяресурса'
,'parent' => 1
,'content' => 'Текстресурса'
,'template' => 1
,'isfolder' => 1
,'published' => 1
));
if ($response->isError()) {
$modx->log(modX::LOG_LEVEL_ERROR, $response->getMessage());
return;
}
else {
print_r($response->response);
}Вот теперь можно делать что хотите с MODX, из своих скриптов от лица авторизованного админа. Комментарии: 26
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
как ни мучался с правами user — НОЛЬ.
попробовал описанным методом, но тогда теряется авторизация пользователя…
как сохранить её?
А чтобы юзер смог добавлять товары, ему надо назначить кучу прав, типа «edit_document»,«publish_document» и т.д.
Я так даже не заморачивался ни разу.
Первый блок срабатывает, второй – нет. Включив дебаг, при попытке авторизации выводится вот что:
и дальнейший скрипт не срабатывает, так как юзер, оказывается, аноним… пробовал гуглить, но ничего полезного не нашёл. Может подскажите, в чем может быть дело?
Кстати, при обращении к скрипту, сессия в БД создаётся, нот с другим ИД.
Ошибки с сессией избавился. Похоже, контекст не совпадал.
Но другая штука вылезла: авторизация проходит успешно, а вот $modx->user остаётся тот самый, как и был (т.е. там и дальше хранятся данные, что наш юзер – аноним). Вообще-то это мне не мешает (правда, жаль что в БД не записывается информация о том, какой юзер создал импортированные товары), но странно всё-таки… Или всё так и должно быть?
Пробовал session_abort или session_destroy, но мне кажется тут не все так просто из-за метода подключения API.
Как правильно залогиниться под админом, например в login.php с «примерно» вышеуказанным кодом?
для поиска: Авторизация админа api
где $next_date вида 21.07.15
Не получается, вставляется текущая дата и всё. Думал надо в UNIX формате указывать. Сделал, стали прописываться какие-то совершенно левые даты… Не пойму в чём дело.
С датой публикации всё немного сложнее — нужно еще указать, что документ опубликован:
Fatal error: require(): Failed opening required '/home/mesial1/www/test.mymilena.ru/core/cache/includes/elements/index.php' (include_path='.:/opt/php54/pear') in /home/mesial1/www/test.mymilena.ru/core/cache/includes/elements/modsnippet/92.include.cache.php on line 3
Вот код
Указанный код необходимо размещать в каком-либо подкаталоге корня сайта, тогда и подключение корректно произойдет, и от MODX_API_MODE будет толк.
Она значит — подняться на одну директорию выше текущего файла и там найти файл index.php. PHP ищет этот файл в директории elements и не находит. Об этом и сообщается в ошибке. Файл index.php находится в корне. Поэтому, чтобы его подключить, нужно ещё 4 раза вызвать функцию dirname().
Как быть с остальным кодом, при добавлении товара через процессор, в кроне получаю:
В сообществе уже обсуждалось, поищите.
В этой статье afres.ru/blog/working-with-modx-revolution-api
Нужно перед авторизацией включить сессии!
Как то так у меня получилось…
И вот тут то меня выручили сессии…