И ещё пара моментов. Просто у меня ситуация такая — есть свои классы и задумал я тут прикрутить к ним процессоры. Проблема не в создании процессоров, а в организации прав. Чего я хочу. Я хочу, чтобы юзеры с фронта могли просматривать/создавать/редактировать/удалять/getlist своих/чужих этих самых объектов. И чтобы все разрешения можно было гибко настроить из админки. Какие есть варианты? а) Создать свои глобальные политики доступа с именами вроде: 'load_my_super_object', 'list_my_super_object', 'view_my_super_object', 'create_my_super_object', 'delete_my_super_object' и т.п. Т.е. какие процессоры нужны, такие политики и насоздавать. И в каждом из этих процессоров проверять нужную в методе mod<какой-то там>Processor::checkPermission(). б) Отнаследоваться от modAccessibleSimpleObject, чтобы из коробки получить стандартные проверки на delete, save, load. Но здесь я нифига не понял — что именно нужно писать в findPolicy() и checkPolicy()?.. Всё остальное делать в процессорах. Ну и всё так же создать шаблон с вышеописанными политиками. А ведь ещё как-то надо организовать, чтобы политиками можно было регулировать возможность просмотра/редактирования/удаления/etc. чужих объектов, т.е. созданными другими юзерами. Как такое провернуть? Надо так же создать несколько политик, вроде такого: 'load_another_my_super_object', 'list_another_my_super_object', 'view_another_my_super_object', 'delete_another_my_super_object' И в каждом процессоре на каждый чих делать проверки — нужной «another» политики и является ли юзер «владельцем» этого объекта? Или есть пути попроще? Решил начать с создания шаблона политик. И вот здесь я снова в тупике. Дело в том, что, при создании своего шаблона политик, modx мне предлагает в принудительном порядке выбрать на основании какого шаблона политик доступа делать новый. (нда, «политики»-«шаблоны», «политики»-«шаблоны»..)) ? Какой бы шаблон не был выбран в качестве основы, при создании новой политики — всё-равно в подсказках будет отображаться весь список всех возможных политик из всех возможных шаблонов. ? Зачем тогда давать выбирать основу? Что вообще это даёт? Я понимаю, если бы политики из этого шаблона-основы были бы доступны в созданном шаблоне, так ведь нет же! Создаётся пустой список. И какой всё-таки надо выбирать? Есть несколько кандидатов: ElementTemplate: add_children, copy, create, delete, list, load, remove, save, view ObjectTemplate: list, load, remove, save, view ResourceTemplate: add_children, copy, create, delete, list, load, move, publish, remove, save, steal_lock, undelete, unpublish, view и AdministratorTemplate со всем его зоопарком политик. Вот столько у меня вопросов… Извини за назойливость, но я реально здесь нифига не понимаю :-(

Ох блин, как всё сложно! Уже 4 раза полностью переписывал огромный комментарий с возникшими вопросами, но теперь вот окончательная версия) Во-первых, спасибо огромное за материал! Очень ценно! Ну и, собссна, во-вторых. Какие у меня вопросы. Возьмём класс modResource. Есть шаблоны политик доступа:

1. ResourceTemplate с разрешениями: add_children copy create delete list load move publish remove save steal_lock undelete unpublish view 2. И есть AdministratorTemplate с кучей разрешений, из которых нам интересны: delete_document edit_document new_document new_document_in_root new_static_resource publish_document resource_duplicate resource_quick_create resource_quick_update resource_tree save_document tree_show_resource_ids undelete_document unpublish_document view_document В этих списках есть как уникальные, так и политики-«синонимы»: delete == delete_document create == new_document publish == publish_document copy == resource_duplicate save == save_document undelete == undelete_document unpublish == unpublish_document view == view_document (при чём везде '_document', но 'resource_duplicate', очередная странность). И это при условии, что в шаблоне AdministratorTemplate так же есть простые load, list, view, create, delete, copy и т.д. Я, конечно, понимаю, что политики из первого списка можно проверить только через modResource::checkPolicy(), а из второго списка через $modx->hasPermission(), но лично для меня ясности это нифига не вносит.
2. В чём между ними в итоге разница-то?
3. Какие политики надо назначать пользователям, для нужных разрешений? Первые? Вторые? И те и другие? Здесь у меня ступор :-) Примеры. У modResource, как наследника modSimpleAccessibleObject, вшиты проверки на load, save и remove в соответствующие методы (например). Здесь проверяется локальная политика. Предположим, что нам надо создать документ. И по сути, логично найти проверку на create где-нибудь в modSimpleAccessibleObject::newObject(). Так ведь нифига! Проверки на create ресурсов я вообще не нашёл! (может плохо искал?). Зато в процессоре на создание ресурса проверяется глобальная new_document через $modx->hasPermission(). Как такое понять?? Дальше, предположим, что нам надо опубликовать документ. Процессор modResourcePublishProcessor наследуется от modProcessor (кстати, почему бы ему сразу не отнаследоваться от modObjectProcessor, в котором уже прописан метод для проверки для глобальных прав?). Как видно из метода modProcessor::run(), в нём сначала проверяются глобальные права (вызывается modResourcePublishProcessor::checkPermissions(), который возвращает $modx->hasPermission('publish_document')), а затем вызывается метод modResourcePublishProcessor::initialize(), который проверяет локальные права save и publish! Масло масляное? Мало того, ещё и при сохрании ресурса ещё раз проверится локальная политика save! Нафига? Нафига делать одно и тоже 2 раза? Т.е. получается, что мало дать юзеру (ну группе этих юзеров) право publish_document из шаблона политик AdministratorTemplate, надо ещё и обязательно дать ему права save и publish из шаблона ResourceTemplate?? Вот об этом я ни разу не подозревал, сколько раз права настраивал. Видать не правильно настраивал? Зачем вообще разделять тогда на глобальные и локальные? И так во многих процессорах — проверяются глобальные разрешения, потом те же, но локальные. Почему тогда не сделать все проверки глобальными и через процессоры? Вот всего этого я не понимаю :-( Изучая процессор resource/duplicate, я начал смутно представлять зачем нужны локальные политики — там внутри методов процессора есть проверки разрешения на добавление к родительскому ресурсу дочерних документов, т.е. как-то так: if ($parentResource->checkPolicy()){ // ... } Да, здесь это, безусловно, оправдано. Но, исходя из вышеизложенного, картинка у меня всё-равно как-то не складывается. Николай, помоги советом! А то я уже близок к тому, чтоб плюнуть на всё это и загулять))

Ясно. Мне, в принципе, без разницы — пакет или снимок. Просто снимок не мог я поставить на хостинг. Но сам виноват, ступил. Резервная копия — это действительно решение. А когда можно ждать релиз?

Просто реально готовить какую-то облегченную версию — вообще никак. У меня есть опыт этого дела, и я знаю как это все сложно. А выдать пакеты по отдельности, и даже дать очень подробные инструкции по настройке всего этого дела в единую систему — это будет несоизмеримо сложно.

Ну вот даже если уперся, ты все понял как это делается. Dev-версия у себя, а ему уже переносишь боевую.

Действительно, ступил что-то, про архив не подумал. А с хостингом — заказчик уперся.

Кстати, если получится, то снимок все таки и в официальный маркетплейс попадет, а значит можно будет легко создать из него облако на modxcloud.com и потом так же снять архив сайта и перенести.

Да, это будет снимок. Но ведь никто тебе не мешает локально накатить этот снимок, а потом перенести на хостинг архивом. А лучше вообще хостинг сменить. Я вот сейчас на digitalocean.com хостюсь и нормально. За $5 в месяц очень даже нормально получается.

А новая сборка тоже будет снимком сайта? Нельзя ли что-нибудь полегче сделать? Я так и не смог поставить на beget, даже через ssh. Только на локальном смог установить. (а может, потом руками перенести — много это проблем?)

Ничего, скоро и мы облачные технологии свои запустим, тоже в плане синхронизации dev- и production- сайтов поработаем.