Павел

Мощным компонентом приложения правил является его способность планировать и выполнять действия в будущем. Когда действия запланированы, они будут отображены в области Плановые действия в меню в админцентре. Любое количество действий может быть запланировано в любой момент времени, и они будут находиться в очереди до тех пор, пока не будет достигнуто их запланированное время выполнения. В любой момент после планирования, действия можно выполнять вручную раньше своего времени, или может быть вручную изменена их запланированная дата. В случае вручную запланированных пользовательских действий, аргументы действий и детали планирования также могут быть изменены в любое время. Действия, запланированные с помощью правил Когда действия добавляются на вкладку правила "Действия", у вас есть возможность либо выполнить это действие в режиме реального времени, либо запланировать для выполнения в будущей дате/времени. Любые действия можно планировать на будущее (включая пользовательские действия) при добавлении их в правило. Ключевые фразы расписания Иногда желательно иметь только один экземпляр типа действия в очереди на выполнение. Например, когда пользователь входит в систему, вы можете захотеть запланировать отправить ему e-mail сообщение через несколько месяцев после его неактивности, тем самым призвать вернуться в сообщество. В таком случае вы вряд ли хотел бы отправить пользователю все запланированные письма, но только последний экземпляр e-mail сообщения, который запланирован. Для этого необходимо использовать ключевую фразу планирования. Ключевая фраза планирования похожа на уникальный идентификатор запланированного действия, который гарантирует, что только один экземпляр этого действия может присутствовать в очереди в любой момент времени. Если другое действие запланировано с использованием той же ключевой фразы, оно перезапишет существующее запланированное действие. И поскольку обычно необходимо иметь один экземпляр запланированного действия в очереди для нескольких объектов в системе (например пользователей), токены могут быть использованы в ключевой фразе для её изменения сущностью. Например, ключевая фраза "Отправить e-mail сообщение для пользователя:[member:id]" использует токен [member:id], который будет заменён на ID пользователя (если предположить, что токен доступен в списке токенов для события). Это гарантирует, что каждый член может одновременно иметь свой отдельный экземпляр действия, запланированного в очереди, но только один для каждого пользователя. Любое количество токенов может использоваться в ключевой фразе, чтобы сделать ее уникальной для своего приложения. Действия, запланированные вручную Вы можете вручную запланировать выполнение пользовательского действия в заранее настроенную дату и время. Пользовательские действия могут быть запланированы вручную, чтобы происходить на регулярной основе или в качестве одноразового события. Чтобы запланировать пользовательское действие вручную, нажмите стрелку раскрывающегося списка для пользовательского действия в меню "Пользовательские действия" и выберите вариант "Запланировать вручную". Повторяющиеся запланированные действия Когда вы вручную планируете действие, которое будет происходить на постоянной основе, указанный период времени будет автоматически сброшен, и действие будет снова запланировано каждый раз, когда пользовательское действие завершит его выполнение. На странице ручного планирования выберите "повторно" в качестве параметра частоты действий, а затем укажите период времени между которым должно выполняться действие. Массовая обработка Каждый аргумент, используемый вашим пользовательским действием, может быть настроен вручную для обработки. Вы можете опционально выбрать "аргумент массовой обработки" в настройках массовой обработки для запуска действия повторно для каждой из записей в системе, связанной с аргументом массовой обработки. Например, если один из аргументов ваших пользовательских действий был настроен для принятия объекта пользователя, то выбор этого аргумента в качестве параметра массовой обработки приведет к выполнению пользовательского действия для каждого пользователя системы при каждом запуске. Примечание: Когда вы выбираете аргумент массовой обработки, вы можете установить ограничение количества записей в системе, которые будут обрабатываться при каждом запуске крона, пока цикл обработки не будет завершен.

Правила позволяют прикрепить свои собственные поля данных к любому контенту, контейнерам контента или пользователям в системе. Поля пользовательских данных могут быть настроены только для внутреннего использования или настроены для редактирования пользователями с помощью форм ввода. Дополнительным преимуществом использования полей пользовательских данных является то, что они позволяют вам создавать дополнительные правила, которые запускаются, когда ваши поля пользовательских данных обновляются (либо через правила, через форму ввода, либо через собственный код). Разрешения Поля данных также имеют связь с разрешениями групп пользователей, что позволяет вам ограничить тех, кто сможет просматривать и редактировать данные. В дополнение к разрешениям, вы так же можете ограничить поля пользовательских данных для конкретных контейнеров контента (форумы, категории, и т.д.). Режимы доступа Поля данных могут быть настроены в трех разных режимах доступа: Внутреннее использование Когда поле данных настроено для внутреннего использования, оно не будет представлено для редактирования в любой форме, независимо от разрешения на редактирование данных в поле. Оно может обновляться только с помощью правил или настраиваемого PHP-кода, но по-прежнему полностью доступено для условий правил. Публичное использование Когда поле данных настроено для публичного использования, оно будет представлено в форме редактирования для каждого пользователя, у которого есть разрешение на редактирование поля данных и элемента контента, которому оно принадлежит. Административное использование Когда поле данных настроено для публичного использования, оно будет представлено пользователям, у которых есть соответствующее разрешение редактирования поля, а также имеют разрешения модератора редактировать объект, к которому он вложен. Методы доступа к данным Правила предоставляют несколько способов доступа к пользовательским данным, связанным с объектами. Существует три метода API для получения и сохранения данных правил, а также два сокращенных способа доступа к данным правил через свойства объекта. Методы API (для php): Метод getRulesData() может использоваться для извлечения данных, которые были сохранены в объекте. Этот метод будет извлекать данные независимо от разрешений зарегистрированного пользователя. $data = $object->getRulesData( 'data_key' ); Метод getRulesDataWithPermission() может использоваться для извлечения данных, сохраненных в объекте, учитывая разрешения. Если у зарегистрированного пользователя нет разрешения на просмотр данных, данные не будут возвращены этим методом. $data = $object->getRulesDataWithPermission( 'data_key' ); Метод setRulesData() может использоваться для обновления данных, связанных с объектом. Примечание. Данные должны быть одного и того же типа данных, которые были определены при настройке поля пользовательских данных, иначе будет брошено исключение \InvalidArgumentException. $object->setRulesData( 'data_key', $data ); Сокращенные методы (для php или тегов шаблонов) Сокращенные методы доступа к данным правил очень полезны по нескольким причинам. Во-первых, они короче. Но что более важно, их можно безопасно использовать для проверки данных правил, даже если правила не установлены на сайте или были отключены. Это означает, что при использовании метода сокращенного доступа к данным в тегах шаблонов или в php-коде ошибки не будут появляться, если приложение правил отключено. Ключ данных (с разрешениями) Доступ к данным правил можно получить для объекта, просто используя data_key для данных как свойство объекта. Этот метод доступа к данным правил также будет учитывать разрешения, установленные для данных, поэтому, если у зарегистрированного пользователя нет разрешения просматривать данные, тогда свойство будет пустым. /* php-код */ $data = $object->data_key; <!-- теги шаблона --> {{if $object->data_key}} <strong>Data:</strong> {$object->data_key} {{endif}} Ключ данных (без разрешений) Доступ к данным возможен для объекта без проверки разрешений путем префикса data_key с «r_». Поэтому любые пользовательские данные, сохраненные в объекте, будут доступны независимо от разрешений зарегистрированного пользователя. /* php-код */ $data = $object->r_data_key; <!-- теги шаблона --> {{if $object->r_data_key}} <strong>Data:</strong> {$object->r_data_key} {{endif}}

Пользовательские действия - это хлеб и масло правил. Когда вы создаете пользовательское действие в правилах, выполняются две вещи. Пользовательские действия могут запускаться или планироваться как любое другое действие из вкладки "Действия" у существующих правил. Могут быть созданы новые правила, которые используют пользовательское действие как событие, через которое они запускаются. Поэтому пользовательские действия позволяют строить полностью новые "процедуры обработки" правил, которые могут быть вызваны как одно действие. Фактически, вы решаете КОГДА пользовательское действие должно быть выполнено с использование правила, а затем вы также можете выбрать ЧТО ПРОИСХОДИТ, когда пользовательское действие выполнено с помощью других правил. Создание нового пользовательского действия Для создания пользовательского действия, посетите раздел настроек Правил "Действия" в вашем админцентре Система -> Правила. Нажмите кнопку Создать. Далее вам предстоит указать название вашего нового действия и его описание (необязательно). Эти данные в дальнейшем вы сможете изменить. Как только действие будет создано, оно станет доступно для использования во вкладке "Действия" у существующих правил, а также доступно как событие при создании новых правил. Тем не менее, вы, как правило, хотите создать аргумент события или два, которые позволят вам передавать данные переменной в свое пользовательское действие. Для этого кликните по иконки "плюс" рядом с созданным нами действием. Название аргумента: это название аргумента, которое будет использоваться в формах конфигурации правил. Описание: краткое описание предоставляемых данных. Тип аргумента: тип данных, которые должны быть предоставлены для аргумента. Тип значения: если вы выбрали "объект" или "массив" в качестве типа аргумента, вы можете выбрать тип объекта (ов), который должен быть предоставлен. Обязательно: укажите, будет ли ваше действие требовать эти данные. Использование пользовательского действия После того, как вы настроили пользовательское действие и какие-либо аргументы, которые ему понадобятся, вы можете начать создавать правила, которые будут определять, что происходит, когда действие будет предпринято. Когда вы создадите новое правило, в вашем списке событий будет доступно новое событие; это то, что вы будете использовать для программирования функций для вашего пользовательского действия. Вы можете создать столько правил, групп правил и/или наборов правил, сколько необходимо для выполнения цели вашего пользовательского действия. Для вызова своего действия, просто добавьте его на вкладку "Действия" любого существующего правила, для которого оно должно быть применено.

Существует два способа организации правил, которые вы можете использовать для их удобного и аккуратного хранения. Каждое правило может полностью функционировать самостоятельно, однако есть случаи, когда у вас могут быть два или более правила, которые работают совместно для выполнения одной задачи. В таких случаях хорошей практикой будет организовать их вместе, для более удобного обновления, импорта, экспорта, включения, отключения и/или отладки. Группы правил Правила в группе правил всегда используют одно и то же событие. Когда правила, вызываемые разными событиями, должны быть организованы вместе, необходимо использовать "набор" правил. Любое правило можно легко превратить в группу правил, нажав кнопку со значком "плюс" (которая добавит "подправило"). Когда вы добавляете новое "подправило" в существующее правило, эти правила становятся "группой правил". Подправила родительского правила будут срабатывать только в том случае, если выполнены условия родительского правила. Это делает возможным под-правилам наследовать любые условия родителя, поскольку, если условия родителя не выполняются, не сработают и дочерние правила. Конечно в под-правилах могут создаваться свои условия. Каждый раз, когда два правила используют одно и то же событие и одно или несколько условий, их можно объединить в группу правил. Когда вы создаете группу правил, важно, чтобы правило родителя содержало только те условия, которые являются общими для всех под-правил. Преимущество организации правил в группы заключается в том, что, когда вам нужно настроить условие, которое является общим для всей группы, вам нужно сделать это в одном месте (родительское правило) вместо того, чтобы настраивать одно и тоже условие для каждого подправила. Набор правил Наборы правил позволяют организовывать правила, которые работают вместе в рамках одной цели или задачи. Правило работает одинаково как внутри набора, так и вне набора, однако размещение правил в наборе правил позволяет легко включать, отключать, экспортировать, удалять или отлаживать все правила в этом наборе единоразово. Другими словами, наборы правил похожи на папки для хранения ваших правил. В качестве примера у вас может быть ряд правил, установленных на вашем сайте, которые призваны стимулировать учавствовать пользователей в жизни вашего сообщества, создавая "поздравительные" уведомления, когда пользователь достигает определённого этапа развития (например набирает 200 сообщений), а затем отправляют e-mail сообщение, если пользователь не реагирует. Эти правила могут быть объединены в набор правил, под названием "Правила стимулирования пользователей" для удобства.

Разработчики постарались максимально возможно сохранить совместимость тем для Invision Community 4.1 и 4.2. Однако, учитывая множество изменений в темах и новые функции в 4.2, вам придётся внести некоторые изменения вручную. Обновление шаблонов темы Самый простой и эффективный способ обновления шаблонов темы для совместимости с 4.2 это простой возврат его к исходному состоянию (при просмотре шаблона темы в редакторе, нажмите кнопку "Оригинал"). Это приведёт к сбросу всех его модификаций и проблем с устареванием этого шаблона. Соответственно после этого вы должны снова внести все изменения в данный шаблон. Другой способ - вручную обновить тем шаблоны, которые вызывают ошибки. Это не совсем правильно, т.к. перед этим необходимо выяснить причину ошибки и убедиться, что после внесения изменений в шаблон ошибка полностью устранена. Следуйте данному руководству В этом руководстве описаны основные области, которые должны быть обновлены для достижения совместимости. Однако оно не является полным, т.к. в зависимости от степени кастомизации вашей темы, могут быть не описанные здесь правки. Кроме того, в этом руководстве не описаны изменения для обновления ваших шаблонов к новым возможностям 4.2. Цель руководства попытаться избежать фатальных ошибок и визуальных проблем после обновления. Мы по-прежнему рекомендуем следовать сравнению всех исправленных вами шаблонов, чтобы внести изменения. Однако, перечисленные в данном руководстве области позволят минимизировать ошибки в последствии обновления. Изменение структуры основной навигации HTML структура бара основной навигации была немного переработана, чтобы позволить ему быть в полную ширину страницы. Тег <nav> больше не содержит класс ipsLayout_container. Вместо него данный класс приобретает элемент ipsNavBar_primary. Таким образом: Отрывок кода шаблона 4.1.19: {{if !in_array('ipsLayout_minimal', \IPS\Output::i()->bodyClasses )}} <nav class='ipsLayout_container' data-controller='core.front.core.navBar'> <div class='ipsNavBar_primary {{if !count( \IPS\core\FrontNavigation::i()->subBars( $preview ) )}}ipsNavBar_noSubBars{{endif}} ipsClearfix'> Отрывок кода шаблона 4.2: {{if !in_array('ipsLayout_minimal', \IPS\Output::i()->bodyClasses )}} <nav data-controller='core.front.core.navBar' class='{{if !count( \IPS\core\FrontNavigation::i()->subBars( $preview ) )}}ipsNavBar_noSubBars{{endif}}'> <div class='ipsLayout_container ipsNavBar_primary {{if !count( \IPS\core\FrontNavigation::i()->subBars( $preview ) )}}ipsNavBar_noSubBars{{endif}} ipsClearfix'> Не забывайте, что это отрывок кода, соответственно закрывающие теги тоже присутствуют. Бар основной навигации также имеет отрицательное верхнее значение в 4.2, чтобы способствовать новому позиционированию. Таким образом, в кастомных темах это может привести к завышенному расположению навигационного бара, чем там, где он должен быть. Если в вашей теме наблюдается данная проблема, вы можете сбросить верхнее позиционирование: .ipsNavBar_primary { top: 0; } Ну и наконец, в стандартной теме установлен фон к #ipsLayout_header (используется настройка темы main_nav_tab). На кастомных темах это может вызвать цветной блок, отображающийся за навигационным баром. Вы можете исправить это путём добавления этого CSS: #ipsLayout_header nav { background: transparent; } Нет цвета у фона контента Стандартная тема 4.2 более не имеет фонового цвета у элемента #ipsLayout_contentWrapper. Если ваша тема использует цветной фон страниц и опирается на фон contentWrapper, вы можете добавить цвет для фона обратно, путём добавления стиля в ваш custom.css файл: #ipsLayout_contentWrapper { background-color: #ffffff; } Нет внешнего отступа у #ipsLayout_mainArea, бокового блока или хлебных крошек Если вы столкнулись с проблемой выше с #ipsLayout_contentWrapper, скорее всего, у вас также возникнет и эта проблема. Стандартная тема 4.2 больше не включает отступы у #ipsLayout_mainArea, элементов в боковом блоке, или хлебных крошек. Если вы применили фоновый цвет к #ipsLayout_contentWrapper, вы, скорее всего, увидите контент, касающийся сторон фоновой области. Вы можете изменить это путём добавления отступов: #ipsLayout_mainArea { padding: 0 20px; } .ipsBreadcrumb { margin-left: 20px; margin-right: 20px; } #ipsLayout_sidebar { padding-left: 0; padding-right: 0; } html[dir="ltr"] #ipsLayout_sidebar.ipsLayout_sidebarleft, html[dir="rtl"] #ipsLayout_sidebar.ipsLayout_sidebarright { padding-left: 20px; } html[dir="ltr"] #ipsLayout_sidebar.ipsLayout_sidebarright, html[dir="rtl"] #ipsLayout_sidebar.ipsLayout_sidebarleft { padding-right: 20px; } По умолчанию цвет фона основной навигации не задан Из-за нового стиля заголовка и навигации в 4.2, бар основной навигации больше не использует цвет фона, определённого в настройках темы (вместо этого он прозрачный, а цвет заголовка окружает навигацию). Если ваш дизайн темы зависит от этого цвета фона, вы можете добавить его обратно с помощью CSS: .ipsNavBar_primary { background: {theme="main_nav"}; padding: 5px 5px 40px 5px; } Необязательные заголовки теперь скрыты по умолчанию Чтобы скрыть лишние элементы дизайна со страницы, 4.2 скрывает множество заголовков (так же называемые 'maintitle'), которые расположены над таблицами/областями контента. Почти по всех случаях разработчики оставили разметку для этих заголовков в коде темы, что позволяет вам включить их отображение, если в этом есть необходимость. .ipsApp .ipsType_sectionTitle.ipsHide { display: block; } Изменён параметр подключении шаблона хлебных крошек Мы рассмотрим изменённые параметры в следующей области, но мы должны рассмотреть важный параметр в шаблоне хлебных крошек, т.к. он встречается в глобальном шаблоне globalTemplate. Ранее первым параметром шаблона было boolean значение. Это изменено, соответсвенно вам нужно обновить все вызовы данного шаблона с: {template="breadcrumb" app="core" group="global" params="FALSE, 'top'"} на {template="breadcrumb" app="core" group="global" params="'top'"} Тоже самое применено для второго вызова хлебных крошек в этом шаблоне, который отображает нижние хлебные крошки - просто удалите первый параметр. Изменена логика ссылки Обратная связь Если ваша тема имеет изменённый шаблон футера, вы, скорее всего, получите внутреннюю ошибку на каждой странице вашего сообщества из-за вызова метода, который больше не существует. Этот вызов оборачивает ссылку Обратная связь и проверяет разрешение пользователей. Вы должны обновить код: {{if \IPS\core\modules\front\contact\contact::canUseContactUs() and !( \IPS\Dispatcher::i()->application->directory == 'core' and \IPS\Dispatcher::i()->module and \IPS\Dispatcher::i()->module->key == 'contact' )}} должен быть: {{if \IPS\Member::loggedIn()->canUseContactUs() and !( \IPS\Dispatcher::i()->application->directory == 'core' and \IPS\Dispatcher::i()->module and \IPS\Dispatcher::i()->module->key == 'contact' )}} Обратите внимание на новый метод canUseContactUs. Изменены параметры шаблонов Некоторые шаблоны имеют новые или изменённые параметры, передаваемые из PHP фреймворка. Проверьте список шаблонов ниже, если вы изменили один из этих шаблонов, вы должны вручную изменить параметры шаблона, чтобы избежать фатальных ошибок. Это делается путём перехода в окно редактирования кода шаблона и нажатием на кнопку "Параметры". Возможно, вам также потребуется обновить контент шаблона, чтобы использовать новую переменную. Core > Global > Forms > address; Core > Front > Forms > editContentForm; Core > Global > Forms > editorAttachmentsPlaceholder; Core > Global > Forms > node; Core > Global > Forms > nodeCascade; Core > Front > Global > breadcrumb; Core > Global > Global > pollForm; Core > Front > Global > reputationMini; Core > Global > Login > mfaRecovery; Core > Front > System > searchResult; Core > Front > System > settingsOverview; Core > Front > System > settingsProfileSync; Forums > Front > Forums > forumPasswordPopup; Forums > Front > Index > indexButtons; Blog > Front > Submit > submit; Calendar > Front > Submit > submitPage; Calendar > Front > View > view; Gallery > Front > Browse > album; Gallery > Front > Global > embedAlbums; Nexus > Front > Global > embedProduct; Nexus > Admin > Support > request. В репутацию добавлены реакции Invision Community 4.2 включает в себя Реакции как обновление и дополнение к текущей системы репутации. В результате этого появились новые дополнения к шаблонам и устаревшие методы, влияющие не темы. Это изменение повлияет на любой шаблона, вызывающий метод $content->reputation(), включая: Forums > Front > Topics > postContainer; Forums > Front > Topics > post; Blog > Front > Widgets > blogCommentFeed; Pages > Display > Database > comment; Pages > Display > Database > commentContainer; Core > Front > Global > comment; Core > Front > Global > commentContainer; Core > Front > Statuses > statusReply; Downloads > Front > Widgets > downloadsCommentFeed. Эти шаблоны необходимо обновить для корректной проверки/отображения реакций на контент с использованием нового метода. Разработчики добавили обратную совместимость для метода reputation(), где это возможно, чтобы предотвратить ошибки. Однако, старый метод reputation() уже устарел и будет удалён в следующем обновлении, поэтому вам необходимо при первой же возможности обновить любые пользовательские шаблоны, вызывающие метод reputation(). В дополнение к этому новому методу, изменился способ проверки шаблонов, в которых поддерживается репутация/реакции, т.к. реакции используют PHP трейты. Вместо такого: {{if $comment instanceof \IPS\Content\Reputation and settings.reputation_enabled}} {template="reputation" group="global" app="core" params="$comment, 'ipsPos_right ipsResponsive_noFloat'"} {{endif}} Код теперь выглядит так: {{if \IPS\IPS::classUsesTrait( $comment, 'IPS\Content\Reactable' ) and settings.reputation_enabled}} {template="reputation" group="global" app="core" params="$comment"} {{endif}} Если вы определили, что один из ваших пользовательских шаблонов требует обновления в связи с использованием реакций, мы рекомендуем воспользоваться инструментом сравнения шаблонов, чтобы корректно применить новый код. Новые настройки тем В 4.2 добавлены некоторые новые настройки. Хотя они не должны оказать существенное влияние на существующие пользовательские темы, вы можете увидеть, что добавились некоторые цвета, не вписывающиеся в ваш дизайн темы, т.к. они контролируются новыми настройками темы. Вы можете просмотреть цвета, установленные этими настройками, и настроить их в соответствии с вашими требованиями. тег (цвет фона тега); префикс (цвет фона префикса); widget_title_font (цвет текста строки заголовка виджетов); comment_count (фоновый цвет кол-ва комментариев, иногда показываемый вместе с контентом); comment_count_font (цвет текста выше); featured (цвет, используемый для определения рекомендуемого / популярного контента); pagination_active (цвет фона активной страницы в постраничной навигации); link_button (обводка и цвет текста кнопок ссылок). Просмотр форума сеткой теперь не настройка темы В 4.1 и ниже, опция просмотра форума в виде сетки была выполнена в виде отдельной настройки в теме. В 4.2 теперь это системная настройка, которая связана с новым Отзывчивым видом форума. Если вы делали проверку на просмотр сеткой в шаблонах темы, вы должны обновить конструкцию проверки. Вместо: {{if theme.forum_layout === 'grid'}} //.... нужно {{if \IPS\forums\Forum::getMemberView() === 'grid'}} //... Админцентр теперь менее зависит от пользовательской темы Разработчики решили уйти от концепции темизации админцентра на равне с темизацией сайта. Это значит, что в 4.2 админцентр по-прежнему загружает тему в том же порядке, что был в 4.1, однако теперь не может быть изменён. - многие области темы админцентра теперь жёстко закодированы в своих собственных CSS файлах и не будут наследовать настройки темы сайта. В следующих версиях админцентр нельзя будет кастомизировать, его тема будет использоваться как есть на всех сайтах.