As I might have mentioned once or twice, January is theme month at Fun with WordPress and I already have some interesting posts lined up thanks to everyone that has gotten in touch. For today’s post I have been asked to give a quick guide to adding dynamic sidebars(the widgety kind) to a theme, in particular horizontal sidebars.

There are three parts to adding extra sidebars to your theme:

1. Register the sidebars in functions.php
2. Call the sidebars form the PHP
3. Add some extra styling to layout the sidebar

Register the sidebars

Registering the sidebar is about more than just telling WordPress it exists. You also need to specify the structure of the sidebars. In this case I want to use a structure something like this:

The wrapper div will be contained within the theme itself as it will have a specific ID based on its location. The remainder is specified in the array shown below:

//create the array
$sidebar_array = array(
	'before_widget' => '<div id="%1$s" class="widget %2$s">',
	'after_widget' => '</div>',
	'before_title' => '<h2 class="widgettitle">',
	'after_title' => '</h2>',
    );

In this you can see that the HTML specified in before_widget and after_widget wrap the widget in a DIV tag. %1s and %2s will be automatically replaced with the ID and title of the widget so they can be individual styled if necessary. before_title and after_title wrap the title in H2 tags. The content will be specified by the widget.

Except for this styling there is only one more variable we need to provide that is the name of each sidebar. As this is separate for each of the sidebars we will need to modify the array twice. Each time just before the sidebar is registered with the Register sidebar function. For example:

//set the name
$sidebar_array['name'] = 'Sidebar';
register_sidebar($sidebar_array);
$sidebar_array['name'] = 'footer';
register_sidebar($sidebar_array);

With these two sets of code included in functions.php you should now have two named sidebars available for widgets. But don’t add them yet.

Call the sidebars

The next step is to add the function calls in the HTML files. The function call itself is very simple: dynamic_sidebar(sidebar_name);, but for most themes you will want to do a little more to cope with situations where there are no widgets added, and to highlight where the widgetised areas are.

If there are no widgets then dynamic_sidebar will return false. This means you can easily add it as the equation in an IF statement like this:

<div id="footer">
<?php if ( !dynamic_sidebar('footer') ) { ?>
	<p>Sample Content</p>
<?php } ?>
<p class="clear">&nbsp;</p>
</div>

In this example I have included some example content that will be shown if there are no widgets. In the default theme, and most others, this will contain a pre-widget sidebar. The default theme also checks to see whether widgets are installed at all. I am assuming they are, but check sidebar.php in the default theme to see how to check.

I have also added the wrapper DIV I mentioned above, this one for the footer, and a paragraph with a class of clear, so I can float the widgets and use this to clear them.

Styles the sidebars

If you go ahead and add some widgets to the footer sidebar now you will find that they all appear above one another, like a normal sidebar. This is not what we want for a footer, so a little styling is needed. But only a little.

#footer div.widget
{
	float:left;
	margin-right:30px;
	margin-left:30px;
}
 
#footer p.clear
{
	line-height:0.001;
	font-size:0.001em;
	clear:both;
}

The CSS is really simple. If you look back at the initial array and widget layout diagram you see that each widget is surrounded by a div with the class of widget. This CSS floats each widget to the left if they are within the footer wrapper, and the paragraph with a class of clear makes sure the footer grows with the height of the widgets.

The example above is the default theme. To make it work in the default theme I also needed to alter another line of CSS. Line 83:

//from
 
background: #eee url('images/kubrickfooter.jpg') no-repeat top;
 
//to
 
background: url('images/kubrickfooter.jpg') no-repeat bottom;

Well, the inexorable drive toward the future continues with this post on the WordPress development blog about prioritising features for 2.8, and the associated survey. So I though I would take this opportunity to tell you what I think 2.8 should bring.

Widget Management

One of the options in the survey is widget management. I rated this as most important out of the available options. But it isn’t just the UI that needs attention, although it does, as my post on widget management concepts shows. If you have ever tried to do anything slightly advanced with widgets (see my widget structures plugin) then the code requirde can drive you mad.

Right now it is far too difficult to code widgets. Single widgets are easy enough, although not easy for those without coding knowledge (that is why I created the Fun with theme widgets plugin), but multiple use widgets are horrible and require a huge amount of code that you need to copy almost verbatim. It isn’t so much a feature of WordPress as a hack the developers figured out and then provided as an example.

I think that all this stuff needs to be added to the core so that a multiple use widget requires setting a single variable in the add widget function. Alternatively, or perhaps better yet, provide a widget class that you extend to make the new widget.

Finally, I think they need to consider whether widgets can be produced using something other than code. Perhaps XML that can be imported. I write about this back at the start of November - Does WordPress need a better type of widget?

Modularisation

This is the second major thing that I think WordPress needs to start doing, and I think should start doing in 2.8.

There are significant parts of WordPress that can be segregated out and put into core plugins. While these things do no harm if they are in the core and are not used it also means that you are limited to hooking into them, or rewriting them completely if you want to change them. I would like to see a system where you could copy the core plugin into user plugins, modify it, and then it would be a simple matter to make serious changes without modifying the core itself. Widgets would be a prime candidate for pluginisation as would links.

This may mean that the plugin system needs to be looked at to get the maximum performance out of it. But that is fine by me.

This is a very big project and that dovetails nicely with my feeling that they should really let 2.7 rest for a bit before replacing it. It is by far the most advanced (in terms of what users can do) system out there and I don’t think there is an immediate need to tinker with it beyond making major improvements.

Sum

WordPress has everything it needs right now. Having revamped the UI I think there is a need to step back and do the same for the underlying architecture and code. Considering where WordPress will go in the future. Should content management be the key, or better interaction with other blogs. And how about looking at which of the BuddyPress features should be plugins for WordPress as a whole.

The real things that are needed next are a focus on developers. This means modularisation, flexibility, and simplicity.

What do you think?

Following on from my post about Widget Management Concepts, I have produced a new plugin with the aim of making it super easy to include widgets within themes without needing to be concerned with writing plugins, or code in functions.php.

Installation

To install the plugin just download it and activate it. It has no options.

Creating Theme Widgets

Creating a theme widget really is very easy. Here is a step by step process.

Step 1

Create a new PHP file in the theme and call it {something}.widget.php.

Step 2

Add a PHP comment at the top of the file to indicate the name and description of the widget. Like this:

<?php
/*
Widget Name: 3 Random Posts
Widget Description: Outputs 3 random posts in a list
*/
?>

Step 3

Add the code you want for your widget. In this example I am adding code to output three posts at random:

<?php $postslist = get_posts('numberposts=3&order=ASC&orderby=rand'); ?>
 
<ul>
<?php foreach ($postslist as $post) : ?>
	<?php setup_postdata($post); ?>
	<li>
	<strong><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></strong><br/>
	<?php the_excerpt(); ?>
	</li>
 <?php endforeach; ?>
</ul>

Note that this code is identical to the code you would insert into a theme file to do this manually. There is nothing special about this code that needs to be changed to make it a widget.

Step 4

Assign the widget to sidebar.

On the left of the image is the output (there is only one post because it is a fresh installation) on the right the widget added to the sidebar.

Download

You can download the plugin from WordPress extend.

The Potential

I think that making it this easy to create, and more importantly understand, the widgets included with a theme opens up a lot of possibilities. For example, with this it would be easy to use a sidebar and widgets to offer different layouts for a featured post on the home page.

If you have any suggestions for improvements to the plugin itself, or ideas about how it can be used, let me know.

Jeff Chandler wrote a post a few days ago explaining his vision for the WordPress widget system. His post got me thinking so I want to take his vision one step further and look at some of the practical methods of achieving them.

For a wireframe widget system to truly work the wireframe needs to be set up by the theme author before hand. I envisage an area of WordPress.org where a theme author can upload a large screenshot of their theme, and using the tools provided, select the regions where the sidebars are placed. For example:

The theme in this example is Clockwork Simple

For each region they select they provide a nice name, and the name of the sidebar within the theme so that WordPress can match them up later on. Once finished they are given an XML file containing the screenshot filename, the coordinates of each region, and the names of each sidebar. The XML file and large screen shot are saved within the theme folder.

When the user installs the theme and navigates to the widgets page they are presented with the list of widgets, as now, but instead of clicking add, they drag the widget to the location they want. For example:

I think this process could really create a solid usable widget system, but I also think that more change is required to the process of creating a widget in the first place.

In the scenario described about, and which I wrote about in a previous post — changing layouts using widgets, many more places use widgets to provide options. For example, the main area could contain a single post widget, that is only used for single posts, a multiple post widget, for archives, and a page widget. These do away with the need for multiple template pages as each widget deals with one specific situation. The problem with this is that widgets are too hard to create.

Widgets are simple enough to create for a plugin author, but theme authors should be able to define a PHP file as a widget by adding some code at the top, in the same way as the CSS file contains the theme details.

If the want to create a single post layout with an image on the left they create it as a file and add the widget code. They can then do the same for a single post layout with the image on the right, a larger image with text below it, and so on, without needing to worry about the plugin style code that would be needed in functions.php right now.

In the next few days I will release a plugin that allows widgets to be created from theme files in this way so you can see for yourself how easy things could be. All we need now is the new font end. Roll on 2.8.