Добрый день не могу никак решить проблему с установкой ShopModxBox через консоль. Все время одна и та же ошибка PHP Parse error: syntax error, unexpected T_STRING in /home/www/site1/public_html/vapor/import.php on line 123 Подскажите пожалуйста что это может быть.
Требуется настроить робокассу на интернет магазин modx revo+shopmodxbox и по мелочи, а также не мало работы на других сайтах
Когда вы закачиваете файл в дропбокс, вы сами указываете путь для него, а значит он вам известен. Вопрос как скачать файл, зная этот путь. Создаете сниппет, вот примерный код: <?php // $modx->setLogLevel(1); $id = 33; // Здесь ID вашего медиасурса $source = $modx->getObject('source.modMediaSource', $id); $source->initialize(); $path = '/path_to_file.ext'; // Путь до вашего файла в дропбоксе return $source->getContent($path); // Возвращаем полученный контент.
Я лишь хотел понять причину почему $_SESSION можно, а $_REQUEST нельзя. Я вам ответил почему. Вы это не приняли как причину. Ваше право. Я не буду усиленно объяснять вам свою точку зрения. Но ваши пожелания не буду внедрять, потому как они мне будут мешать (это по опыту работы). Вполне вероятно и вы к этому когда-нибудь придете. А может и не придете. Сейчас в компоненте ошибки нет. В той же сборке ShopModxBox проверка каптчи вызывается внутри процессора формы, в который передаются данные запроса явно. Единственное что в том процессоре следует доработать, так это передачу еще и параметра «captcha_key» (просто этот параметр появился позже, чем был написан тот процессор).
«это не правильно потому-что я так сказал» — вот ваш ответ между строк. Как бы я не просил вас аргументировать ваш ответ, вы кроме придирок ничего так и не ответили. А сейчас просто сливаете разговор чтобы не оказаться не правым. А по-поводу "… развивать ваш проект.." я написал специально чтобы посмотреть действительно ли задето ваше самолюбие, и вы это подтвердили. Вы уж извините меня за это. Я лишь хотел понять причину почему $_SESSION можно, а $_REQUEST нельзя. Чтож пусть будет так. А пользоваться вашими компонентами я буду и впредь ибо они мне нравятся намного больше чем аналоги, хоть иногда и случаются вот такие казусы =)
Не понятно то, что вы вместо того чтобы развивать компонент доказываете мне то чего нет. =) Куда развивать? Вы будете учить как и что развивать? Вам не кажется это наглостью? Вам который раз говорится, что так не правильно, а вы гнете свое. Вы имеете право не использовать то, что мы предоставляем. Но учить как «правильно» в своем убеждающем формате — это уж извольте. Диалог закончен.
И опять работа с глобальной переменной… Кто бы сомневался. Ну если вы так желаете, то: код в консоли: <?php $method = 'REQUEST'; $key = 'action'; echo $modx->request->getParameters($key, strtoupper($method)); вывод: exec 'action' это POST переменная передаваемая коннектору консоли, а 'exec' её значение ) Очевидно, что это рудимент, который, судя по истории процессора, даже никогда не использовался. Надо просто удалить будет. Ну учитывая то что есть REQUEST это понятно. Не понятно то, что вы вместо того чтобы развивать компонент доказываете мне то чего нет. =) Я лично вам не нравлюсь, или ваша идеология программирования не совпадает с моей, я не знаю. Но факт в том что ничего «не правильного» и «плохого» в использовании modRequest внутри процессора нет, тем более что он уже там есть в объекте $this->modx->request.
кстати совсем забыл по поводу вот этого: Сессия одна на все области видимости скрипта. Все суперглобальные массивы имеют один экземпляр на все области видимости =), а $_REQUEST, $_GET, $_POST, $_COOKIE и т.д. это все спуреглобальные переменные на ряду с $_SESSION Единственное это то что данные в $_REQUEST, $_GET, $_POST, $_COOKIE нужно фильтровать ибо они не безопасны. Но так как в нашем случае идет обычное сравнение то фильтрация это излишний функционал.