Легко! Код в консоли: $_REQUEST['mykey'] = '123'; $method = 'REQUEST'; $key = 'mykey'; echo $modx->request->parameters[$method][$key]; И опять работа с глобальной переменной… Кто бы сомневался. по умолчанию $method задан в вашем же процессоре и его значение 'REQUEST' Очевидно, что это рудимент, который, судя по истории процессора, даже никогда не использовался. Надо просто удалить будет. Еще раз: делайте как вам больше нравится. Это из серии совета. Все на ваше усмотрение.

Легко! Код в консоли: <?php $_REQUEST['mykey'] = '123'; $method = 'REQUEST'; $key = 'mykey'; echo $modx->request->parameters[$method][$key]; вывод: 123 по умолчанию $method задан в вашем же процессоре и его значение 'REQUEST', но в случае если процессор был запущен вот так $scriptProperties['method'] = 'GET'; $modx->runProcessor('modcaptcha/web/check', $scriptProperties, array( 'processors_path' => $path.'processors/', )) То параметр будет перезаписан в параметрах modProcessor согласно вот этому куску кода: modprocessor.class.php function __construct(modX & $modx,array $properties = array()) { $this->modx =& $modx; $this->setProperties($properties); } А вот так туда попадуют параметры по умолчанию, и если заметить они не перезаписывают те что передаются при инициализации через $scriptProperties public function setDefaultProperties(array $properties = array()) { $this->properties = array_merge($properties,$this->properties); return $this->properties; } Точно так же в параметры процессора попадают все остальные параметры. Единственное что бы я поправил, и у себя поправлю это все таки сделаю вот так: $code = $modx->request->getParameters($key, strtoupper($method)); в методе getParameters клсса modRequest нет привидения к верхнему регистру как ни странно.

Почему $_SESSION это не плохо, а $this->modx->request->parameters[$method][$key] плохо? Сессия одна на все области видимости скрипта. Ее нельзя ни с чем спутать. Работая с сессией вы априори знаете, что работаете только с ней. А вот обрабатывая данные запроса в процессоре, вы рискуете обработать данные не своего запроса. Сейчас, с каптчей, вы рассчитываете только на то, что у вас есть уникальный ключ параметра запроса и типа это вас перестраховывает. Да, это отчасти так, но это всего лишь меньший риск при использовании неправильного подхода. Он тем и не правильный, что при большей вероятности неуникального ключа, возрастает вероятность и логической ошибки. Если вы используете правильный подход, он всегда вам больше дает шанса на то, что и результат будет правильный. Но вот вам еще один вариант: попробуйте свой скрипт вызвать не со страницы, а через Console. Будет ли у вас там нужный? $this->modx->request->parameters[$method][$key]; И что вы будете делать, чтобы у вас этот параметр был в пост-запросе? Как отладку будете выполнять?

плохие глобальные переменные это

$a = 111;

class A {     public function myfunc() {         global $a;         echo $a;     } } $_REQUEST: Замечание: Это 'суперглобальная' или автоматическая глобальная переменная. Это просто означает что она доступна во всех контекстах скрипта. Нет необходимости выполнять global $variable; для доступа к ней внутри метода или функции. Источник. Где тут глобальные переменные которые «плохие»? )) $this->modx->request->parameters[$method][$key]; Метод modRequest::getParameters() работает с глобальными переменными, а значит работая с $this->modx->request->parameters вы работаете с глобальными переменными. А надо использовать методы $this->getProperties()/$this->getProperty().

У меня такое чувство что мы с вами говорим о разных вещах. Ведь даже вот тут github.com/MODX-Club/modCaptcha/blob/master/core/components/modcaptcha/processors/modcaptcha/web/check.class.php строка 29, и это не мой код, а ваш =) $session_code = (!empty($_SESSION[$key]) ? $_SESSION[$key] : ''); $_SESSION это суперглобальный массив =) Почему $_SESSION это не плохо, а $this->modx->request->parameters[$method][$key] плохо?

стоп стоп. Не путайте меня =) я нигде и не использовал глобальные переменные о которых вы говорите =) переменные $method и $key получаются из Properties процессора, их значения по умолчанию задаются в initialize(), и перезаписываются в случае если были переданы через $scriptProperties. А вот уже основываясь на этом я получаю значение $code в $modx->request который в свою очередь обрабатывает массивы $_REQUEST и т.д. И это не я придумал, а создатели modx =) Где тут глобальные переменные которые «плохие»? )) плохие глобальные переменные это $a = 111;

class A { public function myfunc() { global $a; echo $a; } }

Гуглите «почему глобальные переменные плохо».

А тут и не производиться работа с глобальными переменными, это уже сделал modRequest, мы лишь спрашиваем у него переменную по ключу и имени массива, и то только в случае если в параметрах процессора не был найден параметр «code». Ведь он уже инстанцирован и содержит все эти данные и без нас. Почему не использовать? Ответ «не правильно» без аргументации не ответ имхо.

создал 2 поля ввода и вывод 2-х картинок всё с разными «captcha_key». Каждый экземпляр отработал независимо от другого. =) Для этого параметр captcha_key и создавался. Но еще раз: прописывать внутри процессора работы с глобальными переменными запросов — не правильно. Но спорить с вами не буду. Вы можете делать так, как вам больше нравится.

Почему нет? параметр в $_REQUEST уникален, а если ключи разные то каждый вызов получит свой, мы ведь передаем в вызов «captcha_key» он и служит ключём в $_REQUEST, собственно как и «method» говорит в каком массиве искать. Только что ради эксперимента создал два вызова процессора в шаблоне, создал 2 поля ввода и вывод 2-х картинок всё с разными «captcha_key». Каждый экземпляр отработал независимо от другого. =)