#11611 closed enhancement (fixed)
Allow pluggable arg checking in current_theme_supports
Reported by: | hakre | Owned by: | ryan |
---|---|---|---|
Milestone: | 3.4 | Priority: | normal |
Severity: | normal | Version: | 2.9 |
Component: | Themes | Keywords: | has-patch 3.2-early |
Focuses: | Cc: |
Description
There is an @todo task left in the file wp-includes/theme.php inside the current_theme_supports function. The original author should decide wether or not he wants to implement the noted feature or to just drop it.
From other code I've seen today, it's commong to check $args[0] for being an array and if so to set $args =& $arg[0];
Attachments (3)
Change History (15)
#1
follow-up:
↓ 2
@
15 years ago
- Keywords dev-feedback has-patch added; developer-feedback removed
- My Take of how the pluggable support should be done.
#2
in reply to:
↑ 1
@
15 years ago
Replying to dd32:
attachment 11611.diff added
- My Take of how the pluggable support should be done.
I've read it in another way then. Can you just share two or three words what your patch is doing / should provide? I have problems to understand it.
#4
@
15 years ago
I've read it in another way then. Can you just share two or three words what your patch is doing / should provide? I have problems to understand it.
My understanding was, That for any features which accepts an array, There needed to be a filter to allow for plugins to take care of the array-based checking - As core only knows about how to handle the post-thumbnail array, Other features arrays may contain different data.
#5
@
15 years ago
- Milestone changed from 3.0 to 3.1
- Type changed from defect (bug) to enhancement
Patch looks okay to me.
There are other issues in the theme support API we're not going to get to in 3.0, such as a more robust remove_theme_support() (#12739) that can handle multiple arguments. Moving to 3.1 for now.
#8
@
14 years ago
- Keywords 3.2-early added
- Milestone changed from 3.1 to Future Release
Missed the boat, entering beta. 3.2-early.
#9
@
13 years ago
- Keywords changed from has-patch, 3.2-early to has-patch 3.2-early
Pretty much how I was writing the patch before I double checked for an existing ticket.
However, I think moving the return apply_filters
out of the switch statement would be better for readability. Having it as the default case makes the final return true;
dead code and weird.
Related: #18691