Позвольте мне предвосхитить это, сказав, что я почти никогда не работал с WordPress - фактически, когда я в последний раз делал сайт в WordPress, вернулся в 2.2. Вчера я все испортил и задал несколько вопросов, пытаясь заставить работать основной плагин меню.
Теперь у меня есть плагин, полностью работоспособный и ведущий себя точно так, как я ожидал, поэтому я решил внести небольшие изменения здесь и там, чтобы добавить функциональность и совместимость - в том числе с помощью API настроек. Тем не менее, очень короткий момент в чтении руководств по этому API, и я сильно запутался, затем эта путаница только углубилась, когда я продолжил читать и попытался реализовать примеры - что стало еще более трудным из-за того, что мой плагин реализован как класс ,
Если я не делаю что-то не так, из того, что я понимаю, для использования API настроек требуется создание новой функции НА НАСТРОЙКИ. Это означает 3-5 функций для среднего плагина и до сотни для более сложных плагинов. Просто кажется нелепым писать такое множество функций (и разрабатывать систему именования, чтобы не перепутать их), когда вы с такой же легкостью можете импортировать все применимые $_POST
переменные в массив и отказаться от всего беспорядка.
Возможно, я старомоден, но если от этого что-то не получится, я не вижу причины, чтобы утроить или увеличить в четыре раза объем написанного кода. Вот как я управлял параметрами, прежде чем пытаться добавить API настроек:
function __construct() {
/* constructor stuff */
$this->options = $this->db_options = get_option( 'de-menu-options' );
if( $this->options === false ){
$this->options = $this->defaults;
}
if (is_admin()) {
add_action('admin_menu', array(&$this, 'admin_menu'));
}
/* more stuff */
// When WordPress shuts down we store changes to options
add_action('shutdown', array(&$this, 'update'));
}
public function admin_menu() {
add_options_page('DE Menu Options', 'DE Menu', 'manage_options', 'de-menu-options', array(&$this, 'options'));
add_option('de-menu-options', $this->options);
}
public function options() {
if (!current_user_can('manage_options')) {
wp_die( __('You do not have sufficient permissions to access this page.') );
}
if ( !empty($_POST) && check_admin_referer('de-menu-options') ) {
// These options are saved to the database at shutdown
$this->options = array(
"columns" => $_POST["de-menu-columns"],
"maintenance" => $_POST["de-menu-maintenance"]
);
echo 'DE Menu options saved';
}
?>
<div class="wrap">
<h2>DE Menu Plugin</h2>
<form method="post" action="<?php echo $_SERVER['REQUEST_URI']; ?>">
<?php settings_fields('de-menu-options'); ?>
<input type="checkbox" name="de-menu-maintenance" />
<label for="de-menu-columns">Columns:</label>
<input type="text" name="de-menu-columns" value="<?php echo $this->options['columns']; ?>" />
<p class="submit">
<input type="submit" name="de-menu-submit" value="Update Options »" />
</p>
</form>
</div>
<?php
}
function update() {
// By storing all changes at the end we avoid multiple database calls
$diff = array_diff( $this->options, $this->db_options );
if( !empty( $diff ) ){
update_option('de-menu-options', $this->options);
}
}
Теперь с настройками API у меня есть что-то похожее на следующее:
function __construct() {
/* constructor stuff */
// Do I load options? Will they be loaded for me? Who knows?
if (is_admin()) {
add_action('admin_menu', array(&$this, 'admin_menu'));
add_action('admin_init', array(&$this, 'admin_init'));
}
/* more stuff */
// Settings API should update options for me... I think
}
public function admin_menu() {
add_options_page('DE Menu Options', 'DE Menu', 'manage_options', 'de-menu-options', array(&$this, 'options'));
add_option('de-menu-options', $this->options);
}
public function admin_init() {
register_setting('de-menu-options','de-menu-options',array(&$this,'validate'));
add_settings_section('de-menu-main-options', 'Main Settings', 'options_section', 'de-menu-options');
add_settings_field('de-menu-maintenance', 'Maintenance Mode', array(&$this,'options_maintenance'), 'de-menu-options', 'de-menu-main-options');
add_settings_field('de-menu-columns', 'Columns', array(&$this,'options_columns'), 'de-menu-options', 'de-menu-main-options');
}
public function options() {
if (!current_user_can('manage_options')) {
wp_die( __('You do not have sufficient permissions to access this page.') );
}
if ( !empty($_POST) && check_admin_referer('de-menu-options') ) {
// These options are saved to the database at shutdown
$this->options = array(
"columns" => $_POST["de-menu-columns"],
"maintenance" => $_POST["de-menu-maintenance"]
);
echo 'DE Menu options saved';
}
?>
<div class="wrap">
<h2>DE Menu Plugin</h2>
<form method="post" action="<?php echo $_SERVER['REQUEST_URI']; ?>">
<?php settings_fields('de-menu-options'); ?>
<?php do_settings_sections('de-menu-options'); ?>
<p class="submit">
<input type="submit" name="de-menu-submit" value="Update Options »" />
</p>
</form>
</div>
<?php
}
public function options_section() {
echo '<p>' . __('Main description of this section here.','de-menu-lang') . '</p>';
}
public function options_maintenance() {
echo "<input id='de-menu-maintenance' name='options[maintenance]' type='checkbox' />";
}
public function options_columns() {
echo "<input id='de-menu-columns' name='options[columns]' type='checkbox' value=".$this->options['columns']."/>";
}
function validate($options) {
return $options; // I guess?
}
Вероятно, из полос прокрутки до боли видно, что код уже длиннее всего с двумя вариантами. Из комментариев очевидно, что я не совсем понимаю, что делаю. Тогда есть вопрос наличия 5 новых функций (и удаления только 1), чтобы выполнить все это.
Так какое же преимущество я получаю от всей этой дополнительной работы?
источник
add_settings_section
иadd_settings_field
эти две функции добавляют вздутие живота в ваш код больше, чем что-либо другое, избегайте их и вы избегаете вздутияОтветы:
Моя точка зрения заключается в том, что основной целью и преимуществом API настроек является структура .
Это помогает сохранять сложные настройки параметров:
Как и в случае любых таких структурных накладных расходов, это приносит пользу более сложным вариантам использования и выгодно менее простым.
Таким образом, вы можете реализовать все, что API настроек делает без его использования. Вопрос в том, сможете ли вы сделать это надежным, безопасным и расширяемым способом.
источник
Если вы используете обратные вызовы правильно, вам не нужен весь избыточный код. Вот как я могу реализовать API настроек таким образом, чтобы он был полностью масштабируемым .
Преимущества (среди прочего):
источник
oenology_get_settings_by_tab()
иoenology_get_default_options
даже не определяет их сначала? Я думал, что это было достаточно плохо с 209 строками кода (после удаления комментариев и пустых строк), но как только эти функции будут определены, это будет еще длиннее ... Для четырех вариантов?oenology_get_settings_by_tab()
самом деле не имеет отношения к тому, что вы делаете. Но вы должны определить свою форму поля разметки где - то , как вы должны для проверки / дезинфицировать пользовательского ввода - то , так что если вы делаете это правильно, вы будете иметь все тот же код , как хорошо.Спасибо за публикацию, мне было интересно то же самое. Много функций.
Чтобы уменьшить их, вы можете хранить ваши параметры в виде массивов. Wordpress сериализует данные для вас. Это экономит код (или функции в любом случае), но ухудшает данные. Например, если вы хотите отсортировать, отредактировать вручную, экспортировать и т. Д. Ваши таблицы, они будут иметь эти сериализованные значения. С другой стороны, ваш плагин добавляет меньше записей в таблицу параметров, и их легче очистить.
Итак, вот ваш код переделан. Несколько заметок:
<label>
для доступности. Использование add_settings_error (), settings_error (), которые обрабатывают сообщения, а также ошибки. Это часто единственная причина иметь отдельные функции проверки для каждой опции. Вы можете видеть ниже validate_w () и validate_h () может быть одной функцией. Я пытался абстрагироваться от сообщений, но, насколько я помню, вы не получаете достаточно информации в обратном вызове проверки. Как то, над чем вы работаете.Код:
источник