Adding Sidebars to a Child Theme

Worked for me, I removed (commented out) the function twentyten_widgets_init() {
// Area 1, located at the top of the sidebar.
register_sidebar( array( ……etc

in my parent themes functions.php .. unfortunately the only clean way I was able to get WP to not call both functions.php widgets functions.

For adding alternative widget areas to your child theme, check out “WordPress Tip: Different Sidebars on Different Pages”. One thing that’s important to keep in mind is that a child theme’s functions always load before the parent theme’s functions. In the ‘functions.php’ file for Theme Twentyten, there’s an instruction:

* To override twentyten_widgets_init() in a child theme, remove the action hook and add your own function tied to the init hook.

This means, in your child theme’s ‘functions.php’ file, you need to use the 'remove_action( 'widgets_init', '$name' ); script. For instance, in your twentyten-child theme’s ‘functions.php’ file, use:

remove_action( ‘widgets_init’, ‘twentyten_widgets_init’ ); //necessary to replace parent theme’s code

Immediately follow with your newly named function, for example:

function twentyten_child_widgets_init() {

And then proceed to register_sidebar and define your arrays. If you want to keep the parent theme’s default sidebar areas, then copy and paste here, and add your alternative sidebars to them, like this:

// Area 7, located at the top of the sidebar.
register_sidebar( array(
‘name’ => __( ‘Alt Primary Widget Area’, ‘twentyten’ ),
‘id’ => ‘alt-primary-widget-area’,
‘description’ => __( ‘Alt primary widget area’, ‘twentyten’ ),
‘before_widget’ => ‘<li id=”%1$s” class=”widget-container %2$s”>’,
‘after_widget’ => ”,
‘before_title’ => ‘<h3 class=”widget-title”>’,
‘after_title’ => ‘</h3>’,
) );

Finally, add_action, like this:

/** Register sidebars by running twentyten_child_widgets_init() on the widgets_init hook. */
add_action( ‘widgets_init’, ‘twentyten_child_widgets_init’ );

In this way you can keep the parent theme’s sidebars (without fear of losing them every time there’s an upgrade), and you can introduce new widget areas into your child theme.

Photocurio, are you sure you haven’t left intact the native widget areas in your new function declaration? Paste the relevant code from your child’s functions.php up at wordpress.pastebin.com and give us the link to look it up.

Functions.php looks fine. Should have disabled the parent theme’s widget areas. But I don’t know enough about this… maybe the widget areas are disabled, but not removed? Are any of the widgets in those primary and secondary widget areas showing up? I see the default search and archives – these do not appear to be widgets. But what about the Recent Posts and Categories? Are these widgets? What’s in your sidebar.php? Sorry, it’s very late here, and I’ve had a very long day and need to catch some rest, but I’ll check back later in the morning. In the meantime, maybe someone more knowledgeable will be able to help!

Photocurio, I’m getting the same behavior. To test it out, I deleted the parent theme’s default widget areas from my child theme’s functions.php and left only the alternative widget areas, saved as. When I viewed the website, all the widgets in the default areas are showing up as before. In the backend, my alternative widget areas are now listed above the default widget areas, but indeed, both alternative and default widget areas are accessible. This is unexpected.

Next left only the ‘remove_action’ string and did not replace with any new widget areas. This had the result of disabling the widgets, but not actually removing the widget areas, as they are still accessible in the backend.

I also just tested deleting the primary & secondary widget areas from the parent theme’s functions.php. This does remove the widget areas from the backend. Problem is: everytime your client upgrades, the functions.php will be overwritten and back to default.

Apparently the ‘remove_action’ in the child theme’s functions is not the same as deleting. We need a different string. I tried Esmi’s suggestion :

unregister_sidebar( array(
‘name’ => __( ‘Primary Widget Area’, ‘twentyten’ ),
‘id’ => ‘primary-widget-area’,
‘description’ => __( ‘The primary widget area’, ‘twentyten’ ),
‘before_widget’ => ‘<li id=”%1$s” class=”widget-container %2$s”>’,
‘after_widget’ => ”,
‘before_title’ => ‘<h3 class=”widget-title”>’,
‘after_title’ => ‘</h3>’,
) );

coupled with the ‘remove_action’, but it did nothing that I could see. Unfortunately, I’m not a php geek. Anyone else?

Same weblink, but scroll down to the comments. Justin Tadlock has given the solution.

Quote: Adding an extra action hook is completely unnecessary. Your child theme (when unregistering didn’t work) was simply not executing the code on the correct hook or your parent theme developer decided to not use a hook when registering the sidebars. Which theme’s functions.php file is loaded first should be irrelevant if developers properly code their themes.

The parent theme should put its sidebar registration on something like widgets_init.

add_action( 'widgets_init', 'my_register_sidebars' );

The child theme should put its unregister sidebar function on the same hook with a later priority.

add_action( 'widgets_init', 'my_unregister_sidebars', 11 );

WordPress already has built-in hooks for these things. There’s no need for trying to find workarounds when the solution is already handled in core. Theme developers just need to use them instead of randomly dropping code into functions.php.

I tested as follows. Following the declaration of new widget area in child theme’s functions.php, after the final add_action string, placed this:

function my_unregister_sidebars() {
unregister_sidebar( ‘primary-widget-area’ );
}

//unregister sidebars by tying onto same hook again, with priority ’11’
add_action( ‘widgets_init’, ‘my_unregister_sidebars’, 11 );

That did the trick, removed the primary widget area from backend and of course, frontend. Note: In my newly defined widget areas in child theme functions.php, I had included the default widget areas and simply added new widget areas. Not sure if this is necessary to use this method.

Having followed this thread to achieve the same outcome (and having come unstuck a couple of times) i thought i would try and help anyone else who follows on themselves. [All hail to those that worked it out – i didn’t!]

Firstly, here is the “final code” solution that works.. this is the basic contents of functions.php located in your child theme directory (based on ‘twentyten’); this as mentioned previously is loaded before the parent theme file copy of the same name.

[Code moderated as per the Forum Rules. Please use the pastebin]

The outcome of this code is apparent in the “widgets” section of your admin panel. Note that you will see two widget areas remaining ‘forth-footer-widget-area’ and ‘Alt primary widget area’. To get rid of the final legacy widget area ‘forth-footer….’ simply add the line

unregister_sidebar( ‘fourth-footer-widget-area’ );

Lastly and importantly, REMEMBER to activate your Child theme in the admin > themes page or none of this will be apparent