Widgets are a great way of showing information in specified areas. Themes handle this in different locations and different ways. Some have page template with up to thirty widget areas. Yes, thirty! Sorry, felt like a salesman when I typed it out but it is true. And then you get the occasional theme that wants you to type out content. Yes. Dealing with themes and content.
The reason I’m not a fan of this is because once the theme is switched you lose that content. I know some will ask how much content is too much content? Any content that isn’t theme specific is too much.
What drives me up a wall more is when some themes bundle a widget that core is more than capable of handling. A very common one is the infamous call to action button widget. Yes. I dislike that button widget. You can use core’s text widget! Let’s see an example shall we?
Yes, it does look like quite a bit of code but there is a reason for it. The function that does the magic for us is
the_widget. What’s super cool is that this means you can create an instance of a widget to create a great looking theme preview. Not only that it can serve as a bit of documentation for your theme.
Let’s take a look at another example, shall we?
The plugin I used is Feature a Page. All I did was a simple search in the plugin repository and picked one at random.
if ( class_exists( 'FPW_Widget' ) ): the_widget( 'FPW_Widget', array( 'title' => 'About our Clients', 'featured_page_id' => '1141', // ID of page 'layout' => 'banner', 'show_title' => false, 'show_image' => true, 'show_excerpt' => true ), array( 'before_widget' => '<aside id="%1$s" class="widget %2$s">', 'after_widget' => '</aside>', 'before_title' => '<h3 class="widget-title">', 'after_title' => '</h3>', ) ); endif;
Let’s run through the code a little. The first line checks to see if the class
FPW_Widget exists. If it does, then we can run our code. As you can see the second argument we’re passing is an associative array with some settings we want our widget to display.
In this particular case the widget has some settings that we can change. They are:
$defaults = array( 'title' => '', 'featured_page_id' => '', 'layout' => 'wrapped', 'show_title' => true, 'show_image' => true, 'show_excerpt' => true, 'show_read_more' => false );
They will vary from widget to widget so be mindful of that. The codex page has the default widgets and their respective settings that you can change.
Now, what’s neat is that you can use the third argument in order to style the output of the widget. To a degree. Let’s look at the first example:
array( 'before_widget' => '<aside id="%1$s" class="widget %2$s">', 'after_widget' => '</aside>', 'before_title' => '<h3 class="widget-title">', 'after_title' => '</h3>', ) );
Notice that I’m using a simple copy paste of what a
register_sidebar call would do. In particular the
before|after_title parts. Reason being, odds are, you’ve styled the widget areas with certain CSS classes and using those instead of the default ones
the_widget uses. Core markup is:
$before_widget = sprintf('<div class="widget %s">', $widget_obj->widget_options['classname'] ); $default_args = array( 'before_widget' => $before_widget, 'after_widget' => "</div>", 'before_title' => '<h2 class="widgettitle">', 'after_title' => '</h2>' );
So if you don’t define the third argument, what will be used on output is the above.
I used the plugin because it is a great example of how you can pull user generated content to create a widget. What’s really nice is there are several plugins that create widgets and deal with widgets. Don’t forget that you can even use a simple setting in order to create a featured content area as well. There are several themes that do this already so explore their code and learn from them.