Поиск сообщества

Расширение маршрутизации контента для Элемента Контента Многие фнукции Invision Community обрабатываются централизованно и автоматически, например, предупреждения и разрешения модератора. Для поддержки этого, вам необходимо зарегистрировать ваши типы элементов контента с помощью ядра, что с делается с помощью простого расширения Content Router (далее Маршрутизация Контента). Дополнительные сведения о расширениях смотрите в соответствующем документе. Как реализовать расширение ContentRouter Первым шагом к реализации вашего маршрутизатора контента является создание расширения ContentRouter в Центре разработчика вашего приложения. Имя класса должно иметь отношение к цели вашей модели, к примеру Темы. Откройте созданный файл и добавьте такой код (изменив значения, если это необходимо): namespace IPS\yourApp\extensions\core\ContentRouter; class _YourClass { public $classes = array( 'IPS\yourApp\YourContentItemClass' ); } Далее добавьте следующее свойство в вашу модель ноды (но не в модель элемента контента): static $modPerm = 'string'; Значение используется как ключ для хранения нод, с которыми модератор имеет разрешение работать. Это может быть что угодно. Создайте языковую строку в вашем файле lang.php с этим же ключом - это будет текстовое представление того, как называются ваши ноды (например, 'Категории'). Наконец, добавьте языковую строку в файл lang.php для каждого из действий модерации, используя этот формат: can_<action>_<title> где <title> это ключ, определяемый статическим свойством $title из вашей модели элемента контента. Действия, которые вам нужно определить, будут зависеть от того, какие функции элементов контента вы поддерживаете в своей модели, но могут включать: pin и unpin (если поддерживается закрепление). feature и unfeature (если поддерживается возможность делать контент популярным). hide, unhide и view_hidden (если поддерживается скрытие и одобрение). lock, unlock и reply_to_locked (если поддерживается закрытие). edit. move. delete. Примечание: если ваш элемент контента поддерживает комментирование, повторите этот последний шаг для действий, которые могут быть выполнены у комментариев (edit, delete, hide, unhide и view_hidden), где <title> будет ключом, определённым статическим свойством $title из вашей модели комментария контента. В качестве примера предположим, что $title нашей модели элемента контент является 'myapp_entry'. В таком случае языковые строки будут с такими ключами: 'can_edit_myapp_entry' => "Можно редактировать записи?", 'can_move_myapp_entry' => "Можно перемещать записи?", 'can_delete_myapp_entry' => "Можно удалять записи?" ...и так далее. Поведение, которое изменяется после реализации расширения ContentRouter При создании модератора администраторы смогут настраивать разрешения модератора для ваших элементов контента. При просмотре профиля пользователя, показ всего контента, размещенного этим пользователем, будет содержать и ваши элементы контента. Если вы поддерживаете скрытие элементов контента, при просмотре панели модератора будут показаны скрытые элементы контента из вашего приложения. При перестройке количества сообщений пользователя учитываются элементы вашего контента. При удалении всего контента пользователя, элементы контента вашего приложения у пользователя также будут удалены.

Большинство URL-адресов в Invision Community являются "дружественными", также известные как FURLs (ЧПУ – человекопонятные ссылки) - то есть, они на простом английском и легко читаются пользователями и поисковыми системами. FURL (ЧПУ) отображаются с помощью Invision Community в виде традиционных URL с параметрами, на основе преобразования, предоставляемого приложением. Например, FURL site.ru/messenger/compose может быть отображен как site.ru/index.php?app=core&module=messaging&controller=messenger&do=compose. Как загружаются контроллеры Контроллеры автоматически запускаются, когда совпадает URL. Параметры URL используются Invision Community, чтобы найти нужный контроллер: app=core Указывает, что контроллер находится в приложении “core” module=messaging Указывает, что контроллер находится в модуле обмена сообщениями “messaging”, в базовом приложении “core” controller=messenger Указывает, что мы загружаем контроллер “messenger”, в модуле обмена сообщениями “messaging”, в базовом приложении “core” do=сompose Параметр do не является обязательным, и позволяет вызывать конкретный метод в контроллере, чтобы обработать запрос. Если этот параметр опущен, то по умолчанию будет вызываться метод manage. Так, для URL site.ru/index.php?app=core&module=messaging&controller=messenger&do=compose, загружаемый контроллер будет находиться в /applications/core/modules/front/messaging/messenger.php, и будет вызываться метод compose внутри контроллера, чтобы обработать запрос. По этой структуре очень легко определить, какой именно способ, в каком контроллере обрабатывает запрос для любого заданного URL. Определение дружественных URL-адресов При разработке приложения, ваша FURL конфигурация создается в файле furl.json в каталоге /data вашего приложения. JSON структура определяет дружественный URL, реальный URL, который ему соответствует, и некоторые другие данные которые могут быть использованы. Простой пример FURL ... "messenger_compose": { "friendly": "messenger/compose", "real": "app=core&module=messaging&controller=messenger&do=compose" }, ... Ключ (в данном случае messenger_compose) это то, что идентифицирует этот FURL в IPS4. При создании ссылок в шаблонах или контроллерах, вы будете использовать этот ключ, чтобы указать, какой FURL будет использоваться для генерации и парсинга URL-адреса. Значение friendly это ЧПУ, который будут видеть пользователи. Значение real является фактическим URL, который будет использовать Invision Community, чтобы найти правильное app/module/controller для обработки запроса. FURLs с использованием параметров Хотя многие FURL статичные и простые, как в вышеуказанном примере, некоторые будут динамическими и будут включать в себя параметры, идентифицирующие конкретную запись, которая должна отображаться - например, просмотр темы на форуме. Для облегчения этой задачи, FURL определения поддерживают параметры. ... "profile": { "friendly": "profile/{#id}-{?}", "real": "app=core&module=members&controller=profile" }, ... Параметры, находящиеся внутри FURL заключены в фигурные скобки {}. Первый символ может быть либо #, чтобы соответствовать номеру, или @, чтобы соответствовать строкам. За этим следует имя параметра, и оно должно совпадать с именем параметра, который будет подставлен в реальном URL. Например, здесь мы используем {#id}, который совпадает с номером и приведет к &id=123 и передается в наш реальный URL. Тег {?} может быть использован для SEO заголовков; то есть дружественный текст, который идентифицирует отдельные записи, но который не является частью реального URL. Примером этого было бы название темы - оно включено в URL, чтобы помочь пользователям и поисковым системам, но только id темы используется для её поиска в реальном URL-адресе. Вы можете использовать несколько SEO заголовков в пределах URL, используя нулевой индексированный номер в теге, например {?0}, {?1} и {?2}. Вам не следует указывать FURL параметры, которые вы собираете в реальном URL; они автоматически добавляются к реальному URL-адресу диспетчером. В приведенном выше примере URL пользователь будет видеть что-то вроде site.ru/profile/123-имя-пользователя. Специфика FURL Порядок, в котором вы указываете ваши FURL значения имеет большое значение. Когда диспетчер пытается соотнести URL, он проходит последовательно через значения FURL, и останавливается на первом значении, которое подходит. Отсюда следует, что ваши более специфичные значения должны идти перед менее специфичными в furl.json. Например, предположим, у нас есть два значения, относящиеся к профилю пользователя. Одним из них является домашняя страница профиля, другой – страница редактирования профиля. Если мы указали значения таким образом: "profile": { "friendly": "profile/{#id}-{?}", "real": "app=core&module=members&controller=profile" }, "edit_profile": { "friendly": "profile/{#id}-{?}/edit", "real": "app=core&module=members&controller=profile&do=edit" }, …Тогда edit_profile не будет использоваться. profile/1-имя-пользователя URL будет найден первым и вызван диспетчером. Вместо этого следует сделать так, указав значения следующим образом: "edit_profile": { "friendly": "profile/{#id}-{?}/edit", "real": "app=core&module=members&controller=profile&do=edit" }, "profile": { "friendly": "profile/{#id}-{?}", "real": "app=core&module=members&controller=profile" }, ... это означает что edit_profile будет пропущен, пока не будет определено более частное значение, что позволяет более точно определить все запросы для обработки.