вторник, 13 октября 2015 г.

Epic Tumblr Stats - сервис для отображения статистики блога Tumblr

За пару дней сваял прототип веб сервиса с функционалом, которого мне так не хватает в Tumblr, а конкретно: отображение полной статистики по моим блогам(а у меня их четыре) в одном месте. Даже если был бы только один блог - всеравно на Tumblr не удобно просматривать статистику:
Плохо видно сколько с последнего посещения прибавилось подписчиков, из популярных постов виден только один, нельзя просмотреть статистику за все время - максимум за последний месяц. И самое главное: нет возможности проанализировать в какое время и с какими тегами лучше выкладывать посты, что я и собираюсь реализовать в своем веб сервисе в ближайшее время.
Такой функционал был бы полезен как SMM-щикам, так и обычным пользователям, которым интересно набирать популярность своего блога.

На скрине виден функцонал, который доступен когда вы вошли в сервис со своего Tumblr аккаунта.
Если же у вас нет аккаунта, то вы можете ввести в соответствующее поле на главной имя интересующего блога и посмотреть статистику по нему.
В тоже время в своем блоге опубликовал запись с рекламированием сервиса, но пока-что безуспешно. Очень надеюсь что скоро появятся пользователи, которым будет интересно пользоваться сервисом и развивать его своими идеями и поддержкой.
Читать далее

вторник, 15 сентября 2015 г.

MODX - Перенос сайта на хостинг клиента

 Требования к хостингу:
  • Расширения PHP:
    • zlib
    • hash
    • JSON (or PECL library)
    • mod_rewrite (for friendly URLs/.htaccess)
    • GD lib (required for captcha and file browser)
    • PDO, specifically pdo_mysql (for xPDO)
    • ImageMagick (for thumbnails)
    • SimpleXML
    • cURL (for Package Management)
  • Настройки PHP:
    • safe_mode off
    • register_globals off
    • magic_quotes_gpc off
    • php-mbstring on (required on some extras like Gallery)
    • PHP memory_limit 24MB or more, depending on your server
Алгоритм переноса:
  1. Чистим всё через админку ModX. 
    1. Управление - Обновить сайт.
    2. Управление - Снять блокировки. 
    3. Управление - Перезагрузить права доступа.
    4. Завершить все сеансы. 
    5. Чистим папку core/cache, либо cd .../docs/core/cache, rm -rf ./*, либо через FTP, либо оставляем на следующий шаг.
  2. Переносим файлы
    1. Пакуем всё в ZIP архив: cd .../docs, zip -r -9 sitename.zip *
    2. Переносим sitename.zip в каталог нового хостинга, распаковываем в админке хостинга.
    3. Если не удалили кеш ранее, заходим в /core/cache и удаляем. (Лучше проверить наличие содержимого папки с кешем в любом случае, вдруг кто-то успел зайти на сайт после очистки).
  3. Переносим таблицы.
    1. Открываем PhpMyAdmin у себя, открываем базу, экспортируем(можно установить сжатие в zip) нашу базу в файл, скачиваем.
    2. Создаём у хостера новые базу и пользователя(копируем их данные чтобы потом записать в конфиг).
    3. Заходим у хостера в phpMyAdmin и заходим в базу. Импортируем в новую БД наш файл с табличками.
  4. Редактируем core/config/config.inc.php
    1. Меняем пути в файле конфигурации с путей старого хостинга (например /var/www/sitename.ru/docs/) на пути нового (например /home/sitename/sitename.ru/docs/).
    2. Меняем строки соединения с базой данных, переписывая новыми данными.
  5. Переустановка
    1. Проверяем на наличие каталога setup на новом хостинге, если нет то скачиваем тот же дистрибутив MODX, закидываем на хостинг, и из него копируем папку setup в корень.
    2. Открываем .../sitename.ru/docs/setup/index.php в блокноте, добавляем куда-нибудь error_reporting(E_ALL); ini_set('display_errors', 1);
    3. Открываем в браузере sitename.ru/setup/. Выбираем существующую установку. Если хостер поотрубал нам модули, необходимые для работы и сыплются ошибки вроде PDO::__construct cannot find file... или что-то подобное - идём в настройки модулей у хостера, переходим в настройку PHP, и проверяем на наличие подключенных модулей из начала статьи.
    4. Пробуем снова открыть /setup, выбрать язык, далее, далее, в отчете о переустановке все сообщения должны гореть зелёным. Если не может соединиться с базой - проверяем файл конфигурации core/config/config.inc.php и данные связи с базой. Если будет ошибка в модулях - должен выводить ошибку наверху страницы.
    5. Если вылазиет просто ошибка 500(без подробностей), то идем в /core/cache/logs/error.log и проверяем его на наличие ошибок, действуем по обстоятельствам.
    6. Производим установку. Файлы установки на всякий случай не удаляем. 
  6. Проверка сайта
    1. Крестимся и переходим по ссылке авторизации. Ещё раз крестимся и вводим логин и пароль, который использовался на dev-хостинге.
    2. Если крест животворящий помог, значит вас должно пустить в админку. Если начнёт говорить что action not found или что-то подобное - вы забили на шаг с очисткой кеша. Чистите и пробуйте ещё раз.
    3. Если после установки появляются ошибки вроде неожиданной скобки [, это значит что хостер застрял в прошлом и не в состоянии обновить РНР до нормальной версии. Ну или кто-то слишком ленив, чтобы создавать массивы через array(). Исправляйте код через БД.
    4. Если после установки сайт выдаёт 500 - что-то неверно в конфигурационных файлах. Проверяйте соединение с базой данных в первую очередь и пути к файлам.
Инструкция создана по мотивам инструкции от Егора Приставки, и с его неоценимой помощью :).
Читать далее

четверг, 3 сентября 2015 г.

MIGX DB - Как создать свои объекты с таблицами БД в MODX

В MODX есть удобная возможность создавать свои классы, ассоциировать их с таблицами в базе данных и хранить там коллекции данных оперируя ими как объектами в ООП.
К тому-же ими можно удобно управлять контент менеджерам сайта с помощью MIGX DB через странички админки, которые можно довольно быстро создать:

Для этого в MODX нужно создать свой пакет(package), добавить туда схему модели в xml файле, спарсить эту схему, создать таблицу в БД и подключить этот пакет для работы. На самом деле в ручную все это делать довольно долго и есть возможность допустить кучу ошибок, поэтому лучше воспользоваться менеджером пакетов MIGX:


Первым делом создаем новый пакет(package), после создания мы сможем его увидеть в списке папок внутри core->components.  После создания пакета нужно написать свою XML схему(или взять мой пример), которая представляет из себя один класс(<object>) или набор классов внутри модели(<model>) с полями(<field>). Именно с этими полями мы сможем потом работать в сниппете или плагине примерно таким образом:

$student = $modx->getObject('myStudent',array('id'=>2));
$name = $student->get('name');

В схеме прописываем:
model package - имя пакета, то-же самое что написали в "Package Name" наверху;
object class - имя класса нашего объекта;
object table - имя таблички в БД, где будут храниться наши объекты;
field key - имя поля нашего объекта;
field dbtype - тип поля(int, varchar, text, datetime и т.д.);
field default - значение по умолчанию для поля;
aggregate alias - имя связи(например University), которую мы сможем использовать подобным образом:
$university = $student->getOne('University');
aggregate class - класс объекта связи;
aggregate local - имя локального id поля для связи с объектом;
aggregate foreign - имя id объекта связи(в большинстве случаев то поле, которое хранит id-шник нашего объекта для связи);
aggregate cardinality - вид связи(one, many);
aggregate owner - указание объекту: кто тут главный(в случае связи Университет - Студенты: главный университет);

Я рекомендую не писать заново схему, а скопировать уже существующую(например из моего примера) и изменить на свой лад.
Кстати благодаря object extends="xPDOSimpleObject", а не xPDOObject в объект автоматически добавляется поле id. Вообще наследовать объект можно от любого класса, благодаря чему в объект попадут все поля от наследуемого класса.

Когда сохраняем XML схему, да и когда проводим другие операции над нашим пакетом в менеджере MIGX нужно следить за тем, чтобы в поле "Package Name" было написано имя именно того пакета, над которым мы проводим операции.
Следующим шагом будет parse Schema на соответствующей вкладке:

После этого нам остается только создать таблицу в БД:

Теперь можно заглянуть в PHPMyAdmin и проверить наличие наших табличек в БД:


Вот и все, необходимый минимум выполнен, теперь мы из кода можем добавить в любую из табличек объект, сохранить его там, а после, в нужный момент получить с помощью подобного кода:

$modx->addPackage('mypackage', MODX_BASE_PATH . 'core/components/mypackage/model/', 'modx_');

$university = $modx->newObject('myUniversity');
$university->set('name', 'Тихоокеанский Государтсвенный университет');
$university->set('abb', 'ТОГУ');
$university->save();

$petrov = $modx->newObject('myStudent');
$petrov->set('fullname', 'Иванов Иван');
$petrov->set('university', $university->get('id'));
$petrov->save();

$ivanov = $modx->newObject('myStudent');
$ivanov->set('fullname', 'Петров Петр');
$ivanov->set('university', $university->get('id'));
$ivanov->save();

Этот код можно, например, выполнить в консоле.
После выполнения записи добавятся в БД:
Вы наверно заметили ту некрасивую строчку($modx->addPackage) в начале нашего кода, она нужна для подключения нашего пакета со всеми его классами. Можно организовать автоматическое подключение пакета, если в настройках системы прописать для extension_packages:
[{...здесь уже что-то есть...},{"mypackage":{"path":"[[++core_path]]components/mypackage/model/"}}]
Более подробнее тут.
После этого строчка $modx->addPackage будет не нужна и мы будет использовать наши новык классы как родные MODX-овские (типа modResource или modUser) без лишних манипуляций.

Теперь, когда мы проверили что все работает как надо, можно создать страницы для работы с этими табличками в админке MODX. Для этого заходим в Меню:
Примечание: в старой версии MODX пункт "Меню" назывался "Действия".

На странице "Меню" выбираем родителя, куда мы добавим новый пункт меню - "Верхнее меню" и добавляем пункт students-and-universities, прописывая указанные параметры:

После сохранения в MIGX в верхней меню появляется новый пункт students-and-universities (позже можно зайти в управление словарями и присвоить этому ключу в пространстве migx и языке ru подходящее значение для вывода):

Пункт меню будет направлять нас на страничку по адресу, оканчивающемуся на &configs=students||universities (потому-что именно это мы и прописали при создании), по нему очевидно что на странице должно что-то отображаться с помощью каких-то конфигов. Все встает на свои места когда мы заходим в MIGX(или Приложения->MIGX) на вкладку MIGX:


Именно здесь должны располагаться наши конфиги, которые наша страница для работы с БД будет использовать для отображения и вообще работы в целом. Я описывал в своей прошлой статье по MIGX создание этих конфигов и использование их как TV в ресурсах, но конфиги для MIGX DB будут отличаться дополнительными настройками для связи с БД и дополнительным описанием.
Здесь подготовлен конфиг по модели Студента, если экспортируете его и зайдете посмотрите через GUI менеджер то увидете на вкладке Migxdb-Settings настройки для подключения к нашему классу myStudent:

А на вкладке CMP-Settings можно настроить надписи для нашей странички управления записями БД:

Так-же в колонках(Columns) нужно добавлять id,deleted и published для корректной работы редактирования, удаления в корзину и публикации.
Конфигурацию для университетов попробуйте создать сами, можно на основе конфигурации Студентов заменив класс и надписи в настройках и убрав лишние поля оставив только name.
Так-же при создании конфигураций стоит прописывать им unique MIGX ID: поле которого находится в первой вкладке Settings, и который должен быть уникален у каждой конфигураций(я прописываю таким-же как и имя у конфигурации).
Теперь когда мы создали наши конфигурации, присовили им имена, unique MIGX ID и настроили MIGX DB у каждой из них, можно зайти на страничку students-and-universities и посмотреть список наших студентов:
Вывод имени университета обеспечивается с помощью настроек Joins на вкладке Migxdb-Settings в менеджере MIGX:
И колонки с Field: University_name, где University - это alias связи <aggregate> в xml схеме нашей модели, а name - это поле внутри object myUniversity.
Если вы попробуйте зайти в редактирование студента, то увидите что выбор университета так-же работает:
Он работает с помощью input TV type: listbox и @SELECT в Input Option Values:
Для сравнения я добавил так-же поле mod_user, которое берет inputTV: select-user(вам следует его создать как новый TV у себя в MODX если хотите протестировать), который так-же обеспечивает выбор из обьектов БД по принципу, который я описывал в этой статье.
В отличие от выбора университета, выбор пользователя работает со строкой поиска что часто очень полезно при работе с БД. К сожалению я не смог найти как добиться такой-же функции у input TV type: listbox.

Теперь когда объекты лежат в Базе Данных и ждут своего часа мы можем выводить их на страницах нашего сайта с помощью migxLoopCollection , который уже находится в пакете MIGX. Примеры использования можно посмотреть здесь и здесь.
Или самостоятельно получать через сниппеты с помощью $collection = $modx->getCollection('myUniversity', array('deleted'=>0));

Обяснение почему нужно наследоваться от xPDOSimpleObject
Документация MIGX по созданию такой-же странички для управления записями в БД "Doodles Manager"
Документация по созданию модели xpdo обьектов MODX
Примеры моделей и запросов xpdo обьектов MODX
Видео туториал по созданию подобной странички
Инструкция по добавлению пользовательских обьектов в MODX
Примеры использования Joins 
Конфигурация MIGX CMP для One to Many схемы
Читать далее

воскресенье, 30 августа 2015 г.

MODX Ограничение доступа к источнику файлов. Каталог upload.

При подготовке сайта к использованию контент менеджером следует опасаться того, что им открыт доступ к файлам ядра системы и прочим жизнено важным файлам сайта, которые случайно могут удалиться/переместиться/похититься пришельцами.
Чтобы избежать таких неприятностей следует создать пользователя content_manager(например) и выделить ему папку upload для того чтобы он использовал её в качестве хранилища файлов, и не мог ничего натворить за её пределами.
В итоге должно получиться что-то типа этого:
Для того чтобы этого добиться сперва создадим папку upload:

После этого создадим источник файлов "Upload". Для этого заходим в Медиа => Источники файлов, и там создаем его:
После чего заходим на страницу редактирования и указываем пути к папке upload:

Ну вот, мы добились того, что у нас сейчас есть два источника файлов: FileSystem - с полным доступ к файлам с корня каталога сайта, и Upload - с доступом к файлам с папки upload, в этом можно убедиться создав или закинув в папку upload какойнибудь файл:
Теперь логично предположить что для того чтобы контент менеджер имел доступ только к источнику файлов Upload нужно чтобы у него не было доступа к источнику файлов Filesystem, а лучше чтобы он вообще его не видел. Для этого можно использовать готовую политику доступа из моего репо: зайти в контроль доступа и импортировать её как это описано в этой статье на примере политики доступа "Content Manager", после чего присвоить её источнику FileSystem в Правах доступа группы пользователей "Content Managers":
Теперь просто добавим наш новый источник файлов в доступы группы пользователей, чтобы получилось как-то так:
Ну вот и все, после Перезагрузки прав доступа мы можем зайти как пользователь content_manager и проверить:
Теперь о том как использовать наш источник файлов в дополнительных полях, где подразумевается работа с файловой системой(например TV Изображение).
Для использования достаточно указать в дополнительном поле на соответствующей вкладке наш источник файлов Upload:
После этого при указании изображения с помощью нашего TV в редактировании ресурса будет виден только источник файлов Upload, и при последующем выводе в теле страницы будет добавляться 'upload/' к пути файла.
Насчет последнего: чтобы этого добиться при использовании нашего TV в MIGX необходимо на соответствующей вкладке указать source From: tv, как это сделано в конфиге images-tv-upload в моем репо.

Ссылки:
Статья - инструкция по созданию группы пользователей Content Managers
Политика доступа None Media для ограничения доступа к истонику файлов
Конфиг Images TV Upload с использованием TV image и его источника файлов
Оффициальная документация по MODX Media Sources
Читать далее

среда, 26 августа 2015 г.

Мультиязычность в MODX с Babel. Развернутое руководство. Автоматический перенос ресурсов

Я в свое время столкнулся с такой задачей и так и не смог найти развернутого решения(а тем более на русском языке): от начала и до конца - как же происходит реализация мультиязычности в MODX.

Есть несколько способов реализации мультиязычности: от нескольких готовых решений, среди которых Babel и xLexicon, так и множество велосипедов, в том числе с session(как я однажды попробовал сделать).
В этой статье будет рассмотрено организация мультиязычности с помощью Babel.

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


Первым шагом к мультиязычности будет создание контекста для всех дополнительных языков помимо основого(для примера будет реализована мультиязычность для английского и немецкого). С начала переименуем контекст "Website" в "Русский":
Потом создадим контекст для английского языка:
И таким же образом для немецкого языка. После этого мы получим такой список контекстов:

После этого скачиваем компонент Babel через Приложения > Установщик > Загрузить дополнения > Поиск, и устанавливаем его, проверим что в Context Keys прописаны все наши контексты для мультиязычности.

После установки заходим во все наши ресурсы и создаем переводы для соседних контекстов(по сути просто копируем ресурсы в другие контексты с созданием связи).
Если ресурсов много, да еще и в виде кучи деревьев, то можно воспользоваться моим скриптом копирования ресурсов с созданием связи, который переносит все ресурсы из одного контекста в другой с пометкой в pagetitle (например [EN] или [DE]).

После создания переводов страниц в соответствующей менюшке отображаются связи, и к ним можно перейти по ссылкам:

Теперь приведем в порядок наши контексты, в них нужно создать следующие настройки:
Для основного контекста(web - Русский):
base_url: /
cultureKey: ru
site_url: http://your_site.ru/
site_start: 1
Для дополнительных контекстов(en - English, de - Deutsch)
base_url: /en/
cultureKey: en
site_url: http://your_site.ru/en/
site_start: 3
где "en" заменяем на то сочетание букв, которое соответствует нужному языку, а в site_start прописываем id главного ресурса соответствующего контекста.

Теперь создадим плагин switchContext для переключение контекста:
И назначим его на событие "OnHandleRequest":
Теперь нужно убедится что проставлены настройки системы и ЧПУ из этой статьи, после чего добавить в файл .htaccess такие строчки:

# redirect all requests to /en/favicon.ico and /de/favicon.ico
# to /favicon.ico
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(en|de)/favicon.ico$ favicon.ico [L,QSA]
  
# redirect all requests to /en/assets* and /de/assets* to /assets*
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(en|de)/assets(.*)$ assets$2 [L,QSA]
  
# redirect all requests to /en/upload* and /de/upload* to /upload*
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(en|de)/upload(.*)$ upload$2 [L,QSA]
 
# redirect all other requests to /en/* and /de/*
# to index.php and set the cultureKey parameter
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(en|de)?/?(.*)$ index.php?cultureKey=$1&q=$2 [L,QSA]

вместо строчек #The Friendly URLs part.

Ну вот и все, все настроено для того чтобы работала мультиязычность, можно зайти по адресу site.ru/en и убедиться что там выводится главный ресурс из соответствующего контекста.

Теперь перед нами стоит задача вывода ссылок для переключения между языками. С этим справиться нам поможет сниппет BabelLinks, который можно положить в том месте где должны быть ссылки переключения языков:
<div class="lang-links>
   [[!BabelLinks? &showCurrent=`1`]]
</div>

Теперь, когда у нас настроена мультиязычность нам нужно задуматься о том как будут выводится те слова на сайте, которые не относятся к какому-либо ресурсу, которые лежат в шаблонах или чанках и представляют из себя невинные "Цена", "Оплата" и т.д. Нам же их тоже нужно переводить, но и в ресурс никакой их не положишь, не уместно будет. Тут нам на помощь приходит lexicon или Словари в MODX, о которых я уже писал в этой статье.
Все что нам нужно дополнительно сделать - это создать папки "en" и "de" в папке lexicon, где под такими-же именами записать переводы для слов, после чего помещать в шаблоны или чанки такой вызов lexicon:
[[!%sitename.example? &namespace=`sitename` &language=`[[++cultureKey]]`]]

Вот и все, теперь в нужных местах будут выводится нужные слова из нужных языков.

ПРИМЕЧАНИЕ:
Как вы наверняка заметили: в lexicon вызове используется переменная [[++cultureKey]], которую мы определили в настройках контекстов. Мы таким образом можем вызывать настройки системы из соответствующей страницы в админке и настройки контекстов, которые переопределяют настройки системы.
Для чего это я поясняю: благодаря такому приему можно так-же прописывать id ресурсов, на которые у нас идет непосредственная ссылка из шаблонов или чанков. Это нам может пригодится в тех случаях когда нужно вывести какие-то данные или дочерние ресурсы непосредственно из какого-то определенного раздела. Например у нас есть раздел "Отзывы", из которого в шапке на каждой странице нужно выводить последний оставленный отзыв. Этот раздел "Отзывы" в русском контексте будет например под id: 7, а в английском контексте под id: 9, таким образом прописав соответствующие айдишники под именами "reviews_id" в настройках наших контекстов мы сможем при вызове сниппета getResources(например) выводить в каждом контексте отзывы на нужном нам языке прописав &parents=`[[++reviews_id]]`.
Если же мы напишем свой сниппет, то нам может понадобиться получить этот reviews_id в теле сниппета, для чего мы можем выполнить
$reviews_id = $modx->getOption('reviews_id'); 

Ссылки:
Плагин switchContext
Скрипт копирования ресурсов с созданием связи Babel

Начало работы в MODX. Первоначальная настройка. Приложения для установки, настройки системы и дружелюбные URL

Управление словарями в MODX

[MODx] 10. Using Babel for Muti-languages support
Настройка мультиязычности MODx REVO + Babel без .htaccess
Settings MODX
Читать далее

вторник, 9 июня 2015 г.

Управление словарями в MODX

Практически на каждом сайте требуется создать свой словарь, из которого контент менеджер мог бы управлять словами и выражениями на сайте не связанными с какими-то конкретными ресурсами. Для таких целей в MODX предусмотрена страница "Управление словарями"

Но в Управлении словарями эти самые словари разделены на пространства имен(среди них компоненты) и темы в них, и все они заполнены уже сформированными специализированными наборами слов, которые применяются в других компонентах в большинстве случаев для отображения в админке сайта на MODX. Эти наборы слов будут мешаться контент менеджеру, если он захочет изменить содержимое конкретно нашего сайта.

Для того чтобы позволить контент менеджеру редактировать слова, относящиеся только к нашему сайту нужно создать свое пространство имен. Для этого с начала создадим папки с содержимым начального набора слов, которые потом можно будет добавлять через это-же Управление словарями.
Структура папок для нашего пространства имен должна находится в core/components/sitename(где sitename - название нашего сайта) и иметь такой вид:

Внутри должен лежать файл default.inc.php, в котором и будут находится исходные слова для нашего словаря.
Теперь, когда папка есть, нужно создать пространство имен через соответствующую страницу в админке MODX:

Создаем пространство имен:
Очищаем кеш сайта и заходим в управление словарями, которое у меня расположено во вкладке Управление как в моей предыдущей статье

Вуаля, все ради того, чтобы в Управлении словарями появился наш сайт с нашими словами:
Теперь, для того чтобы их использовать, в любом месте сайта просто вставляем:
[[!%sitename.example? &namespace=`sitename` &language=`ru`]]
или
[[!%sitename.another_example? &namespace=`sitename` &language=`ru`]]
в зависимости от того, какое слово мы хотим вывести из словаря.
Если кого-то смущает дублирование sitename, то можете не создавать имена слов из Словаря через точку с именем файла, но так безопаснее, потому-что многие имена слов из Словаря могут перебиваться именами из других пространств имен, хотя указано именно наше пространство, по крайней мере у меня такой баг возникал.

Есть еще такой трюк: в значения слов из словаря можно вставлять переменные MODX, например:
"Наш сайт [[++site_name]] рад приветствовать вас"
или:
"Вы попали на страничку [[*pagetitle]]"
Читать далее

пятница, 29 мая 2015 г.

MODX. Как не дать контент менеджеру сайт испортить

Статья руководство о том как настроить админку и ограничить доступ контент менеджеру(администратору сайта) к средствам разработчики на сайте. Чтобы он не смог зайти на вкладку "Элементы", и в "Настройки системы", и вообще чтобы не видел их.
В конечном результате мы должны получить что-то типа этого:

Как видно на скриншоте из админки исчезла вкладка "Элементы", исчезла шестеренка справа наверху, отвечающая за настройки MODX, а пункт "Управление словарями" из этих настроек перенесен в меню "Управление", чтобы у контент менеджера была возможность редактировать словари.
Во вкладке Файлы есть доступ только к источнику Upload, это просто папка в корне сайта /upload/ в которой контент менеджер может творить что хочет не опасаясь что может испортить в ядре сайта.
Итак, как же добиться такой крутой админки для контент менеджера?
Для начала зайти в Контроль доступа:


И импортировать подготовленную политику доступа:

После этого создаем новую группу пользователей и называем её соответственно, прописываем в ней все необходимые поля, включая имя предварительно созданного пользователя("Управление"->"Пользователи"->"Новый пользователь" только не назначайте ему неограниченные права соответствующей галочкой и не забудьте галочку "Активный").

Если все сделали правильно появится новая группа пользователей, уже содержащая нашего указанного пользователя, который будет заходить в админку и видеть только необходимые ему вкладки и пункты меню MODX. Чтобы этого добиться отредактируем нашу группу пользователей вызвав контекстное меню группы Content Managers:

На вкладке "Разрешения" в "Доступе к контекстам"  измении политику доступа на нашу "Content Manager", чтобы получилось таким образом:

После этого нужно сохранить изменения в группе пользователей и перезагрузить права доступа:


Вот и все, теперь можно попробовать зайти в другом браузере(чтобы не переключаться по несколько раз с контент менеджера на админа) зайти как контент менеджер и проверить работоспособность админки:


Вид обновленной админки:


Но остались два последних штриха: перенести Управление словарями из настроек MODX в меню "Управление" и ограничить доступ к файловой системе, дать доступ только к папке /upload/.
Начнем с того что попроще: чтобы перенести в Управление словарями в меню Управление нужно через пользователя admin(в нашем случае пользователь с неограниченными правами, у которого все еще есть доступ к настройкам MODX) зайти в Действия

И просто перенести пункт меню "Управление словарями" из настроек в другое меню(Управление):

Перезагружаем страницу, и готово: пункт меню на нужном нам месте:

Теперь чтобы у контент менеджера был доступ только к папке /upload/ воспользуемся инструкцией из этой статьи.

ПРИМЕЧАНИЕ: Если нужно скрыть какую-то дополнительную менюшку, например MIGX, то достаточно в Действиях зайти в редактирование пункта меню, и поставить в нем ключ привилегии, который будет отвечать так-же за показ этого пункта меню помимо прочих:


Ключи привилегий можно посмотреть в редактировании нашей импортированной политики доступа Content Manager(например):

Таким образом меню MIGX, в котором мы поставили в Привилегии components не будет отображаться для нашего пользователя content_manager потому-что мы убрали эту привилегию в политике доступа Content Managers. То-есть меню MIGX вместе с остальными менюшками и пунктами меню, где проставлены в Привилегии components, не будет отображаться для пользователя потому-что у него нет такой привилегии :) Все оказывается достаточно логично и просто если задуматься.

Ссылки:
http://bobsguides.com/blog.html/2013/10/24/hiding-modx-top-menu-items-from-some-users/
Читать далее