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.

[costdev]

#58925 was marked as a duplicate.

[dcavins]

I'd like this ticket to happen, but it seems like it's gone to the dead ticket ranch many long years ago. What is required to get this simple and straightforward improvement pushed through? Please let me know if I can help. Thanks!

[dcavins]

A refereshed version of the previous patch that adds removal functions.