Как стать автором
Обновить

Комментарии 14

Сниппет addResource никуда не годится.

Я уже говорил об этом, и повторяю снова — нужно использовать runProccessor для создания ресурсов и подобных системных действий.

Это позволит не выставлять вручную дефолтные параметры (процессор будет брать их сам из настроек системы) и, что главнее, будут отрабатывать плагины!

А плагины в вашем случае очень полезны — ибо позволят гибко фильтровать создаваемый контент, вести статистику и т.д.
Насколько мне известно, процессоры требуют, чтобы у пользователя были права на создание ресурса, и он был авторизован, а в тот момент, когда пользователь еще даже не зарегистрирован, использовать процессор у меня не получилось…
Расширить/изменить любой системный процессор можно вот так — смотрите checkPermissions().
Особо не вдавался в приведенную статью, но по мне это не совсем классно все, потому что контролировать код расширяемых классов гораздо сложнее, чем права отдельных юзеров через интерфейс, тем более если еще и несколько контекстов.

Я делаю это по-другому:
1. создаем нужные нам шаблон и политику безопасности.
2. Создаем системного пользователя, для которого разрешаем те или иные политики.
3. На входе в нужных нам процессорах просто перегружаем пользователя MODx (вот это на самом деле огроменная дыра в MODx, но с этим ничего не поделать)
$modx->user = $modx->getObject('modUser', $id);

И все. Для данного и последующих для него действий будут учитываться политики безопасности именно этого пользователя.

Создайте раз такого пользователя и дальше без лишних костылей будете управлять доступами к контекста, группам ресурсов и т.п.
Я никогда не трогаю файлы системы, чтобы можно было без проблем обновить движок.

Поэтому — расширяю системный класс или процессор, и уже в своем расширении встраиваю необходимый функционал.

Эти class-based процессоры для того и придуманы, и я считаю их главным достижением Revolution 2.2.
Ну может быть. У каждого своя реализация.
Я все-таки очень уважаю систему прав доступов, потому плясать от нее люблю.
Одно другому только помогает.

Свой процессор, в нем проверка нужных вам прав — и клиент может обновлять движок и ваш компонент без головной боли.

При расширении системного процессора, его проверка уже не будет работать, если вы замените ее своей — в этом и смысл, чтобы не хакать ядро.
ОК, покапаю как-нибудь на досуге.
Илья, привет!

Мои уроки не прошли даром? Плотно подсел на MODx? :-)
О, да — твои уроки были мощным толчком для меня))) Сейчас для ФСКН доделываем блоговую соц. сеть)
Рад, что не зря время тратил :-)
А я вот решил с социалкой не заморачиваться, а поставить LiveStreet и сдружить с ним MODx.
Читал?: habrahabr.ru/post/151540/
Я Revo не использовал сколько-нибудь серьезно, но Evo для чего-либо многопользовательского — это последний выбор, среди того, что доводилось применять.
Увидел знакомые темы — &submittedResourceId=`9` &activationResourceId=`11`
Вспомнил, ужаснулся.
Просто любопытно — почему именно MODx? Со своей колокольни — в Drupal это проще сделать. И что еще более важно — проще модифицировать и развивать в дальнейшем. Есть еще «более лучшие» варианты для соцсети, наверно.
Просто тяга к творчеству?
Тут показан простейший вариант «в лоб» со стандартными сниппетами.
Это простейший вариант, который, конечно, не подходит для серьезного применения. Скорее — это просто пример гибкости расширений MODX =)

А вообще, на Revo можно написать что угодно, с Evo его сравнивать как то даже неловко.
Я что-то прослоупочил упоминание о себе, спасибо)
У себя в проекте я делал профили по-другому, примерно так. А ресурсами сделал основные страницы интерфейса.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории