$visibilityLimit / canViewModerated изменен
Изменения, которые здесь происходят, довольно обширны, хотя влияние на дополнения не окажут.
Как правило, эти изменения должны поддерживать контроль над тем, просматривают ли страницы листинга контент, который может ожидать одобрения для отдельных пользователей. Абсолютное большинство пользователей не будет иметь ничего ожидающего, и эта проверка не подходит для производительности. Теперь мы будем искать только ожидающий контент для пользователя в этих запросах в течение ограниченного времени после того, как они отправят контент, ожидающий утверждения.
Любые методы, которые получили параметр $visibilityLimit (как правило, в репозитории), теперь получают массив в своем месте, чтобы разрешить применение нескольких ограничений без добавления аргументов. Из коробки большинство случаев знают 2 варианта:
Если вы расширили метод, подобный этому, скорее всего, вы просто обновите определение метода и как вы вызываете родительский метод.
Это также означает, что методы canViewModeratedX в объектах теперь всегда возвращают булевское значение, а не true/false/int.
Отслеживание, когда пользователь отправляет ожидающий контент
Это не перерыв BC для каждого набора, но связанный с вышеизложенным, если вы измените свои собственные типы контента для использования вышеуказанного подхода, вы захотите вызвать
XF\AddOn\CheckRequirementsInterface устарел
Этот интерфейс устарел и будет удален для стабильной версии XF2. Любые классы установки, реализующие этот интерфейс, будут ошибочными после его удаления. Начиная с бета-версии 7, ее использование вызовет предупреждение об устаревании.Интерфейс больше не нужен. Пустой метод теперь определен для
XF\Tfa\AbstractProvider::generateInitialData изменена подпись
Чтобы упростить реализацию поставщиков TFA, требующих дополнительной настройки, была изменена подпись этого абстрактного метода. Любая пользовательская реализация TFA для XF2 должна будет изменить определение их метода.Теперь он получает второй аргумент, массив данных конфигурации, который может быть получен из новых методов requireConfig() / handleConfig(). Они могут быть реализованы для разрешения начальной конфигурации перед запуском тестового / установочного запроса TFA.
Изменения, которые здесь происходят, довольно обширны, хотя влияние на дополнения не окажут.
Как правило, эти изменения должны поддерживать контроль над тем, просматривают ли страницы листинга контент, который может ожидать одобрения для отдельных пользователей. Абсолютное большинство пользователей не будет иметь ничего ожидающего, и эта проверка не подходит для производительности. Теперь мы будем искать только ожидающий контент для пользователя в этих запросах в течение ограниченного времени после того, как они отправят контент, ожидающий утверждения.
Любые методы, которые получили параметр $visibilityLimit (как правило, в репозитории), теперь получают массив в своем месте, чтобы разрешить применение нескольких ограничений без добавления аргументов. Из коробки большинство случаев знают 2 варианта:
visibility- это то, что булевое значение $visibilityLimit используется для представления (true/false)allowOwnPending- это контролирует, будем ли мы включать контент, ожидающий одобрения для данного конкретного пользователя (когда они не могут просмотреть все ожидающие содержимого)
Если вы расширили метод, подобный этому, скорее всего, вы просто обновите определение метода и как вы вызываете родительский метод.
Это также означает, что методы canViewModeratedX в объектах теперь всегда возвращают булевское значение, а не true/false/int.
Отслеживание, когда пользователь отправляет ожидающий контент
Это не перерыв BC для каждого набора, но связанный с вышеизложенным, если вы измените свои собственные типы контента для использования вышеуказанного подхода, вы захотите вызвать
XF\Session\Session::setHasContentPendingApproval() когда пользователь отправляет контент, который требует одобрения модератора. Чтобы проверить это (перейти к методу, который его использует), вы можете вызватьXF\Pub\Controller\AbstractController::hasContentPendingApproval().XF\AddOn\CheckRequirementsInterface устарел
Этот интерфейс устарел и будет удален для стабильной версии XF2. Любые классы установки, реализующие этот интерфейс, будут ошибочными после его удаления. Начиная с бета-версии 7, ее использование вызовет предупреждение об устаревании.Интерфейс больше не нужен. Пустой метод теперь определен для
XF\AddOn\AbstractSetup::checkRequirements.XF\Tfa\AbstractProvider::generateInitialData изменена подпись
Чтобы упростить реализацию поставщиков TFA, требующих дополнительной настройки, была изменена подпись этого абстрактного метода. Любая пользовательская реализация TFA для XF2 должна будет изменить определение их метода.Теперь он получает второй аргумент, массив данных конфигурации, который может быть получен из новых методов requireConfig() / handleConfig(). Они могут быть реализованы для разрешения начальной конфигурации перед запуском тестового / установочного запроса TFA.
