Closed sergey-s-betke closed 10 years ago
sergey-s-betke
commented
10 years ago Да, предложенный подход вполне возможен. Причём описанные выше классы станут предками существующих классов Base для страницы настроек и для секции на странице настроек.
sergey-s-betke
commented
10 years ago Для добавления секций на существующие страницы настроек:
new WPF\GUI\Setting\Page\Existing( 'options-general.php', 'writing',
секции...
)Позднее - изменил и упростил:
new WPF\GUI\Setting\Page\Base( 'options-general.php', 'reading', ... )Вторую часть задачи пока отложу - не вижу целесообразности.
sergey-s-betke
commented
10 years ago Вероятнее всего - не доделал. Необходимо тестировать.
Дело в том, что проверка и собственно изменений настроек происходит в соответствии с той группой настроек, которая возвращается get_option_group() методом страницы настроек. А настройки я регистрирую для плагина, и группа для них не зависит на сегодняшний день от того, на какой странице они будет редактироваться. Просто сейчас в обоих случаях использую $plugin->get_namespace().
Следует проверить, можно ли выводить несколько групп settings_fields() (раньше было нельзя). По хорошему, данную функцию следует вызывать для каждой секции.
Либо же придётся явно указывать группу для настроек при размещении их на существующих страницах, а не на странице настроек плагина.
Итого: сейчас секция не генерирует settings_fields(), что, возможно, не очень правильно.
sergey-s-betke
commented
10 years ago Как я и предполагал, settings_fields() на одной странице настроек может быть вызван только однажды. Поэтому для размещения собственных настроек на чужих страницах необходимо и опции (setting) определять соответствующим образом - включать их в группу страницы, на которой планируется разместить элементы управления для их редактирования.
В итоге возникает дилема. С одной стороны, опции (настройки) мы определяем как самостоятельные компоненты плагина. С другой стороны, при регистрации настроек важно корректно их привязать к странице настроек.
Напрашивается необходимость разделения собственно опций и настроек, и последние должны быть связаны не с плагином, а со страницей настроек!
Верификаторы и санитизаторы при этом должны быть привязаны именно к настройкам, а не к опциям.
sergey-s-betke
commented
10 years ago Назревает существенный редизайн классов опций и настроек по указанным выше причинам.
Самым, вероятно, простым и удобным для использования будет решение по реализации функционала настроек в рамках элементов управления. По сути, для этого необходимо перенести валидатор и его параметры в элементы управления из опций. И регистрацию настройки, естественно, так же придётся перенести из класса опции в базовый класс элемента управления.
Итак, элемент управления у нас будет реализовывать функционал настройки, и за регистрацию настроек так же он будет отвечать. Верификатор, в итоге, будет его параметром, а не параметром опции.
Опции же будут только отвечать за инкапсуляцию API работы с опциями, и за регистрацию / удаление опций при установке / удалении плагина. И всё.
sergey-s-betke
commented
10 years ago Выделил описанную выше проблему в отдельную задачу - https://github.com/IT-Service-WordPress/WPF/issues/48.
Сейчас реализована возможность для создания собственных страниц настроек, секций на них и элементов управления в них. Однако, будет правильным предоставить возможность расширять существующие страницы настроек, а не только создавать собственные:
Наиболее логичной и простой будет реализация классов для представления существующих страниц настроек и секций в них вместо создания собственных. Тогда структура кода плагина не изменится, и код элементов управления не потребует каких-либо изменений.