Next up, I tested the site to see if it was up and running ok. On the surface things looked fine but then I noticed that when I tried to type in a URL without the trailing forward-slash (‘/’), the page wouldn’t appear. Normally, depending on how you’ve configured your Permalinks, it will simply add the trailing slash automatically. Instead, all I got was a blank white screen starring back at me. Needless to say, a few expletives were uttered!

I tried thinking back to when everything seemed to be working fine. I also tried to remember what changes I’d made the day before. From memory, it was mainly some CSS updates to change links colours. There were no major code updates from what I could remember. I also couldn’t work out why the URL’s weren’t being processed correctly. After doing some Googling, I decided to raise a (low priority) support ticket with my hosting provider to see if any server changes had been made within the last few days. It was as if the .htaccess rules weren’t being obeyed. Good and bad news. The good news… no changes had been made to the server. The bad news… this didn’t get me any closer to resolving my issue.

The next step was to try changing to the default WordPress theme and do some testing. Things seemed to improved after changing themes. I could save my pages consistently. I could log in and out of the Dashboard without a problem. Even the URL’s worked fine, with or without the trailing slashes. Hmmm It would appear that the culprit was my own theme, which I’d been lovingly hand crafting. Next test was a restore from a backup of my theme. Luckily I’m quite strict at performing backups. I perform a backup of my workstation and my development server every couple of days, with the files kept on a separate hard drive. I rotate between 4 different sets for each machine. I restored the oldest backup which was just over a week old. Sure enough, everything worked fine. The next backup I tried was one from only two days prior. This also worked fine. Things were starting to look up! What this meant was that I’d narrowed it down to being caused by the changes that I’d made the previous day.

I now needed to compare the latest version of my code (the one with the problems) to the version from two days prior. I downloaded and installed WinMerge, which is an extremely handy Open Source differencing and merging tool (for Windows). Luckily there weren’t too many files changed. As mentioned earlier, most of the changes were in my main stylesheet. Starting from a copy of my restored (working) theme, I slowly started to integrate the changes that I’d made the previous day. Most seemed fairly mundane. A few CSS changes and some very minor code updates. I then got to my functions.php file. I incorporated the changes and lo and behold, things broke immediately. Yay!! I’d found the damn file that was causing all my problems! Now it was simply a matter of narrowing down the exact cause.

Looking through the code reminded me of the changes that I’d made. I’d added a few comments to the code to document a couple of the functions (Silly me, I know! Real developers don’t document code!!). The other thing I’d done was to add a blank line in between where I’d closed a PHP tag and opened up the next one. The code snippet is question looked like this…

You’ll notice that between the closing PHP tag and the following opening tag, there’s a blank line. Gasp!! This is what was causing all the drama! The solution was to simply remove the offending blank line. In fact, since I was simply closing the PHP tag and immediately reopening it, I could easily omit both of them. The resulting code looked like…

As for the problems that it caused, well there were quite are few.

URL’s weren’t processed properly

Since my Permalinks were setup using the format “/%year%/%monthnum%/%postname%/“, the posts wouldn’t display properly if they didn’t have the trailing slash. Normally, this is something that is handled by your .htaccess file. Instead, I was simply receiving a blank page unless I specifically had the slash on the end of the URL.

Strange content appearing

This was a strange one. As you can see in the image below, characters such as quotes and apostrophes were being rendered incorrectly. You’d think this was because their was some ‘strange’ characters stored in the database, but nope, it displayed perfectly fine once functions.php was fixed.

Blank lines appearing at top of document source, before the DOCTYPE

One of the repercussions of the blank line “incident” was that it caused blank lines to appear before the DOCTYPE within the html. This can cause problems with your RSS feed, in particular with Feedburner. Blank lines (outside of PHP tags) in any of your page templates can also cause the same problem, so I made sure I thoroughly checked those as well.

Problems in the WP Dashboard

As mentioned above, one of the first things that alerted me to the problem was my administration dashboard becoming unstable. I found that whenever I tried to save some content changes, the page wouldn’t refresh. Also, I couldn’t even log out of the WordPress Dashboard. I was able to browse through the various menu options within the Dashboard, but when it came to performing an action such as saving a page, that’s when the problems surfaced.

Due the the ‘strangeness’ of some of the problems, this was one bug that took a while to track down. Thankfully though, it’s all fixed now. It’s certainly something that I’ll be more mindful of in the future when I create themes.

Have you come across this problem or any other strange issues? I’d love to hear, so feel free to leave a comment

Since WordPress is so configurable, it’s possible to have multiple sidebar columns defined such as when you have multiple page templates set up. For example, you may have a specific page template defined for your sites static homepage. As well as defining the body content for that page, you can also define a separate sidebar in case you would like it to appear differently from the rest of the site.

It’s also possible to register multiple sidebars that contain all the widgets. This latter sidebar is what we’ll be discussing here. A typical WordPress theme may only have one sidebar configured although it’s not uncommon to have 2 or 3 or even more. Even though it’s called a “sidebar” it doesn’t need to specifically reside in the sidebar of your website. You can add a “sidebar” to anywhere in your site you want to display your widgets. A common place to include them is the site footer.

Defining your new sidebar

Adding additional sidebars to your site is relatively easy. Within your functions.php file you will most likely have something similar to the code below, for your existing sidebar.

<?php

if ( function_exists('register_sidebar') ) {

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

}?>

To add another sidebar you simply need to register another instance. If you are registering more than one, then you will also need to name them. Change your functions.php file to look like the following. Take care to add in the extra line that specifies the name of your sidebar. Once these are functions are defined, you will notice the extra sidebar appear in the WordPress Dashboard under the Appearance > Widgets option. It’s here that you can drag and drop all your widgets into your various sidebars.

<?php

if ( function_exists('register_sidebar') ) {

   register_sidebar(array(
   'name' => 'sidebar 1',
   'before_widget' => '<div id="%1$s" class="widget %2$s">',
   'after_widget' => '</div>',
   'before_title' => '<h2>',
   'after_title' => '</h2>'
    ));

   register_sidebar(array(
   'name' => 'footer sidebar 1',
   'before_widget' => '<div id="%1$s" class="widget %2$s">',
   'after_widget' => '</div>',
   'before_title' => '<h2>',
   'after_title' => '</h2>'
   ));

}?>

You can find more details on the various parameters of the above call on the WordPress Codex.

Adding your new sidebar to your template

Within your sidebar.php file, change the call to your existing sidebar to include its name that you defined within the functions.php file earlier.

<?php if ( !function_exists('dynamic_sidebar') || !dynamic_sidebar('sidebar 1') ) : ?>

   <h2>Articles by month</h2>
   <ul>
      <?php wp_get_archives('title_li=&type=monthly'); ?>
   </ul>
   <h2>Categories</h2>
   <ul>
      <?php wp_list_categories('show_count=0&title_li='); ?>
   </ul>

<?php endif; ?>

To add your new sidebar, you can either copy the above code or you can simply copy the following lines. Add these lines to wherever you’d like your new widgets to appear. In this example you can see from the name that I’m placing mine in the footer of my website. As before, don’t forget to specify the correct sidebar name. In the above code, the html that appears between the php statements is what will appear when there are no widgets added to your sidebar. This ‘default’ code can obviously be modified to suit your theme. In the following code, since there is no extra html, nothing will be displayed unless a widget has been added into the sidebar within your WordPress dashboard.

<?php if ( !function_exists('dynamic_sidebar') || !dynamic_sidebar('footer sidebar 1') ) : ?>
<?php endif; ?>

You will now find that your site has two widgetized sidebars. As mentioned earlier, there’s no reason why you couldn’t include further ones. It’s simply a matter of registering the new sidebar and then including the php to display it, in the relevant part of your site template.

I’ve also published this tutorial on Twitter Study Group. It’s a great place to learn, so check it out.

Thinking of adding more widgets to your WordPress site? Leave a comment and let me know if you found this useful. Thanks