Wordpress Tamilnadu

WordPress Theme Building Course!

This article is part of the How to Build a WordPress Theme course. If you’re new to WordPress theme building, be sure to start from the beginning of the course to get a complete picture.

FULL COURSE 

Believe it or not, as I’ve stated many times before, building a WordPress theme is not a difficult task at all. That’s why using Underscores as a guide is perfect for this short course.

All you need to understand is what a WordPress theme is supposed to do, what languages it uses to make it happen, and how to style it.

From there, you’re stuck with the responsibility of growing on your own as a theme developer. Practice makes a better theme developer. Tapping into the hundreds, if not thousands, of available WordPress resources makes an even better theme developer.

You won’t hit the nail on the head on the first try. You’ll have to learn what does and doesn’t work. You’ll have to learn how to avoid common conflicts, like with popular plugins. You’ll start to pick up on best practices while developing your own way of doing things.

None of this can be taught. It all comes from experience.

Hopefully this course was enough to get your started messing around with custom theme building. If so, the coming experiences will guide you the rest of the way.

Tools of the Trade

Not only is it important that you know how to build a theme, but you should also know how to put it to the test.

Since Build WordPress Yourself was created to be the ultimate resource, it only makes sense that those testing tools be available to you right here on the site.

Stop by the WordPress Theme Building Tools page to see an always-growing list of tools recommended for WordPress theme developers.

These tools take you through the exact process that the WordPress team would use if you were trying to submit your theme to the WordPress theme repository for mass distribution.

From coding standards to extreme content situations, the tools page has you covered. Use it.

Gaining More Experience

You might want to build a theme or two for yourself before you start taking on clients or selling them. You simply want to get a few “reps” in.

Once you’re ready, though, be sure to browse through the blog for a host of tutorials on how to do all kinds of cool things with your theme, making your finished product more awesome than the user ever expected.

Integration with popular software and how to build custom theme options are just a couple of the subjects talked about here. Take advantage.

In Conclusion

Most developers and budding developer can relate to the idea that sometimes all it takes is one tool or experience that helps you move from one level to the next.

For those who have been tinkering with WordPress themes and frameworks for years but don’t have a theme of their own, this is your push in the right direction.

WordPress Theme Building Course!

This article is part of the How to Build a WordPress Theme course. If you’re new to WordPress theme building, be sure to start from the beginning of the course to get a complete picture.

FULL COURSE 

The final lesson covers theme design. But like the rest of this course, it’s not going to be what some of you may have expected.

WordPress themes are intended to be unique. Functionality aside, there’s no reason for two themes to look exactly alike. The way a theme looks is an expression of a designer’s personal style or the requests of someone guiding the creative development.

That said, the very last thing I want to do in this course is help all of my readers create the same exact theme. That’s pointless.

Instead, I want to talk to you about how to approach theme design when starting from scratch (as far as design is concerned) like you are with Underscores.

Build Out Your Visual HTML Structure

Again, I’m not here to teach you CSS. That is not within the scope if this course, and shouldn’t be.

If you are already familiar with the language, you understand that not all CSS properties focus on making things look pretty. Some of them are more concerned with how HTML behaves structurally.

That should be your first concern here. As stated in part 1, the natural HTML flow of your content and sidebar containers is one on top of the other. So if you have Underscores installed already, you’ll notice that your “sidebar” appears beneath your content, as it should.

Now it’s up to you, the theme designer, to change that if, for example, you want your content to be on the left and your sidebar on the right.

Please understand that your content HTML flow is important regardless of how it’s positioned on the screen. It doesn’t matter if your layout is content/sidebar or sidebar/content, the HTML flow needs to remain main content above sidebar content as main content is more important on the page and needs to be available to search engine spiders before less important or irrelevant content is read.

This is where the HTML structure of your template files becomes important.

Remember how we talked about the HTML similarities between the content containers of the various template files? They all called the header, footer, and sidebar just alike. But they also needed to share a common HTML structure around the loop.

The reason for this shared structure is now that you’re writing CSS to position your content and sidebar containers, it’s important that the classes and IDs used in the single.php file are the same as the classes and IDs used, for example, in the search.php file.

Can the HTML be different? Sure… as long as it’s intentional. Otherwise, you’ll end up writing many lines of CSS just to get multiple elements to look exactly the same. That’s silly when they could just share the same CSS by sharing the same classes and IDs.

Let’s take a look at how this would work in Underscores.

Here are the single.php and page.php files with their loops removed for clarity.



Notice that there is no difference between the two HTML structures. The visible HTML is exactly the same and remember, they are sharing the HTML structures of the header, footer, and sidebar already.

With this kind of consistency throughout template files, we can write CSS like this.



Targeting all elements with an ID of primary, we can style every content container across every template that uses the same ID. Now it doesn’t matter if WordPress serves a page or a post, the structure will remain the same thanks to one CSS rule.

To make things even better, only one class or ID needs to match across all template that need to follow the same visual structure. So since we target the primary ID there, we could also give each of those same HTML elements in different template files a unique class that only applies to the template it’s used in.

Being unique with your classes, IDs, and styling is perfectly fine. But before being unique, the goal is to minimize CSS by combining/sharing code wherever possible. That’s just good practice.

With that understood, you’d approach your visual HTML structure by bring all of the pieces together and viewing the HTML as a whole.

Because we know that each page served in our basic theme will include certain components thanks to our strategic approach, we can open up our header.php, footer.php, and sidebar.php files. Lastly, we’d want to open up a file we can use to represent the content container of all other template files. If you made them the same, like they are in Underscores, index.php will do.

html-structureOpening those four files in our text editor gives us the opportunity to visualize the full site HTML structure much like we did in part 3.

Remembering the breakdown of which template handles which part of the above HTML, we know which HTML elements to target in our CSS file based on which part of the site structure they represent.

This is really easy to do in Underscores since the structure is so simple. You’d simply need to choose a class or ID applied to the header element in the header.php file, a class or ID applied to the footer element in the footer.php file, a class or ID applied to the sidebar container in the sidebar.php, and a class or ID applied to your content container across all basic template files.

Underscores takes its HTML structure one step further and wraps all body HTML inside of a container with an ID of “page.” You can see this div container start just inside of the HTML body in the header.php and it’s closed just before the closing body tag in the footer.php file. You’d use this container to determine the width and placement of your site with CSS. Then everything inside of this container, which is everything we’ve discussed up to this point, will still behave as expected.


As we discussed in part 1, Underscores actually comes with CSS you can use to setup either a content/sidebar or sidebar/content site structure. It’s located inside of the /layouts/content-sidebar.css and /layouts/sidebar-content.css files. By default, it is not used by your theme.

Though you can write PHP to utilize whichever stylesheet you want from where they currently sit in the file structure, there’s no need have your WordPress theme load an additional stylesheet just for the few rules found in those files.

Instead, open up one of the two CSS files in your layouts directory and copy its CSS into your main style.css file. Refresh the site and you’ll see the site structure take shape with whatever content-sidebar configuration you chose.



This kind of styling is what you want to do very when setting up your new theme. Get the overall structure of your web page together first before you start designing small details.

What we’ve done is setup the visual structure for Underscores, a basic layout. Understand that along with the freedom to adjust template files however you’d like as well as the ability to create new ones with new HTML elements, how you handle the CSS for your visual structure depends 100% on how you handled your site structure through HTML.

Build Out Your Design

Once you have your overall structure in place, that’s when it makes sense to start designing your theme for “looks.”

There are two stages to this process if you are using Underscores as your starting point.

Slowly look over the default style.css file to see what you’re already given
Write your own CSS
The reason why you want to look over the style.css file is because so much work is done for you already.

One of the most overwhelming tasks a new theme developer will face is the amount of things that need to be accounted for when building out a theme design. HTML elements that you’d never consider using on your own personal site still need to be designed if you’re building a theme for distribution.

That said, Underscores does a great job of giving you a head start. Though there aren’t very many fancy styles in place for you, what you need to style is there already so you don’t have to go remember all HTML elements, figuring out CSS selectors, and other redundant tasks.

It is perfectly normal to use some of Underscores’ CSS and delete some of it as well. For example, I don’t like the head start it gives me with styling input elements. So I delete all of it and write it on my own.

That’s still better than having to build out the entire CSS file. Remember, Underscores is just a start theme… a tool. You still have responsibilities to build out your theme.

Once you’re familiar with what’s already styled for you and what CSS selector already exist, you can start writing CSS to make your theme look magnificent.

Understand that your stylesheet will most likely be lengthy so organization is key.

Because you looked over your stylesheet already to see what Underscores had done, you now know what to put where. So when you start styling sidebar elements, for example, make sure you go to the widgets area of the default stylesheet to place your new CSS.

There’s absolutely no reason to have widget related CSS in multiple places in your style.css file.

Seeing the Big Picture

Designing a WordPress theme is not a general task. Instead, how you approach the design is completely tied to how the theme was built.

So when you’re building out your template files and developing your site structure, you should already be thinking about how the overall design of your theme will look.

As described earlier, proper HTML flow should not be negotiable. Therefor, you have to be able to balance your content with your intended style.

It takes practice. It takes skill. But first, it takes an understand of what is expected of you as a theme developer.

Hopefully, this lesson gave you a clear understanding of your responsibilities as a theme designer.

WordPress Theme Building Course!

This article is part of the How to Build a WordPress Theme course. If you’re new to WordPress theme building, be sure to start from the beginning of the course to get a complete picture.

FULL COURSE 

What we’ve done so far in this course is familiarize ourselves with not only Underscores, but also the typical behavior of a basic WordPress theme.

We know which files to use to make our HTML/PHP templates and we know how to manipulate those templates for organization, efficiency, and unique functionality.

What we need to do now is take WordPress theming to the next level. The greatest thing about using WordPress is the fact that its functionality can extend in an endless number of directions using PHP and the WordPress Codex.

In this lesson, we’re going to do just that using our functions.php file and a few others from Underscores.

Building Functionality Into WordPress Themes

Open up your functions.php file from Underscores and take a look inside.

The first thing you’ll notice is that this is not a template file. This is another WordPress-recognized file that is responsible for the setup and functionality of your theme.

View your functions.php file as a multi-purpose plugin. Why? Because that’s what it is. It’s a file filled with code that does the same things plugins can do. This means you need to wrap your head around the idea that plugins are nothing “extra” or special. They’re just code placed in a separate plugin file as opposed to the functions.php file… effectively separating them from the theme itself.

The thing you must understand about a WordPress theme is that it doesn’t do very much for you. Theme developers have to use code to setup a theme’s basic features.

So even though almost every theme you have ever used included a sidebar or some kind of widgetized area, understand that WordPress themes do not have that functionality by default. The code must be written, and that usually happens in the functions.php file.

Example – Creating Widgetized Areas

In your functions.php file, you should have an Underscores function that has a WordPress function inside of it called register_sidebar(). Find it. That function is responsible for creating widget functionality and can be found right in the WordPress Codex ready for use.

The reason this code is placed inside of your functions.php file is because as long as your theme is the active theme in your WordPress install, its functions.php file is guaranteed to be ran.

That means if your theme is built to have a widgetized area as part of the structure, functionality, and design, you can be sure that it will always be there because the code for it is in this important file.

It’s that simple.

Understanding What You’re Learning

It’s important to realize that this course is not here to teach you how to register a sidebar area. It’s not here to teach you how to create navigation menus.

All of that responsibility lies on the WordPress Codex. It’s pointless to teach that information here because this course would end up being 500 lessons long. That’s what the Codex is for.

Instead, what you need to understand is the concept behind building WordPress themes. It’s not about how to register a sidebar, because that code is given to you. It’s about where, when, and how to use that code.

If the Codex gives you the code to register a new navigation menu, where do you put it? That’s what you’re learning here.

The reason why this approach to learning makes more sense is because you will not accidentally limit yourself only to the code you already know. If I teach you how to register a navigation menu and a sidebar, you’ll start building themes with nothing but navigation menus and sidebars. Lame.

I’d rather you learn that navigation menus and sidebars are simply two of many snippets of code you can use to extend WordPress functionality. So the lesson to be learned is how do you use the code in your theme… not necessarily what code you should use.

Does that make sense?

Underscores functions.php Functionality

Getting back to Underscores, its functions.php file is the hub of its functionality.

It uses WordPress actions and filters to “hack” into core WordPress functionality and make your theme do certain things. Keeping with the previous reference, here’s an example from Underscores.

register-sidebar-wordpress

That’s the code responsible for registering Underscores’ one widgetized area.

Because WordPress was built strategically with actions (also known as hooks, in this case), it recognizes those hooks and does whatever a theme or plugin’s code tells it to do in regards to those hooks.

In this case, widgets_init is the hook used to register widgetized areas.

So in the code you see in Underscores, a custom function has been created and inside of that function lies the code for registering a widgetized area.

That custom function with widget code inside of it means nothing as-is. Instead, the custom function now has to be “hooked” into widgets_init so that WordPress will run the code, considering WordPress knows what to do with widgets_init by default.

This means that for every widgetized area you want to register in your theme, it will need to be hooked into widgets_init. This can be done in multiple places or in one custom function like so.



Like we discussed before, it’s not about knowing the code for registering a widgetized area. That’s given to you in the Codex. It’s about knowing where, when, and how to use that code.

Look through the functions file for other actions being used. Another important one is after_setup_theme. You can read about it on its Codex page. You’ll see it quite often.

Extending the functions.php File

In part 1 of this course, I stated that while basic PHP can be used to extend this file’s reach to other PHP files, it is perfectly normal to build your theme details here.

Underscores has done both. Its functions.php not only has code in it like what we discussed above, it also “calls” a few other files that have functionality written into them as well.



Remember when we discussed the file and directory structure in part 1? In the Root Directories section, we talked about the “inc” directory of the Underscores theme and how it held additional file that extended functions.php file functionality. Here’s how.

The require() function is a very basic PHP function and is not specific to WordPress. In this context, what it is essentially doing is exactly what the header, footer, and sidebar functions we learned about in part 3 of this course.

Instead of placing a ton of code inside of your functions.php file, individual groupings of code/functionality are placed in remote files for organization and then called to from the functions.php file.

As WordPress reads through the functions.php file, it will treat the code that’s required from those remote files as if it was in the functions.php files itself.

That said, you can take your theme organization even further by keeping your important functions.php file clean and moving your theme’s core functionality to remote files away from the action. If you are building a theme for distribution, this is a smart move because users are more apt to add code to their functions.php file than any other and you run less of a change that they’ll screw it up, to be honest.

Getting back to Underscores, go ahead and look through the files that its functions.php file required from the “inc” directory. You’ll see that it’s organized by what it does and it’s formatted similarly to the functions.php file.

These additional files basically inherit the importance of the functions.php file. That’s all.

Seeing the Big Picture

What you need to take away from this lesson is that WordPress functionality can be built into your theme however you see fit.

Forget about the details of how to do a specific task. Instead, concern yourself with how WordPress expects to learn about those tasks through your code structure.

The functions.php is the base for your theme functionality and can be extended to any number of other files in your theme. Likewise, all code that adds to or alters the functionality of WordPress can be used in your theme through this file and its inclusions.

In other words, Googling “how to ________ in WordPress” makes more sense than only doing what you already know how to do. With this lesson, you understand where functionality is built. So all you need to do now is find (or write, if you’re awesome like that) the code.

WordPress Theme Building Course!

This article is part of the How to Build a WordPress Theme course. If you’re new to WordPress theme building, be sure to start from the beginning of the course to get a complete picture.

FULL COURSE 

If you think about it, the WordPress Template Hierarchy we’ve discussed in previous lessons works just like a conditional statement in a programming language.



“If the web page being loaded is a single post, load the single.php template file.”

Simple stuff. The thing to understand is that this logic doesn’t stop at the template level when building WordPress themes.

You can also use this kind of logic inside of your template files with a massive list of predefined conditional tags built into WordPress known as WordPress Conditional Tags.

Let’s have a look at an example from Underscores.

Only Show Excerpts for Search Results

Go ahead and open up your content.php file. Remember, the files that start with “content” in Underscores are used to separate the HTML content from the WordPress-recognized template files of the theme. This is done for organizational purposes.

single.php calls content-single.php. Likewise, page.php calls content-page.php.

However, there are times where general HTML content is needed but it’s not specific to any one template file. That’s what the content.php file is for. Your index.php file, which is used on the main blog listing, uses get_template_part() to call content.php, for example.

In most WordPress themes, the main blog listing displays very similar to search results, right? So really, even though your theme has an index.php for the blog listing, and a search.php for the search results, the HTML “guts” of both can share the standard content.php file… which is what Underscores does.

That makes perfect sense and it keeps things organized. It also minimizes files and reduces the size of your theme while increasing efficiency.

But it’s safe to say that there will be times when you want your blog listing and search results to be just a little different. Say, for instance, you show full length posts on your blog home but you’d only like to show excerpts on your search results. This is exactly what Underscores does, once again.

Instead of creating two different “content” files for index and search, a WordPress Conditional Tag is used inside of the content.php file to serve different results based on which template file is using it.

Here’s a slightly modified (for clarity) section of the Underscores content.php file.


What you see is a WordPress Conditional Tag used as a condition in an if statement.

is_search() is the conditional tag. All it does (in this context) is ask if the page WordPress is currently serving to the user’s browser is a search results page. And if it is, do something. In this case, display the post excerpt the_excerpt() wrapped in HTML.

However, if the page being served is not a search results page then the is_search() condition is not met and whatever else is using this content.php file can go ahead and display the full post content the_content() wrapped in HTML.

To sum all of that up one more time, let’s look at exactly how WordPress describes its conditional tags.

The Conditional Tags can be used in your Template files to change what content is displayed and how that content is displayed on a particular page depending on what conditions that page matches.

It doesn’t get any more logical than that. Combined with the template hierarchy, WordPress allows you to organize your theme files even more with easy-to-use conditional tags.

Using WordPress Conditional Tags on Your Own

Here’s a complete list of WordPress Conditional Tags.

For each one that you see, like is_page() or is_category(), you can make them even most specific by using parameters for specificity.

For example, let’s say you wanted to remove the entire page title from one particular page on your WordPress website using your theme. From what we’ve learned in previous lessons, we know that when WordPress loads that page in our browser, it’s going to use the page.php which will call on the content-page.php for the HTML structure of the page content. So that’s the file we need to modify.

The first thing we’d do in the content-page.php is locate the page title.



The problem is that if we simply decided to remove the entire H1 line from the file, every single WordPress Page in our theme would lose its title. That wasn’t the goal. We wanted to target one specific page.

To do that, we need to create a condition that targets one specific page and there are a number of ways we can do that. Check them out here in the WordPress Codex.

The two most common ways to make a basic conditional tag more specific is to use the Post ID or slug of that particular page/post. So if you’re trying to remove the title on, for example, your “About” page and you set that page’s slug to “about,” you can now use that slug in your condition like so: is_page( 'about' )

Brilliant! Now you have a condition that is specific to one particular page (considering no two pages can share the same slug).

In your content-page.php file, you are now free to wrap your page title in a condition.

To do that, we need our condition to basically say, “as long as the page being loaded is not the page with a slug of ‘about,’ go ahead and output the page title.”

Notice the logic I used there. I didn’t ask if a condition was met. I asked if a condition was not met. That’s where we get to use a cool little piece of PHP functionality in our theme. Stick with me here.

! can be used immediately before a WordPress Conditional Tag to reverse the logic. While is_page( 'about' ) means that page is being served, !is_page( 'about' ) means that page is not a page being served.

Here’s the modification in action.



If the condition is met, which means the page being loaded is not the about page, the page title will be display. If the condition is not met, which means the page being loaded is the about page, the page title will not be displayed.

Seeing the Big Picture

Take more time to review the WordPress Conditional Tags list. Notice all of the possibilities.

Also, look through the Underscores template files for more examples of these conditional tags in use.

An obvious spot is in your archive.php file. There are many different types of archive listings – by author, by date, by category, by tag, etc. Instead of having separate files for all of these different types of archives, they all share the archive.php file.

Keeping that in mind, also consider the fact that you need to display on the archive listing what kind of archive it is… especially if we’re talking about an author archive, of which there could be many depending on how many authors a blog has.

Since the archive.php file is shared, but the type of archive being displayed can be different and its necessary to output that difference to the screen, the archive.php has a massive if statement towards the top of the file to output an archive title at the top of the page letting the users know what kind of archive they are viewing.

Take a look at it for yourself and see if it makes sense to you. If not, read this lesson one more time.

WordPress Theme Building Course!

This article is part of the How to Build a WordPress Theme course. If you’re new to WordPress theme building, be sure to start from the beginning of the course to get a complete picture.

FULL COURSE 

In Part 1 of this course, we talked about the file structure of a WordPress theme using Underscores as an example. If you haven’t read that lesson, please go back and do so.

In Part 2, would stepped away from Underscores briefly to discuss what goes on inside of those theme files regardless of what theme is used.

Now in this lesson, we’re actually going to dig inside of some of the important template files to show the HTML structure of Underscores.

HTML Structure Through WordPress Template Files

html-structureAs stated in Part 2, I am not here to teach you HTML. However, let’s take a quick second to look at how and extremely basic HTML structure would look for a website with a header, footer, content column, and sidebar column.

As you can see, it’s not very complicated. The elements inside of the body tag are what display as the HTML structure of the theme.

You should recall from Part 1 of this course that the header, footer, and sidebar elements all have their own WordPress-recognized template files. They are header.php, footer.php, and sidebar.php, respectively.

So as you would expect, header.php includes the <header> element. However, it also includes everything above the header element. So from the closing header tag on up to the start of the HTML, that’s in the header file.

footer.php includes the <footer> element. Again, it also includes everything below the footer element. So from the opening footer tag on down to the closing of the HTML, that’s in the footer file.

sidebar.php includes a <div> element with an ID or class to label it as the sidebar. Using our example, the entire div with the ID of “sidebar” would be in the sidebar file.

Easy stuff, right? This means the only part we didn’t cover was the <div> element with the ID of “content”.

Again from Part 1, we know that this container will hold different content based on the type of page being loaded in WordPress. Therefore, there are multiple template files eligible to fill this role. Here’s how it’s done.

Content Related Template Files – Example: single.php

The beauty of PHP (and many other programming languages) is that code can be re-used over and over again without having to write the code each time.

In this case, WordPress has built-in functions that are designed specifically to search your theme files by name (now you understand why file names matter).

For example, the get_header() function placed anywhere in a WordPress template file will output whatever is in the header.php file. The same relationship is true for get_footer() and footer.php as well as get_sidebar() and sidebar.php.

That said, we can replace all of the HTML in our previous example with the aforementioned functions designed to fetch that HTML from said template files.

wp-html-structure

We remember from part 2 that PHP is a server-side language. So the fetching of file contents happens at the server and by the time it reaches the user’s browser, it displays as HTML just like the basic template above.

As you can see from the image, the only HTML left in the file is the HTML specific to which kind of page is being loaded in WordPress.

This, ladies and gentlemen, is a general idea of what the template files responsible for handling the content column will look like!

The <div> you see in the image would be the same in all template files so that all content site-wide would share the exact same HTML structure. It’s what goes inside of the div that changes from template to template.

Let’s take a look at the WordPress Post template in Underscores, which, of course, is always going to be single.php.

wp-single-template

Though that looks a more complicated than you probably expected, it’s very simple.

Like all PHP files must do, the PHP code is started at the very top with opening PHP tags. Then, a comment block is in place purely for informational purposes.

Below that section is where you find the familiar code. The header template is called first. Skip to the bottom of the file and you have the sidebar and footer templates called.

In between all that goodness is what makes a Post a Post.

The #primary and #main elements will stay the same from template file to template file. It’s inside of those elements that will change. We have the wonderful WordPress loop (from “while” to “endwhile”) where the magic happens.

The loop does exactly what it sounds like… it loops through your database checking for data that should be retrieved based on what type of WordPress page is being loaded.

In this case, because WordPress knows it is loading a single.php file, it searches the database for one specific single post based on the URL (for the sake of this simple example) and returns the data specified for whatever is placed inside of that loop.

In the Underscores single.php example, three things are called inside of the loop – get_template_part(), _s_post_nav(), and comments_template().

get_template_part()

This function is a WordPress theme developer’s best friend. It’s used in the same way as the header, footer, and sidebar functions were to call a template file. Only this time, you call your template file based on its name, which you specified.

Here, we’re calling get_template_part( 'content', 'single' ). WordPress knows exactly what that means. It will now search the root of your theme for a file called content-single.php.

In your get_template_part() function, “content” is the slug and “single” is the name. WordPress puts those two together and searches for content-single.php. If your chosen slug was “html” with a name of “post,” WordPress would search for the file called html-post.php.

Along with plenty of other awesome features, get_template_part() will also fall back to use the slug as the name of a file if the “name” parameter cannot be found or doesn’t exist. In this example, if content-single.php does not exist, get_template_part() will load just content.php instead.

As you may have guessed, inside of this file is the HTML and PHP responsible for outputting the actual post content. You can see this code inside of… you guessed it… the Underscores content-single.php file.

YES. It is 100% possible to simply copy all of the HTML from the content-single.php file and put it in place of the get_template_part() function in single.php. It’s only separated this way for clarity and organization.

_s_post_nav()

Getting back to the code inside of our single.php loop, _s_post_nav() is simply a function responsible for post navigation displayed below our single post content (think “previous post” and “next post” links).

This function is written in Underscores’ /inc/template-tags.php file. Again, instead of using a function, the actual code could have been written in the single.php file. But do you see how sloppy it would be if all this code was in a single template file?

comments_template()

Lastly, getting back to the loop content again, we have our comments template. The if statement wrapping the comments_template() simply checks to see if 1) comments are open for that particular post and 2) that there are comments to display.

As long as one of those conditions is met, comment functionality will display.

But what does all of this mean?

What this means is WordPress knows when to use what file. WordPress will never load something like your header.php or footer.php by itself. There’s no reason to. However, other files will call those files for use.

The template files making those calls are typically the ones WordPress will load on its own in certain situations.

When a single post is being loaded on the front end, WordPress will turn to the single.php file to quickly build the page. In that single.php file, you’ve supplied a header, footer, content column, and sidebar column. Those four elements, three of which were called from other files, come together to create a full web page from the opening <html> tag to the closing one.

When a WordPress Page is being loaded, it’ll do the same with the page.php file. The list goes on. Does that make sense?

Other Content Related Template Files



We discussed the single.php file because it may be the most complex of your basic template files. There are plenty of others, though, that behave the same exact way.


WordPress Pages typically don’t host comment discussions nor do they have page-to-page navigation below the page content. Therefore, you can expect the page.php file, which is the file WordPress is going to look for when a Page is loaded, to match the single.php file with a little less code inside of the loop. Check it out.

wp-page-template

Does it look familiar? The functions calling the header, footer, and sidebar templates are in place just like the single.php file. Even the HTML wrapping the loop is still the same (that makes your CSS file very happy).

The only differences are that the _s_post_nav() function is gone, because pages don’t need that, and the comments_template() function is gone because I don’t want my WordPress Pages to host comments.

Your page.php may still have code for the comments template. Pages can host comments just fine. I simply remove that code because I don’t want it.

The only thing left inside of my loop is the get_template_part() function with a slug of “content” and a name of “page.” Therefore, my function will go searching for the content-page.php file and whatever is in it will output exactly where I called the get_template_part() function.

And again, the code inside of content-page.php could just as easily take the place of the get_template_part() function inside of page.php. Everything would work exactly the same.

Seeing the Big Picture

With Underscores installed on your test site and its theme folder open and accessible through your text editor, go ahead play with these files based on what you’ve learned.

Review Part 1 again if you need a refresher on what files serve what purpose. If everything makes sense so far, open up the files and start tweaking the code.

Remove the “Edit” link Underscores likes to put at the very bottom of WordPress Page content. Move the category and tag listing from the bottom of single posts into the “entry-meta” div of the post <header>.

Using built-in WordPress functions, you are in control of what information is pulled from the database into your theme. From there, you are in control of where that information goes within your HTML structure, which can be easily adjusted in your template files.

The heart of WordPress theme building starts here.