При наличии страницы настроек при активации плагина выдавать notice со ссылкой на страницу настроек

[sergey-s-betke]

Автоматически перенаправлять мы не будем (пример - http://solislab.com/blog/plugin-activation-checklist/), просто добавим ссылку. А использовать для этого будем не опцию, а transient.

[sergey-s-betke]

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

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

[sergey-s-betke]

Данная задача решена. Уведомления выдаются только на некоторых страницах консоли (см. add_review_settings_notice).

[sergey-s-betke]

Целесообразно изменить интерфейс с deffered_action на что-нибудь типа schedule_todo. Реализовать можно как отдельным компонентом, так и в базовом классе плагина.

Смысл в том, чтобы только планировать обязательные действия пользователя с указанием перечня slugов страниц консоли, на которых уведомления будут отображаться. И также - указывать страницу (опционально), после посещения которой уведомление будет автоматически сниматься.

В идеале интерфейс необходимо привести к созданию экземпляра некоего класса, и всё на этом. Далее - за всё должен отвечать этот объект.

Причём не должно быть необходимости создавать его повторно. Его можно сериализовать в transient с указанным при создании временем жизни, и при загрузке плагина отдельным контроллером его "возрождать" как самостоятельный динамический компонент (напрашивается именно некий компонент, так как transient всё-таки необходимо удалять за собой, если TTL не указан). И методом unschedule удалять его из transient.

При таком подходе код для решения данной задачи будет сокращён до нескольких строчек.

[sergey-s-betke]

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

И снова встаёт вопрос о неявном связывании компонентов с объектом плагина. При загрузке динамических компонентов из transient - проблем не будет. Грузить их будет контроллер-компонента, который имеет уже связь с объектом плагина.

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

[sergey-s-betke]

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

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

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

Итак, этим путём и пойдём!

[sergey-s-betke]

• [x] базовый класс динамических компонентов
• [x] динамический компонент - уведомление
• [x] контроллер динамических компонентов

[sergey-s-betke]

Пример первого динамического компонента плагина - \WPF\v1\Plugin\Component\ToDo- уведомление на указанных страницах консоли о необходимости посещения конкретной страницы. После её посещения уведомление удаляется.