Реализовать базовый визуальный элемент - текстовую строку ввода

[sergey-s-betke]

С простейшим валидатором - всё допустимо (он должен применяться по умолчанию, если иной не указан).

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

[sergey-s-betke]

Никаких "внешних" и "разделяемых" визуальных элементов и планировать не буду. Все экземпляры их должны быть явно переданы в конструктор секции, иных вариантов и не рассматриваю.

[sergey-s-betke]

Кстати - секции необходимо разделить по типам - Base, VGroup (последняя - с табличной разметкой для меток и элементов управления, первая - без табличной разметки). - #27

[sergey-s-betke]

Теперь необходимо связать опцию (объект опции) с её элементов управления на странице настроек.

[sergey-s-betke]

Всё-таки, будет правильным дать элементам управления доступ к опциям.

Сейчас у меня элементы управления не имеют доступа ни к секции, ни к странице настроек, ни к плагину.

Работать с опциями целесообразно через плагин, он у нас играет некую роль точки интерфейса. Опять-таки, необходимо "позднее" связывание визуальных элементов (элементов управления) и плагина / его опций. Кроме того, целесообразно связывание проводить непосредственно перед генерацией страницы / секции.

Секция у нас имеет связь с плагином. Посему напрашивается решение возложить обязанность по позднему связыванию элементов управления с плагином / страницей / секцией на объект секции. Необходимо только корректно подобрать момент для этого.

Чтобы избежать пустой траты процессорного времени, предлагаю связывание выполнять непосредственно перед генерацией страницы. Правда - в этом случае мы не сможем выдать предупреждений (admin notice), они уже сформированы и отправлены.

Остановимся пока на варианте связывания перед генерацией страницы настроек.

[sergey-s-betke]

• [x] register_setting() - при активации, admin_init, option_group == $plugin->get_namespace()
• [x] unregister_setting() - при деактивации
• [x] add_settings_field() - вставляем элемент управления в страницу + секцию.
• [x] add_settings_section()
• [ ] add_settings_error()
• [ ] get_settings_errors()
• [ ] settings_errors()

[sergey-s-betke]

Итак... От идеи излишней инкапсуляции доступа к option я предлагаю отказаться. Да, создание и удаление при деинсталляции - всё оставляем, но и от доступа через get_option нет смысла отказываться.

Итого, меняем пространство имён с Option на Setting. Базовый класс - будет именно Option. От него наследуем Setting. А от него уже - PluginSetting. Именно класс Setting будет отвечать за 2 первых API из списка, приведённого выше.

[sergey-s-betke]

Оставшиеся API использовать необходимо в валидаторах. Поэтому пора приступать к валидаторам - #28.