Support » Themes and Templates » Adding Sidebars to a Child Theme

  • So I’m rocking and rolling with child themes, making some really cool changes to them by adding functions to the child themes functions.php file. I’m actually building a library of code that I can apply to any theme to handle the navigation the way I want, display excerpts instead of full blog posts, etc.

    However, the one thing that is killing me that I can’t seem to figure out is how to add sidebars in the child theme while leaving the parent’s sidebars alone. Since the child’s functions.php loads first, it doesn’t know anything about the parent’s functions.php yet so my new sidebars show up first and then the parent’s sidebars show up last. However, in almost all cases that I can think of, I want the parent’s couple of “standard” sidebars (sidebar and footers usually) to remain in tact, still populated with my widgets from other themes that use the standard “sidebar 1” and then have my cool new stuff show up after that.

    To me this is a big problem with WordPress themes in general that every time we switch themes we totally screw up all of our sidebars, but I’d at LEAST like the one main sidebar to remain in tact. Does anyone have a suggestion on how to do that?

    I’ve tried declaring the parent themes sidebars in my child theme, using the same name and even giving it a matching id. I thought those would be required to be unique, but I end up with two copies of each of the parent’s themes sidebars.

    I can’t use an unset function to remove the parent’s sidebars, because they don’t exist yet. I don’t see a filter that can be applied to stop the parent from registering its sidebars using unregister_sidebar().

    Surely there is some way to do this, right?

Viewing 15 replies - 1 through 15 (of 15 total)
  • Has anyone figured this out yet? I am having the same problem.

    Only thing I can think to do is remove the sidebars code entirely from the parents functions.php found at:

    function twentyten_widgets_init() {
    	// Area 1, located at the top of the sidebar.
    	register_sidebar( array(

    Although this defeats the purpose of child themes and NOT needing to modify your parent theme. It seems like a simple mod post upgrade though.

    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.



    Forum Moderator

    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.

    I used exactly this code and it almost worked.. I am able to register new widget areas. However twentyten’s native widget areas are still there. Odd.

    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 and give us the link to look it up.

    daitya, here are more details.. my functions file is short, so I put the entire code on pastebin:

    My testing site is set up here

    twentyten’s primary and secondary widget areas both have widgets in them. Ideally I’d like them not to show up in the admin at all, to reduce client confusion.

    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!

    hey daitya,
    On my dev site, linked above, WordPress is running a child theme of twentyten. And yes, the search, archives, Recent Posts, Categories, and also the Admin, are all widgets sitting in twentyten’s built in widget areas.

    Of course I can easily take the widgets out of twenty ten’s widget areas and they will no doubt disappear. But since I am building this theme for a client, and I want it to be as simple and foolproof as possible, I’d rather not have empty widget areas in the admin interface that could create confusion for the client.

    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?

    Photocurio, take a look at Maybe after remove_action string, when you define your new function twentyten_child_kw_widgets_init() { keep the parent theme’s default sidebar declarations there, and then add to each sidebar registration, the hook do_action('childtheme_sidebars'); and finally after the function for registering all sidebars has been stated, follow with this:

    `//functions.php in child theme
    function $give-it-a-name_unregister_sidebar() {
    add_action( ‘childtheme_sidebars’, ‘$give-it-a-name_unregister_sidebar’ );`

    Don’t forget at the end to also finish up with add_action( 'widgets_init', 'twentyten_child_widgets_init' );

    I haven’t tested it out yet, but it makes sense that the child theme’s functions will not override the parent theme’s functions except by use of these hooks.

    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.

    Thank you, gentlemen, that worked very well. The following code, placed my child theme’s functions file, removed all of Twentyten’s built-in widget areas:

    function my_unregister_sidebars() {
    	unregister_sidebar( 'primary-widget-area' );
    	unregister_sidebar( 'secondary-widget-area' );
    	unregister_sidebar( 'first-footer-widget-area' );
    	unregister_sidebar( 'second-footer-widget-area' );
    	unregister_sidebar( 'third-footer-widget-area' );
    	unregister_sidebar( 'fourth-footer-widget-area' );
    //unregister sidebars by tying onto same hook again, with priority '11'
    add_action( 'widgets_init', 'my_unregister_sidebars', 11 );

    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

    All that is required to remove all the parent sidebars is inside the function child_theme_setup() not unregister_sidebar() but to remove_action():

    /* Remove the Twenty Ten registered sidebars */
    remove_action( 'widgets_init', 'twentyten_widgets_init' );

    See my post here for doing this in a child theme with a neat little function to add back some more new ones.

    Look at the summary section at the end for the full code, or download the child theme for the first series and copy or edit the code.



Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘Adding Sidebars to a Child Theme’ is closed to new replies.