Comments 23
Более подробная установка MODX Revo, вернее, сервер под MODX Revo описана в этой статье.

Мультисайтовость здесь описано, в кратко говоря:
<?php /* don't execute if in the Manager */ if ($modx->context->get('key') == 'mgr') { return; } switch ($modx->getOption('http_host')) { case 'domain2.tld:80': case 'domain2.tld': // if the http_host is of a specific domain, switch the context $modx->switchContext('domain2.tld'); break; default: // by default, don't do anything break; } ?>
Тоже вещать на OnHandleRequest, тут код более понятен и не нужно лишние параметры создавать.
Лишнее написали, в общем-то.

А вот ЧПУ (правда, пример бы привели, как будет) и авторизация на всех контекстах для новичков — спасибо.
За код извиняюсь.
<?php
/* don't execute if in the Manager */
if ($modx->context->get('key') == 'mgr') {
    return;
}
 
switch ($modx->getOption('http_host')) {
    case 'domain2.tld:80':
    case 'domain2.tld':
        // if the http_host is of a specific domain, switch the context
        $modx->switchContext('domain2.tld');
        break;
    default:
        // by default, don't do anything
        break;
}
?>
Это вариант 2.1, который я описывал.
Цитирую:
жёстко задаётся список доменов, которые обрабатываются жёстко заданным списком контекстов..

Насчёт примера по ЧПУ — получается примерно так:
example.com/myresource.html/param1-value1/param2-value2/param3-value3/
жёстко задаётся список доменов, которые обрабатываются жёстко заданным списком контекстов..

С плагином, который я взял с rtfm всё также. Контексты показываются только у своего домена, если домен не указан — то показывается контекст web.
Ну так я про то и говорю. Мой вариант более гибкий — он соответствует варианту 2.2, который я и описывал. Тогда как ваш (взятый с rtfm) — соовтетствует варианту 2.1.
Люди, которые минусуют статью! Просьба сказать, что именно вам в ней не понравилось!
Я не минусовал, да и не хочется, но статья на самом деле странная.
Вы начали в общих чертах описывать систему, потом перешли к ЧПУ, а закончили плагином. Не увидел стройности мысли.
Это некие «заметки на полях» о разных аспектах MODX. По тем вещам, которые заставили меня порыться в гугле, документации, на форуме и в исходниках.
Наверно тогда лучше было бы разнести по разным постам материал, например: «Моя настройка nginx для MODx», «Модернизация ЧПУ для МОДх».
Опять какие то странные изобретения. Расписывать долго, остановлюсь на авторизации.

Логин:
$data = array(
	'username' => $username,
	'password' => $password,
	'rememberme' => 1
	'login_context' => 'web'
	'add_contexts' => 'en,ua,fr'
);

$response = $modx->runProcessor('/security/login', $data);
if ($response->isError()) {
	$modx->log(modX::LOG_LEVEL_ERROR, 'login error. Username: '.$username.' Message: '.$response->getMessage());
}


Логаут:
$response = $modx->runProcessor('/security/logout');
if ($response->isError()) {
	$modx->log(modX::LOG_LEVEL_ERROR, 'logout error. Username: '.$modx->user->get('username').', uid: '.$modx->user->get('id').'. Message: '.$response->getMessage());
}

Подробнее покопаться можно тут. Так же сделан вход\выход и в сниппете Login. Еще, на будущее — мои заметки про использование процессоров: раз и два.

Я понимаю, что вам нравится система и вы спешите поделиться своей радостью. Но вы же учите плохому.
В MODX Revolution отличное API и система процессоров, которые позволяют делать очень многое просто и красиво.

Мой вам совет — поучитесь еще, прежде чем писать такие рецепты.

P.S. плюсую все равно, ибо в хабе MODX очень тихо.
В том-то и вся гибкость моего решения, что не нужно забивать названия контекстов прямо в сниппете, как здесь у вас.
Строчка 'add_contexts' => 'en,ua,fr' не требуется в данном случае — всё делается через плагин.
Что мешает добавить имена контекстов в массив перед авторизацией? И не быстрее ли, один раз их руками написать, чем при каждом входе лазить в базу? У вас новые контексты каждый день создаются и надо во все логиниться?


И неужели вы не поняли, что я вам говорю про использование системного процессора для входа и выхода, вместо вашего ручного формирования сессии?

Что вы будете делать со своими велосипедами в MODX 2.2,4 или в MODX 2.3? Там сессия может и поменяться, а процессоры будут работать как ни в чем не бывало.
То, что я хочу хранить это именно в настройках контекстов, а не где-то ещё. И использовать не только для авторизации, а например и при создании пользователей — да мало ли ещё где!
Или вы предлагаете в том же моём плагине вместо addSessionContext вызывать процессор? А не будет ли больше оверхеда в таком случае? Фактически для других контекстов придётся заново пройти всю процедуру авторизации.
И я не хочу везде вставлять кучу кода для поддержки загрузки нужного списка контекстов из кучи сниппетов. Хочется вставить только один кусок кода — в данном случае сниппет — и чтобы оно автоматом подхватилось везде где только можно. Мой вариант это позволяет. Тем более, что addSessionContext вполне себе документированная функция API.
Я предлагаю использоваться для логина, логаута, работы с юзерами, ресурсами и прочих системных действий системные же процессоры.

Откуда вы их вызываете: плагина ли, сниппета, консольного скрипта — не важно. Важно то, что они все сделают правильно. Проверят права доступа, системные настройки, вызовут плагины и прочее.

Очень советую посмотреть в код процессоров, и вы увидите, что они делают.
Сейчас вы изобретаете собстенный велосипед, с квадратными колесами. Да и на здоровье!

Но не надо этому учить новичков. Вы только отпугнете юзеров от MODX, который и так считают сильно сложным.

Пожалуйста, набросайте простенькую реализацию плагина с использованием процессоров, если не очень сложно. А то я лично вижу тут две фундаментальные проблемы:
1. Плагин OnWebLogin будет вызываться каждый раз, когда я буду вызывать процессор, надо как-то запретить это наверное?
2. У плагина OnWebLogin нет информации о пароле польователя. Можно, конечно, вместо этого использовать событие OnWebAuthentication, куда передаются данные в том числе о введённом пароле, но… Зачем заставлять заново проверять уже один раз проверенный пароль для каждого контекста?
Вы не понимаете суть. Это процессор security/login вызывает событие OnWebLogin (исходник).

Сейчас у вас:
1. Авторизация через Login
2. Login запускает процессор security/login, тот вызывает OnWebLogin
3. Срабатывает ваш плагин и вы добавляете нужные контексты юзеру

Замечу еще, что у сниппета Login, есть настройка, котрая позволяет юзера сразу авторизовать в разные контексты.

В вашем случае нужно или вызвать верно Login, или просто выкинуть его и самому всех авторизовать.
1. Юзер шлет куда-то логин\пароль.
2. Ваш сниппет ловит их и передает процессору. В зависимости от ответа — вход или ошибка.

Плагин ваш — просто лишняя нагрузка.
Я знаю, что процессор вызывает OnWebLogin, в этом-то и проблема.
Ещё раз повторяю — я НЕ ХОЧУ править все сниппеты чтобы туда по необходимости включать те или иные контексты. Более того, я не хочу даже увеличивать текст тега для сниппета Login — я хочу, чтобы вся обработка всех лог инов и лог аутов происходила в одном единственном месте — в данном случае в моём плагине, а настройки на эту тему хранились в другом месте — где им и положено, в настройках контекстов. Фактически, я хочу чтобы с моим кодом автоматически оказался совместим фактически ЛЮБОЙ сниппет БЕЗ его изменения, будь то Login, чей-то самопальный, Loginza или ещё чего.
Не надо сарказма. Или вы хотите сказать, что мой способ не позволяет этого сделать?
Only those users with full accounts are able to leave comments. Log in, please.