Вопросы специалистов

Системное администрирование

Blog by Fi1osof

Вопрос по Gallery

Кто-нибудь работал с пакетом MyComponent?

Как правильно хранить свойтва элемента каталога?

Будет ли более легкая сборка shopmodx?

$this->_lazy и повторные запросы к БД при $object->toArray() и ->get();

Превращение xPDO-объектов

modAvatar for MODX Revolution. Обновляем фото пользователя через админку

Кастомная галерея by Gallery

Почему я всем советую изучать xPDO

CentOS 6.4x32 установка Nginx + php-fpm + memcache + zendoptimizerplus

Все понятно. Блин, хотелось бы все же с процессорами разобраться. По-моему, mgr/item/getlist в gallery меньше кода гоняет

Все понятно. Блин, хотелось бы все же с процессора

Как создавать собственные галереи на основе Gallery, я писал здесь.
 

А по поводу возвращаемого JSON-а: изначально modProcessor::outputArray() возвращает JSON-строку.
 

public function outputArray(array $array,$count = false) {
    if ($count === false) { $count = count($array); }
    return '{"total":"'.$count.'","results":'.$this->modx->toJSON($array).'}';
}

Но так как мы часто пишем метод process сами, и возвращаем в нем $this->success() или $this->failure(), то $this->outputArray() мы и не замечаем. А вот modObjectGetListProcessor в process() именно его и возвращает.
 

public function process() {
    $beforeQuery = $this->beforeQuery();
    if ($beforeQuery !== true) {
        return $this->failure($beforeQuery);
    }
    $data = $this->getData();
    $list = $this->iterate($data);
    return $this->outputArray($list,$data['total']);
}

Вот поэтому ты на выходе и получаешь JSON. Перегрузи outputArray и все. Можешь в нем $this->success($msg, $array) вернуть, а можешь сразу массив вернуть, как у меня в getdata-процессорах.
 

public function outputArray(array $array, $count = false){
        return array(
            'success' => true,
            'message' => $this->getMessage(),
            'count'   => count($array),
            'total'   => $count,
            'object'  => $array,
        );
}

Как создавать собственные галереи на основе Gallery, я писал здесь. А по поводу возвращаемого JSON-а: изначально modProcessor::outputArray() возвращает JSON-строку. public function outputArray(array $array,$count = false) {
    if ($count === false) { $count = count($array); }
    return '{"total":"'.$count.'","results":'.$this->modx->toJSON($array).'}';
} Но так как мы часто пишем метод process сами, и возвращаем в нем $this->success() или $this->failure(), то $this->outputArray() мы и не замечаем. А вот modObjectGetListProcessor в process() именно его и возвращает. public function process() {
    $beforeQuery = $this->beforeQuery();
    if ($beforeQuery !== true) {
        return $this->failure($beforeQuery);
    }
    $data = $this->getData();
    $list = $this->iterate($data);
    return $this->outputArray($list,$data['total']);
} Вот поэтому ты на выходе и получаешь JSON. Перегрузи outputArray и все. Можешь в нем $this->success($msg, $array) вернуть, а можешь сразу массив вернуть, как у меня в getdata-процессорах. public function outputArray(array $array, $count = false){
        return array(
            'success' => true,
            'message' => $this->getMessage(),
            'count'   => count($array),
            'total'   => $count,
            'object'  => $array,
        );
}

Как создавать собственные галереи на основе Galler

Понятно, спасибо. Сейчас попробую.

Так кто мешает? Говорю же — перегрузи метод outputArray() и все.

Так кто мешает? Говорю же — перегрузи метод output

Пожалуйста.

<?php
require_once(MODX_CORE_PATH.'components/gallery/processors/mgr/item/getlist.class.php');

class modSiteGalleryProcessor extends GalleryItemGetListProcessor{

public function outputArray(array $array, $count = false){
        return array(
            'success' => true,
            'message' => $this->getMessage(),
            'count'   => count($array),
            'total'   => $count,
            'object'  => $array,
        );
}
}
return 'modSiteGalleryProcessor';


<?php
$response = $modx->runProcessor('gallery/getlist', 
array(
    'album' => 1,
), 
array(
    'processors_path' => $modx->getOption('core_path') . 'site/processors/'
));
print_r($response->response);


ничего не выдает, только Loading крутится. Что-то я еще не сделал?

вот что получилось: <?php
require_once(MODX_CORE_PATH.'components/gallery/processors/mgr/item/getlist.class.php');

class modSiteGalleryProcessor extends GalleryItemGetListProcessor{

public function outputArray(array $array, $count = false){
        return array(
            'success' => true,
            'message' => $this->getMessage(),
            'count'   => count($array),
            'total'   => $count,
            'object'  => $array,
        );
}
}
return 'modSiteGalleryProcessor'; вызываю из консоли <?php
$response = $modx->runProcessor('gallery/getlist', 
array(
    'album' => 1,
), 
array(
    'processors_path' => $modx->getOption('core_path') . 'site/processors/'
));
print_r($response->response); ничего не выдает, только Loading крутится. Что-то я еще не сделал?

вот что получилось: <?php
require_once(MODX_CORE_P

1. В начале кода в консоли пропиши ini_set('display_errors', 1); Чтобы php тебе выводил ошибки.
 2. Поставь FireBug или типа того, чтобы видеть Ajax-овые запросы и т.п.
 3. Ошибка у тебя 99,999% из-за $this->getMessage(). Это моя функция в моем процессоре, и в процессорах MODX-а ее нет. Поэтому у тебя скрипт и разваливается с критической ошибкой.

1. В начале кода в консоли пропиши ini_set('displa

'processors_path' => $modx->getOption('core_path'). 'site/processors/'

А что это ты из core_path процессор пытаешься дернуть? У тебя по идее как минимум в core_path. components должно лежать. Пути в общем проверь.

И еще: 'processors_path' => $modx->getOption('core_path'). 'site/processors/' А что это ты из core_path процессор пытаешься дернуть? У тебя по идее как минимум в core_path. components должно лежать. Пути в общем проверь.

И еще: 'processors_path' => $modx->getOption('core

Точно, исправил — заработало.

да просто в core положил папку site, где все процессоры и шаблоны. Не люблю слишком длинные пути.

да просто в core положил папку site, где все проце

А все-таки, что экономичнее на твой взгляд — getCollection или все-таки процессор? я так понял, процессор превьюшки генерит (у него возвращаются их адреса)? Они-то как раз и не нужны.

А все-таки, что экономичнее на твой взгляд — getCo

Я как-то ковырял его, еще весной. Не могу сказать, что я уверенно понял, зачем он, но мне показалось, что основная идея этого — раз помучился, собрал все, зато потом быстро все установил и радуешься. Это типа того, как я когда-то собирал modxSite (я как-то писал про установку нескольких пакетов из одного пакета) и modBlog.
 Но подход Рея мне показался очень сложным и не эффективным, поэтому я забросил его брать на вооружение.
 

В общем, это много ручной работы.

Я как-то ковырял его, еще весной. Не могу сказать, что я уверенно понял, зачем он, но мне показалось, что основная идея этого — раз помучился, собрал все, зато потом быстро все установил и радуешься. Это типа того, как я когда-то собирал modxSite (я как-то писал про установку нескольких пакетов из одного пакета) и modBlog.
 Но подход Рея мне показался очень сложным и не эффективным, поэтому я забросил его брать на вооружение. В общем, это много ручной работы.

Я как-то ковырял его, еще весной. Не могу сказать,

Крайне неудачное решение. Используй MODX_CORE_PATH .'components/site/processors/' и все.
 А экономия с путями тебе сразу несколько минусов дает:
 1. Компонент — это не только процессоры. Это еще контроллеры для админки, модели и т.п.
 2. Папка core не попадает в снимки сайта, так что Vapor-ом уже не сможешь перенести свой сайт.
 И еще куча минусов, включая «элементарно забыть про что-то там в core».

Крайне неудачное решение. Используй MODX_CORE_PATH

Резонно. Так и поступлю.

что кономичнее на твой взгляд — getCollection или все-таки процессор?

Ты путаешь довольно разные вещи. getCollection — это конкретный метод xPDO для получения массива объектов. При этом это не только запросы к базе данных, но и набивка результатов в конечные объекты. Чтобы это лучше понимать, прочитай эти статьи: 
 modxclub.ru/blog/200.html
 modxclub.ru/blog/166.html
 

А процессор — это процессор. И в нем логика может быть какая угодно. Так вот, классический modObjectGetlistprocessor использует в том числе и метод xPDO::getCollection(). Просто помимо этого он имеет ряд методов для проверки прав, формирования запроса, подсчета общего числа элементов, обработки вывода и т.п. Конечно же он по определению тяжелее, чем просто getCollection(). Но если брать те же getlist-процессоры из shopModx-а, то там не используется метод getCollection, а используется чистое PDO/xPDO. Те процессоры в итоге легче гораздо. 
 Но в случае с Gallery работать с объектами конечно же лучше как минимум по двум причинам:
 1. получаемые galItem-объекты имеют все необходимые методы для работы с этими картинками, а так же формирования путей, самбов и т.п.
 2. как правило элементов не много, так что нагрузкой можно пренебречь.

что кономичнее на твой взгляд — getCollection или все-таки процессор? Ты путаешь довольно разные вещи. getCollection — это конкретный метод xPDO для получения массива объектов. При этом это не только запросы к базе данных, но и набивка результатов в конечные объекты. Чтобы это лучше понимать, прочитай эти статьи: 
 modxclub.ru/blog/200.html
 modxclub.ru/blog/166.html А процессор — это процессор. И в нем логика может быть какая угодно. Так вот, классический modObjectGetlistprocessor использует в том числе и метод xPDO::getCollection(). Просто помимо этого он имеет ряд методов для проверки прав, формирования запроса, подсчета общего числа элементов, обработки вывода и т.п. Конечно же он по определению тяжелее, чем просто getCollection(). Но если брать те же getlist-процессоры из shopModx-а, то там не используется метод getCollection, а используется чистое PDO/xPDO. Те процессоры в итоге легче гораздо. 
 Но в случае с Gallery работать с объектами конечно же лучше как минимум по двум причинам:
 1. получаемые galItem-объекты имеют все необходимые методы для работы с этими картинками, а так же формирования путей, самбов и т.п.
 2. как правило элементов не много, так что нагрузкой можно пренебречь.

что кономичнее на твой взгляд — getCollection или 

Ясно. Так и поступлю. Спасибо.

<?php
/**
 * Smarty plugin
 *
 * @package Smarty
 * @subpackage PluginsFunction
 */


function smarty_function_galAlbum($params, & $smarty)
{
    if(!isset($params['album']) OR !$album = $params['album']){return;}

	$output = '';
    if(!$rowTpl = $params['rowTpl']){
		$output = array();
	}

    if(!empty($params['assign'])){
        $assign = (string)$params['assign'];
    }
    
    $modx = & $smarty->modx;

	// Получаем все элементы
	$q = $modx->newQuery('galItem');
	$q->join('galAlbumItem', 'AlbumItems');
	$q->where(array(
	    'AlbumItems.album' => $album,
	));

	if($items=$modx->getCollection('galItem', $q)){
		foreach($items as $item){
		    $item = array(
		        'name'			=>$item->get('name'),
                'description'	=>$item->get('description'),
//                'filename'	=>$item->get('filename'),
//                'mediatype'	=>$item->get('mediatype'),
//                'url'			=>$item->get('url'),
		        'relativeImage'	=> $item->get('relativeImage'),
//                'thumbnail'	=>$item->get('thumbnail'),
//                'image'	=>$item->get('image'),
//                'absoluteImage'	=>$item->get('absoluteImage'),
//                'filesize'	=>$item->get('filesize'),
//                'image_path'	=>$item->get('image_path'),
		    );
			if($rowTpl){
	            $smarty->assign('item',$item);
				$output.=$smarty->fetch($rowTpl);
			}
			else{
				$output[]=$item;
			}
		}
	}
    return !empty($assign) ? $smarty->assign($assign, $output) : $output;
}



Ну, примерно так: <?php
/**
 * Smarty plugin
 *
 * @package Smarty
 * @subpackage PluginsFunction
 */


function smarty_function_galAlbum($params, & $smarty)
{
    if(!isset($params['album']) OR !$album = $params['album']){return;}

	$output = '';
    if(!$rowTpl = $params['rowTpl']){
		$output = array();
	}

    if(!empty($params['assign'])){
        $assign = (string)$params['assign'];
    }
    
    $modx = & $smarty->modx;

	// Получаем все элементы
	$q = $modx->newQuery('galItem');
	$q->join('galAlbumItem', 'AlbumItems');
	$q->where(array(
	    'AlbumItems.album' => $album,
	));

	if($items=$modx->getCollection('galItem', $q)){
		foreach($items as $item){
		    $item = array(
		        'name'			=>$item->get('name'),
                'description'	=>$item->get('description'),
//                'filename'	=>$item->get('filename'),
//                'mediatype'	=>$item->get('mediatype'),
//                'url'			=>$item->get('url'),
		        'relativeImage'	=> $item->get('relativeImage'),
//                'thumbnail'	=>$item->get('thumbnail'),
//                'image'	=>$item->get('image'),
//                'absoluteImage'	=>$item->get('absoluteImage'),
//                'filesize'	=>$item->get('filesize'),
//                'image_path'	=>$item->get('image_path'),
		    );
			if($rowTpl){
	            $smarty->assign('item',$item);
				$output.=$smarty->fetch($rowTpl);
			}
			else{
				$output[]=$item;
			}
		}
	}
    return !empty($assign) ? $smarty->assign($assign, $output) : $output;
}

Ну, примерно так: <?php
/**
 * Smarty plugin
 *
 *

Да, подобные решения очень нужны. Планирую выпустить серьезно обновленную сборку, в котором будет больше готовых модулей на процессорах+Smarty, включая менюшку на процессорах и т.п.
 Но вот оформлению в виде Smarty-плагинов предпочитаю именно процессоры. Есть ряд причин:
 1. Smarty-плагины — это не формат MODX-а, и они не особо укладываются в модель пакетов для него. А даже если их включать в пакеты, то для подключения их надо указывать Smarty дополнительную директорию расширений (через плагин). Все это очень не удобно.
 2. Smarty-плагины подходят только для самого Smarty. Отдельно их не вызовешь. А вот MODX-процессоры можно вызвать где угодно — хоть в Smarty, хоть в плагиных, хоть в сниппетах, хоть в других плагинах. К тому же процессоры можно использовать и в других системах шаблонизации (ведь все еще витают идеи прикрутить Twig и т.п.).
 3. Smarty-плагины — это просто функции, а значит их расширить или переопределить нельзя. С процессорами все гораздо интересней, потому что это классы.
 

В общем, я стараюсь Smarty не обвешивать особенно.

Да, подобные решения очень нужны. Планирую выпустить серьезно обновленную сборку, в котором будет больше готовых модулей на процессорах+Smarty, включая менюшку на процессорах и т.п.
 Но вот оформлению в виде Smarty-плагинов предпочитаю именно процессоры. Есть ряд причин:
 1. Smarty-плагины — это не формат MODX-а, и они не особо укладываются в модель пакетов для него. А даже если их включать в пакеты, то для подключения их надо указывать Smarty дополнительную директорию расширений (через плагин). Все это очень не удобно.
 2. Smarty-плагины подходят только для самого Smarty. Отдельно их не вызовешь. А вот MODX-процессоры можно вызвать где угодно — хоть в Smarty, хоть в плагиных, хоть в сниппетах, хоть в других плагинах. К тому же процессоры можно использовать и в других системах шаблонизации (ведь все еще витают идеи прикрутить Twig и т.п.).
 3. Smarty-плагины — это просто функции, а значит их расширить или переопределить нельзя. С процессорами все гораздо интересней, потому что это классы. В общем, я стараюсь Smarty не обвешивать особенно.

Да, подобные решения очень нужны. Планирую выпусти

1. Сколько примерно будет товаров?
 2. Чем не устраивают стандартные TV-параметры?

1. Сколько примерно будет товаров?
 2. Чем не устр

Товаров примерно 1500. 5 параметров для 800 товаров и еще 4 для 700 товаров. Получится 9 TV-парметров для 1500 товаров. Как я понял, это на самом деле мало. Просто хотел узнать как правильно сделать. Рассматриваю еще вариант с таблицей в TV-параметре. Стоит связываться или лучше отдельными TV-параметрами?
 А как прикрутить табличное редактирование товаров? Пробовал через компонент «Групповое редактирование ресурсов», но не получилось редактировать цену товара (sm_price).

Товаров примерно 1500. 5 параметров для 800 товаро

Вот здесь я писал про магазин на 150 000 товаров. На самом деле там почти 180 000 товаров и 45 000 TV-параметров. Магазин еще не окончательно доделан (еще предстоит его немного оптимизировать), но без дополнительного кеширования он каталог с постраничностью отдает менее чем за 0,6 секунд. Думаете, ваши 1500 товаров реально могут создать нагрузку?
 А вот здесь 13 000 товаров и почти 100 000 TV-параметров. Пощелкайте. Не думаю, что у вас будут тормоза именно из-за TV-шек. Тем более что процессоры shopModx-а специально написаны для работы с TV-шками. Так что даже если 20 TV-шек будет — не беда.
 

Пробовал через компонент «Групповое редактирование ресурсов», но не получилось редактировать цену товара (sm_price).

Вы скорее всего пробовали GroupEdit? Он заточен чисто под ShopKeeper и конечно же он не будет менять sm_price, так как это кастомный элемент. У меня есть свой табличный редактор, но я его еще не публиковал из-за неидеальности. Но он точно появится в новой сборке магазина.

Вот здесь я писал про магазин на 150 000 товаров. На самом деле там почти 180 000 товаров и 45 000 TV-параметров. Магазин еще не окончательно доделан (еще предстоит его немного оптимизировать), но без дополнительного кеширования он каталог с постраничностью отдает менее чем за 0,6 секунд. Думаете, ваши 1500 товаров реально могут создать нагрузку?
 А вот здесь 13 000 товаров и почти 100 000 TV-параметров. Пощелкайте. Не думаю, что у вас будут тормоза именно из-за TV-шек. Тем более что процессоры shopModx-а специально написаны для работы с TV-шками. Так что даже если 20 TV-шек будет — не беда. Пробовал через компонент «Групповое редактирование ресурсов», но не получилось редактировать цену товара (sm_price). Вы скорее всего пробовали GroupEdit? Он заточен чисто под ShopKeeper и конечно же он не будет менять sm_price, так как это кастомный элемент. У меня есть свой табличный редактор, но я его еще не публиковал из-за неидеальности. Но он точно появится в новой сборке магазина.

Вот здесь я писал про магазин на 150 000 товаров. 

Понятно. Спасибо. Будем ждать табличный редактор.

согласен. В принципе, я вчера и процессор испытал — все удобно. И полностью согласен с тобой в плане процессоров. Просто я пока во всем этом новичок, все интересно, да и опыта набираюсь потихоньку.

согласен. В принципе, я вчера и процессор испытал 

Не, поиграться и попробовать различные способы — это и полезно, и интересно. Всяко поддерживаю.

Не, поиграться и попробовать различные способы — э

А не пробовал устанавливать через консоль по ssh? Я уже говорил, что в новой версии Vapor-а есть файл import.php
 Загружаешь любой пакет (или снимок — это ведь тоже пакет) и выполняешь в консоли:
 

php vapor/import.php package=core/packages/packagename-transport.zip

Само собой имя пакета — твоего.
 И все. В большинстве случаев успешная установка (таймвеб — точно исключение, потому что за 100% загрузку процессора в течение 5-ти секунд — смерть процессу). Во всяком случае nginx здесь уже точно не отобьет (элементарно потому что его нет), да и для консольного php часто более демократичные настройки идут. Плюс к этому нет проблем с сессиями.
 

Пакет shopmodx как я понял содержит только процессоры (без корзины).

Да, shopModx — это только объекты да процессоры (в общих чертах). Но shopModx — это более крупное решение. Там и другие компоненты установлены, и шаблоны элементарные написаны, и управление заказами, и политики безопасности настроены. В общем, более легкого варианта этой сборки не будет.
 

как там реализуется подключение модуля оплаты?

В следующей сборке будет оплата Робокасса. У меня есть свой модуль, прикручу.

А не пробовал устанавливать через консоль по ssh? Я уже говорил, что в новой версии Vapor-а есть файл import.php
 Загружаешь любой пакет (или снимок — это ведь тоже пакет) и выполняешь в консоли: php vapor/import.php package=core/packages/packagename-transport.zip Само собой имя пакета — твоего.
 И все. В большинстве случаев успешная установка (таймвеб — точно исключение, потому что за 100% загрузку процессора в течение 5-ти секунд — смерть процессу). Во всяком случае nginx здесь уже точно не отобьет (элементарно потому что его нет), да и для консольного php часто более демократичные настройки идут. Плюс к этому нет проблем с сессиями. Пакет shopmodx как я понял содержит только процессоры (без корзины). Да, shopModx — это только объекты да процессоры (в общих чертах). Но shopModx — это более крупное решение. Там и другие компоненты установлены, и шаблоны элементарные написаны, и управление заказами, и политики безопасности настроены. В общем, более легкого варианта этой сборки не будет. как там реализуется подключение модуля оплаты? В следующей сборке будет оплата Робокасса. У меня есть свой модуль, прикручу.

А не пробовал устанавливать через консоль по ssh? 

А когда ожидается новая версия? И будет ли она как-то совместима с текущей версией?

А когда ожидается новая версия? И будет ли она как

Скорее всего появится в течение пары недель.
 Обратной совместимости не будет. То есть это не пакет, который устанавливается методом обновления. Он устанавливается только на голый сайт (или имеющееся затрет вообще).
 Обратная совместимость есть только у выпускаемых публичных пакетов (shopModx, modxSmarty, phpTemplats) и т.п. То есть их всегда можно устанавливать поверх с большой долей вероятности. А сборка — это типовой сайт.
 

Я объясню почему такой подход — универсальные и обратносовместимые пакеты — это довольно трудоемкая задача (особенно чтобы обеспечить совместную работу с другими пакетами). Многие хорошие наработки не идут в массы только из-за сложности собрать качественный пакет (это не только меня касается. Знаю много других примеров). А по опыту могу сказать, что в большинстве случаев собранный индивидуальный сайт практически всегда индивидуально и развивается, без особых наблюдений за новыми релизами пакетов и т.п. (не редко встречаются сайты на старых движках). Поэтому сборка — это такой баланс «дешево и сердито». Один раз поставил, настроил — и забыл. Все равно ведь скачивая пакеты для MODX-а, вы все равно их настраиваете и т.п. Так что есть называть вещи своими именами, то народ больше интересует базовый функционал, а не обратная совместимость, то есть что уже имеется на борту, чтобы в дальнейшем и обновляться не надо было. 
 

В общем, сейчас со сборкой подход простой — скачали, попробовали, годится для текущего проекта? — значит используем. Не годится и нет желания докручивать? — не начинайте даже, не стоит рассчитывать на то, что выйдет новая сборка и можно будет обновиться, дополнив функционал.

Скорее всего появится в течение пары недель.
 Обратной совместимости не будет. То есть это не пакет, который устанавливается методом обновления. Он устанавливается только на голый сайт (или имеющееся затрет вообще).
 Обратная совместимость есть только у выпускаемых публичных пакетов (shopModx, modxSmarty, phpTemplats) и т.п. То есть их всегда можно устанавливать поверх с большой долей вероятности. А сборка — это типовой сайт. Я объясню почему такой подход — универсальные и обратносовместимые пакеты — это довольно трудоемкая задача (особенно чтобы обеспечить совместную работу с другими пакетами). Многие хорошие наработки не идут в массы только из-за сложности собрать качественный пакет (это не только меня касается. Знаю много других примеров). А по опыту могу сказать, что в большинстве случаев собранный индивидуальный сайт практически всегда индивидуально и развивается, без особых наблюдений за новыми релизами пакетов и т.п. (не редко встречаются сайты на старых движках). Поэтому сборка — это такой баланс «дешево и сердито». Один раз поставил, настроил — и забыл. Все равно ведь скачивая пакеты для MODX-а, вы все равно их настраиваете и т.п. Так что есть называть вещи своими именами, то народ больше интересует базовый функционал, а не обратная совместимость, то есть что уже имеется на борту, чтобы в дальнейшем и обновляться не надо было. В общем, сейчас со сборкой подход простой — скачали, попробовали, годится для текущего проекта? — значит используем. Не годится и нет желания докручивать? — не начинайте даже, не стоит рассчитывать на то, что выйдет новая сборка и можно будет обновиться, дополнив функционал.

Скорее всего появится в течение пары недель.
 Обра

На самом деле перенести несколько smarty-шаблонов, создать несколько TV-параметров, перенести img-css-js вот и весь сайт.
 Проблема только в импорте-экспорте документов. Правильно? Посоветуй, где почитать про импорт?

На самом деле перенести несколько smarty-шаблонов,

создать несколько TV-параметров, перенести img-css-js вот и весь сайт.

По большому счету да, тем более если все на Смарти-шаблонах и процессорах, а не на чанках и сниппетах.
 

Посоветуй, где почитать про импорт?

Я вообще вот так обычно делаю: modxclub.ru/blog/99.html
 

То есть если у вас все будет на Смарти и процессорах, то перенос особо не должен проблем вызвать:
 1. Разворачиваете новую сборку
 2. Переносите туда свои Смарти шаблоны, публичные шаблоны, картинки и т.п. (файлы)
 3. Следуете представленной инструкции (удаляете все шаблоны, документы, TV-параметры, пользователей, товары и т.п.) и заливаете свои данные.
 4. Далее только придется актуализировать процессоры.
 Это наверняка уже 90% выполненного импорта.

создать несколько TV-параметров, перенести img-css-js вот и весь сайт. По большому счету да, тем более если все на Смарти-шаблонах и процессорах, а не на чанках и сниппетах. Посоветуй, где почитать про импорт? Я вообще вот так обычно делаю: modxclub.ru/blog/99.html То есть если у вас все будет на Смарти и процессорах, то перенос особо не должен проблем вызвать:
 1. Разворачиваете новую сборку
 2. Переносите туда свои Смарти шаблоны, публичные шаблоны, картинки и т.п. (файлы)
 3. Следуете представленной инструкции (удаляете все шаблоны, документы, TV-параметры, пользователей, товары и т.п.) и заливаете свои данные.
 4. Далее только придется актуализировать процессоры.
 Это наверняка уже 90% выполненного импорта.

создать несколько TV-параметров, перенести img-css

понял. попробую.

Я вообще не это имел ввиду, но за это тоже спасибо. Думаю, что скоро пригодится.
 Где почитать по импорт документов из csv, xml и т.д.

Я вообще не это имел ввиду, но за это тоже спасибо

Публичного модуля импорта нет.

Здравствуйте, использую ваш код, ссылка /assets/components/gallery/connector.php?action=web/image/gallery/small&src=/assets/gallery/1/2.jpg"/> выдает сообщение {«success»:false,«message»:"\u0414\u043e\u0441\u0442\u0443\u043f \u0437\u0430\u043a\u0440\u044b\u0442.",«total»:0,«data»:[],«object»:{«code»:401}}. Как это можно исправить?

Здравствуйте, использую ваш код, ссылка /assets/co

1. Смотрите коннектор вызываемый. Там в паблике без проверки прав будет работать только для действия web/phpthumb.
 

2. В помощь: modxclub.ru/blog/voprosy-spetsyalistov/136.html

Здравствуйте. 1. Смотрите коннектор вызываемый. Там в паблике без проверки прав будет работать только для действия web/phpthumb. 2. В помощь: modxclub.ru/blog/voprosy-spetsyalistov/136.html

Здравствуйте. 1. Смотрите коннектор вызываемый. Та

Fi1osof Спасибо за чудесный плагин, все работает супер, но подскажите, как его можно использовать для обновления фото пользователя через фронтнд? Со сниппетом UpdateProfile? как бы его использовать через postHooks или pretHooks? Куда копать?

Fi1osof Спасибо за чудесный плагин, все работает с

Напишите свой сниппет и стандартную HTML-форму. Все, что вам нужно — это обновить профиль пользователя.
 

$profile = $modx->getObject('modUser', $id);
$profile->set('photo', $photo);
$profile->save();

Это вещи настолько тривиальные, что тут даже готовое решение не обязательно искать.

Напишите свой сниппет и стандартную HTML-форму. Все, что вам нужно — это обновить профиль пользователя. $profile = $modx->getObject('modUser', $id);
$profile->set('photo', $photo);
$profile->save(); Это вещи настолько тривиальные, что тут даже готовое решение не обязательно искать.

Напишите свой сниппет и стандартную HTML-форму. Вс

Спасибо за отличную плюшку, но есть ли возможность ещё чуть чуть её доработать для бэкэнда?
 Добавить к мёду ложку, так сказать)) Я имею ввиду — добавить выбор фотки не только на странице «Update User», но и на странице «Edit Account», чтобы все, кто имеет права на редактирование своего профиля мог менять свой аватар самостоятельно без дополнительных форм и сниппетов.
 Если такая возможность есть — подскажите пожалуйста как это можно сделать.

Спасибо за отличную плюшку, но есть ли возможность

Сорри, нет времени на это. Вряд ли появится в обозримом будущем. Да и нечего в админке делать всем подряд.