You hear people complain about “hard to use content management system”, “bad graphics”, “excessive downtime from host”, etc. These are all factors, and in some rare cases can kill a site, but almost always the real killer of a web site is bad content, stale content, or no content.

Fancy graphics are nice, if they are wrapped around good content. Reliable hosting is a real plus, but only if people are coming to your site in the first place. An easy to use content management system makes life easier - if you’re updating content. Otherwise it’s just an excuse for not posting new material.

Look at some of the most high traffic sites on the internet: Google, Facebook Youtube, etc. Which one has the best graphic design?

Google doesn’t have ANY graphic design. Text over a white background. Any good graphic artist will tell you that’s the kiss of death on a web site. You need flash animations, video teaser and fancy AJAX to get visitors to your site. Obviously Google doesn’t know anything about running a successful web site. Yeah, right.

What about Facebook? Still a pretty lame design. IBM blue, gray shading, ruling lines, busy layout. Any Design 101 student will tell you that site is a disaster. Nobody young and hip would ever use that site.

Youtube does a little better. But we’re still taking about a lot of plain text on white backgrounds and default blue links. You’d think a site that specializes in video would be more hip.

So why are these sites successful? Content. People use Google, Facebook, and Youtube for the content, not to be impressed with the web experience.

I’m not against good design. We have a full time graphic designer on staff. A good design does enhance the web experience, but it can’t make up for bad content, stale content or no content. If your organization will spend half as much effort on the content plan as you do on the graphic design, I can almost guarantee significantly improved results from your site.

The Problem

You’re writing a new post, and you decide to spice this one up by adding a neat image. It’s not a full-width image, so you decide to float it over to the left and let the text flow over it. “That would look great,” you think.

You start writing the post, you add the image, and you set it to align to the left. You look at your new post, and it does indeed look great.

You then publish the post all exicted to see you new fancy post. It doesn’t look great. It actually looks really bad. What happened?

What happened is that your theme doesn’t have the CSS settings needed to allow your pages to render properly based on how WordPress aligned your images.

The Solution

There are three classes that WordPress uses to align those images: centered, alignleft, and alignright. If your theme doesn’t have definitions for these classes or doesn’t properly define them, your aligned images will look a lot like the image above.

The following CSS can be added to your theme’s style.css file to add the CSS settings that the default theme (Kubrick) uses for image alignment:

/* Begin Images */

/* Using 'class="alignright"' on an image will
   (who would've thought?!) align the image to
   the right. And using 'class="centered', will
   of course center the image. This is much
   better than using align="center", being much
   more futureproof (and valid) */

img.centered {
        display: block;
        margin-left: auto;
        margin-right: auto;
        }

img.alignright {
        padding: 4px;
        margin: 0 0 2px 7px;
        display: inline;
        }

img.alignleft {
        padding: 4px;
        margin: 0 7px 2px 0;
        display: inline;
        }

.alignright {
        float: right;
        }

.alignleft {
        float: left
        }
/* End Images */

Of course you can modify this to meet your own specific needs. At a minimum, you need the following in your style.css file:

img.centered {
        display: block;
        margin-left: auto;
        margin-right: auto;
        }

.alignright {
        float: right;
        }

.alignleft {
        float: left
        }

After adding the default CSS styling from the Kubrick theme to my theme’s style.css file, my post now looks much better.

Warning: Cannot modify header information - headers already sent by (output started at /home/site/public_html/wp-content/themes/my-theme/functions.php:49) in /home/site/public_html/wp-includes/pluggable.php on line 770

Maybe you just made a change to your code. Maybe you just changed something in your theme. Maybe you just touched the wp-config.php file. Whatever you did, it killed your site and you can’t find any errors in your code. What is going on?

The problem is a blank line in the file mentioned in the error at the line number specified. Keep in mind that the first file and location listed is where the error is, not the second file and location. So, going by my previous example, the problem is a blank line at line 49 of the current theme’s function.php file.

If you were to have the following code in your functions.php file, you will get this error:

<?php example_function(); ?>

<?php example_function(); ?>

To fix the problem, you would remove the blank line:

<?php example_function(); ?>
<?php example_function(); ?>

You could also group the PHP code together such as the following:

<?php
    example_function();

    example_function();
?>

Happy coding.

Modify the theme

If you are a theme author or know how to modify your theme, you can set up your theme to tell WordPress what the maximum width image your theme will accept for display in posts. The key is a new global variable named content_width. If the content_width global is not set, WordPress defaults to a full-size width of 500 pixels. You can see the logic that they are using in the following code snippet from the wp-includes/media.php file (note: I refomatted it a bit to fit the post):

// we're inserting a full size image into the editor. if
// it's a really big image we'll scale it down to fit
// reasonably within the editor itself, and within the
// theme's content width if it's known.  the user can
// resize it in the editor if they wish.
if ( !empty($GLOBALS['content_width']) ) {
    $max_width = $GLOBALS['content_width'];
}
else
    $max_width = 500;

So, as you can see, the way to have your theme inform WordPress of the maximum width is by supplying a value for $GLOBALS['content_width']. This can be easily done by adding a line of code to your theme’s functions.php file. For example, adding the following line of code to a theme’s functions.php file will tell WordPress that full-size images should be limited to a width of 460 pixels (the width of Main Street Open’s posts).

$GLOBALS['content_width'] = 460;

Cori Schlegel has correctly pointed out that this feature has been present since 2.5. Thanks for the correction Cori.

Modifying the image after adding it to the post

If you aren’t the author of your theme and aren’t comfortable modifying code, you can manually change the size of the image after adding it to the post. After adding the image, you can change the size by doing the following:

• Click on the image and select the “Edit Image” button
  

• Click on the “Advanced Settings” tab. You can either click on the “Original Size” button to set the image to be full-size or you can manually set the width and height for the image
  
• Click the “Update” button at the bottom of the Edit Image view.

Here is the normal register sidebar call as most are used to using it.register_sidebar(array(
'before_widget' => '<li id="%1$s" class="widget %2$s">',
'after_widget' => '</li>',
'before_title' => '<b class="widget_title">',
'after_title' => '</b>',
'name' => 'Middle Footer'

Which produces something like this. My problem with this is that if I want the widget title to run full width of the widget area, I will have to do something really clever to pad the widget content. And really clever always ends up with cross browser compatibility problems. So here is the simple way to do it.

register_sidebar(array(
'before_widget' => '<li id="%1$s" class="widget %2$s">',
'after_widget' => '</div></li>',
'before_title' => '<b class="widget_title">',
'after_title' => '</b><div id="widget_content"',
'name' => 'Middle Footer'

By adding the div at the end of after_title and closing the div at the beginning of the after_widget, we are encapsulating the widget content.

Now we have an easy way to specifically stylize the widget content. Giving us the most flexibility with the layout of our widgets. I also prefer to use divs instead of lists for my widget areas, just because most of the sites I work on do not benefit from using lists because the widgets are used for movies and images and if we use media specific style sheets then we won’t need the lists easy formating. So I end up with a function that looks like this.

register_sidebar(array(
'before_widget' => '<div id="%1$s" class="widget %2$s">',
'after_widget' => '</div></div>',
'before_title' => '<b class="widget_title">',
'after_title' => '</b><div id="widget_content"',
'name' => 'Middle Footer'

We also find some plugins from time to time that we don’t have an immediate need for but which are interesting for one reason or another. We’ve added a list for these as well.

See our recommended and interesting WordPress plugins lists.

If you have a theme installed in your wp-content/themes/ directory, then to make a child theme you simply create a new folder in the themes directory with a new name. Copy the style.css and images folder to the new child theme. The important thing that we are keeping separate are the PHP files. There may be other folders that contain images or media files that you may need for your theme. Copy all that over because anything in the theme that links to the bloginfo(’template_url’) will need to be located within the child theme, because that is the template url. In most cases the images and style.css are the only changes a user needs to make to customize the theme. Although if other changes need to be made, we simply copy over the relevant files and make the changes we need. For example, most themes incorporate a header graphic that will need to be changed by the end user to include their logo in the design. This would normally all be in the header.php file, so we would just make a copy of it into the child theme and make the appropriate changes.

Then we need to specify in the header of the style.css file that we have a parent to this template. You can do so by typing “Template: parent-template”, where parent-template is the directory location for the parent template. ie wp-content/themes/parent-template/

That alone will give you a new theme to choose from in the WordPress back end and through the built in WordPress Theme Editor you can now start making the changes to the theme. And because we are making changes through the child theme it is clear what files we are touching and what changes have been made to the theme. Keeping track of the changes like this will avoid misunderstandings with clients about what changes have been made and how the original theme they purchased works.

Child themes will also be more useful as theme developers become more aware of there purposes. If designers will avoid hard coding text into the themes and utilize more widget ready areas on their sits, then the benefits of child themes become more meaningful. On more complicated themes with more built in custom PHP code, the ability to separate the graphic elements from the more complex code will also be a benefit to the end user. If they want to tinker with style they won’t be in a position to break a line of code that will cause the entire site to go down.