0

I'm messing about with overriding parent themes by child themes.

The parent theme registers custom backgrounds by hooking add_theme_support('custom-background',$args) to after_setup_theme.

Now, if I want to simply disable custom backgrounds in the child theme I have no trouble defining my own function and hooking it to after_setup_theme priority 11:

child_remove_custom_background(){
  remove_theme_support('custom-background');
}

But if I want to then add custom-background support back with a new default color or image, I cannot. The previously registered $args remain in effect.

A little poking around in core /wp-includes/theme.php reveals why:

// Merge in data from previous add_theme_support() calls. The first value registered wins.
if ( isset( $_wp_theme_features['custom-background'] ) )
    $args[0] = wp_parse_args( $_wp_theme_features['custom-background'][0], $args[0] );

if ( $jit )
    args[0] = wp_parse_args( $args[0], $defaults );

if ( defined( 'BACKGROUND_COLOR' ) )
    $args[0]['default-color'] = BACKGROUND_COLOR;
elseif ( isset( $args[0]['default-color'] ) || $jit )
    define( 'BACKGROUND_COLOR', $args[0]['default-color'] );

if ( defined( 'BACKGROUND_IMAGE' ) )
    $args[0]['default-image'] = BACKGROUND_IMAGE;
elseif ( isset( $args[0]['default-image'] ) || $jit )
    define( 'BACKGROUND_IMAGE', $args[0]['default-image'] );

Knowing this, I can work around it by simply firing my child theme's custom-background args onto after_setup_theme priority 9 to beat the parent theme to the "register first" finish line. And maybe, baby, it's right, but it feels so wrong.

So my question is why? And is just firing the child theme's replacement call to add_theme_support() on a lower priority the best workaround available? The behavior I am observing is obviously intentional, or at least done with full awareness, given the comment within the code. But what purpose could possibly be served setting the background color and image in stone as constants so that first one wins, rather than using yet another (infamous) global variable that would allow the last (presumably overriding) registration to win? I'm not looking for theoretical speculation or opinion here. What am I not understanding? Is there a "That's the WordPress Way" principle here I'm not aware of that will turn up to bite me in other places? Or maybe the answer is, "Yeah, there's no good reason for this, submit a ticket and a patch on trac."

Thanks.

  • the question as it is is not very productive. No one here wrote that code therefor it is unlikely that you will get an authoritative answer. If you want to ask how to get around this limitation (and I do not know if it is possible, but I am not an expert in that area) please edit your question to reflect it. – Mark Kaplun Mar 8 '15 at 4:36
  • I realize that no one here wrote the code. But I was hoping that someone more experienced than I might know of a reason that makes sense and would perhaps be operating in other situations as well. I suppose, if there really <em>isn't</em> one, if the answer is "It's an anomaly," a way around it would be to submit a ticket/patch on trac. However, I'll also edit the question to clarify. – Caspar Mar 8 '15 at 11:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.