Если вы про то, чтобы развернуть там снимок сборки — то 95% никак. Там скрипт отбивается, если в течение 5-ти секунд нагружает процессор на 100%. Это политики таймвеба. Разворачивайте сборку на другом каком-нибудь хостинге, который позволяет это сделать, и потом уже переносите файлы и БД на таймвеб.
Подскажите как корректно настроить сборку на хостинге TimeWeb
Евгений ака Agel_Nash в очередной раз нашел способ выполнять взлом MODX Revolution. По сути он объединил в данном случае сразу две более ранние уязвимости — подмена контекста в запросах к коннекторам, и, собственно, SQL-инъекции в xPDO. Первую уязвимость в свое время как бэ прикрыли в версии 2.2.8. Сейчас Евгений просто выполнил чуть другой финт, который позволяет сделать то же самое, и во вчерашнем релизе 2.2.13 добавили еще проверочку, которая защищает от подобного рода хаков (хотя я по прежнему убежден, что им следует дергать контекст из БД, убеждаясь, что запрошенный контекст действительно существует, а не просто играться с новым объектом). А вот саму уязвимость с SQL-инъекциями пока так и не закрыли, и это очень даже не хорошо. Могу точно сказать, что есть еще не мало способов выполнить этот эксплойт, так что они прикрыли только одну из кучи дверей, ведущих к данной дыре.
Так что же делать, чтобы дополнительно обезопаситься от этого? Ответ прост — используйте другие названия для системных папок connectors, core, manager, а так же свой уникальный префикс для таблиц вместо _modx. Это в значительной степени повысит безопасность сайта, так как во-первых, надо знать где коннекторы, чтобы отправить на них атакующие запросы, а во-вторых, SQL-инъекция требует знания полного наименования таблицы, чего злоумышленник не может сделать, не получив конфиги сайта.
Собственно, вкупе с этим и анонсирую новую сборку ShopModxBox. В ней как раз доработана корректная работа с кастомными системными папками и префиксами таблиц. То есть инсталлируете чистый MODX с кастомными конфигами, накатываете на него эту сборку и она будет работать нормально. Есть только один момент — хотя я и добавил в пространства имен плейсхолдеры-конфиги типа [[++core_path]], в момент снятия снимка эти конфиги источников файлов все равно конвертируются в абсолютные значения в соответствии с текущими конфигами сайта-источника, и потому в снимок попадают абсолютные значения. Итог — у вас часть источников файлов будет иметь некорректные пути. Их надо будет вручную поправить в настройках источников файлов.
Еще такой момент: если кто-то хочет свой MODX-сайт изменить, чтобы в нем были другие папки и префиксы таблиц, то здесь опять-таки помогает vapor. Делаете им снимок текущего сайта, инсталлируете новый MODX Revo со своими кастомными папками и префиксами, и накатываете на него этот снимок. В большинстве случаев все будет ОК.
Алексей, позволь пару замечаний:
1. Если не получается подключить пакет, то почему не прерывается процесс? Это я про вот это:
echo "\naddPackage " . ($success? 'OK' : 'Failed'); $success = $modx->loadClass('Paysystem');
То есть если !$success, то и loadClass делать нет смысла. Это же касается и попытки подключения класса — если не удалось подключить класс, то и создавать новый объект нет смысла. К слову, $modx->newObject() и прочие методы в принципе включают в себя метод $modx->loadClass(), так что не надо специально его вызывать заранее.
2. Данный код крайне избыточный, особенно имея ввиду то, что пакет billing имеется в экспеншенах, и выполняется автоматически. Соответственно, его нет смысла подключать через $modx->addPackage(). В итоге, конечный работающий код будет выглядеть вот так:
if(!$object = $modx->newObject('Paysystem', array( "name" => "EdinayaKassa", "comment" => "Единая касса приема платежей", ))){ print "Не удалось создать новый объект платежной системы"; return; } // else if(!$object->save()){ print "Не удалось сохранить новый объект платежной системы"; return; } // else print "Был создан новый объект платежной системы с id ". $object->id;
альтернативный вариант добавления записи платежной системы в таблицу modx_billing_paysystems через consol обратите внимание, на префикс таблиц modx.
$packageName = 'billing'; $base_path = $modx->getOption('core_path'); $success = $modx->addPackage($packageName,$base_path.'components/'.$packageName.'/model/','modx_billing_'); echo "\naddPackage " . ($success? 'OK' : 'Failed'); $success = $modx->loadClass('Paysystem'); echo "\nloadClass " . ($success ? 'OK' : 'Failed'); $obj = $modx->newObject('Paysystem'); $obj->set('name','EdinayaKassa'); $obj->set('comment','Единая касса приема платежей'); if ($obj->save()) echo "<br />Запись успешно добавлена";; $result = $modx->getCollection('Paysystem'); echo "<br />Содержимое таблици:"; foreach($result as $row){echo '<pre>';print_r($row->toArray());echo '<pre>';}
25 февраля 2014 года состоялся первый в этом году мастер-класс MODX-Клуба, который проводил Николай Fi1osof Ланец. (анонс)
?
На мастер-классе разбирались следующие вопросы:
  • разработка магазина на базе ShopModxBox с нуля;
  • обзор новых версий сборок;
  • модификация шаблонов сайта;
  • дополнительные поля товаров;
  • обзор типичных ошибок и многое другое
Отметим, что все это демонстрировалось на реально существующих проектах, так что можно было наглядно видеть “до” и “после” каких-либо преобразований с кодом.
?
Встреча (будем называть ее так), прошла в очень дружеской атмосфере: пришли действительно заинтересованные люди, со списком вопросов, которые работают над проектами, основанных на MODX Revolution.
В большом и комфортном конференц-зале на огромной “плазме” наглядно показывались все “фишки” движка и раскрывались некоторые секреты.
Среди участников были как “новички”, так и “старички”, которые уже не первый раз посещают семинары и мастер-классы Клуба, что, конечно, особенно приятно. Они делились своими впечатлениями о том, как подобные открытые формы общения помогли им некогда начать работать с MODX Revolution. Теперь они сами строят свои сайты на MODX (получая при необходимости ответы на все интересующие вопросы на форуме Клуба), популяризируя тем самым данную платформу. Ключевой посыл “старичков” — MODX Revolution — это успешная, интуитивно понятная и гибкая (одно из ее ключевых преимуществ) платформа, на которой реально можно зарабатывать хорошие деньги!
В конце встречи были определены наиболее интересные темы для будущих встреч. Мастер-классы подобного вида будут проводиться и дальше (как платные, так и бесплатные), ввиду явной заинтересованности в подобного рода мероприятиях. Также в будущем планируется организовывать платные индивидуальные уроки для тех, у кого уже есть свой проект на MODX.
Благодарим всех участников за неподдельный интерес и горящие глаза, за поток интересных и важных вопросов, за множество предложений относительно будущего развития MODX-Клуба.
Следите за новостями, будем рады видеть вас! У нас есть, что рассказать вам! ?
Почему то он выводит только первый уровень вложенности, а мне надо все 3 уровня которые вложены в id 4…
Вам здесь не только знание php требуется, но еще и знание SQL. Если вы указываете parent=>4, это уже получается $where[«parent»] = $parent; (см. код). Плюс к этому вы еще указываете 'template' => 5.
В итоге у вас получается
'where' => [ 'parent' => 4, 'template' => 5 ],
То есть в вашу выборку могут попасть только те документы, которые являются непосредственно дочерними для документа с id 4, а так же у которых шаблон 5. К этому еще не забываем про автоматически добавленные условия Опубликован, Не удален, Не скрыт из меню.
Резюмирую: если вы явно указываете раздел, то будут получены документы только этого раздела.
А если вы хотите получить все документы во всех вложенных разделах, то эта задача весьма не простая, и требует правильной организации каталога, чтобы можно было попроще это выполнить. Есть два пути: 1. Все целевые документы должны иметь какой-то уникальный признак, который бы позволил сделать выборку без учета вложенности. К примеру, иметь какой-то свой особенный шаблон или типа того. 2. Если не сделано как в первом пункте, то придется выполнять перебор всех необходимых уровней и выбирать оттуда нужные документы. В качестве примера можете изучить процессор, который получает товары из определенного раздела. Он сначала перебором делает выборку всех дочерних разделов, а потом получает конечную выборку товаров, для которых указанные разделы являются родительскими.
{assign var=params value=[ "parents" => 4, "tpl" => "productSmarty", "useSmarty" => true, "where" => '{"template:in":[5]}' ]} {snippet name=getProducts params=$params parse=true}
так тоже выводит только первый уровень, и не работает depth. Почему так? почему не где не написано, это же важный момент, почему везде примеры которые выводят один первый уровень…
Сегодня я расскажу про один маленький, но очень полезный и замечательный метод — xPDOObject::isDirty($key); С помощью этого можно проверить, была ли изменена целевая колонка у нашего объекта (вообще, это конечно совсем не колонка, а только свойство, значение которой хранится в колонке его таблицы, но тем не менее, назовем это так).
Зачем это нам может быть нужно? Допустим, мы хотим препятствовать изменению email-а пользователем. Пропишем проверку:
if($profile->isDirty('email')){ return 'Нельзя менять email!'; }
Получить массив названий всех измененных полей можно в свойстве xPDOObject::_dirty.