Dogfood the Settings API

[johnbillion]

WordPress has had a ​Settings API for eight years, but the core settings screens in WordPress don't use it. Instead, these screens use hardcoded sections and fields, which means it's impossible for a plugin to remove sections or fields without removing the entire screen.

There's a new ​Fields API in development but this doesn't mean the core settings screens shouldn't be improved in the meantime by switching to the Settings API.

I think the best approach for this is to address one screen at a time, starting with General Settings, and go from there.

If anyone thinks this change should not be made, speak now or forever hold your peace.

Related: #9296, #15691, #18801, #32396

[sc0ttkclark]

This would significantly help us in our work with the Fields API by the way, there are certain settings fields on these screens which are not easily reproduced with the normal Settings API sections > fields structure as currently built.

[afercia]

Replying to sc0ttkclark:

by the way, there are certain settings fields on these screens which are not easily reproduced with the normal Settings API sections > fields structure

It would be a very good opportunity to simplify some of the settings controls :) see for example #31354 and #31356

[afercia]

Discussed in today's weekly accessibility bug-scrub and we'd like to try to do this for at least the General Settings page for 4.8.

[afercia]

Related (and closed as "maybelater"): #18285 perhaps the most interesting discussion about the Settings API is there.

[johnbillion]

38734.diff​ is an MVP (minimum viable patch) which does the following for the General Settings screen:

• Registers all of the settings.
• Registers fields for each of the existing settings table rows.
• Migrates all the hardcoded fields into settings fields.

TODO: Replace all the new procedural functions with a nice class per settings screen (eg. WP_Settings_General) with a method for each field and setting.

[afercia]

Noticed there are (also in the current options-general.php) a couple misplaced <span> elements and just thought to fix them. No other changes in the refreshed patch.

[afercia]

Punting as we're running out of time for the 4.8 release.

[MadtownLems]

I'm curious about the status of this issue/proposal. It seems set as Future Release, and got some positive comments with nobody really speaking out against the idea, but hasn't gone anywhere in 8 years (beyond John removing himself as owner).

It's still wild to me that Core doesn't "dogfood" its own Settings API. There are plenty of core settings that we don't want our Site Administrators controlling in our MultiSite environments, and we're forced to rely on JS/CSS hacks to try to hide them from people rather than simply and securely removing them with a single line of code.