Network admin should have its own settings API

[joostdevalk]

preferably using options.php and the same API as normal admin, this way making a plugin multisite compatible (ie. adding a Network admin screen to it) would be much easier.

15691.patch takes the following tack:

• Don't use options.php but instead have a wrapper settings_form_action() that returns options.php on Site Admin and edit.php?action=pluginsettings on Network Admin. Seems more consistent with the way that Network Admin works, which strikes me as a good thing. Downside is that plugins would have to be updated to be Network-compatible. But this is not a regression, so that seems OK to me.
• When settings come from Network Admin, save them to site options automatically. This strikes me as appropriate for the majority of plugins. It does mean that plugin authors will need to be smart when they are calling up their options in order to prepopulate the settings fields - if they want plugins to work both networkwide and on single sites, they'll have to use $options = is_network_admin() ? get_site_option( 'my_plugin_options' ) : get_option( 'my_plugin_options' ); or something like that.

This second point seems problematic to me. Ideally, it would be nice if settings were registered from the very beginning (register_setting()) as site_options or not. But this would require a pretty significant rewrite of how register_settings(), and the option whitelists, currently work.

Feedback welcome.

if they want plugins to work both networkwide and on single sites, they'll have to use $options = is_network_admin() ? get_site_option( 'my_plugin_options' ) : get_option( 'my_plugin_options' );

If plugin authors want to have per-site options that overwrite network-wide options, they'll have to handle it themselves. It would be nice to have it in Core, but it's not a sticking point.

A separate API for network settings is unnecessary. My Login Security Solution plugin, ​http://wordpress.org/extend/plugins/login-security-solution/, successfully uses the same API for both regular and multisite network installs.

The main tweaks to make it fly are a few conditional statements for changing action and file names. Take a look at the plugin's source code (it's only two files) and search the text for the handful of is_multisite() calls.

In addition, this plugin is structured for easy reuse. Just rename the directory and plugin file, then change a few class constants and properties and it'll run as a whole new plugin.

convissor - It looks like your solution works on Multisite by displaying the settings panel in Network Admin, but then saving blog options to blog #1. This won't work for plugins that need to have separate settings for each site on a network (those plugins can use the regular settings API and avoid the Network Admin altogether). It also won't work for plugins that want to store their settings in Network Admin - options.php doesn't know how to handle site_options. This latter point is the crux of the issue described in this ticket.

boonebgorges:

The patch moves a large chunk of code from wp-admin/options.php to a new function called process_settings() in wp-admin/includes/misc.php. The patch also modifies the code that's been moved. While both things are good ideas, doing them in one patch obscures what changes are being made inside that block of moved code.

I have pretty much no say in what happens in core, but may I suggest making two patches? One that moves the existing code into the function. Then another that makes the rest of the changes.

Question: this new Network Settings API will use the same API (function calls, HTML, etc) as the existing Settings API, right? So plugins will be able to create one settings screen that'll work under both regular and multisite installs. If so, a hearty +1 from me.

I would like to suggest that this be marked as related to #18285 so that when it gets revised a Network option is added with a couple options to define scope of the setting, blog or network.