Вообще да. Причем сразу лучше эту готовую сборку, так как там уже настроены на совместную работу modxSite, shopModx, phpTemplates, modxSmarty и прочие тонкости. Эти пакеты сами по себе очень не плохие, но максимальный эффект именно от совместного использования получаешь.
 А там уже технологии освоишь и без проблем в modSociety разберешься, потому что принципы те же используются.

То есть надо сразу щупать ShopModx?

Дай я тебя расцелую за это.

Народ, сегодня я хочу к вам обратиться с призывом!
 
В последнее время я все чаще и чаще слышу от MODX-разработчиков о том, что MODX очень сильно теряет в популярности именно из-за того, что некоторые популярные пакеты создают кошмарное представление о самом MODX-е. Простой пример: некто ставит MODX Revolution (все мы знаем, что это отличная платформа, и здесь вообще вопросов никаких нет). Но ведь самой голой системы не достаточно. Надо же поставить необходимые модули, чтобы выводить новости, развернуть магазин и т.п. И вот как по вашему должен реагировать разработчик, когда он ставит пару пакетов, в которых десятки тысяч строк кода, в которых черт ногу сломит, а еще и все ужасно тормозит?! Реакция очевидная. И в результате мы имеем уже очень низкий рейтинг самого MODX-а. Сам лично уже не раз наблюдал фразы типа «ставим минус просто за то, что это MODX».
 
Пришло время кардинально это дело поменять. И мы можем это сделать.
 
Корень зла и всех бед — это повсеместное использование чанков и сниппетов (в общем все то, о чем я говорил много раз уже). Разработанные и используемые мной в каждом новом проекте пакеты типа phpTemplates — это решения, позволяющие значительно увеличить производительность, а так же облегчить сопровождение MODX-проекта.  
 
Приведу список с краткими описаниями этих пакетов:
 1) phpTemplates — позволяет использовать статические MODX-шаблоны как обычные php-файлы. То есть с использованием phpTemplates мы не просто храним некий статический код в шаблоне, а получаем нужную нам php-логику еще на уровне шаблона. А здесь мы можем уже и сторонний шаблонизатор использовать, и просто php-код выполнить, и отдать на вывод конечный результат, который будет закеширован MODX-ом, и в дальнейшем будет отдаваться как простой HTML-код, без лишнего парсинга. Таким образом наши шаблоны превращаются в контроллеры, а шаблонизация уже уходит на уровень специализированной системы шаблонов.
 
2) modxSmarty — специально адаптированный для MODX шаблонизатор Smarty. В Smarty-шаблонах вы можете использовать как нативные MODX-теги, типа [[Wayfinder]], так и специально написанные для Smarty теги типа {snippet name=Wayfinder}. В чем разница и какой смысл от этого?
 1. Производительность. Когда вы используете классический [[Wayfinder]], то этот тег сначала должен быть найден MODX-парсером (строковые операции), затем парсер его разбирает на предмет параметров и т.п., затем находит и инициализирует объект (modSnippet), получает результат выполнения этого сниппета, затем делает реплейс MODX-тега в общем коде вывода этим результатом, а в итоге еще и записывает это все по отдельности в кеш документа (то есть не сразу конечный код, а тег отдельно, результат его отдельно).
 К примеру, вот кусочек кеша документа:
 
'_content' => '<!DOCTYPE html>
<html lang="ru-RU">
<head>
	<title>[[*pagetitle]]</title>
    
    <!-- base xhtml4 -->
	<base href="http://btj.fi1osof.modxcloud.com/" />
	<meta name="robots" content="noindex, nofollow" />
	<link rel="canonical" href="http://btj.fi1osof.modxcloud.com/common/404.html" />
	<meta http-equiv="content-language" content="ru" />
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
	<meta http-equiv="pragma" content="cache" />
	<meta http-equiv="cache-control" content="cache" />
	<meta http-equiv="Content-Style-Type" content="text/css" />
	<meta http-equiv="Content-Script-Type" content="text/javascript" />
<!-- meta -->
	<meta name="keywords" content="[[$AllKeywords:notempty=`[[$AllKeywords:strip]], `]]" />
Это кеш документа, в шаблоне которого используются кешируемые MODX-теги. При этом, как видите, эти кешируемые теги на месте. То есть не конечный код на их месте, а именно сами теги. А значения этих тегов отдельно. Вот кусочек:
 
'elementCache' => 
  array (
    '[[*contentType:lcase]]' => 'text/html',
    '[[*keywords:strip]]' => '',
    '[[*description:strip]]' => '',
    '[[*description:notempty=`<meta name="description" content="" />`]]' => '',
    '[[%page_not_found]]' => 'Страница не найдена',
    '[[*longtitle:replace=`<br />== `:replace=`
== `:striptags]]' => 'Страница не найдена',
То есть, даже если документ полностью закеширован, все равно при каждом заходе на страницу, MODX будет делать разбор кеша с целью поиска тегов и замещения их результатами (опять-таки куча строковых операций, инициализаций объектов и т.п.).
 Все еще удивляетесь почему ваш MODX-сайт тормозит?
 
А что делает modxSmarty? Когда тег обрабатывается на уровне Smarty, типа {snippet name=Wayfinder}, тогда результат выполнения сразу же попадает в вывод уже в виде конечного HTML-кода. То есть в кеш документа в _content уже будет записан HTML-код без MODX-тегов. А значит MODX-парсер будет значительно разгружен, ему не придется обрабатывать кучу тегов, реплейсить их результатами и т.п. Поверьте, что нагрузка снижается в разы сразу.
 
2. Более гибкая шаблонизация. Здесь бы сразу отметил две очень важные фишки: расширение шаблонов (чего нет в MODX-е в принципе) и практически полная поддержка php-функций (то есть так необходимые циклы, условия, форматирование и т.п.).
 Плюс ко всему еще и полная поддержка объекта $modx. К примеру, в шаблоне вы легко можете выполнить вот так:
 
{foreach $modx->resource->getMany('Children') as $child}
    <br />Название дочернего документа: {$child->pagetitle}
{/foreach}

Такую простую операцию вы в MODX-е без использования дополнительного сниппета в чанке не сделаете. А это дополнительные объекты, память, время.
 
3) shopModx. Не смотря на то, что это модуль для создания интернет-магазинов на MODX Revolution, я использую его во всех своих текущих проектах. Точнее не сам модуль, а входящие в него list-процессоры (я так называю процессоры, предназначенные для выборки данных объектов). Так вот, в состав shopModx-а входит getdata-процессор, который делает выборку не только документов, но и всех их TV-параметров, и возвращает результат в виде очень удобного массива (все TV-параметры идут в ключе tvs). И вот эти процессоры очень удобно выполнять в Smarty-шаблонах и выводить результат (хотя можно конечно и с ниппетах и в плагинах вызывать эти процессоры через $modx->runProcessor(), но все-таки львиная доля вызовов приходится на Smarty-шаблоны). Вот пример:
 
{processor action="web/getdata" ns="mynamespace" params="param1=`data`¶m2=`data`" assign=result}


{* Проверим права на просмотр отладочной информации *}
{if $modx->hasPermission('debug')}
    {* Посмотрим на все данные ответа *}
    <pre>{print_r($result)}</pre>
{/if}

{if $result.success}
    {* Выведем результат *}
    {foreach $result.object as $object}
        <div>
            ID документа: {$object.object_id}<br />
            Заголовок документа: {$object.pagetitle}<br />
            Опубликован: {date('Y-m-d', $object.publishedon)}
            
            <h2>TV-параметры:</h2>
            {foreach $object.tvs as $tv_name  => $tv}
                Название TV-поля: {$tv_name}<br />
                ID: {$tv.tv_id}<br />
                Значение: {$tv.value}
            {/foreach}
        <div>
    {/foreach}
{else}
    Error: $result.message
{if}

И здесь можно с этим делать все, что угодно.
 
Но дело не только в удобстве (включая расширение процессоров и т.п.). Дело еще и в производительности. Выборку 500 документов за раз делает менее чем за 0,01 сек.
 
4) Console. Это один из самых простых моих пакетов, и при этом один из самых полезных :-) Он позволяет в админке выполнять произвольный php-код с полной поддержкой MODX-окружения. То есть можно сделать выборку документов, модифицировать их, сохранить и т.п. Так же можно выполнить сниппеты, процессоры и т.д. и т.п. В общем все, что угодно.
 Но еще я его вот как использую: я часто на сайте пишу собственные формы на Smarty+процессоры, а не использую eForm или типа того. При этом в вызов процессора в качестве параметров передается $smarty.post или $smarty.get (в зависимости от задачи). То есть на уровне процессора эти параметры доступны через $this->getProperies() и $this->getProperty($property). А это значит, что процессор себя будет вести точно так же, если я его буду вызывать в консоли с передачей в него произвольного массива параметров, типа $modx->runProcessor($action, $properties);
 В общем, отладкой форм я занимаюсь прям в консоли, получая все ошибки и т.п., не тратя время на перезагрузку страницы, повторное заполнение формы и т.п.
 Плюс такого подхода еще заключается и в том, что обработчик формы становится полностью универсальным, и его можно хоть со страницы вызывать, хоть через коннектор, хоть через плагин и т.п. Везде логика будет одна и та же, только вывод меняй при необходимости.
 
Резюме
В общем, я твердо убежден, что эти технологии позволят использовать MODX Revolution более качественно и выгодно. И сейчас надо просто сделать так, чтобы об этих технологиях узнало побольше MODX-еров и начали брать их на вооружение. И вы можете этому помочь: ставьте «лайки» этим пакетам на modx.com (им не много надо для выхода в ТОП), да и сами берите на вооружение.
 
Любые вопросы по ним можете задавать здесь.

А на самом деле клева получается. Во-первых, исключается человеческий фактор (не надо учить менеджеров что делать. Один раз прогнал все документы, а потом при любом сохранении документа обновляется превьюха). Во-вторых, идет как чистая статика, сервер вообще не грузится.

ОК. Завтра сделаю.

Да это старая тема :) ShopModx по своей природе более поздний продукт.

Доброго времени суток, Иван!
 Топик вынес на главную. Но вообще это старая тема, просто переношу свои старые топики с коммунити.
 А вообще тема требует развития, и оно обязательно будет. Просто сейчас я плотно развиваю eCommerce в лице shopModx, но движок для социалок также в обязательном порядке будет доведен до ума.
 
Есть ли какие-либо обязательные расширения для того, чтобы все заработало? (GetResources и.т.п?)
Нет. Ничего такого не требуется. Но подобные пакеты так же могут вам в чем-то помочь. Это все равно, как вы можете и без getResources обойтись, и самостоятельно вывести список дочерних документов, но все равно используете getResources, просто потому что так легче. Но в целом все мои решения рассчитаны все-таки на использование API MODX.

верни статью на этот сайт

радикально. у меня тут пара сотен страниц с вызовом phpThumbOf завалялась, а на каждой по 16-30 мегабайтных картинок уже есть и переделывать их реально в ломы, проще сервер купить (что и сделано было)=)
 
воспользуюсь информацией позже, спасибо.