Make WordPress Core

Opened 3 years ago

Last modified 2 months ago

#15691 new feature request

Network admin should have its own settings API

Reported by: joostdevalk Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Plugins Keywords: has-patch settings-api
Focuses: administration, multisite Cc:


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.

Attachments (1)

15691.patch (7.7 KB) - added by boonebgorges 3 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 nacin3 years ago

  • Milestone changed from Awaiting Review to Future Release

comment:2 boonebgorges3 years ago

  • Cc boonebgorges@… added

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.

boonebgorges3 years ago

comment:3 mercime2 years ago

  • Cc mercijavier@… added

comment:4 scribu2 years ago

  • Keywords has-patch added

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.

comment:5 convissor2 years ago

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.

comment:6 boonebgorges2 years ago

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.

comment:7 convissor19 months ago


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.

comment:8 unknowndomain16 months ago

  • Keywords settings-3.6 added

comment:9 unknowndomain16 months ago

  • Cc me@… added

comment:10 SergeyBiryukov16 months ago

  • Keywords settings-api added; settings-3.6 removed

comment:11 unknowndomain15 months ago

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.

comment:12 toscho11 months ago

  • Cc info@… added

comment:13 sbrajesh9 months ago

  • Cc brajesh@… added

comment:14 DrewAPicture9 months ago

  • Cc xoodrew@… added

comment:15 Offereins8 months ago

  • Cc lmoffereins@… added

comment:16 nacin2 months ago

  • Component changed from Network Admin to Plugins
  • Focuses administration added

comment:17 nacin2 months ago

  • Component changed from Plugins to Admin APIs

comment:18 nacin2 months ago

  • Component changed from Admin APIs to Plugins

Sorry for the noise.

Note: See TracTickets for help on using tickets.