[wp-trac] [WordPress Trac] #15691: Network admin should have its own settings API
WordPress Trac
noreply at wordpress.org
Sat Feb 6 13:45:14 UTC 2016
#15691: Network admin should have its own settings API
-------------------------------------+-------------------------------------
Reporter: joostdevalk | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: Future Release
Component: Plugins | Version:
Severity: normal | Resolution:
Keywords: has-patch settings-api | Focuses: administration,
dev-feedback | multisite
-------------------------------------+-------------------------------------
Changes (by flixos90):
* keywords: has-patch settings-api => has-patch settings-api dev-feedback
Comment:
As discussed on Slack, [attachment:15691.2.diff] is a new take on this
ticket, based on @boonebgorges original patch. Some notes on the
implementation:
* Settings are processed in a new `process_settings()` function which
contains the code that generally overlaps between regular site vs network
options. The function has a `$context` parameter which is set to `site` by
default, but accepts `network` as well. This implementation is flexible to
support possible settings-related features in the future, for example
global options (that go for all networks) or user options.
* The `process_settings()` function is called from `wp-admin/options.php`
and `wp-admin/network/settings.php` respectively. I left the code parts in
there which I considered to be too specific to go into
`process_settings()`, but maybe we could even merge more of that into the
function.
* Lines 150-188 of `wp-admin/options.php` and lines 47-65 of `wp-
admin/network/settings.php` contain actions that are specific to their
respective type of options (see above bullet point) - these should
probably placed elsewhere, but I left them in there for now for a better
overview.
* In `wp-admin/network/settings.php`, there is a global
`$whitelist_options` array now, similar to `wp-admin/options.php`. I gave
the one existing default settings page the slug `general`, and by default
this is the only settings page in that array. A filter
`whitelist_network_options` allows for new custom network settings and is
used by `register_setting()` when called in network mode.
* I also adjusted the related Settings API functions with the new
`$context` parameter (for example `register_setting()` and
`settings_errors()`, providing an easy way to distinguish between the type
of setting to manage. Settings errors are handled on a network-wide level
when needed.
* I also allowed `settings_fields()` to be network-compatible and adjusted
the related code of the network settings page to output the nonce and
action hidden fields, so that the network settings check for these
variables instead of simply checking whether `$_POST` contains something,
aligning it with the regular API.
* What I didn't include in this implementation are functions like
`add_settings_section()` and `do_settings_sections()` which I think should
be enhanced in the same manner as well, but they are not crucial to this
first approach, so we could do that later.
The following code shows an example of how to use this implementation.
{{{#!php
<?php
function nst_menu() {
add_submenu_page( 'settings.php', __( 'Network Settings Test',
'nst' ), __( 'Network Settings Test', 'nst' ), 'manage_network_options',
'network-settings-test', 'nst_render_page' );
}
add_action( 'network_admin_menu', 'nst_menu' );
function nst_register_setting() {
register_setting( 'network_settings_test',
'network_settings_test', 'nst_sanitize_settings', 'network' );
}
add_action( 'admin_init', 'nst_register_setting' ); // consider creating a
new action 'network_admin_init' for things like that
function nst_sanitize_settings( $options ) {
if ( false !== strpos( $options['test_value2'], '@example.com' ) )
{
add_settings_error( 'network_settings_test',
'some_email_error', __( 'You must not provide emails @example.com.', 'nst'
), 'error' );
$options['test_value2'] = '';
}
return $options;
}
function nst_render_page() {
$options = get_site_option( 'network_settings_test', array() );
?>
<div class="wrap">
<h1><?php _e( 'Network Settings Test', 'nst' ); ?></h1>
<form method="post" action="settings.php"
novalidate="novalidate">
<?php settings_fields( 'network_settings_test',
'network' ); ?>
<table class="form-table">
<tr>
<th scope="row"><label
for="test_value1">Name</label></th>
<td><input type="text"
id="test_value1" name="network_settings_test[test_value1]" value="<?php
echo isset( $options['test_value1'] ) ? $options['test_value1'] : ''; ?>"
/></td>
</tr>
<tr>
<th scope="row"><label
for="test_value2">Email</label></th>
<td><input type="email"
id="test_value2" name="network_settings_test[test_value2]" value="<?php
echo isset( $options['test_value2'] ) ? $options['test_value2'] : ''; ?>"
/></td>
</tr>
</table>
<?php submit_button(); ?>
</form>
</div>
<?php
}
}}}
I'm curious for feedback, if this is something we could build upon -
making the regular Settings API network-compatible. And regarding this
implementation, especially about possible issues with backwards
compatibility. One point that I'm not sure about is whether in line 46 of
`wp-admin/network/settings.php` we might need to continue support for just
checking on `$_POST`.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/15691#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list