А phpThumbOf не стал ставить по умолчанию? Думаешь, редко кто будет использовать? Просто я, например, без него уже не могу — особенно списки дочерних документов с кратким описанием и картинкой…
 Плюс помимо страниц 404 и 401, думаю, надо добавить еще и sitemap.xml + robots.txt
 Я их всегда ресурсами делаю и о них после даже не задумываюсь. robots.txt у меня такой, например:
 
User-agent: *
Allow: /
Disallow: /core/
Disallow: /connectors/
Disallow: /manager/

Host: [[++site_url:replace=`http://== `:replace=`/== `]]
Sitemap: [[++site_url]]sitemap.xml

О, здорово! Хорошая вещь))) Спасибо)

Сайты-визитки — самый распространенный тип заказываемых сайтов. Тем не менее и под них приходится довольно многое делать на MODX-а (шаблоны создать, текстовый редактор настроить, чанки-сниппеты написать и т.п.). И только в последнюю очередь идет просто наполнение сайта. По опыту могу сказать, что до конечного наполнения сайта-визитки, только на ее первичную подготовку и разработку, может уйти и две, и три недели.
 
Сегодня я хочу анонсировать сборку, которая уже решает процентов 80 задач, связанных с первичными работами по разработке сайта-визитки.
 
Список того, что вошло в сборку:
 Пакеты:
 
Ace 1.3.3-pl
Console 2.0.0-rc
modxSite 1.0.0-rc
modxSmarty 0.0.5-beta
phpTemplates 1.4.0-rc
TinyMCE 4.3.3-pl
Wayfinder 2.3.3-pl
getResource 1.6.0-pl
getPage 1.2.3-pl
DirectResize 1.3.1-rc1 (настроен через набор параметров на ресайз картинок только из папки assest/images/resizable/ и ее вложенных папок)
Translit 1.0.0-beta
Сниппеты:
 
templates.pagetitle — возвращает комплексный титл страницы.
 
Плагины:
 
Debug
memory_get_usage
Медиа-источники:
 
Images — для картинок (в системе установлен по умолчанию)
Files — для файлов.
Controllers — для контроллеров (статических MODX-шаблонов с выполняемым php-кодом).
Templates — Smarty-шаблоны.
Наборы параметров:
 
DirectResize
Созданы страницы по умолчанию:
 
404 — Страница не найдена
401 — Доступ запрещен
Изменены системные настройки:
 
Источник файлов по умолчанию — Images (id)
Публиковать по умолчанию — Да
Использовать дружественные URL — Да
Использовать вложенные URL — Да
Транслитерация псевдонимов — russian
Страница ошибки 404 «Документ не найден» — id страницы
Страница ошибки 401 «Доступ запрещен» — id страницы
Максимальный размер загрузки — 10000000 (modxcloud позволяет заливать файлы до 10 Мб).
Прочее:
 
Добавлена группа ресурсов «Для зарегистрированных пользователей».
Добавлена группа пользователей «Зарегистрированные пользователи».
Настроены политики доступов зарегистрированных пользователей к закрытым документам и вывод страницы «Доступ запрещен» для не авторизованных пользователей.
Модифицированны сборщик пакетов Vapor с проверкой доступов (по сути рассчитан только на выполнение sudo-пользователями) и архивированием папки manager/components/ (modxcloud пока архивируют без этой папки. что не есть хорошо).
Настроены правила .gitignore
После установки данной сборки, вы уже получаете все необходимое для разработки сайта. Останется только дописать какие-то специфические сниппеты, сверстать и наполнить сайт. Все для этого уже готово.
 Снапшот доступен по этой ссылке: modxclub.ru/downloads/sborki/sajt-vizitka/versiya-0.0.1-beta.zip (только для полноправных членов Клуба). 
 Разворачивайте из него сайт на http://modxcloud.com, и в путь :-)
 
Видео установки сайта из снапшота.
 
 
Кто готов попробовать, говорите, я вам дам на облаке доступ, быстренько клонируете себе этот сайт. Только в профиле укажите свой MODX-аккаунт.

На modxcloud.com этот вопрос легко решается просисыванием nginx-правил для конкретного облака. Пример:
 
if($http_host != 'mydomain.ru'){
  return 301 mydomain.ru$request_uri;
 }

Алишер, привет!
 По мультиязычности можно будет на днях провести совместную он-лайн конференцию.
 А пока немного информации: MODX очень хорошо поддерживает мультиязычность, и дает несколько вариантов решения. Для оптимального выбора в основном надо ориентироваться на уникальность структуры сайтов на разных языках и как много полей у создаваемых документов. Если на разных языках сайты будут отличаться по структуре, то лучше всего это делать на разных контекстах с уникальными документами для каждого сайта в отдельности. Если же структура везде одинаковая, только языковые поля будут отличаться по содержанию, то однозначно лучше создавать TV-параметры под разные языки, и в одном документе сразу наполнять тексты на разных языках в разных полях.
 А глобально по всему сайту текущий язык определять по системной переменной cultureKey.
$modx->getOption('cultureKey', null, 'ru');
Или [[++cultureKey]] в чанках. Или в Смарти {config name=cultureKey}

Существует такое понятие, как корневой домен, соответственно, в конце каждого домена есть точка. Возможно, вы и не подозреваете, что ваш сайт доступен по доменному имени с точкой в конце (domain.zone.), так как браузеры позволяют обращаться к сайтам, как с точкой в конце домена, так и без неё.
 
Полная статья: habrahabr.ru/post/172999/

Валерий, ты все правильно говоришь. Это потому что ты и специалист, и представитель заказчика со стажем. То есть ты и техническую сторону понимаешь, и роль заказчика на себе прочувствовал.
 И я действительно как раз эти цели перед собой и ставлю. Не зря же я всю ночь докручивал свой modLivestreet, чтобы не просто обеспечить статус страницам скрыт/не скрыт, а именно обеспечить уровни доступов на уровне ACL MODX-а. У нас уже на этом сайте настроены групповые политики, чтобы не просто распределить людей на программист/не программист, а еще и рулить кто куда какой доступ имеет. То есть и будут тимлиды, и проджект-менеджеры, и рядовые исполнители и т.п. И именно поэтому я добавил в профили типовые поля контактов, необходимые для работы (гит, битбканет, modxcloud).
 Но наша сегодняшняя проблема заключается в распределенности технологий. То есть modxcloud обеспечивает хостинг с фишками для разработки. Битбакет — трекер и гит-репозиторий. И на битбакете, и на modxcloud если политики доступов, можно расшаривать проекты и т.п. Но минус заключается в том, что для выполнения каких-то задач приходится переходить именно туда. То есть хочешь создать проект — идешь на битбакет, кликаешь Создать (там же трекер), создал новый тикет здесь, программист откликнулся, с заказчиком они договорились, заказчик посмотрел у него в профиле аккаунт на битбакете, у себя в панели на битбакете дал доступ программисту (если проект не новый и работы уже велись ранее, программист сможет увидеть, что и как раньше выполнялось), а делать это все он будет на modxcloud. Как бы все единое и в рамках одного бизнеспроцесса, на на трех системах. И вот я как раз хочу это доработать. На битбакете вроде есть API. Если мы настроим отсюда, то не придется переходить на битбакет, все взаимодействия клиента со специалистами будут проходить здесь.
 
Между заказчиком и разработчиком очень часто нехватает так сказать «руководителя проекта сайта» — это необхимый элемент для того, чтобы можно было гарантировать 100% качество исполнения проекта и возможность поддержки проекта в любое время и на любом этапе дальнейшего развития.
Здесь дело не только в непонимании. MODX — очень мощная система, но она не накладывает никаких стандартов. Сколько программистов, столько методов разработки. Каждый проект на MODX — отдельная уникальная система. Здесь мы будем вырабатывать единые стандарты разработки. Сайты не будут сразу выполняться на чистом MODX-е. Сначала разрабатывается сборка-база для разработки типовых решений, и только потом на ней выполняется конкретный сайт. То есть если это сайт-визитка, то большинство таких сайтов отличаются только дизайном и структурой документов (которые создаются через дерево документов в админке). То есть правильный сайт-визитка вообще не должен разрабатываться. Берется движок, в шаблонизации создается новый шаблон, натягивается новый дизайн и наполняется сайт. Все. 100 сайтов-визиток, а движок один. Посмотрел как в нем что сделано, знаешь как сделаны все эти 100 сайтов.
 Если это магазин — то создается движок магазина. Понятно, что на индивидуальных проектах могут быть доработки, но и доработки в пакеты можно оформлять. Здесь у нас будет репозиторий пакетов, все будет храниться в одном месте. Все будет документироваться. Использование единых стандартов и методик исключит большинство типовых проблем.
 
Другой вариант — это сделать клуб только для внутреннего использования разработчиками.
Нет, не стоит. Мы может тематически разграничить области сайта, так, чтобы клиенты видели больше информации для клиентов, а программисты для программистов. Но все должны быть в одной информационной системе, так как и у клиентов есть необходимость обмениваться опытом и учиться. Ведь для кого-то порой просто вставить картинку может оказаться проблема. А так уже один клиент что-то спросил, ему ответили, и другие клиенты для себя могут что-то новое узнать. Я последнее время часто на вопросы клиентов видеоролики снимаю что и как делается, буду здесь выкладывать.

Именно для этого клуб и создается, чтобы решать эти резонные проблемы. У меня много очень много опыта и в разработках, и проджект-менеджменте, и пока во главе всего буду я. Но я очень надеюсь, что совсем скоро появятся и другие тимлиды, и проект-менеджеры, и четко определенные узкопрофильные специалисты — эксперты в своей области.
 Задач много, и все их решать надо будет командно. Я создаю сейчас первичные инструменты, дальше уже совместно развиваться будем.
 Вот к примеру этот сайт: на нем уже заведены различные группы пользователей, и постепенно будет наполнено много четко определенных групп, чтобы легко можно было посмотреть сколько у нас программистов, сколько верстальщиков, сколько дизайнеров, копирайтеров и т.д.
 Далее modxcloud.com: вот у меня есть сайты клиента, придет новый разработчик, которые готов будет взяться за доработки. Мне не придется пускать его на боевой сайт, и потом смотреть что он натворит. Я просто отправлю ему клон облака в 3 клика, и он будет делать на копии сайта. То есть если все хорошо, то наработка полностью совместима с оригинальным сайтом, и ее легко будет накатить на боевой, или просто переключиться на новую версию сайта.
 На битбакете (будет нашим основным гит-сервером) так же все рулится с распределением по группам пользователей. Там же трекер. Будем на вооружение и новые полезные инструменты брать.

В данном ролике показано как вставлять картинки на страницы сайта.
 

Полностью поддерживаю цели клуба. Но для практической реализации нужно более четко разобраться в механике задачи :)
 
Между заказчиком и разработчиком очень часто нехватает так сказать «руководителя проекта сайта» — это необхимый элемент для того, чтобы можно было гарантировать 100% качество исполнения проекта и возможность поддержки проекта в любое время и на любом этапе дальнейшего развития. Заказчик часто не понимает технических ньюансов, влияющих на весь проект в целом (и его дальнейшую судьбу), которые нужно продумывать изначально. Разработчика обычно это не заботит, сделал что сказали (зачастую на скорую руку и через одно место) — получил деньги, и забыл. Ни о какой грамотной реализации и дальнейшей поддержке никто не задумывается.
 По-хорошему надо чтобы все заказчики были проинформированы об этой ситуации, чтобы было сформировано новое общественное мнение о том, как надо делать сайты и что для этого нужно.
 
Конечно, заказчикам бывают нужны также и дизайнеры, и SEO-специалисты — и их работа по-хорошему тоже должна быть согласована с техническими ньансами проекта. И если мы хотим сформировать грамотное создание и 24/7 поддержку любых проектов в рамках клуба — то необходима координация и трэкинг всех, кто задействован в проекте. Связки «заказчик-программист» — недостаточно.
 
Было бы супер сделать этот клуб как полноценную систему ведения проектов, с тесной интеграцией с MODx Cloud. Необходимы «роли» и «политики доступа».
 
Заказчик создает проект — объявляется конкурс на роль «руководитель проекта». Как только он определяется — уже руководитель проекта формирует тикеты на другие задачи, к которым выбираются другие исполнители (программист, дизайнер, seo-оптимизатор — при этом дизайнерам и seo не обязательно быть в клубе, их можно будет добавлять как «внешнего исполнителя», с указанием контактов). В дальнейшем любого исполнителя (в т.ч. и руководителя проекта) можно будет изменить, но в системе будет вся история этих изменений — таким образом, новый исполнитель всегда сможет контактировать с предыдущим для решения некоторых вопросов. Недобросовестные исполнители будут забанены, а т.к. клуб закрытый — то таких будут единицы, если вообще будут. Соответственно система будет гарантировать заказчику качество и эффективность работ любого вида по его проекту.
 
Другой вариант — это сделать клуб только для внутреннего использования разработчиками. Тогда вместо самих заказчиков здесь проекты создавать будут «руководители проекта». Сами же заказчики в этом случае непосредственно в клубе участвовать не должны.