Closed sergey-s-betke closed 10 years ago
add_settings_error
использовать не получится. Функции этой группы явно проверяют строку запроса на обновление опций. Поэтому можно только построить нечно аналогичное.
Суть данной идеи была в том, чтобы в случае ошибки активации вывести суть ошибки сразу и деактивировать плагин, чтобы уже в дальнейшем при его загрузке и не проверять лишнего. Для этого необходим уже существующий в wordpress механизм вывода сгенерированной ошибки.
Раз add_settings_error
нам не подходит, единственный вариант - генерировать вывод при активации в случае ошибки, который будет отображён в песочнице (фрейме), но крайне желательно при этом - подключить стили по возможности.
Предположительно ошибку в коде активации для этого потребуется генерировать через trigger_error
. Да, генерация ошибки таким образом позволяет остановить активацию плагина, и wordpress всё сделает сам. Сообщения, конечно, выводятся в iframe, и без стилей, что не очень хорошо, но это уже косяки wordpress, исправлять их сейчас смысла нет.
Итак, есть предложение - переписать проверку совместимости на генерацию сообщений через trigger_error
.
Для обоих валидаторов целесообразно реализовать общий базовый класс.
И метода validate
должен возвращать WP_error
, и уже метод, вызвавший валидацию, должен генерировать необходимый вывод. Тогда валидация будет единой в базовом классе.
В этом объекте можно сохранить и коллекцию ошибок, что нам и требуется. Посему переводим валидаторы на использование данного объекта.
При выводе в <iframe></iframe>
ошибок на этапе активации плагина подключил и некоторые стили. Шаблон - views\plugin_activation_error.php
.
В том числе - и требования программной совместимости. Проверять их при активации и обновлении, и через transient передавать в консоль. Посмотреть для этих целей
add_settings_error
. Данная функция как раз использует transient, в результате, надеюсь, вообще не придётся использовать явно admin notice, а также повторять проверки не в install / update time