Expand theme support removal for 3.0 features

[nacin]

We need remove_editor_style(), remove_custom_header_image(), and remove_custom_background().

These should internally remove theme support. I suppose the blacklist in that function needs to go.

Alternatively, we can simply add a switch statement in remove_theme_support() and handle the special instances there, but then that introduces an inconsistency, as add_theme_support() is used only internally there.

Also consider aligning the implementation of this with #14837.

[Denis-de-Bernardy]

Removing menus would also be sweet.

[nacin]

Replying to Denis-de-Bernardy:

Removing menus would also be sweet.

See unregister_nav_menu()

[Utkarsh]

remove_custom_background

[Utkarsh]

Added remove_custom_background. If the code looks fine, please let me know, I'll go ahead and create the other two.

[nacin]

Patch looks good.

Calling remove_theme_support will hit the blacklist.

We could either access the global directly, or remove the blacklist and have it then run whichever function required. We can probably add in a hook so it is pluggable and we can then just attach these functions to said hook. I can write that if you just want to keep going.

Also, it would be easier to just set the argument default to the default name of the callback.

[Utkarsh]

As only one custom background can be registered at any moment, I guess we shouldn't have the parameter for remove_custom_background at all? But I don't think the header_callback is stored anywhere.

What do you suggest for the remove_theme_support? removing the blacklist and something like do_action("remove_theme_support_$feature")?

[nacin]

Instead of returning false as a consequence of the blacklist, we can do:

return apply_filters( "remove_theme_support_$feature", false );

Then someone (us) can hook in, and additionally return true if we are successful.

Then it's trivial to just add_action( 'remove_theme_support_custom-background', 'remove_custom_background' );

I agree with you about the callback, but we still need to know the name of the callback, otherwise we can't remove the action. (At which point I'm not sure my add_action is a perfect idea, either, but then again, they can then just use remove_custom_background.)

[jorbin]

if you add a patch for remove headers, you might want to also look at #14837

[Utkarsh]

Replying to nacin:

Instead of returning false as a consequence of the blacklist, we can do:

return apply_filters( "remove_theme_support_$feature", false );

Then someone (us) can hook in, and additionally return true if we are successful.

Then it's trivial to just add_action( 'remove_theme_support_custom-background', 'remove_custom_background' );

I agree with you about the callback, but we still need to know the name of the callback, otherwise we can't remove the action. (At which point I'm not sure my add_action is a perfect idea, either, but then again, they can then just use remove_custom_background.)

If we do this, adding custom header would be add_custom_header call, and removing would require remove_theme_support call. Only a remove_custom_header do it.

[Utkarsh]

I meant remove_custom_header should handle everything.

[nacin]

(In [16674]) Introduce remove_custom_image_header(). see #14903.

[nacin]

(In [16675]) Allow the various header constants to be redefined in Twenty Ten. see #14903.

[nacin]

(In [16677]) Return true if not is_admin. Tidy. see #14903.

[nacin]

(In [16720]) Introduce remove_custom_background(). see #14903.

[nacin]

(In [16721]) Introduce remove_editor_styles(). fixes #14903.

[nacin]

(In [17300]) Check for theme support before calling has_post_thumbnail for child theme compatibility. see #14903.