#14903 closed task (blessed) (fixed)
Expand theme support removal for 3.0 features
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 3.1 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | Themes | Keywords: | |
Focuses: | Cc: |
Description
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.
Attachments (1)
Change History (16)
#3
@
13 years ago
- Cc admin@… added
Added remove_custom_background. If the code looks fine, please let me know, I'll go ahead and create the other two.
#4
@
13 years ago
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.
#5
@
13 years ago
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")?
#6
follow-up:
↓ 8
@
13 years ago
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.)
#8
in reply to:
↑ 6
@
13 years ago
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.
Removing menus would also be sweet.