Содержание

Сброс пароля от панели администратора MODX – Beget

У CMS Modx есть 2 основные версии:

  • Modx Evolution версии 1.*.*
  • Modx Revo версии 2.*.*

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

Как узнать имя базы?

Узнать имя базы, с которой работает сайт, и префикс таблиц можно в конфигурационном файле сайта.
Для Modx Evolution 1.*.* он находится по следующему пути от корня сайта:

./manager/includes/config.inc.php

А для версии Modx Revo 2.*.*его следует искать по следующему пути от корня сайта:

./core/config/config.inc.php

Корень сайта можно узнать в разделе Сайты:

На скриншоте можно наблюдать, что в нашем случае корнем сайта является modx/public_html, и, соответственно, файл будет находиться по следующим путям для версии Modx Evolution 1. *.* и Modx Revolution 2.*.* соответственно:

modx/public_html/manager/includes/config.inc.php

и

modx/public_html/core/config/config.inc.php 

Теперь нам нужно открыть нужный файл любым удобным способом, например, через Файловый менеджер, и найти в нём следующие строки:

$dbase = 'passreset_modx1';
$table_prefix = 'modx_';

Значения в этих строках означают имя базы, с которой работает сайт, passreset_modx1 и префикс таблиц базы — modx_.
В вашем случае название базы данных будет отличаться, а префикс таблиц может быть таким же.

Редактирование базы данных

После того, как мы узнали имя базы, нам нужно попасть в саму базу данных. Сделать это можно через phpMyAdmin в разделе MySQL. Находим нужную базу данных в списке и напротив неё нажимаем иконку PMA. Возможно, сразу phpMyAdmin не откроется, так как Ваш браузер блокирует всплывающие окна, поэтому разрешите использование всплывающих окон.

Дальнейшие действия для каждой из версий разные, поэтому далее мы рассмотрим процесс отдельно для MODX Evolution и MODX Revo.

Modx Evolution 1.*.*

Перед нами база данных, с которой работает наш сайт. Нам нужно найти таблицу с пользователями нашего сайта. Её название имеет следующий вид – Префикс_manager_users. В нашем случае она называется modx_manager_users. Найдём её в списке и нажмём на неё:

Перед нами появилась информация из таблицы modx_manager_users, в которой указана информация о всех зарегистрированных пользователях вашего сайта. Вам нужно найти строку с логином Вашей учётной записи, в нашем случае это учётная запись admin. Теперь откроем эту строку для редактирования, нажав на иконку с карандашом в левой части строки:

Теперь приступим к самой смене пароля. Для этого находим строку с названием password:

И поменяем в ней 2 строки: в поле Значение удаляем все текущие символы и вводим туда желаемый пароль, например BegetNewPass, а в поле Функция выбираем из списка MD5.

В итоге поля должны выглядеть следующим образом:

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

После всех выполненных действий пароль успешно изменился. Для проверки перейдите на страницу авторизации в админ.панель Вашего сайта и введите логин Вашего аккаунта и новый пароль.

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

Modx Revo 2.*.*

Перед нами база данных, с которой работает наш сайт. Нам нужно найти таблицу с пользователями нашего сайта. Её название имеет следующий вид – Префикс_users. В нашем случае она называется modx_users. Найдём её в списке и нажмём на неё:

Перед нами появилась информация из таблицы modx_users, в которой указана информация о всех зарегистрированных пользователях вашего сайта. Вам нужно найти строку с логином Вашей учётной записи, в нашем случае это учётная запись admin. Теперь откроем эту строку для редактирования, нажав на иконку с карандашом в левой части строки:

Теперь приступим к самой смене пароля. Для этого находим строку с названием password:

И поменяем в ней 2 строки: в поле Значение удаляем все текущие символы и вводим туда желаемый пароль, например BegetNewPass, а в поле Функция выбираем из списка MD5.

В итоге поля должны выглядеть следующим образом:

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

После всех выполненных действий пароль успешно изменился. Для проверки перейдите на страницу авторизации в админ.панель Вашего сайта и введите логин Вашего аккаунта и новый пароль.

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

Инструкция к CMS Evolution (MODx)

Обращение к читателям статьи

Изначально мы написали эту статью в помощь клиентам нашей студии. Но спустя время эту страницу стали посещать тысячи пользователей со всей России, которые искали информацию по этой замечательной CMS. Мы разрабатываем сайты на этой системе управления уже много лет, поэтому, если вас интересует поддержка или доработка вашего сайта, вы можете смело обращаться по электронной почте [email protected]!

Вход в систему управления сайтом

Для входа в систему управления сайтом необходимо к адресу вашего сайта добавить /manager. Итоговый адрес будет site.ru/manager

Далее необходимо ввести логин и пароль, который мы вам предоставляем, после этого вы попадаете на главный экран системы управления.

Словарь терминов

Чтобы общаться с вами «на одном языке», приведём несколько понятий, которые пригодятся:

«Система управления сайтом», она же «CMS (Content Management System)», она же «админка».
Это та «оболочка», через которую вы осуществляете всю работу с сайтом – наполнение, управление и так далее. На скриншоте ниже вы можете увидеть её внешний вид

Бэкенд («бэк»), фронтенд («фронт»)
Как понятно из названия, это «задник» и «передник» сайта. Бэком называется то, что вы видите в админке. Фронтом – то, что на реально действующем сайте.

Дерево ресурсов
Структура страниц сайта в виде раскрывающегося дерева. Её вы можете увидеть в левой части окна CMS. Она позволяет визуально понять, какие разделы, подразделы и страницы есть на сайте. На скриншоте выше дерево ресурсов находится слева, тёмная область.

Ресурс
Любая из страниц сайта. Это может быть главная, страница, статья, услуга, товар, страница контактов — что угодно. Всё, что вы видите на сайте — это ресурсы.

Дочерний ресурс
Ресурс второго уровня (подресурс). Например, у нас может быть раздел «Услуги» (в таком случае он называется ресурсом) и его подразделы — вот они будут называться дочерними ресурсами («дочерний» — понятие относительное, поэтому при любом раскладе они всё же называются «ресурсами»)

ID (айди) ресурса
Цифра, написанная справа от ресурса в дереве. Нужна, в основном, чтобы избежать путаницы при общении по какому-то вопросу. Например, может быть одновременно два ресурса с одинаковым названием (например, два врача-однофамильца). Чтобы проще объяснить кому-тО, какой ресурс смотреть, можно назвать его порядковый номер, то есть, айди.

Шаблон
Визуальная структура ресурса. От шаблона зависит, как будет отображаться та или иная страница. Любой ресурс можно сделать любым шаблоном. Например, любой услуге можно присвоить шаблон «Контакты» и на ней ожидаемо появится карта. Именно этот фактор является огромным преимуществом этой CMS. Любой ресурс может выступать в роли любой страницы при условии смены всего лишь его шаблона.

Публикация
Статус ресурса. Ресурс может быть опубликован (тогда его увидят все пользователи), либо не опубликован (тогда его увидят только администраторы сайта и никто более)

«TV-параметр» (ТВ-параметр)
Поле с неким параметром сайта. Это может быть ввод картинки, какого-то названия, текста, заголовка – по-русски это называлось бы просто «параметром», но в рамках работы с этой CMS, чтобы не было путаницы, ввели понятие «TV-параметр». Самый простой пример – это ввод номера телефона, который отображается в шапке сайта. Поле ввода и будет называться TV-параметром. Пример ТВ-Параметров ниже на скриншоте.

«Мульти-TV»
Аналогично предыдущему термину, это просто параметр ресурса. Однако, название явно показывает, что у него есть возможность ввода множества данных, объединённых одним TV-параметром. Например, если у компании несколько телефонов, то плодить множество TV-параметров неудобно (т.к. телефоны могут появляться хоть по 5 штук в день). В таком случае используется Мульти-ТВ. Пример внешнего вида мульти-ТВ находится ниже на скриншоте. Зелёным плюсом и красным минусом мы можем регулировать количество ТВ-параметров внутри одного мульти-ТВ

DocPicker (ДокПикер)
Используется нечасто и не факт, что у вас он будет, но инструкция общая для всех, поэтому нужно его упомянуть. Используется для логической связи ресурсов между собой. Например, одна из частых задач – конкретному филиалу компании присвоить нужных сотрудников. Для этого в строке пишутся номера ID ресурсов. На скриншоте ниже показано, что сотрудник относится именно к филиалу на Московской, д. 123.

Табы
«Закладки» внутри админки, на которых расположены ТВ-параметры. Расположены в самом верху окна редактирования ресурса.

Файловый менеджер
Используется для загрузки файлов и изображений на сайт. Вызывается кликом по кнопке «Вставить» в ТВ-параметре.

Представляет собой стандартный проводник с обычными файлами и папками. То, что вы видите в нём – это файлы, расположенные на хостинге (а не на вашем ПК). Для того, чтобы загрузить файл, необходимо нажать зелёную кнопку «Загрузить» и выбрать необходимый файл на вашем ПК. Рекомендуем создавать папки в левом дереве файлов, а не грузить всё в одну, чтобы потом вам самим было проще найти нужный файл.

PageBuilder (ПейджБилдер)
Один из самых сложных, но при этом, самых часто встречающихся модулей нашей админки. Представляет собой «сборщик-конструктор» страницы. В основном, используется на каких-то больших внутренних страницах (например, конкретной услуги, продукта, статьи и так далее).

Для начала вернёмся к объяснению, которое мы 100% рассказывали вам на встрече, просто вы забыли. Любая страница состоит из неких визуальных блоков. Если бы статья содержала в себе только текст, то было бы прекрасно, и никакой ПейджБилдер нам не потребовался бы. Однако, зачастую, статья может содержать в себе: текст, галерею, слайдер, отзывы, преимущества, что угодно. Все эти блоки имеют свой html-код, свою вёрстку. И без знаний этого кода вы просто-напросто не сможете скомпоновать порядок блоков на странице так, как вам нужно.

Рассмотрим на примере. Ниже будет скриншот страницы услуги Стоматологии.

Явно видно, что на картинке шесть разных визуальных блоков. Но ведь очевидно, что прайс-лист на какой-то услуге может быть, а на какой-то – нет. На какой-то услуге может быть блок с круглыми картинками, а какая-то услуга – это всего лишь один абзац текста, т. к. про неё больше нечего писать. Именно для этого и нужен ПейджБилдер. Он позволяет без знания кода формировать порядок блоков на странице. Фактически, ПейджБилдер – это всего лишь чуть более навороченный МультиТВ.

Теперь посмотрим, как выглядит этот же сайт в разрезе ПейджБилдера в админке.

По принципу МультиТВ мы можем добавить в любом порядке блок с определённой визуальной структурой и наполнением. Эти блоки можно менять местами, можно добавлять несколько одинаковых блоков и так далее.

Вот именно понять, как выбрать наиболее привлекательный блок для какого-то наполнения – это и есть основная проблема (даже не проблема, а сложность) в наполнении сайта.

Рассмотрим на примере. Один и тот же текст можно вверстать в сайт по разному, ниже три примера:

 

 

«Правильного» решения тут нет, это – абсолютный субъективизим, который влияет только на визуальную подачу, не более. Но именно этот момент вызывает у всех большинство вопросов.

Работа с деревом ресурсов

Работа с деревом ресурсов очень простая. Давайте прям пошагово:

  • Первое, что нужно знать – изначально, все ресурсы и их подресурсы свёрнуты. Чтобы посмотреть, какие дочерники содержит в себе ресурс, необходимо нажать на стрелочку слева:

  • Зажав ЛКМ, можно перетаскивать ресурсы вверх-вниз, это будет влиять на порядок отображения на фронте.
  • По ресурсу можно кликнуть левой кнопкой мыши (далее просто «ЛКМ») или правой кнопкой мыши (далее ПКМ).

    ЛКМ откроет окно редактирования конкретного ресурса в правой области админки.

    ПКМ откроет контекстное меню редактирования ресурса, остановимся на нём.

По порядку по скриншоту:

  • Дочерний ресурс. Создаст дочерний ресурс выбранного ресурса. Используется для добавления статей, услуг и так далее.
  • Редактировать. Действие, аналогичное ЛКМ.
  • Переместить. Позволяет перемещать созданный ресурс (например, если вы создали его не в том ресурса)
  • Сделать копию. Создаёт полную копию выбранного ресурса (включая заполненные ТВ-параметры)
  • Отменить публикацию. Меняет статус публикации ресурса.
  • Удалить. Действие аналогично удалению файла в Windows. То есть, сначала ресурс просто зачёркивается, и только после нажатия на иконку корзины сверху, он удаляется. Это очень удобно и защищает от случайного удаления ресурса.
  • Дочерняя веб-ссылка. Как правило, не используется.
  • Обзор ресурса. Как правило, не используется.
  • Просмотр ресурса. Открывает страницу сайта для просмотра.

Работа с окном редактирования ресурса

Работа с окном редактирования ресурса довольно простая. Давайте по порядку, сверху-внизу. Ниже – скриншот-пример:

Всегда обращаем внимание на табы. Есть три стандартных таба, которые есть у каждого ресурса: Общие, Настройки страницы, SEO.

А есть у некоторых ресурсов дополнительные. Как правило, это различные галереи, пейджбилдеры и другие ТВ-параметры.

У каждого ресурса есть стандартные поля:

  • Заголовок. Это – название страницы. Как правило, используется на фронте в качестве заголовка.
  • Псевдоним. Это адрес страницы на фронте. Например, site.ru/adres-stranicy. В данном случае, adres-stranicy является псевдонимом. Его трогать не нужно, он формируется автоматически на основе заголовка по правилам транслитерации.
  • Шаблон. Как правило, шаблон выбирается автоматически при создании ресурса (на основе «соседних» ресурсов). Но если вы видите, что вы наполнили всё верно, а на фронте какая-то ерунда, то в первую очередь проверьте шаблон и сверьтесь с ресурсом, который работает корректно.
  • Позиция в меню. Порядковый номер вывода ресурса на фронте.

Табы SEO и «Настройка страницы», как правило, заказчиками не используется. Если же вам это нужно, то, скорее всего, вам эта инструкция уже бесполезна 🙂

Работа с редактором контента

Работа с редактором текста не сложнее работы в Microsoft Office.

На картинке дали пояснения к основным кнопкам.

Самые частые вопросы по использованию редактора контента:

  • Как изменить шрифт текста, размер, интервалы? Делать этого не нужно! Над вашим сайтом работал профессиональный дизайнер, который подобрал именно тот шрифт, именно тот размер, именно то выравнивание, которое идеально подходит для тех или иных целей. Ваша задача – просто вставить текст, не более.
  • Текст на фронте выглядит «слипшемся, без абзацев». Частая проблема, когда вы копируете текст с какого-то чужого сайта. Вам в некоторых случаях необходимо вставлять абзацы самостоятельно (просто нажав Enter на нужном участке текста). Ниже пример «слипшегося текста» и текста, как он должен выглядеть в админке, чтоб был красивый на фронте:

Что важно понимать?

Наполнение сайта — это сложный процесс, который требует усидчивости. Каждый сайт индивидуален, каждый имеет свой набор ТВ-параметров, табов, полей, визуальных блоков и так далее. Написать инструкцию к каждому — просто нереально технически

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

Подведем итоги

Мы надеемся, что эта инструкция поможет вам красиво и быстро наполнить сайт. Руководство постоянно пополняется, поэтому у нас есть большая просьба — если в процессе наполнения вы столкнулись с тем, чего нет в этом руководстве, сообщите нам. Вы поможете будущему поколению заказчиков в этом сложном вопросе.

Настройка админ панели клиента Modx Revo

Когда я начал работать на CMF Modx Revolution (до этого сажал сайты на Evolution) я открыл для себя неприятную новость — я не могу создать админку для клиента с теми правами доступа, чтобы клиент ничего не испортил на сайте. То есть с закрытыми «Элементами», рабочими файлами системы, системными настройками и так далее. Вообщем я не знал как настроить админку под клиента. Сейчас знаю :)) И хочу поделиться этими знаниями с вами!

В Evolution все было достаточно просто: создаешь права пользователю и готово! А здесь нужно проделать достаточно много шагов, но сдругой стороны — в Modx Revolution с правами на документы и файлы можно делать все, что угодно (если конечно разбираться в этом). Ну что ж, начнем!

1. Переходим в «Безопасность» — «Контроль доступа» в верхнем меню админ-панели

 

2. Заходим во вкладку «Политика доступа»

3. Нажимаем на кнопку «Создать политику доступа»

У нас откроется окно с полями. В поле Имя пишем «manager», шаблон политики доступа — AdministratorTemplate. Жмем кнопку сохранить

 

4. После сохранения политики доступа «manager» мы видим, что она появилась у нас в списке политик доступа

 

5.

Редактируем manager

 

6. Убираем галочки ненужных параметров

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

Убираем галочки со следующих параметров:

  • access_permissions     Вывод страницы с настройками прав доступов пользователей
  • dashboards          Просмотр и управление панелями
  • element_tree          Возможность просмотра дерева элементов в левой навигационной панели
  • menu_reports          Показывать в верхнем меню пункт «Отчёты»
  • menu_security          Показывать в верхнем меню пункт «Безопасность»
  • menu_system          Показывать в верхнем меню пункт «Система»
  • menu_tools          Показывать в верхнем меню пункт «Инструменты»
  • new_static_resource   Создавать новые статичные ресурсы.
  • remove_locks          Удалять все блокировки на сайте

Обязательно нажимаем кнопку «Сохранить»

7. Переходим во вкладку «Безопасность» — «Контроль доступа» — «Роли»

 

8. Нажимаем кнопку «Создать новый», в поле Имя вбиваем Manager, Ранг — 9, нажимаем кнопку «Сохранить»

 

9. Сохраняем изменения и переходим в меню «Безопасность» — «Контроль доступа» — «Группы пользователей»

Правой кнопкой мыши жмем на «Administrator» и нажимаем «Создать группу пользователей»

 

10. Создаем новую группу: Имя — Manager, Политика бэкэнда — нет политики, жмем «Сохранить»

 

11. Находим ее в списке Групп пользователей и жмем «редактировать»

 

12. Заходим в меню «Доступ к контекстам» и нажимаем «Добавить контекст»

 

13. Контекст — mgr, Минимальная роль — Manager — 9, Политика доступа — Manager

 

14.

Добавляем еще одни контекст

А точнее редактируем уже имеющийся web: Контекст — web, Минимальная роль — Manager — 9, Политика доступа — Administrator. Нажимаем кнопку «Сохранить»

 

15. Мы увидим такую картину! Сохраняем все во вкладке «Группа пользователя: Manager»

 

16. Далее: «Безопасность» — «Управление пользователями»

 

17. Создаем нового пользователя (это будет наш клиент) — нажимаем кнопку «Новый пользователь».

Имя вы ему можете задать какое угодно, я назову его — manager

 

18. Имя пользователя — manager, жмем галочку — Активный, вбиваем email

 

19. Указываем пароль

 

20. Перед тем как сохранить, зайдите во вкладку «Права доступа»

 

21. Жмем кнопку «Добавить пользователя в группу», Группа пользователя — «Manager», Роль — «Manager»

Сохраняем.

На этом создание админ панели, где у клиента есть доступы только к правке и созданию страниц в дереве документов, закончено. Но этот пользователь до сих пор имеет доступ ко всем файлам системы. И поэтому мы сейчас сделаем так, чтобы он имел доступ только к одной папке, которую мы создадим в корне сайта Modx Revolution

22. Переходим во вкладку «Инструменты» — «Источники файлов»

 

23. Откроется список всех источников файлов. По умолчанию создан одни единственный — Filesystem

Перед созданием нового источника файлов, нужно сначала изменить этот. Нажимаем на «Filesystem» правой кнопкой мыши и выбираем «Редактировать»

 

24. Откроется такое окно. Жмем «Добавить группу пользователей»

 

25. Группы пользователей — Administrator, Минимальная роль — Super User — 0, Политика — Media Source Admin. Нажимаем «Сохранить»

 

26.

Возвращаемся к Источникам файлов и создаем новый источник файлов

Назовем его «Manager», Тим источника файлов — Файловая система

Жмем «Сохранить»

 

27. Нажимаем правой кнопкой мыши на новый источник файлов «Manager» и выбираем «Редактировать»

 

28. Откроется такое окно! Нам нужно изменить первые 4 параметра

В basePath в поле значение мы вбиваем /manager/, basePathRelative и baseUrlRelative оставляем как есть со значениями «Да», в поле baseUrl пишем manager/

Жмем сохранить! Теперь осталось только задать права доступа к источнику файлов, но перед этим нам нужно задать источник файлов ко всем tv параметрам, которые будет администрировать наш клиент

29. Заходим в tv параметр

 

30. Нажимаем самую последнюю вкладку «Источники файлов»

и меняем источник файлов с «Filesystem» на «Manager». Сохраняем!

 

31. Добавляем группу пользователей в «Manager»

Теперь после всех проделанных шагов заходим в «Источник файлов» — «Manager» и добавляем группу пользователей в этот источник файлов

 

32. Группы пользователей — Manager, Минимальная роль — Manager — 9, Политика — Media Source Admin. Жмем «Сохранить»

Сразу после сохранения источник файлов «Manager» исчезнет для администратора. Для того чтобы можно было редактировать этот источник файлов, нужно зайти в меню «Безопасность — Контроль доступа». Открыть на редактирование группу менеджера: Manager и во вкладке «Источники файлов» найти и удалить источник Manager. Только тогда мы сможем вновь редактировать данный источник из под администратора.

 

33. На всякий случай очищаем кэш

и наш пользователь с ограниченными правами и доступами к файловой системе создан!

 

Не скажу, что это достаточно легко, но если делать это на автоматизме, то это не покажется чем то тяжелым. Надеюсь у вас все получилось! Удачи в проектах!

Урок 3. Базовая настройка и установка пакетов MODX

На этом уроке мы разберемся в базовых настройках сайта. Также проведём установку дополнений из репозитория MODX. В этом уроке мы рассмотрим лишь основные настройки и вы поймёте, что менеджер MODX Revolution имеет множество настроек конфигурации и мы вначале рассмотрим основные, а потом изучим разные части менеджера.

Название сайта и другие настройки

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

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

Очевидно, что нужно поменять имя сайта на нужное нам. Настройки сайта и другие настройки в менеджере находятся в выпадающей панели System название System Settings.

На этой странице показаны все системные настройки стандартного набора MODX Revolution. Здесь вы можете увидеть очень большое количество количество настроек, даже вы можете создавать собственные настройки. Мы рассмотрим лишь некоторые из настроек.

В данным момент настройки, которые нас интересуют, это настройки сайта Site settings и мы их можем найти используя функцию фильтра.

В выпадающем меню фильтра Filter by Area можно выбрать нужные нам настройки. Выберите в списке Site, чтобы отфильтровались настройки сайта.

Отредактируем имя сайта сделав в поле имени двойной клик для того, чтобы отредоктировать его. Удалим текущее название сайта и вставим свое имя «Изучение MODX Revolution». После окончания редактирования имени сайта нажмите и спустя некоторое время после обновления страница отобразит новое имя сайта.

Теперь если мы взглянем на заголовок, то он отражает текущее название сайта, а не название, которое было по-умолчанию.

Это только простой пример редактирования системных настроек, но если посмотреть на все настройки, то можно увидеть, что настраивать можно очень многое в сайте. Пока что это так и оставим, я потом вернусь к объяснению нескольких настроек.

Установка дополнений

Другая вещь, с которой необходимо ознакомится в MODX Revolution это то, как устанавливаются дополнения.

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

Еще одним положительным моментом Revolution в сравнении с Evolution — это легкость установки дополнений в сайте. В Evolution вам нужно было закачать архивный zip файл, залить файлы на хостинг и потом скопировать и вставить код куда необходимо. То теперь все это делается автоматически в пару щелчков мышью.

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

Откроется станица, на которой будут показаны последние и наиболее популярные дополнения справа и браузер дополнений (пакетов) слева.

Как вы видите, доступные дополнения, которые вы можете загрузить на ваш сайт, делятся на 5 категорий:

  • MODX Addons (адонны)– это функциональные куски, которые не являются частью ядра MODX, такие как галереи, построители меню, теговые сниппеты и другое. Они не изменяют ядро, а просто добавляют функциональность.
  • Core Extensions (расширения ядра) – это дополнения к самому ядру, которые изменяют работу MODX. Они изменяют работу частей ядра.
  • FrontEnd Templates (шаблоны фронт-энда)– это готовые к использованию шаблоны сайта сделанные в виде пакетов для быстрой установки. Если вы хотите построить/установить свой собственный шаблон можете воспользоватся этими и изменять их как угодно.
  • Manager Templates (шаблоны админки) – это backend шаблоны для изменения вида вашего менедзжера, это повлияет только на внешний вид, но не на функции вашего менеджера.
  • Site Packages (пакеты сайта) – это уже построенные полные сайты, которые вы можете установить и исследовать. Это просто отличный способ установить демо MODX сайт и увидеть как он работает. Демо сайт может быть также отличным материалом для изучения инструментов, так как вы можете в нем посмотреть как реализованная та или иная функциональность.

Не бойтесь изучить самостоятельно все эти категории и исследовать доступные пакеты. Во время написания этого урока наиболее богатой на пакеты была категория MODX Addons и именно в ней мы будем брать используемые в дальнейшем пакеты.

Устанавливается адонн/дополнение/пакет очень просто. Например, мы хотим установить текстовый редактор rich text editor (RTE), все что нам нужно сделать — это нажать на папке , развернуть ее, найти в списке и нажать на , далее просто выбрать из списка необходимый нам редактор.

 

Вы можете узнать подробнее о пакете нажав или нажимайте сразу на для загрузки. После успешной загрузки дополнения, кнопка Download меняется на Downloaded. Вы можете загрузить еще парочку необходимых пакетов, далее нажимаете внизу кнопку

 

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

 

Установщик попросит вас согласится с лицензией и далее установит пакет, далее нажимаете ОК, если не появилось сообщений об ошибках или проблемах и возвращаемся на страницу управления пакетами, которая покажет эти пакеты как установленные. Как видно у нас появилась кнопка Uninstall для деинсталяции. Дополнительно под списком плагинов видно только что установленный новый адонн.

 

Все просто. Правда?

Короткая заметка для пользователей XAMPP, если у вас появились проблемы при установке дополнений, проверте включен ли параметр cURL в вашей установке XAMPP.

Выводы.

В этом уроке мы немного расмотрели менеджер MODX Revolution, посмотрели коротко как изменять системные настройки сайта. Также рассмотрели как устанавливать дополнения из репозитория MODX.

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

Скоро новый урок!

В следующем уроке мы добавим парочку страниц к нашему вебсайту и далее начнем строить шаблон для него. Мы не будем использовать уже построенные шаблоны MODX из репозитория, вместо этого мы используем HTML/CSS шаблон и портируем его в MODX Revolution, используя возможность изучить синтаксис MODX Revolution.

Если есть какие-то идеи/комментарии/поправки — не стесняйтесь комментировать.

Полезные материалы:

  • Настройка ЧПУ (Friendly URL) на сайте MODX Revolution
Jun 19 2012 уроки MODx Revolution Виктор Матушевский

Урок 2. Установка MODX Revolution Советы для начинающих работу с MODX

Please enable JavaScript to view the comments powered by Disqus.

MODX — Загрузки — Синтезаторы — Синтезаторы и инструменты для создания музыки — Продукты

Искать на этом сайте

  • Обзор
  • Функции
  • Обновления
  • Программы
  • Звуковая библиотека
  • Совместимость
  • Часто задаваемые вопросы
  • Спецификации
  • Аксессуары
  • Загрузки

» data-delete-row=»true»>
Имя Английский Английский
MODX 6/7/8 Руководство пользователя [12,9МБ]
Список данных MODX6/MODX7/MODX8 [5,2 МБ]
Дополнительное руководство по MODX 6/7/8 [1,8 МБ]
Руководство по параметрам синтезатора [752 КБ]

Выберите ОС AllMacWin

52
Имя ОС Размер Последнее обновление
MODX Connect V1. 2.0 для Mac macOS 12 macOS 11 macOS 10.15 и macOS 10.14 Mac 18,2 МБ 01.09.2022
MODX Connect V1.2.0 для Windows Вин 15,4 МБ 01.09.2022
USB-драйвер Yamaha Steinberg версии 2.1.1 для Windows 11/10 (64-разрядная версия) Вин 4,6 МБ 22.02.2022
USB-драйвер Yamaha Steinberg версии 3.1.1 для Mac macOS 11/12 (кремний Intel/Apple с Rosetta 2) Mac 4 МБ 07.02.2022
366,9 МБ 22.02.2021
USB-драйвер Yamaha Steinberg версии 2.0.5 для Mac macOS 10.15–10.13 Mac 3,5 МБ 02.02.2021
USB-драйвер Yamaha Steinberg версии 2.0.4 для Mac macOS 10.15–10.12 Mac 3,4 МБ 25.11.2020
MODX Connect V1.1.1 для Windows Вин 15,1 МБ 13.11.2020
MODX Connect V1.1.0 для Mac macOS 11 и macOS 10.15-macOS 10.12 Mac 20,7 МБ 2020-06-02
MODX Connect V1. 1.0 для Windows Вин 15 МБ 2020-06-02
Драйвер USB Yamaha Steinberg версии 2.0.3 для Windows 10/8.1/7 (32-разрядная/64-разрядная версия) Win 7,1 МБ 2020-03-02
MODX Connect V1.0.6 для Windows Вин 20,3 МБ 10.01.2019
MODX Connect V1.0.4 для Mac macOS 10.15-OS X 10.11 Mac 51,4 МБ 2018-09-14

Имя Английский Английский
Список совместимых устройств для MODX6/MODX7/MODX8 [277 КБ]
Представления MOTIF XF для MONTAGE [2,2 МБ]

    org/» typeof=»BreadcrumbList»>
  1. Главная
  2. Продукты
  3. Синтезаторы и инструменты для создания музыки
  4. Синтезаторы
  5. MODX
  6. Загрузки

Путеводители Боба | Скрытие ресурсов в Менеджере

Разрешения могут быть запутанной проблемой в MODX Revolution. Здесь больше сущностей и более сложные взаимодействия между ними, чем в MODX Evolution. Следующая информация предназначена для MODX Revolution и более поздних версий. Информация о разрешениях MODX Evolution находится здесь.

Всегда помните, что вы никогда не должны изменять стандартные политики или шаблоны политик, предоставляемые при базовой установке MODX. Если, например, вы измените стандартную политику администратора, чтобы снять отметку с некоторых разрешений, вы заберете эти разрешения у суперпользователя-администратора. Если вы удалите разрешения из стандартного шаблона политики администратора, вы также заберете эти разрешения у суперпользователя-администратора. Это касается и других стандартных политик и шаблонов политик. Всегда дублировать политики или шаблоны политик и изменять дубликаты.

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

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

Где это делается

Это помогает понять, что система разрешений Revolution состоит из четырех различных частей.

  • Какие ресурсы могут видеть пользователи и что они могут с ними делать, контролируется записями ACL.
  • Видимость вкладки «Элементы» и вкладки «Файлы» контролируется определенными разрешениями (element_tree, file_tree).
  • Видимость и организация главного меню управляются в Manager | Действия.
  • Поля, отображаемые на панели «Создать/Редактировать ресурс» для конкретных пользователей, контролируются в разделе «Безопасность | Настройка формы.

Нет больше веб-пользователей и пользователей-менеджеров

В MODX Revolution больше нет различия между пользователями-менеджерами и веб-пользователями — есть только пользователи. Управление доступом в передней и задней частях осуществляется с помощью контекстов. Пользователи в бэкенде находятся в контексте «mgr», пользователи во внешнем интерфейсе находятся в «веб-контексте» (или другом создаваемом вами контексте). Под серверной частью мы подразумеваем, где вы находитесь, когда вы входите через yoursite.com/manager и работаете в MODX Manager. С другой стороны, пользователи во внешнем интерфейсе посещают сайт через yoursite. com и могут войти или не войти в систему через форму во внешнем интерфейсе сайта.

В Revolution пользователь в любой момент времени вошел в систему или не вошел в систему. Пользователь в диспетчере MODX вошел в систему и находится в контексте «mgr». Пользователь во внешнем интерфейсе находится в «веб-контексте» (или другом создаваемом вами контексте) и может быть зарегистрирован или нет. Если пользователь не вошел в систему, он является анонимным пользователем, имеющим только право «загружать» документы (т. е. просматривать их).

Основные принципы

В MODX Evolution документы «защищены», когда группа документов назначается группе пользователей. После этого только пользователи, которым предоставлены права доступа к документам, смогут получить к ним доступ. Соединения Manager User/Manager Resource Group применяются только в бэкэнде (в MODX Manager). Соединения WebGroup/WebUser применяются только во внешнем интерфейсе сайта.

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

Разрешения на доступ перечислены в политиках доступа. Эти политики назначаются в записях ACL с указанной ролью и указанным контекстом. Списки контроля доступа (ACL) принадлежат определенной группе пользователей, и (в отличие от Evolution) разным пользователям могут быть назначены разные роли в группе. Сейчас это может показаться тарабарщиной, но по ходу дела это должно стать ясно.

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

Я предполагаю, что вы знаете или можете понять, что такое пользователь, группа пользователей и группа ресурсов («Ресурс» — это официальное название документов, веб-ссылок, символических ссылок и статических ресурсов, если вы не знаете, что это все такое, а пока просто подумайте: Ресурс = Документ). Однако если вы привыкли к разрешениям Evolution, вам потребуется некоторая информация о контекстах, ролях, шаблонах политик, политиках доступа и списках управления доступом (ACL).

Короче говоря, политики доступа — это просто списки отдельных разрешений (например, save_tv, edit_document, view_document, access_permissions и т. д.), которые позволяют пользователю выполнять определенные действия или просматривать что-либо в диспетчере. Роли — это имена, связанные с политиками доступа с номером полномочий (подробнее об этом позже). ACL — это просто списки правил доступа, которые связывают группы пользователей с группами ресурсов и/или контекстами и политиками. Давайте рассмотрим эти концепции более подробно:

Контексты

Контексты — это новая концепция в MODX Revolution, которая имеет множество применений, выходящих за рамки этой страницы. Для наших целей здесь мы предположим, что у вас есть только два контекста, «web» и «mgr». Контекст «mgr» — это, по сути, серверная часть (менеджер MODX). Веб-контекст — это внешний интерфейс (за небольшим исключением, о котором мы поговорим позже). Если позже вы создадите больше контекстов, все, что вы узнали здесь о «веб-контексте», будет применяться и к ним.

По умолчанию, когда вы создаете ресурсы в Диспетчере, они располагаются под значком «Интернет» (если вы не создадите другие контексты и не поместите ресурсы в эти контексты). Ресурсы под значком «веб» находятся в контексте «веб». Контекст «mgr» — это просто менеджер MODX. Когда пользователи находятся в контексте «mgr», они входят в диспетчер. Разрешения, привязанные к контексту «mgr», определяют, что пользователь может делать и видеть в диспетчере. Разрешения, привязанные к «сетевому» контексту, ограничивают то, что пользователи могут делать или видеть в интерфейсе сайта.

Роли

В MODX Evolution при создании роли вы точно определяете, какие действия менеджера может выполнять пользователь с этой ролью. Однако в MODX Revolution единственное, что вы устанавливаете при создании роли, — это имя роли, номер полномочий, связанный с этой ролью, и необязательное описание роли. Полномочия роли суперпользователя администратора равны 0. При создании других ролей вы будете назначать им более высокие числа полномочий. Числа представляют собой произвольные числа от 0 до 9.999. Все, что вам действительно нужно знать о них на данный момент, это то, что:

  • Роли, которые должны иметь больше прав, должны иметь более низкие номера полномочий.
  • Как правило, следует избегать дублирования авторизационных номеров.
  • Пользователи в группе пользователей «наследуют» разрешения, данные пользователям с ролями, которые имеют более высокие номера полномочий, чем их роли.

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

Когда вы добавляете пользователя в группу пользователей, вы даете пользователю роль в группе. Вы контролируете, что пользователь может и что не может делать, создавая запись ACL для этой группы пользователей, которая указывает, какая политика доступа соответствует этой роли.

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

Роли создаются при переходе в Безопасность | Управление доступом и выбрав вкладку «Роли». При нажатии на кнопку «Создать новую» будет создана новая роль. Роли можно удалить, щелкнув их правой кнопкой мыши и выбрав «Удалить роль».

Шаблоны политик

Шаблоны политик — это просто списки отдельных разрешений, которые будут отображаться в определенной политике доступа. Каждая политика доступа основана на определенном шаблоне политики и будет отображать разрешения только для этого шаблона. Вы можете увидеть некоторые из них (Важно: не редактируйте и не удаляйте ни одну из них сейчас ), перейдя в Безопасность | Контроль доступа | Вкладка «Шаблоны политик». Щелкните правой кнопкой мыши шаблон политики и выберите «Обновить шаблон политики». Затем щелкните вкладку «Разрешения», чтобы увидеть список разрешений для этого шаблона политики. Обратите внимание, что здесь вы можете добавлять или удалять разрешения, но это не то место, где вы назначаете разрешения пользователям. Это делается на вкладке «Политики доступа».

Добавление и удаление разрешений здесь обычно не требуется, потому что вы можете определить, какие пользователи имеют какие разрешения на вкладке «Политики доступа», установив или сняв их флажок. Как правило, единственной причиной для изменения шаблона политики является добавление пользовательского разрешения. Например, вы можете добавить собственное разрешение, позволяющее пользователям видеть определенные элементы в верхнем меню. Некоторые дополнительные компоненты также могут использовать настраиваемые разрешения. Фрагмент NewsPublisher, например, имеет специальное разрешение, называемое allow_modx_tags, которое позволяет пользователям редактировать ресурсы, содержащие теги MODX.

Политики доступа

При создании записи ACL вы выбираете для нее политику. Эта политика будет основана на шаблоне политики и будет отображать все разрешения в этом шаблоне. В Диспетчере, когда вы редактируете Политику, вы увидите все Разрешения, перечисленные в Шаблоне Политики, но вы можете установить или снять их, чтобы определить, какие Разрешения на самом деле будут у пользователя.

Если Пользователь имеет конфликтующие Разрешения (например, Пользователь принадлежит к двум разным группам и Контекстные Разрешения «mgr» для этого Пользователя разные), будет применяться наиболее разрешающее правило. Итак, если пользователю предоставлено Разрешение в контексте «mgr» в одном месте, никакое другое правило в другом месте не может отменить это Разрешение.

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

  • Никогда не редактируйте включенные шаблоны политики администратора или политики ресурсов. Всегда дублируйте их, а затем редактируйте дубликат.
  • Политики, используемые в записях ACL контекстного доступа, должны быть основаны на стандартном шаблоне политики администратора.
  • Политики, используемые в записях ACL доступа к группе ресурсов, должны основываться на стандартном шаблоне политики ресурсов.
  • Политики, используемые в записях ACL доступа к категории элементов, должны основываться на стандартном шаблоне политики элемента.

Описание каждого Разрешения, включенного в список Разрешений в Диспетчере. Вы также можете получить доступ к официальной документации MODX по безопасности, нажав кнопку «Справка» на одной из страниц безопасности.

Списки контроля доступа

Списки контроля доступа (ACL) — это списки правил, которые соединяют группы пользователей с группами ресурсов и/или контекстами. Каждая запись ACL имеет контекст и минимальную роль. Контекст указывает, в каком контексте применяется правило. Контекст «mgr» указывает, что правила будут применяться в диспетчере. Контекст «веб» указывает, что правила будут применяться в интерфейсе сайта. Минимальная роль определяет, к каким пользователям в группе применяется правило.

Одним из первых камней преткновения для новых пользователей Revolution является найти ACL. Вы достигаете их, перейдя в Безопасность | Контроль доступа | Вкладка «Группы пользователей», щелкните правой кнопкой мыши группу пользователей и выберите «Обновить группу пользователей». Списки ACL доступны на двух вкладках справа на панели «Обновить группу пользователей». Они отображаются в виде сеток, и в настоящее время фраза «Список контроля доступа» не отображается на странице. Каждая строка в сетке — это запись ACL — правило, определяющее, что могут делать или видеть пользователи с определенной ролью.

Обратите внимание, что нет смысла создавать запись ACL до тех пор, пока вы не создадите группу пользователей, роль и политику доступа, которые вы будете использовать в записи ACL.

Существует три типа ACL: ACL доступа к контексту, ACL доступа к группе ресурсов и ACL доступа к категории элемента.

Списки управления доступом к контексту

На вкладке «Доступ к контексту» панели «Обновить группу пользователей» записи в этом списке контролируют, какие административные задачи пользователи могут выполнять в контексте, указанном в записи ACL. Вы создаете новую запись ACL доступа к контексту, нажимая кнопку «Добавить контекст». Разрешения здесь управляют тем, что пользователь может делать и видеть в менеджере MODX в целом. Приведенные здесь разрешения необходимы для применения приведенных ниже разрешений. Например, если у пользователя нет прав на просмотр и редактирование ресурсов в диспетчере, запись ACL доступа к группе ресурсов, дающая пользователю право на публикацию ресурса, не будет применяться.

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

В В группе пользователей-администраторов уже есть записи ACL доступа к контексту как для контекстов «mgr», так и для «веб-контекстов». Это делает эти контексты «защищенными» по умолчанию. Это имеет потенциально запутанный побочный эффект: когда вы создаете нового пользователя, этот пользователь не сможет войти в менеджер, пока вы не поместите пользователя в группу пользователей и не предоставите пользователю доступ в записи ACL контекстного доступа для этого Группа пользователей с контекстом «mgr.» Как только вы это сделаете, пользователь сможет войти в систему, но не сможет увидеть «веб-контекст» в дереве ресурсов в диспетчере, пока вы не предоставите пользователю доступ к , что Контекст в другой записи ACL доступа к контексту для группы пользователей с «веб-контекстом» (это исключение, о котором мы упоминали ранее, из принципа, согласно которому «веб-контекст» влияет только на внешний интерфейс).

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

Допустим, у вас есть группа пользователей, называемая субадминистраторами, и вы хотите, чтобы пользователи в этой группе могли использовать менеджера, но с ограниченными возможностями. Вот шаги, которые вы должны предпринять:

  1. Сначала создайте роль субадминистратора с уровнем полномочий 9.
  2. Создайте группу пользователей SubAdmins и добавьте в нее пользователей с ролью SubAdmin.
  3. Дублировать стандартную политику доступа администратора.
  4. Отредактируйте дубликат и измените имя на SubAdmin.
  5. На вкладке «Разрешения» снимите флажки со всех разрешений, которые вы не хотите предоставлять своим субадминам. Удаление разрешения access_permissions не позволит им изменить свой собственный уровень безопасности и уровень безопасности других пользователей. Удаление разрешений element_tree и file_tree не позволит им видеть эти вкладки на левой панели менеджера. (Примечание: разрешения element_tree и file_tree доступны только в SVN и последующих версиях Revolution RC. )
  6. Сохранить политику
  7. Обновите группу пользователей субадминистраторов, выбрав Безопасность | Контроль доступа | Вкладка «Группы пользователей», щелкните правой кнопкой мыши группу субадминистраторов и выберите «Обновить группу пользователей».
  8. Перейдите на вкладку Контекстный доступ.
  9. Добавьте запись ACL (нажав кнопку «Добавить контекст»). Дайте ему следующее:
  • Контекст: управляющий
  • Минимальная роль: SubAdmin
  • Политика доступа: субадминистратор
  • Перейти к безопасности | Flush Permissions
    1. Если вы выйдете сейчас и войдете в систему как один из субадминистраторов, вход будет успешным, но дерево ресурсов слева будет пустым, потому что мы не предоставили нашим субадминистраторам доступ к «веб-контексту». . Нам нужно создать еще одну запись ACL контекстного доступа со следующим:

    • Контекст: Интернет
    • Минимальная роль: SubAdmin
    • Политика доступа: субадминистратор

    Теперь наши субадмины являются реальными пользователями Manager с ограниченным доступом к Manager.

    Обратите внимание, что мы могли бы сделать это по-другому. Мы могли бы пропустить создание группы пользователей субадминистраторов и просто добавить всех наших пользователей субадминистраторов в группу пользователей администраторов с ролью субадминистраторов. Затем мы бы обновили группу пользователей-администраторов и добавили две записи ACL контекстного доступа, перечисленные выше. Результаты будут такими же, и то, как вы это сделаете, зависит от вашей общей стратегии безопасности. Если вы будете ограничивать, какие документы могут видеть субадминистраторы, вы, вероятно, захотите создать для них отдельную группу пользователей. Если у них будет доступ ко всем документам в менеджере, вы можете добавить их в группу администраторов.

    Обычно я рекомендую *не* помещать других пользователей-администраторов в группу администраторов. Предоставление им собственной группы упрощает понимание и дает вам больше возможностей для настройки формы.

    Ничто из того, что вы делаете в ACL контекстного доступа, не повлияет на то, какие документы любой пользователь может видеть во внешнем интерфейсе. Это можно сделать только в ACL доступа к группе ресурсов, указав контекст, отличный от контекста «mgr».

    Списки управления доступом к группам ресурсов

    На вкладке «Доступ к группам ресурсов» панели «Обновить группу пользователей» записи ACL в этом списке определяют, какие отдельные пользователи ресурсов могут видеть в передней и задней частях, и что они могут делать с ними. эти Ресурсы. Вы создаете новый ACL доступа к группе ресурсов, нажимая кнопку «Добавить группу ресурсов». Как и в случае со списками управления доступом к контексту, после создания записи списка управления доступом к группе ресурсов вы «защитите» ресурсы в указанном контексте. Никто не может видеть их в этом контексте, если им не предоставлен доступ к ним в записи ACL доступа к группе ресурсов.

    Если вы укажете контекст «mgr», ресурсы в группе ресурсов будут видны в дереве ресурсов в диспетчере только пользователям, которым предоставлен доступ к ним. Если вы укажете «веб-контекст», только пользователи, которым был предоставлен доступ к ним (и которые вошли в систему), могут видеть ресурсы во внешнем интерфейсе сайта.

    Эти записи ACL доступа к группе ресурсов имеют те же поля, что и записи контекстного доступа, с добавлением поля, определяющего группу ресурсов.

    Допустим, у вас есть группа пользователей под названием «Редакторы» и группа ресурсов под названием «Новости», содержащая несколько новостных статей. Вы хотите скрыть новостные страницы от пользователей, не являющихся редакторами, в Менеджере. Вы обновляете группу Editors User, чтобы создать запись ACL доступа к группе ресурсов следующим образом:

    • Группа ресурсов: Новости
    • Минимальная роль: Редактор
    • Политика доступа: Ресурс
    • Контекст: управляющий

    Теперь только члены группы «Редактор» с минимальной ролью «Редактор» (или ролью с более низким номером полномочий) могут видеть страницы новостей в Менеджере. У них будут полные права на ресурсы. Чтобы ограничить их, вы можете продублировать политику доступа к ресурсам, изменить имя на «EditorResource», отредактировать дубликат, чтобы снять флажок с разрешений, которые вы не хотите, чтобы они имели, и назначить политику EditorResource в записи ACL вместо политики ресурсов.

    Будучи суперпользователем-администратором, когда вы сбрасываете разрешения (Безопасность | Сброс разрешений), вы заметите, что страницы новостей исчезают из дерева. Чтобы вернуть их, вам нужно либо добавить администратора в группу пользователей «Редакторы» (предположительно с минимальной ролью суперпользователя и политикой доступа «Администратор»), либо обновить группу пользователей «Администратор», добавив запись ACL доступа к группе ресурсов, указывающую Группа ресурсов новостей, контекст «mgr» и снова минимальная роль суперпользователя и политика доступа администратора. Добавление суперпользователя-администратора во все группы пользователей обычно является лучшей стратегией.

    Приведенная выше запись ACL защитит страницы новостей в Менеджере, но любой пользователь по-прежнему сможет просматривать страницы в интерфейсе сайта.

    Допустим, вы хотите скрыть новостные страницы от анонимных пользователей во внешнем интерфейсе. Создайте другой ACL доступа к группе ресурсов следующим образом:

    • Группа ресурсов: Новости
    • Минимальная роль: Редактор
    • Политика доступа: Ресурс
    • Контекст: Интернет

    Теперь страницы новостей могут видеть только члены группы «Редакторы», которые вошли в систему через интерфейс. Эта запись ACL защитит страницы новостей во внешнем интерфейсе, но не повлияет на то, кто может видеть их в Менеджере.

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

    ACL доступа к категории элементов

    Эти ACL работают точно так же, как ACL доступа к группе ресурсов, за исключением того, что вместо защиты ресурсов в группе ресурсов они защищают элементы (фрагменты, фрагменты, шаблоны, переменные шаблона и подключаемые модули) в категории. Сначала создайте категорию, щелкнув правой кнопкой мыши «Категории» в дереве элементов и выбрав «Новая категория». Затем перетащите любые элементы, которые вы хотите защитить, и поместите их в новую категорию. Наконец, перейдите в Безопасность | Контроль доступа | На вкладке «Группы пользователей» щелкните правой кнопкой мыши группу, которую вы хотите изменить, и выберите «Обновить группу пользователей». На вкладке «Доступ к категории элементов» нажмите кнопку «Добавить категорию». Выберите категорию, роль группы пользователей, политику доступа к элементу и контекст «mgr». Сохраните свою работу и сбросьте все разрешения. Элементы в этой категории теперь защищены от всех других пользователей.

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

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

    Управление тем, что пользователи могут делать и видеть в диспетчере

    Если вы просто хотите ограничить действия пользователя в Диспетчере, не скрывая при этом какие-либо ресурсы или элементы, то, в двух словах, вам нужно продублировать стандартную политику Администратора. Затем поместите пользователей в группу пользователей и обновите эту группу пользователей в разделе «Безопасность» -> «Контроль доступа». Создайте запись ACL Context Access для контекста управляющего с созданной вами дублирующей политикой (и ролью с более высоким номером полномочий, чем у администратора). Затем отредактируйте политику дублирования и снимите флажки со всех разрешений, которые вы не хотите, чтобы они имели.

    Это ограничит действия пользователей в Менеджере.

    Если вам нужен более детальный контроль и вы хотите ограничить то, что пользователи могут делать с некоторыми, но не со всеми, ресурсами или элементами, вы можете поместить определенные ресурсы в группы ресурсов и определенные элементы в категории, а затем сделать что-то похожее на выше , но продублируйте политику Resource (для ресурсов) и политику Element (для элементов). Затем вы создаете записи ACL для доступа к группам ресурсов и записи ACL для доступа к категориям элементов с двумя соответствующими политиками и редактируете политики, чтобы снять флажок Разрешения, как указано выше. Это ограничит действия пользователей с определенными объектами в группе ресурсов или категории элементов.

    Вы также можете многое сделать, просто настроив Менеджер. Вы можете скрыть части формы «Создать/редактировать ресурс» с помощью настройки формы. Скройте части дерева ресурсов, установив пользовательский параметр tree_root_id. Полностью скройте дерево элементов и дерево файлов, сняв отметку с разрешений element_tree и file_tree в дублирующей политике администратора. Вы также можете использовать настраиваемые разрешения, чтобы скрыть различные элементы и подэлементы верхнего меню.

    Ограниченные пользователи-менеджеры, которые могут просматривать все документы

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

    Вот шаги для примера, когда вам нужна группа редакторов, не являющихся суперпользователями:

    1. Перейдите на вкладку «Безопасность» -> «Контроль доступа» -> «Роли».
    2. Создайте роль «Редактор» с уровнем полномочий 5.
    3. Перейдите на вкладку Шаблоны политик.
    4. Дублировать политику администратора ; назовите его AdminEditor.
    5. Нажмите на вкладку «Группы пользователей»; щелкните правой кнопкой мыши группу пользователей «Администратор» и выберите «Обновить группу пользователей».
    6. Щелкните вкладку Контекстный доступ.
    7. Щелкните Добавить контекст. Вы создаете запись ACL контекстного доступа; используйте следующие настройки:
    • Контекст: управляющий
    • Минимальная роль: Редактор
    • Политика доступа: AdminEditor
    • Сохранить
  • Перейдите на вкладку «Пользователи».
  • Создайте новую группу пользователей с именем «Редакторы».
  • Добавьте пользователей в группу «Редакторы» с ролью «Редактор».
  • Добавить суперпользователя admin в группу с ролью admin Super User.
  • Щелкните правой кнопкой мыши группу пользователей «Редакторы» и выберите «Обновить группу пользователей».
  • Добавьте запись ACL контекстного доступа с минимальной ролью редактора, контекстом управляющего и политикой AdminEditor.
  • Щелкните вкладку Политики доступа.
  • Щелкните правой кнопкой мыши политику AdminEditor и выберите «Обновить политику».
  • Снимите флажки с тех разрешений, которые вам не нужны.
  • Если вам нужно предоставить разные разрешения разным пользователям, создайте новую роль с другим номером полномочий и новую политику для каждой группы пользователей, которые будут использовать набор разрешений, и повторите шаги, описанные выше, чтобы создать запись ACL контекстного доступа. для каждой группы с соответствующей политикой.

    Дополнительные советы:

    • Помните, что пользователи будут наследовать Разрешения политик в списке Доступ к контексту с минимальными ролями, число которых выше, чем у них в группе.
    • Не забудьте очистить кеш сайта, сбросить все разрешения (и иногда) сбросить все сеансы перед тестированием каких-либо изменений.
    • Обратите внимание, что удаление разрешений file_tree и element_tree полностью скроет эти деревья.
    • Вы можете скрыть определенные TV и поля формы Create/Edit Resource, используя правила настройки формы.
    • Вы также можете скрыть определенные пункты меню в верхнем меню, используя настраиваемые разрешения, но это другое руководство.

    Ограничение пользователей менеджера подмножеством ресурсов с использованием tree_root_id

     

    Примечание: tree_root_id устарел в MODX 2.2.0 и более поздних версиях, но я оставил это здесь, поскольку некоторая информация все еще полезна

    Иногда, вы хотите иметь группу, которая может видеть только некоторые ресурсы в Менеджере. Если вы доверяете своим пользователям, вы можете создать настройку пользователя tree_root_id для каждого пользователя. Параметр tree_root_id представляет собой список идентификаторов ресурсов, разделенных запятыми. Пользователь будет видеть только эти ресурсы и их дочерние элементы в дереве. Это не полностью безопасный вариант, поскольку пользователи, которые могут угадать URL-адрес менеджера ресурса, все равно могут его редактировать.

    Чтобы создать настройку пользователя tree_root_id:

    1. Перейдите в Безопасность -> Управление пользователями
    2. Щелкните правой кнопкой мыши пользователя и выберите «Обновить пользователя».
    3. Выберите вкладку «Настройки»
    4. Нажмите кнопку «Создать новый»
    5. Поместите tree_root_id в поле «Ключ»
    6. Поместите идентификатор корня дерева в поле «Имя»
    7. Поместите разделенный запятыми список идентификаторов ресурсов в поле «Значение»
    8. Нажмите кнопку «Сохранить»
    9. Важно Нажмите кнопку «Сохранить» в правом верхнем углу, чтобы сохранить пользователя
    10. Повторите описанные выше шаги для каждого пользователя
    11. Перейдите в раздел «Безопасность» -> «Сброс разрешений»

    Пользователи теперь должны видеть только те ресурсы в дереве, которые вы им назначили.

    Ограничение пользователей Manager подмножеством ресурсов с использованием групп пользователей и ресурсов

    Здесь есть руководство по сокрытию ресурсов в Manager.

    Здесь есть руководство по созданию пользовательских страниц (например, ограничение доступа нескольких пользователей к их собственным страницам).

    Чтобы действительно ограничить доступ пользователей к ресурсам, вам необходимо использовать группы пользователей и группы ресурсов. Основной процесс заключается в том, чтобы поместить все ресурсы сайта в группу ресурсов и защитить их, создав запись ACL доступа к группе ресурсов, связывающую эту группу ресурсов с группой пользователей-администраторов. Это защищает ресурсы от всех пользователей, не входящих в эту группу. Затем создайте группу пользователей для ограниченных пользователей и группу ресурсов, содержащую ресурсы, к которым они могут получить доступ, и свяжите их с другой записью ACL доступа к группе ресурсов. Это позволяет этим пользователям видеть эти защищенные ресурсы.

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

    Помните, что для входа в Manager и просмотра любых ресурсов в веб-контексте пользователи с ограниченными правами должны иметь запись ACL Context Access как для веб-контекста, так и для контекста управления, как описано ранее на этой странице

    Давайте представим, что вы хотите ограничить членов группы «Редакторы» определенным набором страниц. Вот как бы вы это сделали.

    Создание группы пользователей
    1. Создайте роль «Редактор», как описано ранее
    2. Перейдите в «Безопасность» -> «Контроль доступа» -> вкладка «Группы пользователей»
    3. Нажмите кнопку «Новая группа пользователей»
    4. Поместите «Редакторы» в поле «Имя»
    5. Нажмите кнопку «Сохранить»
    6. Щелкните правой кнопкой мыши группу пользователей Editors и выберите «Обновить группу пользователей».
    7. На вкладке «Пользователи» используйте кнопку «Добавить пользователя в группу», чтобы добавить пользователей
    8. После добавления пользователей нажмите кнопку «Сохранить» в правом верхнем углу.
    Создание группы ресурсов AllDocs
    1. Создайте группу ресурсов с именем AllDocs, используя метод, описанный выше
    2. Перетащите все ресурсы в корне в эту группу ресурсов (дочерние ресурсы будут защищены автоматически)
    3. Сохранить группу ресурсов

    Вы можете загрузить и установить подключаемый модуль DefaultResourceGroup, чтобы автоматически помещать все будущие новые ресурсы в группу AllDocs. Задайте для свойства drg_groups подключаемого модуля значение AllDocs

    Создание группы ресурсов редактора
    1. Создайте новую группу ресурсов с именем Editor
    2. Перетащите в группу только те ресурсы, которые должны видеть редакторы.
    3. Сохранить группу ресурсов
    Защита страниц AllDocs
    1. Перейдите в раздел «Безопасность» -> «Контроль доступа» -> вкладка «Группы пользователей»
    2. Щелкните правой кнопкой мыши группу «Администратор» и выберите «Обновить группу пользователей».
    3. Перейдите на вкладку «Доступ к группе ресурсов»
    4. Нажмите кнопку «Добавить группу ресурсов»
    • Группа ресурсов: AllDocs
    • Минимальная роль: администратор Суперпользователь
    • Политика: Ресурс
    • Контекст: управляющий
    • Сохранить
  • Нажмите кнопку «Сохранить» в правом верхнем углу.
  • Перейдите в раздел «Безопасность» -> «Сброс разрешений»
  • Перейдите в раздел «Сайт» -> «Очистить кэш»
  • В этот момент все ресурсы должны быть защищены от лиц, не являющихся администраторами. Если вы войдете в систему как пользователь Editor, вы не увидите никаких ресурсов в дереве. Следующим шагом является предоставление редакторам доступа к их ресурсам.

    Предоставление редакторам доступа к своим ресурсам
    1. Перейдите в «Безопасность» -> «Контроль доступа» -> вкладка «Группы пользователей»
    2. Щелкните правой кнопкой мыши группу пользователей «Редакторы» и выберите «Обновить группу пользователей».
    3. Перейдите на вкладку «Доступ к группе ресурсов»
    4. Нажмите кнопку «Добавить группу ресурсов»
    • Группа ресурсов: Редактор
    • Минимальная роль: Редактор
    • Политика: Ресурс (или EditorResource, если вы создали эту политику ранее)
    • Контекст: управляющий
    • Сохранить
  • Нажмите кнопку «Сохранить» в правом верхнем углу
  • Перейдите в раздел «Безопасность» -> «Сброс разрешений»
  • Перейдите в раздел «Сайт» -> «Очистить кэш»
  • Если вы войдете в систему как пользователь редактора, вы должны увидеть только ресурсы в редакторе. Группа ресурсов в дереве. Для проверки мы создали группу ресурсов AllDocs и защитили все ее ресурсы, подключив их к группе пользователей-администраторов с помощью записи ACL для доступа к группе ресурсов. Затем мы создали группу ресурсов редактора и предоставили редакторам доступ к ее ресурсам, создав запись ACL доступа к группе ресурсов, соединяющую группу ресурсов редактора с группой пользователей редакторов.

    Здесь есть отличное изображение, созданное пользователем MODX lithiclab, показывающее процесс предоставления группе пользователей доступа к определенному набору ресурсов. при посещении страницы во внешнем интерфейсе, например при очистке кэша или изменении настроек безопасности, вам не нужно беспокоиться об этом разделе. Большинство обычных сниппетов (например, Wayfinder, BreadCrumbs и большинство пользовательских сниппетов) будут выполняться нормально. Весь код также будет выполняться, если вы просматриваете страницу из Менеджера как суперпользователь-администратор.

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

    Unauthorized Versus Error Page

    Это отличие от MODX Evolution. В Revolution, если веб-страница защищена во внешнем интерфейсе, так что ее могут видеть только вошедшие в систему пользователи, по умолчанию анонимные пользователи перенаправляются на страницу «Ошибка (страница не найдена)», а не на «Неавторизованную страницу», когда они попробуйте получить доступ к ресурсу. В Revolution, если у пользователей нет разрешения «загрузить» для ресурса, он как будто не существует — поэтому ответ «страница не найдена». Если вы хотите, чтобы они вместо этого отправлялись на страницу «Неавторизованные», вы можете сделать следующее:

    • Создайте новую запись ACL доступа к группе ресурсов для группы анонимных пользователей с группой ресурсов защищенных ресурсов, контекстом «Интернет», ролью «Член» и политикой доступа «Только загрузка». Сделайте это для каждой защищенной группы ресурсов
    • .

    Обратите внимание, что это не решит проблему для пользователей, которые вошли в систему через внешний интерфейс, но пытаются получить доступ к страницам, на просмотр которых у них нет прав. Чтобы решить эту проблему для этих пользователей, добавьте их в группы пользователей, которым разрешено просматривать страницы, но с ролью «Член». Затем обновите группы пользователей и добавьте еще одну запись ACL доступа к группе ресурсов для группы с группой ресурсов, настроенной на защищенные ресурсы, минимальной ролью «Член» и политикой «Только загрузка».

    Краткий обзор

    Вот краткий обзор, который может помочь, если вы все еще не знаете, как использовать разрешения Revolution

    ?

    1. Первая линия контроля над тем, какие ресурсы пользователи вообще могут видеть в Диспетчере, — это привязка групп пользователей к группам ресурсов в записях ACL доступа к группам ресурсов (с контекстом mgr) — точно так же, как в MODX Evolution. Это эквивалент привязки групп документов к менеджерам групп пользователей в Evolution.
    2. Управление тем, что пользователи в группе пользователей могут делать в диспетчере в целом (например, изменять разрешения, редактировать ресурсы, создавать фрагменты и т. д.), управляется отмеченными разрешениями в политике, которую они назначают в записи ACL контекстного доступа mgr. .
    3. Управление тем, что пользователи в группе пользователей могут *с ресурсами в группе ресурсов* контролируется проверенными разрешениями политики, назначенной для этой группы ресурсов в записи ACL доступа к группе ресурсов, созданной в # 1 (при условии, что Записи ACL контекстного доступа дают им разрешение на выполнение этих действий в диспетчере).
    4. Управление тем, что пользователи в группе пользователей могут *с элементами в категории*, контролируется отмеченными разрешениями на политику, назначенную для этой категории в записи ACL доступа к категории элементов (при условии, что записи ACL доступа к контексту дают им Разрешение на выполнение этих действий в Менеджере).
    5. Пользователи в группе пользователей наследуют разрешения пользователей *в этой группе*, у которых есть роли с более высокими номерами полномочий. Это единственная функция ролей в Revo.

    Все еще запутались?

    Давайте еще раз взглянем на это с точки зрения того, что вы хотите сделать, и установим некоторые твердые правила:

    1. Скрытие выбранных ресурсов в диспетчере всегда выполняется с записями ACL доступа группы ресурсов с политикой, которая является некоторым подмножеством Ресурсная политика и контекст мгр .
    2. Скрытие выбранных ресурсов во внешнем интерфейсе всегда делается с записями ACL доступа группы ресурсов с политикой, которая является некоторым подмножеством политики ресурсов и контекстом сеть .
    3. Управление тем, что пользователь может делать *с определенными ресурсами* (например, просматривать их, публиковать, удалять и т. д.), всегда осуществляется с помощью политики, прикрепленной к любой из двух записей ACL доступа к группе ресурсов, описанных выше.
    4. Скрытие выбранных элементов и управление тем, что пользователи могут делать с ними, точно такие же, как в правилах 1-3, за исключением того, что вы используете записи ACL доступа к категориям элементов вместо записей ACL доступа к группам ресурсов.
    5. Управление тем, что пользователь может делать в диспетчере в целом (например, создавать пользователей, изменять правила безопасности, очищать кеш, редактировать файлы, просматривать дерево элементов и т. д.), всегда выполняется с помощью записи ACL контекстного доступа ( собственно прикрепленная политика) с контекстом мгр .

    После того как вы создадите соответствующие роли, пользователей, группы пользователей, группы ресурсов и политики, все описанные выше шаги будут выполнены в разделе Безопасность | Контроль доступа | Вкладка «Группа пользователей», щелкните правой кнопкой мыши группу пользователей и выберите «Обновить группу пользователей».

    Необходимые записи ACL создаются либо на вкладке «Доступ к контексту» (чтобы контролировать, что пользователи могут делать в диспетчере в целом), либо на вкладке «Доступ к группе ресурсов» (чтобы контролировать, какие ресурсы могут видеть пользователи и что они могут делать с этими конкретными ресурсами). ).

    Где мой полис?

    При попытке добавить политику в запись ACL вы увидите только те политики, которые соответствуют типу создаваемой вами записи ACL. Например, если вы создаете дубликат политики ресурсов и создаете запись ACL для доступа к контексту, вы не увидите свою политику, потому что она там неуместна. Вот как выстраиваются политики:

    • Запись ACL контекстного доступа -> Политика администратора
    • Запись ACL доступа к группе ресурсов -> Политика ресурсов
    • Запись ACL доступа к категории элементов -> Политика элемента

    Убедитесь, что вы продублировали правильную политику для типа записи ACL, которую собираетесь создать.

    Ресурсы безопасности в Bob’s Guides
    • Разрешения Revolution
    • Разрешения на эволюцию
    • Памятка по безопасности Revolution
    • Основные руководства по безопасности
      • Создание нового пользователя
      • Создание новой роли
      • Создание новой группы пользователей
      • Создание новой группы ресурсов
      • Создание новой записи ACL
      • Создание новой категории
      • Создание новой политики
      • Создание нового шаблона политики
      • Редактирование политики
    • Дополнительные руководства по безопасности
      • Создание пользователей-менеджеров
      • Скрытие ресурсов в диспетчере
      • Пользовательские страницы
      • Управление доступом к ресурсам в диспетчере
      • Управление доступом к элементам в диспетчере
      • Скрытие элементов в менеджере
      • Скрытие пунктов главного меню в диспетчере
    • Записи ACL Revolution по умолчанию

    Другие страницы безопасности

    Здесь находится шпаргалка по системе безопасности MODX Revolution.

    Здесь есть учебники по безопасности Revolution.

    Официальная документация по безопасности MODX Revolution находится здесь.

    Посмотрите видео Шона Маккормика (splittingred) о безопасности Revolution здесь.

     

    Моя книга, MODX: Официальное руководство — цифровое издание теперь доступно здесь. Бумажная версия книги доступна на Amazon.

    Если у вас есть книга и вы хотите скачать код, вы можете найти его здесь.

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

    MODX: Официальное руководство состоит из 772 страниц и выходит далеко за рамки этого веб-сайта в объяснении начальных и продвинутых методов MODX. Он включает подробную информацию о:

    • Установка MODX
    • Как работает MODX
    • Работа с ресурсами и элементами MODX
    • Использование Git с MODX
    • Использование общих дополнительных компонентов MODX, таких как SPForm, Login, getResources и FormIt
    • Разрешения безопасности MODX
    • Настройка MODX Manager
    • Использование настройки формы
    • Создание транспортных пакетов
    • Объектные методы MODX и xPDO
    • Системные события MODX
    • Использование PHP с MODX

    Перейдите сюда для получения дополнительной информации о книге.

    Спасибо, что посетили BobsGuides.com

      —  Боб Рэй

    Modx Modx Revolution : Список уязвимостей безопасности

    Скопировать результаты Скачать результаты

    Нажмите ESC, чтобы закрыть

    # CVE-идентификатор Идентификатор CWE # эксплойтов Тип(ы) уязвимости Дата публикации Дата обновления Счет Получен уровень доступа Доступ Сложность Аутентификация конф. Интегр. Доступно.
    1 CVE-2020-25911 611 DoS 31.10.2021 2021-11-02

    6,4

    Нет Удаленный Низкий Не требуется Частичная Нет Частично
    В компоненте modRestServiceRequest в MODX CMS 2. 7.3 была обнаружена уязвимость XML External Entity (XXE), которая может привести к раскрытию информации или отказу в обслуживании (DOS).
    2 CVE-2019-1010123 434 23.07.2019 09.10.2019

    5,0

    Нет Удаленный Низкий Не требуется Нет Частично Нет
    На MODX Revolution Gallery 1.7.0 влияют: CWE-434: Неограниченная загрузка файлов с опасным типом. Результат: создание файла с произвольным именем и содержимым. Компонент: Фильтрация пользовательских параметров перед их передачей в класс phpthumb. Вектор атаки: веб-запрос через /assets/components/gallery/connector.php.
    3 CVE-2018-1000208 22 Реж. Трав. 13.07.2018 07.09.2018

    6,4

    Нет Удаленный Низкий Не требуется Нет Частично Частично
    Версия MODX Revolution <= 2.6.4 содержит уязвимость обхода каталога в /core/model/modx/modmanagerrequest.class.php, которая может привести к удалению файлов. Эта атака, по-видимому, может быть использована через веб-запрос через систему безопасности/логина. Эта уязвимость, по-видимому, была исправлена ​​в pull 13980.
    4 CVE-2018-1000207 732 13.07.2018 03.10.2019

    6,5

    Нет Удаленный Низкий ??? Частично Частично Частично
    Версия MODX Revolution <= 2. 6.4 содержит уязвимость неправильного контроля доступа при фильтрации пользовательских параметров перед их передачей в класс phpthumb, что может привести к созданию файла с произвольным именем файла и содержимым. Эта атака может быть использована через веб-запрос. Эта уязвимость, похоже, была исправлена ​​в коммите 06bc9.4257408f6a575de20ddb955aca505ef6e68.
    5 CVE-2018-20758 79 XSS 06.02.2019 23.10.2019

    3,5

    Нет Удаленный Средний ??? Нет Частично Нет
    MODX Revolution до v2.7.0-pl позволяет XSS через пользовательские настройки, такие как описание.
    6 CVE-2018-20757 79 XSS 06. 02.2019 06.02.2019

    4,3

    Нет Удаленный Средний Не требуется Нет Частично Нет
    MODX Revolution до v2.7.0-pl позволяет XSS через расширенное пользовательское поле, такое как имя контейнера или имя атрибута.
    7 CVE-2018-20756 79 XSS 06.02.2019 06.02.2019

    4,3

    Нет Удаленный Средний Не требуется Нет Частично Нет
    MODX Revolution до v2.7.0-pl позволяет использовать XSS через ресурс документа (например, заголовок страницы), который неправильно обрабатывается во время действия «Обновить», действия «Быстрое редактирование» или просмотра журналов менеджера.
    8 CVE-2018-20755 79 XSS 06.02.2019 06.02.2019

    4,3

    Нет Удаленный Средний Не требуется Нет Частично Нет
    MODX Revolution до v2.7.0-pl позволяет использовать XSS через поле «Фото пользователя».
    9 CVE-2018-17556 79 XSS 26.09.2018 15.11.2018

    3,5

    Нет Удаленный Средний ??? Нет Частично Нет
    MODX Revolution v2. 6.5-pl позволяет сохранять XSS с помощью действия «Создать новый медиа-источник».
    10 CVE-2018-10382 79 XSS 01.06.2018 27.06.2018

    3,5

    Нет Удаленный Средний ??? Нет Частично Нет
    MODX Revolution 2.6.3 имеет XSS.
    11 CVE-2017-1000223 79 XSS 17.11.2017 01.12.2017

    3,5

    Нет Удаленный Средний ??? Нет Частично Нет
    Уязвимость внедрения сохраненного веб-контента (WCI, также известная как XSS) присутствует в MODX Revolution CMS версии 2. 5.6 и более ранних версиях. Аутентифицированный пользователь с разрешениями на редактирование пользователей может сохранить вредоносный код JavaScript в качестве имени группы пользователей и потенциально получить контроль над учетными записями жертв. Это может привести к повышению привилегий, обеспечивающих полный административный контроль над CMS.
    12 CVE-2017-11744 79 XSS 2017-07-30 2017-08-02

    4,3

    Нет Удаленный Средний Не требуется Нет Частично Нет
    В MODX Revolution 2.5.7 параметры «ключ» и «имя» в модуле «Системные настройки» уязвимы для XSS. Вредоносная полезная нагрузка, отправленная на connectors/index.php, будет запускаться каждым пользователем при посещении этого модуля.
    13 CVE-2017-9071 79 XSS 2017-05-18 30.05.2017

    2,6

    Нет Удаленный Высокий Не требуется Нет Частично Нет
    В MODX Revolution до версии 2.5.7 злоумышленник мог запустить XSS, внедрив полезную нагрузку в заголовок HTTP-узла запроса. Это можно использовать только в сочетании с другими проблемами, такими как отравление кеша.
    14 CVE-2017-9070 79 XSS 2017-05-18 30.05.2017

    3,5

    Нет Удаленный Средний ??? Нет Частично Нет
    В MODX Revolution до версии 2. 5.7 пользователь с правами на редактирование ресурсов может вставлять полезную нагрузку XSS в заголовок любого сообщения через параметр pagetitle в коннекторах/index.php.
    15 CVE-2017-9069 434 Исполнительный код 2017-05-18 30.05.2017

    6,5

    Нет Удаленный Низкий ??? Частично Частично Частично
    В MODX Revolution до версии 2.5.7 пользователь с правами на загрузку файлов мог выполнять произвольный код, загружая файл с именем .htaccess.
    16 CVE-2017-9068 79 XSS 2017-05-18 30.05.2017

    4,3

    Нет Удаленный Средний Не требуется Нет Частично Нет
    В MODX Revolution до версии 2. 5.7 злоумышленник может инициировать Reflected XSS, вводя полезные данные в несколько полей на странице настройки, что демонстрируется параметром database_type.
    17 CVE-2017-9067 22 Реж. Трав. 2017-05-18 31.05.2017

    4,4

    Нет Местный Средний Не требуется Частично Частично Частично
    В MODX Revolution до 2.5.7, когда используется PHP 5.3.3, злоумышленник может включать и выполнять произвольные файлы на веб-сервере из-за недостаточной проверки параметра действия для setup/index.php, также известного как обход каталога.
    18 CVE-2017-8115 22 Реж. Трав. +Информация 25. 04.2017 05.05.2017

    5,0

    Нет Удаленный Низкий Не требуется Частично Нет Нет
    Обход каталога в setup/processors/url_search.php (он же страница поиска неиспользуемого процессора) в MODX Revolution 2.5.7 может позволить удаленным злоумышленникам получить информацию о системном каталоге.
    19 CVE-2017-7324 94 Исполнительный код 30.03.2017 2020-01-10

    7,5

    Нет Удаленный Низкий Не требуется Частично Частично Частично
    setup/templates/findcore. php в MODX Revolution 2.5.4-pl и более ранних версиях позволяет удаленным злоумышленникам выполнять произвольный PHP-код с помощью параметра core_path.
    20 CVE-2017-7323 Исполнительный код 30.03.2017 2020-01-10

    6,8

    Нет Удаленный Средний Не требуется Частично Частично Частично
    Функции (1) обновления и (2) установки пакетов в MODX Revolution 2.5.4-pl и более ранних версиях по умолчанию используют http://rest.modx.com, что позволяет злоумышленникам-посредникам подделывать серверы и инициировать выполнение произвольного кода, используя отсутствие механизма защиты HTTPS.
    21 CVE-2017-7322 295 Исполнительный код 30. 03.2017 2020-01-10

    6,8

    Нет Удаленный Средний Не требуется Частично Частично Частично
    Функции (1) обновления и (2) установки пакетов в MODX Revolution 2.5.4-pl и более ранних версиях не проверяют сертификаты X.509 с SSL-серверов, что позволяет злоумышленникам-посредникам подделывать серверы и запускать выполнение произвольного кода через созданный сертификат.
    22 CVE-2017-7321 94 Исполнительный код 30.03.2017 2020-01-10

    7,5

    Нет Удаленный Низкий Не требуется Частично Частично Частично
    setup/controllers/welcome. php в MODX Revolution 2.5.4-pl и более ранних версиях позволяет удаленным злоумышленникам выполнять произвольный код PHP с помощью параметра config_key в URI setup/index.php?action=welcome.
    23 CVE-2017-7320 79 DoS XSS Http R.Spl. 30.03.2017 2020-01-10

    4,3

    Нет Удаленный Средний Не требуется Нет Частично Нет
    setup/controllers/language.php в MODX Revolution 2.5.4-pl и более ранних версиях не ограничивает должным образом языковой параметр, что позволяет удаленным злоумышленникам проводить атаки с использованием файлов cookie и вызывать отказ в обслуживании (исчерпание квоты файлов cookie) или проводить HTTP Ответ Разделение атак с результирующим XSS через недопустимое значение параметра.
    24 CVE-2016-10039 22 Реж. Трав. Включение файла 24.12.2016 14.11.2019

    7,5

    Нет Удаленный Низкий Не требуется Частично Частично Частично
    Обход каталога в /connectors/index.php в MODX Revolution до версии 2.5.2-pl позволяет удаленным злоумышленникам выполнять включение/обход/манипулирование локальными файлами с помощью созданного параметра dir, связанного с браузером/каталогом/getfiles.
    25 CVE-2016-10038 22 Реж. Трав. Включение файла 24.12.2016 29.12.2016

    7,5

    Нет Удаленный Низкий Не требуется Частично Частичная Частично
    Обход каталога в /connectors/index. php в MODX Revolution до версии 2.5.2-pl позволяет удаленным злоумышленникам выполнять включение/обход/манипулирование локальными файлами с помощью созданного параметра dir, связанного с браузером/каталогом/удалением.
    26 CVE-2016-10037 22 Реж. Трав. Включение файла 24.12.2016 14.11.2019

    7,5

    Нет Удаленный Низкий Не требуется Частично Частично Частично
    Обход каталога в /connectors/index.php в MODX Revolution до версии 2.5.2-pl позволяет удаленным злоумышленникам выполнять включение/обход/манипулирование локальными файлами с помощью созданного параметра id (aka dir), связанного с браузером/каталогом/getlist.
    27 CVE-2015-6588 79 XSS 29. 08.2017 2017-09-02

    4,3

    Нет Удаленный Средний Не требуется Нет Частично Нет
    Уязвимость межсайтового скриптинга (XSS) в файле login-fsp.html в MODX Revolution до версии 1.9.1 позволяет удаленным злоумышленникам внедрить произвольный веб-скрипт или HTML через запрос QUERY_STRING.
    28 CVE-2014-8992 79 XSS 22.12.2014 22.10.2019

    4,3

    Нет Удаленный Средний Не требуется Нет Частично Нет
    Уязвимость межсайтового скриптинга (XSS) в файле manager/assets/fileapi/FileAPI. flash.image.swf в MODX Revolution 2.3.2-pl позволяет удаленным злоумышленникам внедрить произвольный веб-скрипт или HTML через параметр обратного вызова.
    29 CVE-2014-8775 200 +Информация 03.12.2014 22.10.2019

    5,0

    Нет Удаленный Низкий Не требуется Частично Нет Нет
    MODX Revolution 2.x до 2.2.15 не включает флаг HTTPOnly в заголовок Set-Cookie для файла cookie сеанса, что упрощает удаленным злоумышленникам получение потенциально конфиденциальной информации через доступ сценария к этому файлу cookie.
    30 CVE-2014-8774 79 XSS 03.12.2014 22. 10.2019

    4,3

    Нет Удаленный Средний Не требуется Нет Частично Нет
    Уязвимость межсайтового скриптинга (XSS) в файле manager/index.php в MODX Revolution 2.x до 2.2.15 позволяет удаленным злоумышленникам внедрить произвольный веб-скрипт или HTML через параметр context_key.
    31 CVE-2014-8773 352 Обход CSRF 03.12.2014 22.10.2019

    6,8

    Нет Удаленный Средний Не требуется Частично Частично Частично
    MODX Revolution 2.x до 2. 2.15 позволяет удаленным злоумышленникам обходить механизм защиты от подделки межсайтовых запросов (CSRF) путем (1) пропуска токена CSRF или с помощью (2) длинной строки в параметре токена CSRF.
    32 CVE-2014-5451 79 XSS 06.11.2014 2018-10-09

    4,3

    Нет Удаленный Средний Не требуется Нет Частично Нет
    Уязвимость межсайтового скриптинга (XSS) в файле manager/templates/default/header.tpl в MODX Revolution 2.3.1-pl и более ранних версиях позволяет удаленным злоумышленникам внедрить произвольный веб-скрипт или HTML через параметр «a» в файл manager/. ПРИМЕЧАНИЕ. Эта проблема возникает из-за регрессии CVE-2014-2080.
    33 CVE-2014-2736 89 Код выполнения Sql 2014-04-24 22. 10.2019

    7,5

    Нет Удаленный Низкий Не требуется Частично Частично Частично
    Множественные уязвимости SQL-инъекций в MODX Revolution до версии 2.2.14 позволяют удаленным злоумышленникам выполнять произвольные SQL-команды через (1) идентификатор сеанса (PHPSESSID) для index.php или удаленным аутентифицированным пользователям выполнять произвольные SQL-команды через (2) пользовательский параметр для Connectors/security/message.php или (3) параметр id в файле manager/index.php.
    34 CVE-2014-2311 89 Код выполнения Sql 2014-03-11 22.10.2019

    7,5

    Нет Удаленный Низкий Не требуется Частично Частично Частично
    Уязвимость SQL-инъекции в modx. class.php в MODX Revolution 2.0.0 до 2.2.13 позволяет удаленным злоумышленникам выполнять произвольные команды SQL через неуказанные векторы.
    35 CVE-2014-2080 79 XSS 01.03.2014 30.07.2015

    4,3

    Нет Удаленный Средний Не требуется Нет Частично Нет
    Уязвимость межсайтового скриптинга (XSS) в файле manager/templates/default/header.tpl в ModX Revolution до версии 2.2.11 позволяет удаленным злоумышленникам внедрить произвольный веб-скрипт или HTML через параметр «a».
    36 CVE-2010-5278 22 1 Реж. Трав. 07.10.2012 2020-01-10

    4,3

    Нет Удаленный Средний Не требуется Частично Нет Нет
    Уязвимость обхода каталога в файле manager/controllers/default/resource/tvs. php в MODx Revolution 2.0.2-pl и, возможно, ранее, когда magic_quotes_gpc отключена, позволяет удаленным злоумышленникам читать произвольные файлы через .. (точку) в Параметр class_key. ПРИМЕЧАНИЕ: некоторые из этих сведений получены из информации третьих лиц.

    Общее количество уязвимостей: 36 Страница : 1 (Эта страница)

    Разрешения и пользователи — веб-дизайн и услуги

    Содержание

    • Пользователи
    • ролей
    • Групповые разрешения
    • Настройка разрешений для файлового менеджера
    • Настройка разрешений для TinyMCE

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

    Пользователи

    У MODx есть два типа пользователей:

    1. Пользователи-менеджеры: люди, которые могут использовать интерфейс менеджера MODx для создания и редактирования контента
    2. Веб-пользователи: люди, которым не требуется доступ администратора, но которым необходимо войти в систему для других функций веб-сайта, например, для комментирования блогов.

    Это различие исчезнет в версии 0.9.7 и выше, но на данный момент оно все еще существует.

    Чтобы создать пользователя-менеджера

    Перейдите к Security > Manager Users , затем нажмите «Новый пользователь».

    Веб-пользователи

    На данный момент это руководство не касается веб-пользователей. В большинстве случаев эти пользователи будут создаваться с помощью отдельного скрипта — например, скрипта для ведения блога. Таким образом, полное обсуждение веб-пользователей выходит за рамки этого конкретного руководства.

    Роли

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

    • Администратор: Учетная запись администратора по умолчанию (эту роль нельзя изменить или удалить)
    • Разработчик: Доступ ко всему, кроме разрешений пользователей, ролей и конфигурации сайта
    • Designer Plus: Доступ к содержимому, файлам [примечание] , шаблонам, фрагментам и фрагментам
    • Дизайнер: Доступ к содержимому, файлам [примечание] и шаблонам
    • Редактор: Доступ к содержимому и файлам [примечание]
    • Корректор: Возможность редактировать контент, но не создавать и не удалять контент, а также нет доступа к файлам.

    Примечания о файлах:

    1. Чтобы предоставить доступ к файловому менеджеру (для загрузки PDF-файлов, документов Word и т. д.), необходимо прокрутить страницу до конца до раздела «Управление конфигурацией». » и выберите «Использовать файловый менеджер».
    2. Вы можете ограничить доступ пользователей к подкаталогам в файловом менеджере.

    Важные моменты о ролях:

    • Всем управляющим пользователям назначается одна и только одна роль. Пользователю-руководителю нельзя назначить более одной роли или вообще не назначать ролей.
    • Роли не контролируют, к каким веб-страницам или разделам сайта имеет доступ пользователь. Для этого необходимо использовать групповые разрешения.

    Чтобы создать роль

    Перейдите Безопасность > Роли > Создать новую роль . Установите флажки рядом с разрешениями, которые вы хотите предоставить.

    Чтобы назначить роль администратора

    Выберите соответствующий параметр в раскрывающемся списке «Роль пользователя» при создании или изменении пользователя ( Безопасность > Пользователи-менеджеры ).

    Групповые разрешения

    В MODx способ ограничения доступа к документам осуществляется с помощью групповых разрешений. Существует два типа групп:

    1. Группы пользователей
    2. Группы документов

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

    Пример

    Вот реальный сценарий. Допустим, у вас есть 13 организаций, информацию о которых вы хотите опубликовать на своем веб-сайте: организация A, организация B, организация C и т.  д. до организации M. Вы хотите предоставить определенным людям в каждой организации доступ к редактированию их собственной страницы, но не веб-страницы других организаций. Чтобы усложнить ситуацию, организации с A по F относятся к категории 1, а остальные относятся к категории 2. Вы хотите назначить группу «менеджеров категории 1» для наблюдения за веб-страницами всех организаций категории 1 и вы хотите назначить другую группу «менеджеров категории 2» для наблюдения за веб-страницами организаций категории 2. Помимо всего этого, у вас есть «царь организации», который отвечает за надзор за всеми организациями в обеих категориях. .

    Вот как это можно настроить:

    1. Создайте группу пользователей для каждой организации. Чтобы упростить задачу, вы можете называть группы пользователей «Организация А», «Организация Б» и так далее до «Организация М».
    2. Создайте группу документов для каждой организации. Я бы использовал такое же соглашение об именах («Организация А», «Организация Б» и т. д.).
    3. Создайте группу пользователей под названием «Категория 1» и группу пользователей под названием «Категория 2».
    4. Создайте группу пользователей под названием «Организации».
    5. Свяжите группы пользователей с соответствующими группами документов .
      • Свяжите группы пользователей для отдельных организаций только с одной группой документов, например группа пользователей «Организация А» будет связана с группой документов «Организация А».
      • Свяжите группу пользователей «Категория 1» со всеми группами документов для каждой из организаций, принадлежащих к Категории 1. Организации от A до F относятся к Категории 1, поэтому свяжите группу пользователей «Категория 1» с группами документов «Организация A» через «Организацию F».
      • Свяжите группу пользователей «Организации» с каждой из групп документов организации.
    6. Назначьте пользователей в соответствующие группы пользователей.
    7. Назначение документов соответствующей группе(ам) документов.

    Чтобы создать группу пользователей

    Перейдите Безопасность > Разрешения менеджера > Группы пользователей . Введите имя группы в разделе «Создать новую группу пользователей». Нажмите «Отправить».

    Чтобы создать группу документов

    Перейти к Безопасность > Разрешения менеджера > Группы документов . Введите имя группы в разделе «Создать новую группу пользователей». Нажмите «Отправить».

    Чтобы связать группы пользователей с группами документов

    Перейдите к Безопасность > Разрешения менеджера > Ссылки групп пользователей/документов . Выберите имя группы документов из раскрывающегося списка документов. Нажмите «Добавить». Вы можете повторить этот процесс, чтобы добавить несколько групп документов в одну группу пользователей.

    Добавление пользователя в группу пользователей

    Перейдите к Security > Manager Users , затем щелкните имя пользователя (или нажмите «Новый пользователь»). Прокрутите вниз, пока не увидите «Разрешения на доступ». Выберите соответствующую(ие) группу(ы) пользователей. Обратите внимание, что вы не можете добавлять пользователей в группы документа , только в группы пользователей.

    Чтобы добавить документ в группу документов

    Нажмите на страницу в дереве документов слева, затем нажмите «Редактировать» в главном окне. Прокрутите до нижней части экрана, пока не увидите список «Разрешения на доступ». Выберите из списка соответствующую(ие) группу(ы) документов. Обратите внимание, что вы не можете добавить документ в пользователя группы, только для документов групп.

    Важные замечания о групповых разрешениях:

    • По умолчанию документы не имеют ограничений доступа. Если документы не относятся к определенной группе, они доступны для редактирования всеми группами документов. В большинстве многопользовательских настроек это плохая идея. Если вы не являетесь небольшой группой администраторов с полными правами, которые полностью доверяют друг другу, вы, вероятно, не хотите, чтобы какой-либо документ был полностью доступен для редактирования всеми. Вы должны создать группы и отнести все страницы хотя бы к одной группе.
    • Пользователи могут получить доступ только к тем файлам, которые принадлежат их группе. Если пользователь не входит в группу, он сможет получить доступ только к документам, помеченным как «Все группы документов (общедоступные)». Если все документы назначены группе (как и должно быть), этот пользователь не сможет получить доступ ни к каким документам.
    • Документы наследуют разрешения своих родительских документов. По умолчанию, когда вы создаете документ, он наследует разрешения своего родительского документа, что, как правило, хорошо… если только вы не осознаете, что забыли назначить правильные разрешения родительскому документу. Затем вам нужно вернуться и вручную связать каждый документ с соответствующей группой (группами). Особенно важно установить правильные разрешения при создании страниц на корневом уровне сайта, потому что без какого-либо родительского документа для наследования они будут доступны для редактирования всеми пользователями по умолчанию, что, как я упоминал ранее, вероятно, плохо.

    ПРЕДУПРЕЖДЕНИЕ. Пользователям должно быть предоставлено разрешение хотя бы на один документ на корневом уровне. К сожалению, система разрешений в MODx не позволяет пользователям получать доступ к подкаталогам, если они также не могут получить доступ к родительскому документу(ам). Если вы не предоставите доступ хотя бы к одной строке родительского документа (ов) вплоть до корневого уровня, пользователи увидят пустое дерево документов и не смогут ничего получить. Это недостаток MODx, потому что это означает, что пользователям должны быть предоставлены полные права редактирования всех родительских документов по этому пути, даже если вы не хотите, чтобы они имели такой доступ. Используя приведенный выше пример, если путь к главной странице «Организация А» — /organizations/category1/organizationA/, вы должны обозначить документы «organizations» и «category1» как принадлежащие группе документов «Организация A». Люди, принадлежащие к группе документов «Организация А», смогут редактировать все страницы в разделе «Организация А», как вы хотели и ожидали, но они также смогут редактировать родительские документы «организации» и «категория 1». как, возможно, вы не ожидаете, и вы, конечно, не хотите. Но так оно и есть. В настоящее время нет способа обойти этот недостаток в системе разрешений MODx.

    Настройка разрешений для файлового менеджера

    Если вы мудро решите, что не хотите, чтобы все ваши пользователи имели полный доступ ко всем файлам в файловом менеджере (папке «активы»), вам нужно будет ограничить их доступ к определенному подкаталогу в этой папке. Это звучит достаточно просто, и в некотором смысле так оно и есть, но все усложняется тем, как работает файловый браузер для текстовых редакторов MODx.

    Принцип достаточно прост: чтобы ограничить пользователя определенным каталогом в файловом менеджере, установите для этого пользователя «Путь к файловому менеджеру» подкаталог в папке «assets». Например, если путь к файловому менеджеру по умолчанию «/home/web/public_html/assets/» [примечание] вы можете установить каталог для пользователя в группе «Организация A» на что-то вроде «/home/web/public_html/assets/org_a/». Но нужно учитывать и другие факторы. Если вы хотите, чтобы люди из групп пользователей «Организации» и «Категория 1» также имели доступ к этой папке, вам, вероятно, следует поместить путь в аналогичную иерархию. Что-то вроде этого может работать: «/home/web/public_html/assets/orgs/cat1/org_a/».

    Примечание: Путь по умолчанию для файлового менеджера задается в конфигурации сайта в разделе Инструменты > Конфигурация > Диспетчер файлов > Путь к диспетчеру файлов .

    Чтобы настроить путь к файловому менеджеру

    Перейдите к Security > Manager Users , щелкните имя пользователя, которого хотите изменить (или выберите «Новый пользователь»), затем щелкните вкладку «Пользователь» и введите желаемый путь для «Пути файлового менеджера».

    • Настройка пути диспетчера файлов не влияет на браузер файлов из редактора форматированного текста. Этот путь необходимо указать отдельно (см. раздел «Настройка разрешений для TinyMCE»).

    Настройка разрешений для TinyMCE

    TinyMCE можно настроить для каждого пользователя с точки зрения интерфейса и файлового браузера. Настройки по умолчанию для сайта доступны в разделе Инструменты > Конфигурация > Интерфейс и функции > Настройки TinyMCE . Чтобы настроить эти параметры для отдельных пользователей, перейдите в Security > Manager Users , щелкните имя пользователя, которого хотите изменить (или выберите «Новый пользователь»), затем щелкните вкладку «Пользователь» и прокрутите вниз до Параметры «Путь к ресурсу» и «URL-адрес ресурса».

    Настройка папки файлового браузера

    Вероятно, вы хотите, чтобы путь файлового менеджера совпадал с путем файлового браузера, используемого в текстовом редакторе TinyMCE с широкими возможностями. Вам нужно изменить два пути: «Путь к ресурсу» и «URL-адрес ресурса». Сделайте «Путь к ресурсу» таким же, как «Путь к файловому менеджеру». В нашем примере путь будет «/home/web/public_html/assets/orgs/cat1/org_a/». Для «URL-адреса ресурса» преобразуйте этот путь в общедоступный URL-адрес веб-сайта: «http://your_web_site.com/home/web/public_html/assets/orgs/cat1/org_a/».

    Важно: Если вы настраиваете путь к файловому браузеру, вам нужно будет создать две подпапки в этом пути: «изображения» и «файлы». Браузер файлов ищет все изображения в папке с именем images и все файлы в папке с именем «файлы». Если этих папок не существует, пользователи не смогут воспользоваться файловым браузером. В нашем примере папки будут находиться по следующим путям: «/home/web/public_html/assets/orgs/cat1/org_a/images/» и «/home/web/public_html/assets/orgs/cat1/org_a/files /”. Вам НЕ нужно вводить эти пути где-либо в настройках конфигурации, но папки должны существовать для работы файлового браузера.

    Настройка интерфейса TinyMCE

    Вам не нужно настраивать интерфейс TinyMCE. Если вы оставите все файлы в разделе «Настройки TinyMCE» пустыми, пользователям будут предоставлены функции по умолчанию, указанные в настройках сайта ( Инструменты > Конфигурация > Интерфейс и функции > Настройки TinyMCE ). Но вы можете решить, что хотите, чтобы у некоторых пользователей были настроенные версии интерфейса TinyMCE. Есть предустановленные «Темы» на выбор: Простая, Расширенная, Редактор контента и Пользовательская. Выберите один из этих вариантов.

    Установка параметров для «Пользовательских плагинов», «Пользовательских кнопок» и «Селекторов CSS» выходит за рамки настоящего руководства, но я упомяну один полезный параметр: добавление элементов управления редактированием таблиц. Вероятно, это следует сделать для всех пользователей, а не только для определенных. Чтобы добавить параметры редактирования таблицы, введите «tablecontrols» в строке 3 «Пользовательские кнопки». Прокрутите вверх и нажмите «Сохранить».

    ПРЕДУПРЕЖДЕНИЕ: Невозможно установить пользовательский файл CSS для каждого пользователя. Если вы задали «Путь к файлу CSS» в конфигурации сайта ( Tools > Configuration > Interface and Features > TinyMCE Settings ), вы застряли с этой таблицей стилей несмотря ни на что, даже на страницах, которые ее не используют. Это настоящий позор и сильно ограничивает полезность опции «Путь к файлу CSS». Один неуклюжий обходной путь — ограничить количество классов, доступных для TinyMCE, перечислив их в опции сайта «Селекторы CSS», а затем убедиться, что все таблицы стилей содержат все эти конкретные классы.

    Список дел по веб-доступности для MODx Manager

    Список дел по веб-доступности для MODx Manager

    Оценка Пола Бохмана с использованием автоматизированных инструментов, таких как FireEyes/WorldSpace от Deque, Wave от WebAIM, но в основном это ручная оценка, сравнивающая действия веб-сайта с Руководством по доступности веб-контента 2.0 и передовыми методами обеспечения доступности веб-сайтов.

    Содержание

    • Резюме
    • Справочная информация о веб-доступности
    • стилей
    • Экран входа в систему
    • Общая структура страницы
    • Верхнее главное меню (убербар)
    • Боковая панель дерева
    • Модальные диалоги
    • Добавить/редактировать ресурс
    • Еще не все. ..

    Резюме

    Доступность для людей с ограниченными возможностями имеет решающее значение не только для самих людей с ограниченными возможностями, которые в настоящее время не могут использовать менеджер MODx, но и для компаний, которые надеются использовать MODx. Государственные учреждения, в частности, подверглись бы юридическому риску, если бы решили использовать MODx из-за несоответствия интерфейса менеджера руководящим принципам веб-доступности.

    Эта оценка еще не завершена, но появились некоторые тенденции:

    • Доступность клавиатуры:
      • В менеджере MODx есть много мест, где требуется мышь. Это делает невозможным использование слепыми пользователями программ чтения с экрана, потому что мышь бесполезна для тех, кто не видит, где ее щелкнуть. Это также делает невозможным это для зрячих пользователей клавиатуры, которые не могут пользоваться мышью, возможно, из-за тремора в руках, или отсутствия рук и использования палочки для рта, или из-за другого подобного заболевания. Многие динамические виджеты (таблицы, списки с множественным выбором и т. д.) необходимо дополнить атрибутами ARIA и сочетаниями клавиш в стиле ARIA, чтобы обеспечить эффективное взаимодействие программ чтения с экрана.
    • Управление фокусом клавиатуры:
      • Фокус клавиатуры должен следовать за действиями динамических сценариев (модальные окна, проверка форм и т. д.).
    • Метки и варианты текста:
      • Каждый активный элемент (ссылки, кнопки и т. д.) и каждый важный элемент, подобный изображению (графика и значки шрифтов), нуждаются в текстовой метке или текстовой альтернативе. Без метки или альтернативного текста программам чтения с экрана нечего читать, поэтому пользователи не знают, что это за элементы.

    Есть и другие проблемы, но вышеперечисленные проблемы широко распространены и должны решаться широко в менеджере MODx.

    Общие сведения о веб-доступности

    • Инвалиды по зрению:
      • Слепым пользователям программы чтения с экрана необходимо:
        • альтернативный текст для изображений, значков и т. д.
        • метки на элементах формы
        • полная доступность с клавиатуры всех функций, включая раскрывающиеся меню, всплывающие подсказки, списки вкладок, модальные окна и т. д.
        • управление фокусом с динамическим содержимым, таким как сообщения об ошибках/обратная связь, динамически загружаемое содержимое AJAX и т. д.
        • логический порядок табуляции
        • действительная ссылка и текст кнопки
        • хорошая структура документа (заголовки, заголовки таблиц, списки, ориентиры)
      • Пользователям с плохим зрением необходимо:
        • хороший цветовой контраст
        • легко видимые стили :focus и, желательно, стили :hover тоже
      • Дальтоникам необходимо:
        • информация, представленная способом, не зависящим от цвета
    • Глухим пользователям необходимо:
      • Стенограммы и субтитры для аудио/визуального контента (не проблема с менеджером MODx)
    • Пользователям с двигательными нарушениями необходимо:
      • полная функциональность клавиатуры (см. выше для слепых пользователей)
      • легко видимые стили :focus (некоторые люди вообще не могут пользоваться мышью, поэтому им нужно всегда знать, где находится фокус клавиатуры)
    • Пользователям с когнитивными нарушениями (включая распространенные нарушения чтения, СДВ и другие) необходимо:
      • простота визуального оформления, организации процессов и т. д.
      • четкие инструкции
      • хорошие механизмы предотвращения ошибок
      • хороших, интуитивно понятных механизмов восстановления после ошибок

    Модели

    • Визуальный индикатор фокусировки клавиатуры:
      • Визуальный индикатор фокусировки на клавиатуре либо отсутствует в некоторых местах, либо его трудно увидеть. Это можно добавить в manager/templates/default/css/index.css:
        body *:focus {outline:2px solid #00948e !important;}
        body #modx-header *:focus {outline:2px solid #fbf5be !important;}

        Это решит проблему почти везде, но потребуется добавить дополнительные стили и/или JavaScript, чтобы убедиться, что вокруг настраиваемых флажков есть видимый контур. Я понимаю, что это несколько влияет на дизайн, но наличие легко видимого индикатора фокусировки клавиатуры является требованием доступности и оказывает огромное положительное влияние на людей, которые не могут использовать мышь. Воздействие на пользователей мыши минимально. Они увидят это в полях формы, но это, вероятно, хорошо. Они не увидят его при наведении курсора мыши (хотя вы, безусловно, можете добавить те же стили для :hover, что также будет полезно для доступности, хотя и не является таким уж обязательным требованием).2861 [ПРИМЕЧАНИЕ. Я только что заметил, что приведенные выше стили лишь частично работают в Safari и Chrome, по-видимому, из-за некоторых конфликтов с другими стилями, специфичными для webkit, где-то в таблице стилей, поэтому требуется дополнительная работа, чтобы визуальный индикатор фокуса клавиатуры работал в браузеры webkit.]
    • Цветовой контраст:
      • Коэффициент цветовой контрастности светлого текста во многих местах не соответствует стандарту WCAG 4,5:1 для обычного текста и 3:1 для крупного текста. Цветовой контраст можно анализировать с помощью автоматизированных инструментов, таких как FireEyes и Wave.

    Экран входа в систему

    • Этикетки:
      • В поле «имя пользователя или адрес электронной почты» должен быть тег
    • Обязательные поля:
      • Используйте aria-required=»true» для всех обязательных элементов . Программы чтения с экрана сообщат «требуется» при чтении пользователям.
    • Порядок вкладок клавиатуры:
      • Порядок табуляции в основном правильный, но селектор языка в нижнем левом углу не в порядке. Его следует переместить в исходный код так, чтобы он был последним на странице в порядке вкладок, как тогда, когда экран входа находится в состоянии по умолчанию, так и когда активирована функция «забыли свой логин». Я заметил, что для некоторых ссылок и полей используется tabindex. Лучше не использовать tabindex с любыми положительными числами, потому что он переопределяет поведение вкладок браузера по умолчанию способами, которые часто нежелательны для пользователей клавиатуры (tabindex=»0″ допустимо поместить что-то в обычный поток вкладок, а tabindex=»-1 » допустимо сделать что-то фокусируемым с помощью JavaScript, но tabindex=»1″ или больше — не лучшая практика). Одна из проблем с tabindex положительных чисел заключается в том, что если вы забудете добавить значение tabindex в ссылку или поле формы, например ссылку «забыли свой логин», а также в поле «имя пользователя или адрес электронной почты» и «отправить электронное письмо для активации», button — вы рискуете навести порядок, что здесь и произошло. Рекомендация состоит в том, чтобы для начала просто расположить вещи в правильном порядке табуляции в DOM и не изменять порядок табуляции с помощью tabindex положительных чисел.
    • Управление фокусом клавиатуры:
      • Когда пользователи нажимают «Забыли логин?» фокус клавиатуры должен переместиться в поле формы «имя пользователя или электронная почта».
    • Сообщения об ошибках/отклики:
      • Сообщения обратной связи («Пользователь не найден…», «Введено неправильное имя пользователя или пароль…») должны быть прочитаны программами чтения с экрана при обновлении страницы.
        • Вариант 1: Один из способов добиться этого — принудительно сфокусировать клавиатуру на сообщении об ошибке при перезагрузке страницы. Сообщение об ошибке должно иметь tabindex=»-1″ для эффективного получения фокуса через JavaScript.
          Пользователь не найден…
          . Сообщение должно предшествовать первому соответствующему полю формы. Если имя пользователя/пароль неверно, сообщение должно появиться над полем имени пользователя. Если ошибка возникает в поле «Имя пользователя или адрес электронной почты» (после выбора «забыли пароль?», то сообщение об ошибке должно появиться непосредственно над полем «Имя пользователя или адрес электронной почты», чтобы пользователи один раз нажали клавишу Tab, чтобы перейти в это поле.
        • Вариант 2: поместите сообщение об ошибке в метку соответствующего поля, либо поместив его в тег
        • Также: Установите aria-invalid=»true» для элемента после того, как форма была отправлена ​​для всех некорректных полей. Программа чтения с экрана скажет «недействительно», чтобы пользователи знали, что им нужно исправить это поле.
    • Цветовой контраст:
      • Коэффициент контрастности между синим текстом ссылки и серым фоном слишком низкий для некоторых пользователей с плохим зрением. Синий текст слишком светлый даже на белом фоне для стандартов коэффициента контрастности для специальных возможностей. Возможное значение #206e99
      • Слишком низкая контрастность серого текста метки «Язык» в левом нижнем углу и метки «запомнить меня». Возможное значение для «запомнить меня» будет #757575. Возможное значение «Язык» — #575757.
      • Слишком низкая контрастность бирюзового цвета фона кнопок по сравнению с белым текстом сверху. Возможным значением будет #007571.

    Общая структура страницы менеджера

    Не указаны ориентиры или роли. Области-ориентиры помогают пользователям программ чтения с экрана быстро переходить к областям, не просматривая всю страницу. Вот регионы, которые я бы предложил для основного макета менеджера:

     <заголовок  роль="баннер"  >
        
    role="search ">
      role="tablist" aria-label="Tablist в виде дерева" > <ли role="tab" >Ресурсы
    • Элементы
    роль = "вкладка" >
    <основной роль="главная" > Сюда помещается весь основной контент (редактирование страниц, редактирование фрагментов, содержимое панели инструментов и т.  д.). <нижний колонтитул роль="contentinfo" > (Сейчас в менеджере MODx нет нижнего колонтитула, но вы бы разметили его так)

    Примечание. Вы также можете добиться того же функционального результата, используя только теги

    с атрибутами ролей вместо тегов HTML 5 и атрибутов ролей, но последнее решение более дальновидно.

    Главное верхнее меню (убербар)

    • Порядок вкладок:
      • Порядок объектов в DOM отличается от визуального порядка. То, как ссылки расположены визуально, я ожидаю, что порядок будет таким:
        • Логотип MODx/home
        • поиск
        • контент/медиа/дополнительно/управление
        • меню пользователя
        • меню передачи/системы
        • значок справки
      • Фактический порядок начинается с пользователя и идет вправо, а затем возвращается на главную страницу MODx и через левое меню, что не интуитивно понятно.
    • Доступность клавиатуры:
      • Основные раскрывающиеся меню недоступны с клавиатуры. Это большая проблема — на самом деле, это нарушение правил — которая затрагивает слепых пользователей и зрячих пользователей клавиатуры, ни один из которых не может эффективно использовать мышь. Меню на 100% недоступно для этих групп. В идеале было бы использовать меню на основе арии, которое позволяет пользователям переходить в группу (всю группу навигации/меню), а затем переходить за ее пределы, вообще не переходя к пунктам меню, и использовать клавиши со стрелками для навигации внутри. сама система меню. См. шаблоны клавиатуры, описанные здесь:
        • http://www.w3.org/TR/wai-aria-practices/#menu
        • http://www.w3.org/TR/wai-aria-practices/#kbd_focus
    • Альтернативный текст для изображений и значков:
      • Изображение граватара не имеет альтернативного текста
      • Для значка шестеренки и значка справки требуется текст. Варианты включают:
        • Использовать визуально скрытый текст, к которому могут получить доступ только программы чтения с экрана (используйте CSS-клип или закадровый текст), и скройте саму иконку на случай, если программа чтения с экрана попытается ее прочитать (он почти наверняка прочитает ее неправильно):
          • Системное меню
        • Или используйте role=»image» и aria-label:
    • Ярлык формы:
      • Поле поиска нуждается в теге
    • Кнопка отправки отсутствует:
      • В идеале форма должна иметь настоящую кнопку отправки, чтобы слепые пользователи знали, что они могут отправить форму. Слепые пользователи не видят значок увеличительного стекла. На самом деле значок увеличительного стекла можно превратить в кнопку отправки, и вы сможете сохранить тот же базовый вид, что и исходящий интерфейс.

    Боковая панель

    • Доступность с клавиатуры для панелей списков/вкладок:
      • Панель вкладок вообще недоступна с клавиатуры. Основные вкладки должны иметь tabindex=»0″ на активной вкладке и tabindex=»-1″ на неактивных вкладках, и JavaScript должен переключать это значение, когда пользователи выбирают разные вкладки. Вам также необходимо переключить aria-expanded=»true» и aria-controls=»the-id-of-the-tabpanel». См. https://dequeuniversity.com/assets/js/aria/saveform/form2.html для примера.
    • Альтернативный текст значка:
      • Все значки (Новый документ, Новая символическая ссылка и т. д., а также Корзина) нуждаются в замещающем тексте, чтобы программы чтения с экрана знали, что сказать. См. «альтернативный текст для изображений и значков» в убербаре выше, чтобы узнать о возможных методах.
    • Роль кнопки для значков:
      • Значки (Новый документ, Новая символическая ссылка и т. д. и Корзина) должны иметь атрибут role=»button» или должны быть заключены в фактические теги
    • Доступные с клавиатуры всплывающие подсказки для значков/кнопок:
      • Всплывающая подсказка должна появляться, когда значки/кнопки получают фокус клавиатуры, а не только при наведении курсора мыши.
    • Клавиатурная доступность кнопки для сворачивания боковой панели:
      • Дескриптор для сворачивания всей боковой панели влево должен быть доступен с клавиатуры, и он должен быть <кнопкой> или иметь role=»button» и должен иметь метку (например, «свернуть боковую панель»), чтобы донести до пользователей его назначение.
    • Доступность клавиатуры для дерева:
      • Пользователи должны иметь доступ ко всем элементам и функциям (обновление, добавление новых __ здесь и т. д.) в дереве с помощью клавиатуры. Было бы лучше реализовать древовидное меню ARIA, позволяющее перемещаться с помощью клавиши со стрелкой. Вы должны перейти к объекту дерева, а затем использовать клавиши со стрелками для навигации по нему, включая развертывание и свертывание узлов в дереве. Использование клавиши табуляции приведет к выходу из дерева, а не к навигации по нему. Древовидные представления довольно сложны, но их можно сделать доступными. Вам нужно будет добавить атрибуты ARIA и переключаться между различными состояниями, такими как aria-expanded=»true». Вам также необходимо убедиться, что функциональность значка развертывания/свертывания/треугольника ясна и отделена от функциональности самого заголовка страницы, который открывает страницу. Видеть
        • http://www. w3.org/TR/wai-aria/roles#tree
        • http://accessibleculture.org/articles/2013/02/not-so-simple-aria-tree-views-and-screen-readers/
    • Доступность клавиатуры контекстного меню в древовидном представлении:
      • Функциональность контекстного меню должна быть доступна пользователям клавиатуры. Все функции доступны в других местах, поэтому это требование уже выполнено, но было бы лучше сделать контекстное меню непосредственно доступным для пользователей клавиатуры, а не заставлять их использовать менее эффективные пути к тем же функциям. . Вы можете реализовать сочетание клавиш, такое как alt + enter, для ссылок в меню, чтобы активировать контекстное меню. Однако, чтобы быть эффективным, вам нужно сообщить пользователям, что это сочетание клавиш существует, чтобы вы могли добавить всплывающую подсказку к каждой ссылке с надписью «Используйте Alt + Enter для контекстного меню». Вам необходимо убедиться, что программы чтения с экрана также читают этот текст. Особенно важна возможность добавлять новые элементы (ресурсы, элементы, файлы) в качестве дочерних элементов элемента, который в данный момент находится в фокусе, поскольку это очень распространенная задача.
    • Управление фокусом клавиатуры:
      • Когда вы выбираете страницу для ее редактирования, фокус изначально переходит на поле заголовка страницы, что кажется логичным. Мне нравится, что. Проблема в том, что дерево меню загружается и обновляется, и при этом фокус клавиатуры в конечном итоге переносится с этого поля на текущую страницу в древовидном представлении. Это прерывает работу с клавиатурой, и если вы не можете использовать мышь, вам придется много раз нажимать вкладки, вкладки, вкладки, вкладки, вкладки, чтобы вернуться туда, где вы были. Убедитесь, что древовидное представление не перехватывает фокус.

    Модальные диалоги

    • Управление фокусом клавиатуры:
      • Отправить фокус модальному
        • Убедитесь, что фокус переходит на модальное окно при его активации. Если это простое модальное окно ok/cancel, то фокус должен перейти на кнопку ok. MODx, кажется, делает это хорошо в местах, которые я искал.
      • Ограничить доступ с клавиатуры к модальному модулю, пока он активен:
        • Убедитесь, что пользователи не могут переходить по ссылкам под модальным окном или использовать программу чтения с экрана для доступа к другим элементам под модальным окном. Один из методов достижения последнего заключается в том, чтобы установить для всего под модальным окном значение aria-hidden=»true». Это не скроет его от визуальных пользователей, но сделает контент недоступным для пользователей программ чтения с экрана, что вам и нужно в данном случае. Используйте JavaScript для управления фокусом, чтобы пользователи клавиатуры не могли переходить вперед или назад (shift+tab) вне модального окна.
      • Полностью скрыть неактивные модальные окна (и другое подобное динамическое содержимое):
        • Убедитесь, что модальное окно полностью скрыто от всех пользователей, в том числе от пользователей программ чтения с экрана, используя display:none для элемента, если он уже находится в DOM. Обязательно верните его обратно в display:none в соответствующее время, после того как пользователь или скрипт закончит с ним. До сих пор я не сталкивался с какими-либо проблемами с модальными окнами в MODx, читаемыми программами чтения с экрана, когда они неактивны, но на это стоит обратить внимание.

    Добавить/редактировать ресурс

    • Ярлыки для полей формы, кнопок и кнопочных (сценарных) элементов:
      • Для основного поля «Содержание» требуется реальный тег
      • Для виджета «Показать/скрыть» над правой частью текстовой области «Содержимое» и справа от вкладок («Документ», «Настройки», «Переменные шаблона…») требуется метка. Дайте ему ярлык, например «скрыть поле содержимого» (для нижнего) или «скрыть свойства страницы» (для верхнего), который должен переключиться на «показать поле содержимого» после его активации. Вероятно, это должна быть кнопка, поэтому ее можно закодировать так:

        В некоторых случаях было бы предпочтительнее иметь настоящий текст на кнопке:
      • В области «Переменные шаблона», если переменная шаблона имеет такое свойство, как @INHERIT, текст, который в настоящее время отображается справа от поля (например, «Унаследованное значение»), должен находиться внутри <метки>. Вы все еще можете оформить его так, чтобы он заканчивался с правой стороны, но не размещайте его за пределами этикетки.
    • Обязательные поля:
      • Используйте aria-required=»true» для всех обязательных элементов . Программы чтения с экрана сообщат «требуется» при чтении пользователям.
    • Доступность клавиатуры:
      • Интерфейс вкладок недоступен с клавиатуры. Пользователи должны иметь возможность переходить к списку вкладок с помощью клавиши табуляции, а затем использовать клавиши со стрелками для перехода к самим вкладкам. См. https://dequeuniversity.com/assets/js/aria/saveform/form2.html для примера доступного списка и панели вкладок.
      • Селектор «Использует шаблон»:
        • Убедитесь, что этот виджет полностью доступен с клавиатуры, чтобы люди, использующие только клавиатуру, могли переключать шаблоны.
      • Виджет отображения/скрытия содержания:
        • Убедитесь, что пользователи клавиатуры могут использовать вкладку этого элемента управления
      • Заскриптованные входы только для чтения на вкладке «Настройки»:
        • Кнопка (и это должна быть кнопка) справа от поля «Родительский ресурс» должна быть доступна с клавиатуры, и/или пользователи должны иметь возможность вводить целое число непосредственно в поле.
        • Кнопка справа от поля «Тип ресурса» должна быть доступна с клавиатуры, а пользователи клавиатуры должны иметь возможность выбирать тип ресурса без мыши.
        • Кнопка справа от «Тип контента» должна быть доступна с клавиатуры, а пользователи должны иметь возможность выбирать тип контента без мыши.
        • Кнопка справа от «Расположение содержимого» должна быть доступна с клавиатуры, а пользователи должны иметь возможность выбирать расположение содержимого без мыши.
      • Панель «Переменные шаблона»:
        • Список таблиц сбоку должен быть доступен с клавиатуры. См. https://dequeuniversity.com/assets/js/aria/saveform/form2.html для примера доступного списка и панели вкладок.
        • Функция «Установить по умолчанию» недоступна с клавиатуры. Пользователи должны иметь возможность переходить к нему и использовать его без мыши. ПРИМЕЧАНИЕ. Обязательно дайте каждому из них отдельное имя, чтобы они не говорили просто «Установить по умолчанию». Вы хотите, чтобы он сказал что-то вроде «Установить идентификатор курса по умолчанию», где «идентификатор курса» — это имя/заголовок для переменной шаблона. В противном случае пользователи не будут знать наверняка, какая кнопка относится к какому полю, поскольку телевизоров может быть несколько, а расположение кнопки «Установить по умолчанию» может быть неоднозначным (относится ли она к предыдущему телевизору или к следующему?).
      • Панель группы ресурсов:
        • Кажется, это недоступно с клавиатуры, но если вы схитрите и щелкнете мышью в списке групп ресурсов, доступ к панели с клавиатуры возможен, даже если доступа к флажкам нет.
      • флажков:
        • Флажки групп ресурсов доступны только с помощью мыши. Они должны быть ориентированы на клавиатуру и работать с клавиатурой (с клавишей ввода или пробелом).
    • Порядок вкладок клавиатуры:
      • По большей части порядок вкладок правильный (для вещей, к которым можно переходить), но флажок «Закрепить URI» не в порядке. Похоже, что он должен быть следующим после «Rich Text», но это не так.
    • Сообщения об ошибках:
      • Если поле недействительно (например, обязательное поле пусто) onblur, добавьте aria-invalid=»true», чтобы пользователь программы чтения с экрана услышал это, когда вернется к полю.
        • Когда пользователь пытается отправить страницу, когда есть недопустимые поля, переместите фокус клавиатуры на недопустимое поле (даже если это поле находится на другой панели вкладок, чем текущий фокус), чтобы пользователи могли найти ошибку и исправить Это. Убедитесь, что сообщение об ошибке связано с полем либо в самой <метке>, либо на него ссылается aria-labelledby. Вот предложение:

          Если и метка, и сообщение об ошибке заключены в тег label вместе с самим вводом, заголовок и сообщение об ошибке будут прочитаны, когда пользователи сосредоточатся на вводе. Это очень удобный способ гарантировать, что сообщения об ошибках будут прочитаны программами чтения с экрана. (Обратите внимание, что aria-invalid=»true» применяется только после того, как поле действительно недействительно, а не при загрузке страницы. )

    Создайте дополнение MODX с помощью Git Package Management

    Недавно некоторые люди спрашивали о том, как создать дополнение MODX, в сообществе Slack. Это то, что я делал несколько раз. Возможно, самой сложной частью создания MODX Extra является фактическая упаковка или этап «сборки». MODX использует специально созданный формат упаковки, предшествующий Composer. Несмотря на надежность и эффективность, написание сценария сборки может быть немного утомительным.

    К счастью, есть фантастический инструмент Git Package Management («GPM»), созданный Яном Пека, плодовитым и талантливым членом основной команды MODX. Я, вероятно, не стал бы выпускать дополнения MODX с такой же скоростью без GPM.

    Однако, несмотря на довольно хорошую документацию, вышеупомянутая ветка Slack показала, что необходимо руководство или руководство по использованию GPM. Так вот, как и обещал.

    Требования

    1. Установка MODX — обычно в вашей локальной среде разработки. Хотя вы можете запустить GPM на рабочем сайте MODX, рекомендуется делать такие вещи на этапе разработки, подальше от посторонних глаз и ожиданий.
    2. GPM установлен — вот как это сделать.
    3. Экстра, которую вы пытаетесь создать. В этом посте мы будем ссылаться на классический пример MODX Extra: «Doodles».

    ПРИМЕЧАНИЕ: документация «Doodles» предоставляет устаревший, но достойный обзор того, как разрабатывать MODX Extra. Этот пост посвящен упаковке или шагу «сборки». Традиционный способ сделать это задокументирован в шаге 3 документации Doodles. Этот пост описывает «путь GPM».

    Репозиторий / Шаблон

    Результаты выполнения шагов этого руководства доступны в этом репозитории на GitHub. На самом деле вы можете клонировать или разветвить это репо и использовать его в качестве отправной точки для вашего Extra. Хотя это совершенно необязательно, использование кнопки «Спонсорство» не будет осуждаться, если вы найдете этот учебник и шаблон полезным;)

    Начало работы

    Структура каталогов

    Существует несколько структур каталогов, поддерживаемых GPM, как указано в документации. В этом руководстве описывается одна из таких структур, которая хорошо зарекомендовала себя, но вы можете выбрать любую из них. Вам нужно настроить это только один раз, когда вы устанавливаете и настраиваете GPM. Вы можете разработать произвольное количество Extras в одной и той же среде без перенастройки структуры каталогов.

    • /modx/base/path/ ‹- корень документа
      • core/ ‹- расположение по умолчанию относительно корня документа (это можно настроить, но не нужно в локальном dev)
      • пакета/ ‹- это для GPM. Примечание: он отличается от core/packages/ .
      • index.php ‹- шлюз MODX по умолчанию, показан здесь только в иллюстративных целях

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

    • /path/to/git/repos/ ‹- запустить клон git https://github. com/sepiariver/gpmdoodles.git
      • gpmdoodles/ ‹- локальное хранилище, где вы запускаете команды git
    • /modx/база/путь/
      • пакетов/ ‹- отсюда запустите ln -s /path/to/git/repos/gpmdoodles gpmdoodles
        • gpmdoodles/ ‹- это будет символическая ссылка на /path/to/git/repos/gpmdoodles/

    После установки GPM попросит вас настроить путь и URL-адрес пакетов. Затем он сохраняет эти значения в настройках системы:

    • gitpackagemanagement.packages_base_url (базовый URL-адрес пакетов) -> /packages/
    • gitpackagemanagement.packages_dir (Каталог пакетов) -> /modx/база/путь/пакеты/

    Добавление пакетов в GPM

    После того, как вышеперечисленное настроено, вы можете перейти к «Дополнительно» Управление пакетами Git» в диспетчере. Нажмите кнопку «Добавить пакет» и укажите имя папки вашего пакета относительно каталога Packages . В этом случае это будет gpmdoodles . GPM пытается прочитать файл конфигурации по адресу (относительный путь) gpmdoodles/_build/config.json . Если файл конфигурации действителен, GPM установит элементы MODX, такие как фрагменты, плагины, системные настройки или что-то еще, что вы настроили для своего дополнения.

    Общие вопросы

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

     Конфигурация ядра недоступна для записи. Пожалуйста, сделайте /modx/base/path/packages/gpmdoodles/config.core.php доступным для записи, чтобы продолжить.
     

    В этом случае проверьте права доступа к файлам. Символические ссылки в папке packages/ должны быть видны в дереве файлов менеджера. Также проверьте наличие опечаток в ваших путях.

     Элементы: /modx/base/path/packages/gpmdoodles/core/components/gpmdoodles/elements/chunks/doodle. chunk.html — файл не существует
    Файл конфигурации недействителен.
     

    В этом случае файл конфигурации недействителен, и GPM сообщает нам, почему 🙂

    Настройка дополнительного оборудования

    Репозиторий gpmdoodles содержит некоторые полезные, но, возможно, самоуверенные структуры начальной загрузки и папок. Почему и зачем это делать — тема для отдельного поста, однако стоит отметить структуру папок, поскольку она относится к GPM и процессу сборки.

    • /path/to/git/repos/gpmdoodles/ ‹- все пути ниже относятся к этой папке проекта
      • _build/ ‹ — содержит файлы конфигурации и сборки GPM, которые не упаковываются вместе с Extra
        • config.json ‹- это важный бит
        • gpm_resolvers/ ‹ — создается GPM
        • build.config.php ‹- GPM создает это при добавлении пакета в менеджере — должно быть в .gitignore
      • активов /
        • компоненты/
          • gpmdoodles/ ‹- если для вашего Extra требуется, чтобы активы были общедоступными, они должны быть здесь, чтобы они были упакованы с Extra
      • ядро ​​/
        • компоненты/
          • gpmdoodles/ ‹- другой каталог, который поставляется вместе с Extra
            • elements/ ‹- конфигурация сборки GPM ищет в этой папке ваши элементы MODX
              • сниппетов/ ‹- таких как сниппеты
              • плагины/ ‹- и плагины
            • модель/ ‹- типичное расположение файлов модели
            • docs/ ‹- файлы, используемые менеджером пакетов MODX
      • тест/ ‹- пример папки, которая игнорируется GPM в сборке и поэтому не упаковывается с Extra
      • config. core.php ‹- GPM создает это в корне проекта при добавлении пакета в менеджер — .gitignore это.

    Как видите, GPM ожидает, что структура папок вашего Extra будет соответствовать соглашению Doodles. Обратите внимание, что сгенерированный композитором каталог vendor/ под core/components/gpmdoodles/model/ зарегистрированы в VC. Установщик дополнений MODX не запускает composer для управления зависимостями.

    Далее мы рассмотрим файл _build/config.json , который можно найти на GitHub здесь.

    config.json

    В документации по управлению пакетами Git подробно описаны различные параметры конфигурации, доступные в _build/config.json . Мы не будем здесь все повторять, но укажем, почему gpmdoodles настроен так, как есть.

    Общий раздел

    имя (строка) Значение свойства используется в качестве категории MODX по умолчанию для всех элементов в этом дополнении. Это также имя, которое отображается в установщике Extras и в каталоге MODX Extras.

    lowCaseName (строка) Вероятно, это самое важное свойство в конфигурационном файле. Его значение используется в качестве пространства имен MODX для этого дополнения. Кроме того, это значение используется во всем Extra. MODX, xPDO и GPM выполняют различные функции, связанные с этим значением. Чтобы соответствовать соглашению и предотвратить неприятные ошибки, лучше всего использовать только буквы нижнего регистра [a-z] .

    версия (строка) Это значение используется установщиком Extras для определения доступности новой версии Extras. Даже если вы не планируете публиковать свой Extra, вы выиграете от использования семантической схемы управления версиями, подобной той, что используется в ядре MODX. Благодаря этому обновление в установщике Extras работает гладко.

    Пакет Раздел

    пакет (объект) Обычно это основная часть конфигурации, и она указывает GPM, как упаковать ваш Extra. Ниже мы коснемся различных подразделов.

    Элементы

    элементов (объект) Этот объект содержит дочернее свойство для каждого типа элемента MODX, который вы хотите включить в свой Extra. Полный список поддерживаемых типов элементов и доступные свойства для каждого доступны в документации. Здесь мы имеем дело с плагинами, сниппетами и чанками.

    elements.plugins (массив) Массив объектов, каждый из которых описывает плагин. Нас интересуют следующие свойства: имя , файл и события .

    {plugin}.name (строка) Имя плагина, которое отображается в менеджере MODX. Он имеет уникальное ограничение в базе данных MODX.

    {плагин}.file (строка) Здесь все становится немного интереснее. GPM ищет файлы в определенном каталоге относительно корня проекта: core/components/gpmdoodles/elements/plugins/ и использует их в качестве источника статических элементов, которые он создает в вашем среда разработки . При сборке пакета GPM использует эти исходные файлы для создания транспортных средств, которые будут развернуты как записи базы данных (стандартные элементы) на сайте MODX, где установлено дополнение.

    Хорошо, это было много слов. Давайте перегоним это. В нашем примере плагина GPM Doodles содержимое файла doodles.plugin.php станет кодом плагина.

    {плагин}.events (массив) Массив строк, каждая из которых является именем события MODX, на котором вы хотите, чтобы ваш плагин выполнялся.

    elements.snippets (массив) Массив объектов, каждый из которых описывает фрагмент. Основные свойства: имя и файл .

    {snippet}.name (string) Имя сниппета, которое отображается в менеджере MODX. Для сниппетов это особенно важно, так как это имя используется для вызова выполнения сниппета. Он имеет уникальное ограничение в базе данных MODX.

    {snippet}.file (string) Аналогично другим элементам, содержимое файла станет кодом Snippet.

    elements.chunks (массив) Массив объектов, каждый из которых описывает фрагмент. Основные свойства: имя и файл .

    {чанк}.name (строка) Имя чанка, которое отображается в менеджере MODX. Фрагменты включаются по имени. Это поле имеет уникальное ограничение в базе данных MODX.

    {чанк}.file (строка) Содержимое файла станет содержимым фрагмента.

    Системные настройки

    Один из элементов — это массив systemSettings . Каждый элемент массива представляет собой объект, описывающий системную настройку. Базовая конфигурация включает ключ и значение .

    {systemSetting}.key (строка) Это ключ к системным настройкам. Он будет иметь префикс пакета пространства имен , разделенных . , поэтому в нашем примере api_url будет установлен в MODX как gpmdoodles. api_url .

    {systemSetting}.value (строка) Значение системных настроек по умолчанию при установке.

    Раздел базы данных

    база данных (объект) Этот объект дает указание GPM вносить изменения в базу данных в соответствии с требованиями вашего Extra.

    database.tables (массив) Массив имен классов объектов. Обратите внимание, что это не имена таблиц, а имена классов PHP, которые взаимодействуют с базой данных, расширяя объекты xPDO. В этом разделе требуется немного справочной информации о схемах базы данных xPDO и о том, как GPM взаимодействует с ними.

    gpmdoodles.mysql.schema.xml

    В нашем примере проекта этот файл находится по адресу: core/components/gpmdoodles/model/schema/gpmdoodles.mysql.schema.xml . Схема xPDO как тема выходит за рамки этого поста, но вот несколько ресурсов:

    • Документация MODX
    • Сообщение в блоге MODX

    Более важным здесь является то, как GPM использует этот файл. В диспетчере в разделе «Дополнительно» Управление пакетами Git вы должны увидеть пакет, который вы добавили в GPM. Щелкните его правой кнопкой мыши, чтобы открыть контекстное меню.

    При выборе параметра «Создать классы из схемы» GPM (с использованием xPDO) создает файлы классов xPDO на основе вашей схемы.

    Еще раз щелкните правой кнопкой мыши и выберите «Обновить пакет» . Теперь GPM создаст таблицы базы данных, определенные в схеме.

    Разработка экстра

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

    Из этого следует, что в настройке GPM, описанной здесь, вы можете изменять код в своих элементах либо , используя менеджер MODX, либо используя выбранную вами IDE/текстовый редактор. Хотя это может быть удобно, это также может привести к потере работы. Пример:

    1. Вы вносите незафиксированные изменения в свою IDE, но
    2. в менеджере открыто представление Элемента с устаревшими данными для того же Элемента, и
    3. , затем вы нажимаете «Сохранить» в менеджере, затем, наконец,
    4. .
    5. вы можете попрощаться со своими незафиксированными изменениями.

    Возможно, будет полезно установить для себя правило: не нажимайте «Сохранить» в представлениях менеджера для любых элементов, управляемых GPM.

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

    Дополнительная упаковка

    Все сводится к этому! В разделе «Дополнительно» Управление пакетами Git» в диспетчере щелкните правой кнопкой мыши имя вашего пакета в представлении сетки и выберите «Создать пакет».