Doing more with widgets: Changing Layouts

A few weeks ago I showed how the home page contents could be moved into a widget to allow additional content to be added above and below it. That’s an interesting technique but not as interesting as this one. Using nested widgets to control the overall layout.

By nesting widgets it is a fairly simple process to allow the sidebar to switch from left to right, and to control the content in both the sidebar and the main content. I have created a sample theme that contains only the code necessary to do this, you can download it at the bottom of the page.

First you need to create the necessary widgets and register the sidebars, this is done in the functions.php file in your theme:

function sidebar_container_widget(){
 
?>
<div id="sidebar">
<?php if ( function_exists('dynamic_sidebar') ) { dynamic_sidebar(2); } ?>
</div>
<?php
}
 
function content_container_widget(){
 
?>
<div id="content">
<?php if ( function_exists('dynamic_sidebar') ) { dynamic_sidebar(3); } ?>
</div>
<?php
}
 
function content_widget(){
 
?>
	<!-- Here you put your WordPress Loop-->
<?php
 
}
 
 
 
 
if ( function_exists('register_sidebar') ) {
	register_sidebar(array(
		'name' => 'layout',
        'before_widget' => '',
        'after_widget' => '',
        'before_title' => '',
        'after_title' => '',
    ));
		register_sidebar(array(
		'name' => 'sidebar',
        'before_widget' => '<div>',
        'after_widget' => '</div>',
        'before_title' => '',
        'after_title' => '',
    ));
	    register_sidebar(array(
		'name' => 'main content',
        'before_widget' => '<div>',
        'after_widget' => '</div>',
        'before_title' => '',
        'after_title' => '',
    ));
 
 
 
	register_sidebar_widget('Sidebar Widget',sidebar_container_widget);
	register_sidebar_widget('Content Widget',content_container_widget);
	register_sidebar_widget('Home Page Content',content_widget);
 
	}

In the code above I have registered three sidebars, the home page layout, the main content, and the sidebar content. I have registered three widgets, one that includes the main content, one that includes the sidebar and one that contains the WordPress loop that would normally be on the home page. In the example I have included one more sidebar and widget, a full width banner than can be inserted above or below both the content and sidebar.

Next you need to set up your styles in an appropriate way to be sure that the sidebar and content can be interchangeable. I have floated them both left with an all round margin.

#content {
float:left;
width:500px;
border:1px solid #cccccc;
margin:10px;
padding:5px;
}
 
#sidebar {
float:left;
width:200px;
border:1px solid #cccccc;
margin:10px;
padding:5px;
}

Next you need to setup your index page. This is a simple prospect as there will not be any remaining content.

<div id="header">
	<h1><a href="<?php echo get_option('home'); ?>/"><?php bloginfo('name'); ?></a></h1>
	<div class="description"><?php bloginfo('description'); ?></div>
</div>
<?php if ( function_exists('dynamic_sidebar') ) { dynamic_sidebar(1); } ?>
<div id="footer">Footer Message</div>

You should now have everything you need to make your layout work. In the example theme I have set up the widgets like this:

Widget Setup Diagram

Which results in the following layout:

Widget Diagram

To move the sidebar over to the left is a simple matter of swapping the sidebar and content widgets around.

You can download the sample theme here. It contains only three files, those necessary to illustrate the technique.

Write one plugin without repetition, deviation or hesitation

How can plugin development be made even easier?

If you’ve ever developed a WordPress plugin (if not why not?) you have probably found that a lot of your time is taken up with things that are effectively a default. This could be something as simple as adding a wrapper div around an admin page or more complicated like accessing a database table.

WordPress abstracts some of this away already; You can save and retrieve options for your plugin without touching the database at all but there are many other cases where things could probably be so much simpler.

I’d like to know what those things are.

Feedback on my plugin generator has been great and I plan to continue developing it, but I want to make things easier still so I want you to tell me what you find to be a chore. What can’t you do simply that you should be able to, what do you have to code which should be automatic, etc.

To get the ball rolling here is one thing that I find a pain: user input. I want to be able to specify that a form field is required, and do nothing. I don’t want to check if the form has been submitted, I don’t want to check if it has content or not, I just want to know that every required field is completed.

How about you?

p.s. If you’re wondering where the post title comes from have a read of this.

Resource for Bloggers, Blog Carnival

A new Blog Carnival is being launched on the 13th aimed at providing resources for new bloggers.

The Resource for Bloggers blog carnival is currently accepting submissions for the first edition so if your blog features any plugins, tips, or other useful resources for newcomers to the blogging scene then get submitting.

The carnival is being hosted by 134u ( 13 is apparently Diana’s lucky number, I used to live at number 13 so I can relate), Hopefully it will feature some interesting Wordpress related goodies.

Using Objects for Wordpress plugins

I think you should give objects a try, for more reasons than just avoiding naming collisions. Here’s why.

I think I’m a pretty typical Wordpress user. I learned a lot of my PHP by playing with themes to get them to do things they didn’t by default. So when I decided to write a plugin I pretty much hacked it together using the guidance that was available.

The only real introduction I had to objects when I started writing plugins was a brief piece about avoiding naming collisisons. None of the guidance seemed to offer more than that so I never really gave it much thought.

Typically my plugins were structured something like this:

//plugin headers
 
class myClass {
    function myFunction() {
        //do stuff
    }
 
}
 
add_action('wp-head',array('myClass','myFunction'));

There isn’t anything wrong with this, but classes can do so much more once they are instantiated as an object. Typically I now structure my plugins more like this:

class myClass(){
 
    function myClass(){
        //php 4 compliant constructor
 
        add_action('wp-head',array(&$this,'myFunction'));
 
    }
 
    function myFunction(){
 
        //do stuff
 
    }
 
 
}
 
if (class_exists('myClass')) {
    $myClass = new myClass();
}

So what are the advantages? The real benefits are simply those gained by using object oriented code versus procedural code. The code becomes easier to maintain and easier to reuse the individual functions in other classes.

It can also be useful for abstracting the administrative content away from the actual code you are modifying; for example, I have found it useful to load all of the plugin options using the constructor and keep them in an internal variable for later use by whichever functions happen to need it using something like this:

class myClass{
 
    function myClass(){
 
        $this->options = get_option('myPluginOptions');
        add_filter('the_content',array(&$this,'myFunction'));
 
    }
 
 
    function myFunction($content){
 
    if ($this->options['wrap-content'] == true) {
        return '<div class="wrapped">'.$content.'</div>';
    } else {
        return $content;
    }
 
    }
}

So, if you are not already instantiating your classes, then I suggest you consider it. You might even enjoy it.