Разделить опции и настройки

[sergey-s-betke]

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

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

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

Опции же будут только отвечать за инкапсуляцию API работы с опциями, и за регистрацию / удаление опций при установке / удалении плагина. И всё.

• [x] перенести валидаторы в параметры элемента управления
• [x] регистрацию настроек так же перенести в элементы управления
• [ ] по возможности - обеспечить совместимость и с существующей структурой кода плагинов, с выдачей соответствующих предупреждений
• [x] внести необходимые изменения в код плагинов

[sergey-s-betke]

Однако, при подобном подходе есть одна проблема - как реализовать редактирование одной сложной опции несколькими элементами управления.

Да, реальную опцию можно представить адаптированным для этой задачи классом опции. Чтение значения опций и запись - всё будет прекрасно. За исключением сохранения значений со страниц настроек.

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

К сожалению, если использовать settings API WordPress - мы не сможем для нескольких элементов управления использовать общее составное свойство для сохранения значения. Придётся подменять отдельные функции settings API, конкретно - settings_fields.

[sergey-s-betke]

Можно "руками" переписать settings_fields (по аналогии с akismet).

Но - вопрос: способ хранения опций определяет класс, представляющий опцию (опции). А setting при этом определяет элемент управления. Хотя - всё реально. Достаточно при сохранении вместо прямого использования option API использовать объекты опций через объект плагина.

Но такой вариант не подойдёт, если размещать свои элементы на чужой странице. В итоге - два относительно рабочих решения:

• либо на форме добавлять скрытые элементы, и в них формировать значения составных свойств (сложная реализация, разделённая между клиентом и сервером)
• перехватить действие "update_option_{$option}", в котором уже вызывать собственные обёртки для изменения составного свойства, при этом удаляя созданные "лишние" свойства...

Итого - красивых и универсальных решений в обход options API я пока не вижу. У каждого есть свои минусы, и приличные. Пока откажемся от составных свойств в пользу использования options API.