In a WordPress Framework or Basic-Theme are one or several Widget Areas (Sidebars) defined. But how can you remove the widget areas if you don’t need them and just confuse other backend users.
The line unregister_sidebar('my-sidebar'); in functions.php of Child-Themes doesn’t do anything. Why? WordPress loads first the function.php of Child-Themes and then of the Framework. The Sidebar, which we like to remove is not there yet. It will be registered while loading the Basic-Themes/Frameworks.
But you can solve the problem with a Hook in the registry of your Framework/Basic-Theme.
//Code of the Framework to register 2 Sidebars
function xtreme_register_dynamic_sidebars() {
register_sidebar( array(
'name' => 'Sidebar One',
'id' => 'sidebar-one',
'description' => 'Sidebar One',
'before_widget' => '', 'after_title' => '
' )); register_sidebar( array( 'name' => 'Sidebar Two', 'id' => 'sidebar-two', 'description' => 'Sidebar Two', 'before_widget' => '', 'after_title' => '
' )); do_action('childtheme_sidebars'); } add_action( 'widgets_init', 'xtreme_register_dynamic_sidebars' );You see the Hook do_action('childtheme_sidebars');
let’s use this Hook:
//functions.php im Child-Theme
function xtreme_unregister_sidebar() {
unregister_sidebar('sidebar-two');
}
add_action( 'childtheme_sidebars', 'xtreme_unregister_sidebar' );
And the Sidebar is removed. Easy huh? 🙂
Comments
10 responses to “WordPress Child Themes – Remove Widget Areas”
Child themes are great because you don’t have to edit the parent theme, so when the parent theme updates, your changes are maintained.
Using this method, you have to edit the parent files. Therefore your changes won’t work if the parent theme updates as the hook will no longer exist. Therefore you might as well just delete the code that registers the sidebars.
Maybe I’m missing something but I don’t see the advantage to the hook.
Is there a way to execute unregister_sidebar(‘my-sidebar’); after the parent theme has loaded?
This is something I’ve wanted a solution for for a long time. I just don’t want to have to edit parent themes.
@Chris: It’s more a tip for Theme developers 😉
@Chris: This article is not motivated to force somebody to modify existing base themes that way. Doing so would indeed result into the behavior you decribed for updates.
But because of the loading order of child and base theme, you will face the issue (by design of WP core), that the child themes function.php will be loaded first and afterwards the base theme function.php too.
Caused by this loading order you are unable to deregister something that has not been loaded while your child themes function.php is processing.
The way of overwriting the registration functions doesn’t work, because if you have a framework as base and the functions.php of framework only contains:
$my_theme_instance = new my_theme_class();you would not able to overwrite instance methods.That’s why the base theme author should provide an action called by the base theme, where the child theme author is able to hook into and do the customizations required while parent also exists and have been loaded.
That is the way proposed here, nothing more.
This is a nice and elegant solution to a problem that we had a while back. I’ll be fixing my ugly hack with this one today. Thanks!
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.phpfile 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.Thanks for the reply – this is it, what i like on WordPress, the community. This is a god solution and i use this on different plugins, the priority of hooks is great solution.
Thanks Justin. I didn’t found the solution.
Thanks for the comments guys. I now get that you were aiming this post at framework devs.
I was trying to get to what Justin said but he put it much better than I did.
[…] Michael at WPEngineer posted about using widgets with child themes. […]
@Justin
Thanks for the elegant child theme solution. Adding the priority works like a charm. How did you find that it needed to be 11?