Category: Theme Development


Making the Perfect WordPress Theme: The Very Basics

In the first post in this series, we talked about what we’re going to be covering over the next few articles. In this article, we’re getting started.

Specifically, we’ll be covering some basic stuff like the APIs, localization, and licensing.

Learning the APIs by Heart

I think it’s safe to say that WordPress is the best platform because of the APIs: The APIs alone give WordPress its speciality of flexibility. Can you imagine an “inelastic” content management system?

I mean it: If WordPress is used by tens of millions of websites today, it’s because of its flexible nature all of which is due to its APIs.

Anyway, it’s important to know what WordPress APIs are and which ones you need to learn every bit of.

You can check all of the WordPress APIs here. While I suggest you learn and study every single API, I can’t say that you’ll need APIs like the HTTP API, the Filesystem API or the XML-RPC API regularly. Your themes should not contain hardcore functionality and invade the territory of WordPress plugins.

Here are the ones you’ll need the most:

  • Options API – It’s the standardized way of storing and retrieving your theme’s options. While you don’t see too much of it, it works together with the Settings API, so it’s important that you learn it well.
  • Settings API – This API is the backbone of your “Theme Options” panel. You can choose to write your own panel or search for options panel frameworks, but you will definitely need to study how the API works. If you don’t, you might wonder why there are some weird curly braces inside the option you retrieved, or do it all wrong and save every theme option in another database table row. Learn it! Learn it from a series called “The Complete Guide to the WordPress Settings API” or a Tuts+ Premium course called “Using the WordPress Settings API“, both created by Tom McFarlin. If you’re interested in the theme options frameworks, you might want check out Kyla Glover’s review on WPExplorer about five free options frameworks.
  • Theme Customization API – If you want to give your users the liberty of previewing the theme customizations, this is the API for you. It allows the users to change the look and feel of your theme and see the changes in real-time (or sometimes, with a Preview button).

    There’s an excellent series you can check out: “A Guide to the WordPress Theme Customizer“. Written by Tom McFarlin, this series will teach you everything about the Theme Customization API.

  • Shortcode API – This is a very helpful API and by far my favorite one! It allows you to create snippets with square brackets that do stuff, basically. There are many articles here on Wptuts+ but if you need a primer on the API, you can check out Rohan Mehta’s article, “Getting Started With WordPress Shortcodes“.
  • Quicktags API – This relatively simple API allows you to introduce new buttons for the WordPress editor (Text mode) on the writing screen. You can use this to let your users include your theme’s shortcodes, for example. Doesn’t hurt to learn it, right?
  • Widgets API – This might be one of the most important APIs of WordPress for you, if you plan to enrich your theme with neat widgets in the sidebars (or footers). It’s not actually hard to implement if you have a basic understanding of Object-Oriented Programming (OOP) with PHP, but I can personally recommend the “WordPress Widgets: Front to Back” Tuts+ course created by Tom McFarlin.

The Importance of Localization

WordPress is huge. You know why it’s huge? Because it’s not only in English, it comes with Macedonian, Turkish, Slovenian, Chinese and Persian, too (to name just a few). Looking at the list of translations for WordPress 3.6 at, we see that there are over 80 translations that are finished or more than halfway through.

I don’t know if you realized this already, but there’s an enormous WordPress market in countries that don’t speak English natively. I’m a Turkish web designer, and I promise you that when it comes to web design, WordPress dominates the market almost entirely here in Turkey. There’s no national marketplace for digital products, and ThemeForest is generally our first choice to find premium WordPress themes, but local businesses sell extremely well, since their themes are written in Turkish.

I’m pretty sure this is the case for most countries and that’s why you must think about making your theme translatable, at the very least. To take it one step further, you can make deals with people to prepare translation files in their languages. You could pay them or let them use your themes freely, it’s up to you and the deal you make.

Trust me, if a French web design agency sees a phrase like “Already translated into French!”, they will definitely move your theme to the top of their “themes to buy” list.

Licensing Options and Using Licensed Products Inside Your Theme

I can’t stress this enough, so here comes a solid warning: If you don’t know what licenses are and how they work, your themes will not be accepted in any marketplace.

Luckily, there’s a website called TL;DR Legal which helps us understand the legalese language by simply summarizing license types like “If you use this license type, you grant people permission to use your stuff in commercial projects” or “If you’re going to use a product licensed with this one, you must give credit to the original author of the work”. You can even filter features to find out which license type is the best for you, or list licenses that have the features you seek.

For example; if you’re going to use a free slider in your premium theme (meaning that you intend to make money from your theme), you must look for sliders with licenses that allow “commercial use”.

If you’re going to sell your themes on ThemeForest, you’ll need to learn about Envato’s licensing options, too. Like TL;DR Legal, Envato’s license types for ThemeForest are really easy to understand. The “SimpleLicense” for Creative Market is also very simple to learn.

Wrapping Up

That’s it for this article. In the next part, we’re going to go over how to .write better code. We’ll learn how to develop with WordPress’ Coding Standards, how to comment our code and how to validate our code.

If you liked this article, don’t forget to share it with your friends, and your comments are always welcome!



Ensuring Your Theme Has Retina Support

With all of the high resolution screens available today, it only makes sense that your WordPress theme includes support for displaying higher quality images. That means adding functionality to create these images on top of a way to load the right one depending on the screen resolution of the end user.

There are quite a few plugins available for regular WordPress users that will add retina support to their site. Doing a search in the WordPress plugin directory brings up these ones as the top five:

Each plugin approaches adding retina support differently, though they all pretty much use the same two components: a detection script and a retina-ready image creation function. For developers who wish to add this feature directly to their themes, the first thing you need to do is include the right JS file to detect the user’s screen resolution.

Display Detection

It only makes sense to display a higher quality image if the end user is using a retina display. For our purposes, the best way is with JavaScript. I like to use a script called retina.js by Imulus. It weighs in at only 4kb and adds all the front-end functionality you need to detect a retina display and load the right image.

Let’s Enqueue

Copy over the retina.js file into your theme’s /js folder. It needs to be in the right place in order to enqueue it.

Add the following to your theme’s functions.php file:

add_action( 'wp_enqueue_scripts', 'retina_support_enqueue_scripts' );
/** * Enqueueing retina.js * * This function is attached to the 'wp_enqueue_scripts' action hook. */
function retina_support_enqueue_scripts() { wp_enqueue_script( 'retina_js', get_template_directory_uri() . '/js/retina.js', '', '', true );

That’s really all you need for the detection side of things. Next comes the functions to create the higher quality images.

Creating the Images

You need to make sure that each time an image is uploaded, a higher quality version is created and stored with @2x added to the filename. The detection script will search for that suffix in order to load the retina-ready version of the image if required.

Set It Up

In order to make sure that a retina-ready image is created automatically whenever an image is uploaded, you need to hook into the appropriate WordPress filter. The correct one to use is wp_generate_attachment_metadata.

This goes in your theme’s functions.php file:

add_filter( 'wp_generate_attachment_metadata', 'retina_support_attachment_meta', 10, 2 );
/** * Retina images * * This function is attached to the 'wp_generate_attachment_metadata' filter hook. */
function retina_support_attachment_meta( $metadata, $attachment_id ) { foreach ( $metadata as $key => $value ) { if ( is_array( $value ) ) { foreach ( $value as $image => $attr ) { if ( is_array( $attr ) ) retina_support_create_images( get_attached_file( $attachment_id ), $attr['width'], $attr['height'], true ); } } } return $metadata;

The above function checks to see if the uploaded file is an image. If it is, then it processes it using the retina_support_create_images() function.

Make the Image

With everything in place to check if an image has been uploaded, the next thing you need is a function to process and create a retina-ready higher quality version.

This needs to also go in your theme’s functions.php file:

/** * Create retina-ready images * * Referenced via retina_support_attachment_meta(). */
function retina_support_create_images( $file, $width, $height, $crop = false ) { if ( $width || $height ) { $resized_file = wp_get_image_editor( $file ); if ( ! is_wp_error( $resized_file ) ) { $filename = $resized_file->generate_filename( $width . 'x' . $height . '@2x' ); $resized_file->resize( $width * 2, $height * 2, $crop ); $resized_file->save( $filename ); $info = $resized_file->get_size(); return array( 'file' => wp_basename( $filename ), 'width' => $info['width'], 'height' => $info['height'], ); } } return false;

Now a new retina-ready image will be created at double the size of the original. Plus @2x will be added to the filename so that the detection script can work its magic correctly on the front-end.

That’s pretty much all you need, though adding one extra function is a good idea in order to help clean things up whenever an image is deleted.

Clean It Up

If a user deletes an image from the Media Library you might as well trash all the extra retina-ready images that were created too.

Place this final code block into your theme’s functions.php file:

add_filter( 'delete_attachment', 'delete_retina_support_images' );
/** * Delete retina-ready images * * This function is attached to the 'delete_attachment' filter hook. */
function delete_retina_support_images( $attachment_id ) { $meta = wp_get_attachment_metadata( $attachment_id ); $upload_dir = wp_upload_dir(); $path = pathinfo( $meta['file'] ); foreach ( $meta as $key => $value ) { if ( 'sizes' === $key ) { foreach ( $value as $sizes => $size ) { $original_filename = $upload_dir['basedir'] . '/' . $path['dirname'] . '/' . $size['file']; $retina_filename = substr_replace( $original_filename, '@2x.', strrpos( $original_filename, '.' ), strlen( '.' ) ); if ( file_exists( $retina_filename ) ) unlink( $retina_filename ); } } }


It doesn’t take a lot to get your theme ready for retina support. With just a few functions and one extra JavaScript file, your users can make sure that their images will always look great on every type of screen.

If you have any comments or feedback on anything you read above, please feel free to discuss it below.



A Guide to the WordPress Theme Customizer: Sections, Settings, and Controls

This entry is part 3 of 3 in the series A Guide to the WordPress Theme Customizer

In the last article, we created a very basic theme that included the Theme Customizer so that we could see how it looks within the context of the WordPress Dashboard.

After tinkering around with the provided options, it’s easy to see just how powerful this particular feature can be. Generally speaking, this single feature can allow us to steer users away from complicated options pages and allow them to see the result of their changes as soon as they make them without having to hop back and forth between the dashboard and the public-facing side of the site.

And as much fun as it is to begin writing code to bring new features to life, it’s important to understand what we’re working with before we begin actually doing work with it, right?

So in this article, we’re going to take a survey at what goes into working with the WordPress Theme Customizer. By the time you finish this article, you should have a clear understanding of the Theme Customizer, and how to begin introducing your own settings into existing sections, creating new sections, as well as some of the built-in controls that are available for us to use in our work.

Components of the Theme Customizer

In short, there are three components that go into creating the interface of the Theme Customizer. These are:

  1. Sections
  2. Controls
  3. Settings

We’ll be taking a look at each of these in-depth in just a moment, but it’s important to understand that this is not completely different from the Settings API.

In fact, I recommend going back and reading through that series especially if you’re going to be introducing the Theme Customizer into a theme that uses the Settings API.

I mention this because as we begin to take a look at the Theme Customizer, we’re going to cover some information that shows how you can tie the Theme Customizer to existing options.

On the other hand, if you’re not currently using the Settings API – no worries! The Theme Customizer will take care of serializing all of the options for you such that you’ll be able to retrieve them programmatically elsewhere in your theme.

Theme Customizer Components
Theme Customizer Components

But before we discuss any of that, let’s talk about the components of the Theme Customizer.


Notice in the illustration above, we have three different sections, one of which is expanded:

  1. Site Title
  2. Colors
  3. Layout

Obviously, your mileage may vary depending on how your theme is setup, or how you’re building your theme. But the point is that sections are made up of controls and settings each of which we’ll talk about in more detail momentarily.

Perhaps the most important thing to note when adding settings to sections is that WordPress actually has several sections that it already provides. For example:

  • title_tagline – this section is used to hold the site title and tagline (sometimes referred to as the blog name or the description).
  • colors – is a section that’s used to hold settings for particular controls related to settings for text color, link colors, and so on.
  • header_image – is used to hold controls responsible for allowing users to specify a header image.
  • background_image – this section is used to hold controls responsible for setting a background image.
  • nav – is the section that will give users the ability to customize their menus.
  • static_front_page – gives users the options necessary to set a static front page or a blog page, when needed.

Although it’s completely possible – and common – to create your own sections (which we’ll be doing later in this series), I mention these here so that when it comes time to begin introducing Settings, you don’t reinvent the wheel of having one that’s already provided.

Case in point: Let’s say that you want to introduce a feature that lets users change the colors of links in their blog. It’d make sense to place this in the colors section that’s already provided rather than, say, create your own section.

It’s all about knowing when to use what’s provided and when to create something that you need unique to your blog.


Simply put, a ‘control’ is a more-or-less fancy word for an HTML element that allows the user to manipulate something on the blog. That can be anything from an input element to a textarea, or a checkbox, to a color picker.

WordPress gives you the ability to easily use any of the most common HTML controls as well as create your own controls (which is out of scope of this particular article).

As far as controls go in the overall system of the Theme Customizer, controls represent the value of a setting and they belong to a single section.

For example, by looking at the illustration above you notice that we have a text input control. This control is responsible for representing the value of the title setting, and it belongs to the ”Site Title” section.

Easy enough, right?


Finally, settings are synonymous with options – in short, they are the values that users tweak or change whenever they are trying to make customizations to their blog.

In case it isn’t clear, note that settings are represented by a control and can only belong to a single section (since controls can only belong to a single section).

Now, here’s where it can get somewhat complicated especially if you’re working with the existing Settings API, or if you’re starting a theme from scratch using the Theme Customizer.

By default, the Theme Customizer uses the theme_mod features to store all of the theme’s values into a single database row. You can read more about get_theme_mod and set_theme_mod on their respective Codex articles.

Generally speaking, note that all theme_mod records are kept in the wp_options table with the key theme_mods_{theme-name} format. This means that you can easily look up the serialized options using a database front end or by running an SQL query.

For example, let’s say we’re using our Theme Customizer Example that we began creating in the last lesson. To see the setting values stored for that theme, you could run the following query:

SELECT * FROM wp_options
WHERE option_name = 'theme_mods_theme-customizer-example'

Or, again, you could browse using a database front end.

If, on the other hand, you’re going to be introducing the Theme Customizer with options that are already being used by the Settings API, it’s very easy to integrate those into the customizer, as well. The primary difference is that rather than using theme_mod, you’ll be using the Options API so all data will still be kept in the wp_options table, but will be retrieved by using get_option.

The nice thing about this is that all settings are contained within a single row in the database, and that you can retrieve the values based on their key using get_theme_mod.

Put It All Together

I contemplated showing how all of this fits together within this article, but I didn’t want to risk including too much information in the article. As such, I wanted to lay a foundation for the three components of the WordPress Theme Customizer so that we have clear terminology and definitions when we begin to write code.

After all, how we can effectively understand the code we’re writing if we’re not even sure what some of the terms are? Then again, this would probably make more sense within the context of some example code.

Up Next…

To that end, in the next lesson, we’re going to take a look at exactly how to implement our own section, control, and setting into the Theme Customizer.

We’ll also take a look at the various transport methods that are available to us which are basically how the updates are shown to the user. At any rate, it’s nothing too complicated, but we’ll be putting all of the above into practice in the next article.

So if you’ve not caught up on the series thus far, now’s the time as we’re going to begin writing a lot of code in the next articles.



Web Design Inspiration from WordPress Theme Demos

We all enjoy browsing web design galleries and showcases of fresh layouts for ideas and inspiration, but there’s a whole world of amazing designs we probably overlook. WordPress themes are often constructed with beautiful layouts but they’re hidden away on the theme’s demo. This post rounds up a collection of some of the most inspiring […]



Beginning With WordPress: Editing the Structure of Your Site

This entry is part 7 of 7 in the series Beginning With WordPress

So, you’ve got your CSS chops up to speed, and your site should now at least be a fair way down the track to being customised with a colour scheme and maybe even some custom fonts to make it really start to feel like it’s much more ‘you’ than it was. But, you’re thinking you’d also like to make some other changes and those changes aren’t exactly style related. So it’s likely you’re going to have to to start getting into editing some of the hard-coded, inbuilt structure, and that means starting to dig into the PHP files of your site.

Oh, but before we do, if you’re looking for the stylesheet I promised last week that completes the conversion of Twenty Thirteen from orange to blue: that’s here – there may be some elements of the theme I may have missed as you navigate through, I didn’t customise every last post-format and there are probably other things you’ll find absent. So, if you’re really planning on using this for a live site you’ll have a fair bit more work to do. But it will, at the very least, get you a fair way into the process and set you up to be able to manage any other customisations you may want further down the track.

Anyway, back to this week’s tutorial!

Before We Start, You need…

  • FTP access to your site
  • Your text editing software

What We’ll Be Doing

  • Editing the default WordPress footer with custom link / content
  • Moving the main navigation to before the header
  • Creating a page description using custom fields

As an introduction I need to explain a little bit more about templates in a WordPress theme and how they work in the context of a child theme. Because, you may remember that, at this stage our theme doesn’t actually include any PHP templates.

Maybe I’m getting ahead of myself. You might not even be aware of the templating system, right? So for really full explanations you could start here:


However, for the short to the point version, let me quote the Codex as I couldn’t say it any better myself:

Templates are the files which control how your WordPress site will be displayed on the Web. These files draw information from your WordPress MySQL database and generate the HTML code which is sent to the web browser. Through its powerful Theme system, WordPress allows you to define as few or as many Templates as you like all under one Theme

Now, if you look at your theme, you’ll notice there actually aren’t any templates in your theme directory at the moment. Do you need me to remind you as to why?


I didn’t think so. You remember that our theme is a “child theme” and therefore, all the templates for our theme are tucked back up there in the parent theme directory.


So, the question then remains, how do we access and edit these files without risking the parent theme, should the theme developer update the theme?

I’m glad you asked! It’s easy, we simply copy the template we want to edit from the parent directory down into our child theme directory. WordPress is clever enough to look for templates first in our child theme’s directory and if it doesn’t find a required file there it will automatically look back to the parent. So, anything we copy into the child theme directory will take priority.

Ok, that’s the background. Now we move onto the stuff that’s going to allow us to make the structural changes we want.

Creating / Copying Files in Your Child Theme

For a start, there is more than one way to get a copy of the templates we want to edit from the parent theme into the child theme.

Method 1

You can drag and drop from Remote to Local and back to Remote in your FTP client.

In FileZilla drag copies of the templates you’re editing from the parent theme, to your desktop (or anywhere else local on your computer) and then drag it back up to your server into the child theme directory:


This doesn’t delete anything from remote, simply creates a copy on your local machine which you’re then copying back up to the remote machine in a different location.

Method 2

We can also set up a bookmark for our FTP server in Text Wrangler so we can save up to alternate locations (like the child theme) like this:

  1. In Text Wrangler go to Text Wrangler » Setup
  2. In the Bookmarks Tab hit the + sign in the bottom left to create a new bookmark

Populate the fields with your FTP data, the same credentials that you used when we set up FileZilla.


With that set up, when you’re in FileZilla and want to copy a file you can then right-click on the file on your server (in our case, footer.php) and choose edit so it opens in Text Wrangler.

Then, in the Text Wrangler File menu, choose Save a Copy to FTP/SFTP server. (If you choose FTP and the program tells you you need to allow a security exception because you’re using choose allow every time and proceed to saving the file – you’ll only have to do this once).


In the window that opens next, you can then navigate to your child theme’s directory and save the new footer.php to your child theme.


This also moves the file down from the sever, and back up again to the new location on that server, it’s slightly more complicated but I think it makes for a cleaner process in that you don’t end up with orphan files on your desktop. In any case, regardless of how you choose to do it we need to have a copy of footer.php (or whichever file we’re editing) in our child theme so that we can make changes to it!

Editing the Footer to Change the Site Info Details

The first change I’m usually asked to make whenever my trainees get to this part of the course is how to change the default Twenty Thirteen Footer


Mostly they want to add a copyright notice, or they may want to change it altogether, either way it probably won’t surprise you to know that fiddling about with this part of your website can be done in the footer template (footer.php) – so, based on the information in the section above, open up your child theme’s copy of the footer.php in your Text Editor.

So, before we go editing anything, let’s break down what we’re looking at.


At the very top of the page we’ll see a code tag that looks like this. This indicates that the text to follow is PHP, a language that is interpreted and executed by the server before the page is served back to the client (browser) – that’s the clever stuff of web technology, we no longer have to use dumb files that sit statically on the server simply served in response to a browser request. Server-side scripting, which is what PHP is, allows for so much more of a clever, dynamic technology that drives a lot of web based products today (there are other languages too, but WordPress is written in PHP and thus is our focus here).

PHP isn’t HTML, but it works in and around HTML because that’s what browsers read. Browsers can’t read or interpret PHP, that all happens on the server (and is why when you ordered your hosting back in episode 2 you had to make sure your host offered a server with PHP which, of course, the vast majority of them do).

In any case, reading down the page you’ll see the following:

  1. The opening PHP tag
  2. Comments about this template indicating its place in the site structure as a whole (contains the footer content, also closes the main content div)
  3. Closing PHP tag
  4. Some HTML tags – with helpful comments…
  5. some HTML tags – with helpful comments… The closing Main </div>, the <footer> section opening
  6. Some PHP tags e.g.<?php get_sidebar(‘main’); ?>
  7. More closing HTML tags

The published code actually looks like this:


You’ll notice there’s only HTML on the page. All the various template parts have been pulled in from either the theme (sidebar.php and footer.php etc.) or from WordPress itself wp_footer(); and are compiled into one HTML page. Each page or post on your site that you visit will have been compiled in the same way from whichever bits of the theme are called for according to where you are in your site.

If you’re on the home page it may be pulling in a home.php or a front-page.php template, if you’re on the blog it will likely be an archive.php template. All of the templates in your theme are pulled together (by the server), as needed when a client (browser) makes a request to the server to view your site.

So, to get back to what we’re wanting to achieve for this exercise, go back to your text editor and start to get an idea of which bits of this footer template code you might be wanting to edit.

If you look closely you’ll see one long PHP tag that seems to contain all the elements that you might be wanting to change. First we can see that this whole snippet is a link back to

 <?php do_action( 'twentythirteen_credits' ); ?> <a href="<?php echo esc_url( __( '', 'twentythirteen' ) ); ?>" title="<?php esc_attr_e( 'Semantic Personal Publishing Platform', 'twentythirteen' ); ?>"><?php printf( __( 'Proudly powered by %s', 'twentythirteen' ), 'WordPress' ); ?></a>

Now, as you get comfortable with this sort of code you can tweak it however you want, you may want to delete that section all together, in which case you could remove everything from:

<div class="site-info">to</div>
<!-- .site-info -->

and have that whole section disappear and your site finish with the bottom of the widgetised footer (sidebar.php).

But in this case what we’re wanting to do is to change the URL to my website and put in a credit for me, as the developer, and a copyright notice to discourage people from reusing my content.

Something like this “Lovingly crafted by The Web Princess for The Site Client © 2013

First, we change the references in this code snippet from twentythirteen to mytheme (the name of our theme) and:

<?php do_action( 'mytheme_credits' ); ?> <a href="<?php echo esc_url( __( '', 'mytheme' ) ); ?>" title="<?php esc_attr_e( 'Semantic Personal Publishing Platform', 'mytheme' ); ?>"><?php printf( __( 'Proudly powered by %s', 'mytheme' ), 'WordPress' ); ?></a>

Then we change the URL from to – so it will link back to my page:

<?php do_action( 'mytheme_credits' ); ?> <a href="<?php echo esc_url( __( '', 'mytheme' ) ); ?>" title="<?php esc_attr_e( 'Semantic Personal Publishing Platform', 'mytheme' ); ?>"><?php printf( __( 'Proudly powered by %s', 'mytheme' ), 'WordPress' ); ?></a>

Then we’ll change the link title from ‘Semantic Personal Publishing Platform‘ to ‘Web Development and WordPress Training‘ (this is a link back to me, let’s tell Google what I can do):

<?php do_action( 'mytheme_credits' ); ?> <a href="<?php echo esc_url( __( '', 'mytheme' ) ); ?>" title="<?php esc_attr_e( 'Web Development and WordPress Training', 'mytheme' ); ?>"><?php printf( __( 'Proudly powered by %s', 'mytheme' ), 'WordPress' ); ?></a> 

Then we change the text ‘Proudly Powered by‘ to ‘Lovingly Crafted by

<?php do_action( 'mytheme_credits' ); ?> <a href="<?php echo esc_url( __( '', 'mytheme' ) ); ?>" title="<?php esc_attr_e( 'Web Development and WordPress Training', 'mytheme' ); ?>"><?php printf( __( 'Lovingly Crafted by %s', 'mytheme' ), 'WordPress' ); ?></a>

Then we change the word ‘WordPress‘ to the phrase ‘The Web Princess‘:

<?php do_action( 'mytheme_credits' ); ?> <a href="<?php echo esc_url( __( '', 'mytheme' ) ); ?>" title="<?php esc_attr_e( 'Web Development and WordPress Training', 'mytheme' ); ?>"><?php printf( __( 'Lovingly Crafted by %s', 'mytheme' ), 'The Web Princess' ); ?></a>

Finally we want to customise it with our copyright notice, adding in the client’s name after our link and a PHP tag to display the date, and we’ve used PHP because this will automatically show whatever the current year is!

<?php do_action( 'mytheme_credits' ); ?> <p><a href="<?php echo esc_url( __( '', 'mytheme' ) ); ?>" title="<?php esc_attr_e( 'Web Development and WordPress Training', 'mytheme' ); ?>"><?php printf( __( 'Lovingly Crafted by %s', 'mytheme' ), 'The Web Princess' ); ?></a> for The Site Owner &copy; <?php echo date('Y'); ?>

There you go! A new customised footer for our site.

By the way, that was rather a long winded way of going about it. In doing it that way we’ve retained all the elements that make it possible to internationalise this theme, which, in a real world scenario of just tweaking it for yourself (rather than preparing your theme for wider distribution) you could simply have skipped it all and replaced all of the code above with the following:

<a title="Web Development and WordPress Training" href="">Lovingly Crafted by The Web Princess</a> for The Site Owner &copy; 2013

Moving the Primary Navigation to Before the Header Image

So, the next thing we’re going to do is to move the primary navigation from its current home below the banner to above it. Then we’ll create a new navigation area below the banner. You know, just because we can.

So this time you need to copy the header.php from the parent theme into your child theme and open the child version in your editor.

Select the code from the beginning of:

<div id="navbar">to the closing tag of the same</div>
<!-- #navbar -->

This is one of the cool things about Twenty Thirteen, all these great comments to help you find where you are. Take note and do the same in your own themes, so people coming up behind you can find their way in your themes.


Cut that code out and paste it above the <header class="homelink"> line. Make sure you keep it within the <div>.


Save the file and refresh the published view of your site so you can see your changes:


Notice how the banner photo is a bit shorter than it was, and the gap between the banner and the page title a bit wide. If we check it out in the inspector we can see that the header section is still the same height. What’s happening is that the header image is being obscured by the nav, so we’re going to move the image down accordingly.


So, to do this we’ll tweak a bit of CSS. In the same way as we did in our previous tutorial, inspect the code until you find this:

body .site-header { background-position: 0px 45px;

The reason we’ve put the body selector in with the .site-header is to increase the specificity of the CSS. Without it we could put the code in our stylesheet and would not see the results we want because the CSS for the .site-header is set elsewhere in the theme and it’s taking priority (comes after our stylesheet in the cascade). Our adding the body tag makes the CSS more specific and means it takes priority and as such the site will reflect our changes.


Save up to the site and refresh the published site!


Looking Good!

Adding a Page Description to Our Page Templates Using Custom Fields

Finally, the last thing we’re going to do is to edit our page.php template to allow us to add in a page description field under the page title. We’ll do this using custom fields (see the Codex for more details on those).

We’ll start by setting our custom field on our Services page.

First you’ll likely have to edit the Screen Options to make sure you have access to the Custom Fields panel, make sure the Custom Fields checkbox is selected:


This opens a new panel below the page editor. Click Enter New to create a new custom field and put ‘page description‘ in the Name field and enter your page’s description in the Value box.


Now we’ve done that we need to add some code to our page template, so copy page.php from the parent theme into our child theme directory and open the child theme’s page.php in our editor. We’re putting this code in the template after the level 1 heading (<h1>) and before the end of the article header.

<h5 class="page-description"><?php echo get_post_meta($post->ID, 'page description', true); ?></h5>

We got the code we used for this page from the Codex’s page on custom fields – look for the Template Functions section – we simply swapped out their ‘key‘ with ours, which is ‘page description‘. Save and upload your file and refresh the published page:


There you go, the beginnings of editing theme templates.


Finding your way around the theme templates can be a little bit daunting, fortunately, starting with a theme like Twenty Thirteen is a really useful start because of how well commented it is throughout.



Anatomy of a Perfect Sidebar

This entry is part 1 of 1 in the series Anatomy of a Perfect Sidebar

Admit it: Most of us see sidebars as nothing more than a simple container that holds stuff, in our blogs and websites. It gets our minimum effort on the design process and we fill it up without thinking which widget should go where.

But for a well–designed website, the designer should consider a number of factors when working on them. For example, consider the number of sidebar containers, the width and height of sidebars, the order of the elements that go into the sidebars and so on.

In this post, we’re going to study the anatomy of the “perfect sidebar”.

The Definition and the Importance of the Sidebar

First things first — we need to define what a “sidebar” is:

A sidebar is a graphically separated section that contains informational and navigational parts of the website.

Granted, I cheated off from Wikipedia’s definition of the term “sidebar” a little bit.

Sidebars hold contextual elements to the content or the whole of the website, like navigational menus, search forms, or subscription widgets. They may also hold non-contextual elements like advertisements or “daily quotes”. They’re almost always narrower than the content section to emphasize that the content is more important than the sidebar. Their main purpose is to help the visitor to understand and navigate the website better.

As a content management system, the WordPress platform considers sidebars as “widget areas” where WordPress theme developers should allow WordPress widgets to be displayed in their themes.

Although they’re not technically “side” bars, the widget areas that belong to the “footer” of the theme could also be considered as “sidebars” since, well, they’re also widget areas.

For the sake of naming things properly, they should be called “footer widget areas” but in this article, we’re going to talk about them, too.

How Many Sidebars Should Be Used in a Theme?

As you might have already guessed, there’s no right answer to this question. Depending on your website’s complexity and the need for sidebar elements, it could be one to four – or none.

Single Sidebar

Single column sidebar design example: Twenty Twelve WordPress Theme
Single column sidebar design example: Twenty Twelve WordPress Theme

A single sidebar is probably the most popular choice for a blog design. And since blog pages tend to be long with the post lists or post content and comment lists, a single sidebar can hold 5 to 10 sidebar elements. Don’t forget, though: If your sidebar exceeds the height of the main content area, it will definitely seem ugly.

The sidebar can be on the left side of the main content area or on the right side. There’s no significant difference between the two but since people read left to right, left sidebars can attract more clicks while decreasing the importance of the main content, thus lowering the visit duration of each page. (The other way around goes for the RTL languages like Arabic or Hebrew.)

Two Sidebars

Two column sidebar design example: Seventeen WordPress Theme
Single column sidebar design example: Seventeen WordPress Theme

Two sidebars could be useful for corporate websites or magazines, since they should be displaying more navigational & informational elements than blogs. The downside of having more than one sidebar is that you need more space for them and that means you have to narrow down your main content area. Although, you can still enjoy two sidebars with a responsive approach: On screens narrower than a standard laptop (1366 pixels wide), you can take one of the sidebars under the other one.

Also, you can design one of the sidebars very narrow to hold some icons or one–word links, too; but, if you design it poorly, the unevenness could bother your visitors.

Three or Four Sidebars

Four column sidebar design example:
Four column sidebar design example:

This one goes without saying: You have to use responsive design techniques for this. Unless you want to annoy your visitors with screens smaller than 1600 pixels, you need to collapse or move the sidebars for narrow screens.

Smashing Magazine’s current design is one of the best examples for four column WordPress designs with a responsive approach. As the screen narrows down; the leftmost sidebar which holds the main navigation becomes the top navigation, then the second left sidebar gets under the first one on the top, then the main sidebar on the right disappears completely while the second left sidebar gets back to its original place, and finally the second left sidebar joins together with the leftmost sidebar on the top as the main navigation (which is activated with a button).

No Sidebars

Sidebarless design example:
“Sidebarless” design example:

Minimalism could be the right answer for any kind of website. If you’re into that, you might want to reconsider which sidebar elements you want to display and which ones to eliminate from your design.

Then, you can display those elements at the bottom of your pages. You can also try displaying them on the top but that could risk the main content area to be below the “fold” — you must consider the height of visitors’ screens, too.

The theme above is a theme of mine, designed for my blog, Beyn. I always used/coded themes with a single sidebar for Beyn but with this new theme, I wanted to try a “sidebarless” design and it worked out beautifully: At the bottom of every page, I only have three widgets: An “announcements” list, a list of email/feed/social subscription buttons and a “latest comments” widget.

The benefit of a “sidebarless” design is your main content drawing the most attention possible.

To Be Continued…

This is the end for part one of this series. We will be covering subjects like the two dimensions of the sidebar, ordering of the elements and other issues to consider (like colors, images and font sizes) in the next part.