Making a WordPress Theme: #5

There’s one more thing I want to go over in this series of blogs and that’s the process I took to take the WordPress theme I made on my local server and put it on my live server, right over at

Managing WordPress files

The first thing I want to do is quickly define the root URL of the WordPress installation. Since this will be different to localhost, this domain is the changing aspect of the permalinks around the website. All URLS, all plugins, all images, all of the files will point to my domain rather than localhost.

define('WP_SITEURL', '');

So to make WordPress recognise this change the above code will be placed in the config.php file of WordPress. Unfortunately this on its own would not automatically rewrite the hyperlinks and make them work out of the box. There’s another step to take before this will work, but I’ll discuss that later in the blog.

First I’ll upload the WordPress files to my server via FTP.  It’ll go in the root folder of my installation. I’ve made sure to clear any other individual files from the root folder to avoid any clashes or conflicted files getting in the way of the transfer.

Next I need to create a backup of the database by storing it in a text file.  I do this by going into the phpmyadmin of my local host, selecting the database (I named mine jgdm_db) and exporting it into an SQL file.

Now, the database exists as an SQL file with queries that when imported to a database environment create  and manage the database in its current state.

I then go into phpymyadmin for my cPanel, and check that the database I just created is listed.   Once there, I need to import the database from the file I just created.


If I was to log onto the website at this point, I’d see nothing but a blank screen, if I go to the admin area, I’d get a database connection error.

This is because currently no database for my WordPress installation exists. I just have to set one up on my web hosting account.  I go into “mySql Databases” in my hosting accounts cPanel and Create the database. Since my web host automatically adds a prefix to the name I create, the database will be called jonniegr_jgdm_db.

This can be a tricky part because when I’ve done imports in the past, they have seldom gone smoothly. On this occasion however, I was able to successfully import the data and create a copy of the database on the host server.  One thing I had to do was change the database name in the SQL file to match.


Next, I create a new username and password for SQL and add this user to the database I just created.

I am then able to login to the WordPress Admin area with the same details I used on localhost as these details are stored in the same database,   And…  great. I am now inside the WordPress Admin area.


I am able to click and edit posts and pages, access my menu, see that my theme is still installed and in place.  Great!

But, when I click on the link to visit the site.  Nothing appears on the front end.  This means it’s time to update the SITE URL on the admin area and start updating permalinks on back end so links start working properly.

First I’ll add the site_url and wp_home link to the config.php file, the snippet that I shared at the beginning of this post. This will tell WordPress that the website exists in a new location and once uploaded, should be reflected in the general settings of the admin area.

Better search and replace Plugin

Now in order to change the links across the database I’d have to go through each individual entry and change the domain from localhost to  I don’t think so. I’ll let a plugin do that for me instead.

Once installed and activated, Better Search and Replace will look for a given string and replace it with another, just like using Find and Replace in your text editor.  It finds matches in rows of data and performs the change like below.

In the example only 2 tables needed to be changed.

Found Rows

Oh No! The Dreaded WSOD

So that should have been that. But no. Something terrible happened. Not only was I still getting a blank screen on the live server but also on the localhost.  The live server being blank I could possibly understand but I just don’t know what I could have done with the server that could have caused this issue. And because I didn’t know, I couldn’t fix it.  But I still had the files from the installation and access to the admin areas for both but no display on the front end.

I had experienced the dreaded White Screen of Death (WSOD) which is like the blue screen you may have experienced on your computer, only much worse because you get no kind of error message reported at all.  Why this happened, I’m not exactly sure but my guess is a corrupt file in the database in my localhost caused it. A corrupt database which of course I then went on to migrate to my live server.  So after plenty of head scratching, lots of thinking and lots of cursing of bad luck I simply went back to the drawing board.

Starting again was much easier than I anticipated.  I knew there was no problem with the theme I set up, nor with my plugins, which is a common cause of WordPress white screens, so it was simply a case of downloading a fresh copy of WordPress, adding my theme and plugins into it, which had my functions ready made.  I was able to get into the back end of my existing install and copy the content from one admin area to the other.

So… having gone through the entire migration process again and carefully going through it step by step, my new local installation is showing up correctly as well as the life install.  Making sure the navigation links worked as a simple case of making sure the permalink setting was correct in the admin area.

Sources:  WordPress Support  – How to Fix The WordPress White Screen of Death


And that’s it. That is the process of creating a basic WordPress theme and migrating it to a live server from localhost. As I said before there’s a lot more to WordPress development than I have touched on in this series of blogs.

Making a WordPress Theme: #4

The theme I’ve been building uses 3 main template files.

These are:

home.php – which we already have set up. it lists blogs that are generated as separate posts in the admin area. Additionally, the template can also be selected as blog template.
single.php – single blog template. This is the template that controls what a single blog post page looks like.
archive.php – which is a template file that WordPress sets aside as a template for a categorised list of blogs. Every time you set a blog category for your blog posts, it gets added as a clickable list of post categories.

Making a blog, a blog!

That’s all great, but when I last left the blog, the blog didn’t have the look of a WordPress blog about it. All it did was generate one blog post after the other… the whole blog for each blog post, and this isn’t necessarily what we’re after. It would be good to have a brief and more structured list of blogs for the blog listing page and some way for users to make comments on the page. What would also be good is to have a clickable title for each log listed on home.php that would take us to that blog post.

Thankfully, WordPress has a whole host of built-in functions that can accomplish this.

These functions are

  • the_excerpt()
  • get_avatar()
  • get_the_author_meta()
  • the_author_posts_link()
  • the_category()
  • the_date()
  • the_time()
  • the_post_thumbnail()
  • the_permalink();

So we could do something like…

       <a href="<?php the_permalink ?>the_title();</a> 
<p><?php the_excerpt()  ?></p>

…just to make sure to make sure each title has a clickable link that would then take you to the appropriate blog. WordPress is then smart enough to know which page is supposed to link to which permalink.

the_excerpt(), cuts off display of text in a blog post at a certain point. This makes sure the blog listing page is consistent and has a nicer feel. One blog is likely to be much bigger than another and having this function in place is a great way to get around that.


You can further customise when this cut off will take place on the blog index. By putting the following function in the functions.php file.

function wpt_excerpt_length($length) {
    return 16;
add_filter('excerpt_length', 'wpt_excerpt_length',999);

Simply edit the return value, which is stored as a single argument of the function.  The 999 number simply ensures the function doesn’t conflict with another in the file by changing its action priority so it runs at a certain point.

Next attention turns to identifying the post author. That is a glaring omission for any blog post. We get the blog author by using the following php function.

<?php echo get_avatar( get_the_author_meta('ID'), 24); ?>

This will display the author of the post to the screen. The retrieve the associated Gravatar you use the get_the_author_meta(‘ID’), 24) with the size of the retrieved image passed in as an argument.

Then to finish off the blog makeover, the list of categories associated with the blog post we simply use the function the_category().   In order to list the categories in a visually pleasing manner, we pass in a separator as a parameter.

And then we just have to find a way to structure it using markup and then of course, CSS. Using lists is a great way to do this. And, in just a few lines of code, we’ve successfully added WordPress blog elements to go along with the WordPress Loop.

<ul class="post-meta">
     <li>Posted by: <a href="">
          <?php echo get_avatar( get_the_author_meta('ID'), 24); ?></a> 
          <?php the_author_posts_link(); ?> on <?php the_time('F j, Y'); ?>
           With the following post categories: <?php the_category(', '); ?>



Finally you may have noticed the time function included with some strange-looking letters passed in as a parameter. These are date formatting arguments.  But doesn’t display a time. We could use the_date() function for this but the reason I opted for time is so that each post displays a date regardless of whether 2 or more blogs have been posted on the same day, so a post doesn’t look out-of-place.

And that’s it. We have a blog.

But there’s a few other “housekeeping” things I wanted to explain before I close the blog

Condition Statements.

Blog post templates are made more powerful when combined with condition statements. We could use one for example to check if a post has what is called a featured image. At the moment, I haven’t coded WordPress to show one

But if I wanted to I’d have to check one exists by using a simple statement like this.

<?php if (the_post_thumbnail() ) : ?>
<?php ?>;
<?php endif; ?>

The first line checks if featured images exist and then if it does displays it. If not, the else (the only alternative option in this condition statement is run instead. the_the_post_thumbnail() in the markup


using strip_tags()

In some cases it may be necessary to strip the front end of certain tags that WordPress might add. To do this you  simply pass the post content, as a parameter of the strip tags function.

<article class="post">
   <h1><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h1>
   <h2><?php strip_tags(the_excerpt() ); </h2>


Now any extra HTML elements that WordPress adds in will be stripped out, so you’ll have changes made via the Admin editor and elements coded in your template files but nothing else.

Checking Formatting styles for blog.

Now there was one more check I wanted to do.  I wanted to write some CSS for every possible formatting scenario that might exist when writing a blog post or new page.

So,  I added a new post with every possible formatting example the WYSIWYG editor on WordPress provides


Some of the formatting wasn’t picked up via the CSS because there were no CSS selectors for it. I had heading elements, list items and preformatted text that wasn’t picked up. No problem,  Now the confidence is there that the text will be used no matter what formatting is applied.



This concludes all of the deveolopment I wanted to cover for my WordPress theme.  It is a pretty standard theme and there is a lot more to learn, but this theme I think will serve me well as I can now write blog posts directly into my website, which means plenty of opportunities for great unique content.

There is much more that can be done with a WordPress theme. I could investigfate and use use a framework like Genesis for example. But this is for another day.

In my final blog post for this series I’ll cover how I transferrred the website from where it currently lives (on localhost) to my web domain.

Making a WordPress Theme: #3

The third stage of making a WordPress Theme I wanted to concentrate on is Widgets; and it is trickiest to date. Not in terms of the technicalities of making WordPress recognise widget areas. But simply finding a place for the widget to go.

Because at the time I didn’t know if I wanted widget areas in my theme I didn’t think so far ahead as to prepare a widget area in my static theme. For the most part, I planned for the site will be free of widget areas visually but I did find I wanted a couple of widgets in the top and bottom of my blog content i.e. the home.php template.

In terms of finding getting widgets to work it is quite straight forward.

  1. Create a widget area in functions.php
  2. Find a place in your templates for the widget to actually go.

As a WordPress Developer, you are in complete control of where your widgets appear.

This is how I did it for my theme.

Hello WordPress, I’m adding a widget area to this theme

There are 2 main functions that WordPress uses to create Widget areas. These are create_widget and inside it, register_sidebar. Sidebar is the WordPress speak for a widget area. I suspect although I’ve not researched it, that’s simply a throwback to early days WordPress terminology.

function create_widget($name, $id, $description) {
       'name' => __( $name ),
       'id' => $id

What happens here is that  an array of objects by using some parameters.   These control the name. id and the description of the widget area; so customisable strings that describe the widget and what it will do.

function create_widget($name, $id, $description) {
    'name' => __( $name ),    'id' => $id,
    'description' => __( $description),
     'before_widget' => '
     'after_widget' => '
     'before_title' => '<h2 class="module-heading">',
     'after_title' => '</h2>'

The ID key doesn’t go in the admin area.  It is merely a unique identifier for the individual widget.  This is the id or slug that WordPress will use to distinguish it from another.

Then the function is then called and the values for the parameters passed in. You’d then see this values in the Widgets page of the admin area. That’s all you need to make the widget area appear in the admin area. There are a few other customisable options such as using dynamic HTML classes as containers for your widgets but these are optional.

create_widget('Page Sidebar','page','description');

Once added, all the widgets are available and can be dragged into the widget areas via admin area.  But much like we did with the menu area for WordPress, all we’ve really done is let WordPress know that a widget area exists.  The next stage is to let WordPress know where in the template it is.

Now WordPress, here’s the place for my widget

WordPress uses a specific template file for widgets that is used to store the widget markup. So this is where the building blocks of the widget will go.

<?php if(!dynamic_sidebar('blog') ) : ?>
     <p>Problem pulling in widget to widget area</p>

<?php  endif; ?>

We generate a widget by first checking that a widget with a certain id exists. If it doesn’t we generate some markup telling us that there is a problem. But if everything does work we should see the widgets below.


How did I get it there?

I carefully placed  a function call anywhere in your desired template file to finally display the widget.  I used a word press function called get_sidebar that directly called the sidebar.php function.

<?php get_sidebar();

That is how to use the function in its simplest form.  And that’s all that is needed to display the widget in this case. But there are a couple of issues regarding using the function I think are worth talking about.

First of all, if you wanted to retrieve a widget that’s been given a particular id you simply pass in that widget id as a string.

<?php get_sidebar("blog");


<?php  get_sidebar();  ?>

will call the contents of sidebar.php you can also pass in a string like this.

<?php get_sidebar("blog");

Currently all I have is the sidebar.php that has my widget, because that is the widget with the id of blog, but if I put it in its own template such as sidebar-blog. So if “blog” was the ID of the widget, WordPress would call that template file sidebar-blog.php.

The second point is that if you’re using get_sidebar() function it can only be called once. for example if you were to have a function call at the bottom of the template and another at the top then only the one at the top will work.

There is however a work around that I utilised to show 2 copies of the same widget.
 <?php get_sidebar(); ?>
 <?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>

 <h1><?php the_title(); ?></h1>
          <?php the_content(); ?>

        <?php endwhile; else : ?>

 <p>Sorry, found no content.</p>

 <?php endif; ?>
 <?php include( TEMPLATEPATH . '/sidebar.php'); ?>

I went into my home.php template and first used the standard WordPress function to call the widget and the top and secondly called the sidebar.php file directly rather than using a function. I called it using an include, using a path to the template folder and the adding the file as a string argument. This was result.


Conclusion: What’s next?

So now I have my design, navigation, blog and widgets set up for my theme.

But there’s still some work that can be done with the blog. At the moment, it only displays a certain amount of posts, there’s no pagination or anything that indicates that the blog looks like a WordPress blog.  That needs changing, and this is what I’ll focus on next.