Make it easy to disable options / user settings

[westi]

We have a wonderful option white listing system.

The one thing it doesn't support is hiding the ui of core options if you don't want them changed.

We should have a generic way of doing this.

[scribu]

Tempted to close this as duplicate of #16413

[scribu]

Related: #18251

[scribu]

The first thing we need, as mentioned in #18251, is the missing functions:

remove_settings_field() remove_settings_section() remove_settings_error()

[ctsttom]

If someone would mentor me a little on this I will try and do it and submit the patch, would love to get into core dev work but just a little confused as to where to start... I know kung-fu (PHP) and I have a couple of plugins but the leap seems a little uncomfortable to pitch my fork in.

[scribu]

See ​http://core.trac.wordpress.org/#HowtoSubmitPatches

[ctsttom]

Okay so here is my first attempt to add the two functions I suggested, I didn't add remove_settings_error() because I don't really know why you'd want that / I don't under stand that part yet...

I also wrote a dummy plugin to test the code out with (there is a function within it called test_removal() which you can uncomment to test, and var_dump the globals $wp_settings_sections and $wp_settings_fields from /wp-admin/includes/template.php

Files attached...

[ctsttom]

Addition of two new functions and a spelling error in a comment

[scribu]

Instead of if ( count( $wp_settings_fields[$page] ) == 0 ), you should use empty(), which is faster.

Also, spaces are needed before and after the parameter list:

function remove_settings_section($id, $page) {

[ctsttom]

Corrections to previous patch

[ctsttom]

Aforementioned dummy plugin to test with

[ctsttom]

I have fixed those two points, funnily enough I was going to put spaces around the parameter list but every other function in that file was missing those so I thought I shouldn't do it.

[ctsttom]

Would someone review this for inclusion?

[scribu]

We need to figure out what we're going to do in #18285 first.

[ctsttom]

@scribu Thanks, I will hold off then.

[ctsttom]

Where are we at with this, and the Settings API stuff?

[scribu]

We are nowhere. A winning approach has not been found yet.

[unknowndomain]

Hey folks,

Wanted to notify you of a call to action on this tickets blocking ticket:
​http://core.trac.wordpress.org/ticket/18285#comment:76

Thanks

Tom

[ctsttom]

Once 3.5.1 is out of the way I am going to referesh this.

[unknowndomain]

I have updated my patch for 3.6 and added remove_settings_error, and some minor changes to my documentation.

Would love a review on this!

[unknowndomain]

I am looking at this again, just wondering if people think it would be best to just wrap the existing code in settings api stuff for now, and @helen is going to be looking at #16413 in 3.8 anyways.

[unknowndomain]

Example of how the Settings API might be implemented.

[unknowndomain]

I have been playing about and you can see this might be one way of implementing the settings api to these files, I haven't done even one whole file as it is time consuming, but perhaps people could provide feedback on my patch and how it might work?

[chriscct7]

I'm going to take a look at this as part of #32396

[chriscct7]

Duplicate of #28754.

[chriscct7]

Duplicate of #28754.

[alpipego]

I can't see how this is a dupe.