Every WordPress theme has a common set of files to ensure a functioning website. While some of these files, which are considered “core,” are not required, others are absolutely necessary. In this post, I’m going to discuss a few of both types of files, while offering commentary regarding each.
STYLE.CSS
We all know what stylesheets do. They control the presentation – the visual design and layout of a website. While this may be true, WordPress also uses the primary stylesheet (style.css) to identify the meta details pertaining to your theme via a comment block located at the top of the file.
While I won’t discuss styling CSS here, because it’s really beyond the scope of this post, I will offer an example of the header comment I referred to above. And since it’s probably the first task you’re going to complete when putting your custom theme together, it’s important to understand.
Parent Theme Meta Data
/* Theme Name: Twenty Thirteen Theme URI: http://wordpress.org/themes/twentythirteen Author: The WordPress Team Author URI: http://wordpress.org/ Description: The 2013 theme for WordPress takes us back to the blog, featuring a full range of post formats, each displayed beautifully in their own unique way. Design details abound, starting with a vibrant color scheme and matching header images, beautiful typography and icons, and a flexible layout that looks great on any device, big or small. Version: 1.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: black, brown, orange, tan, white, yellow, light, one-column, two-columns, right-sidebar, flexible-width, custom-header, custom-menu, editor-style, featured-images, microformats, post-formats, rtl-language-support, sticky-post, translation-ready Text Domain: twentythirteen This theme, like WordPress, is licensed under the GPL. Use it to make something cool, have fun, and share what you've learned with others. */
I took this example from the WordPress Codex page (slightly modified). If you’re interested, you can see that page here.
Now, there are two different versions – or actually one version and another modified version of this meta data area at the top of your CSS file. If you have a parent theme, or just one theme version on your site, you’d use something similar to what I just posted. If you have a child theme that’s built off of a parent theme, you would need another style.css file in that child theme directory, along with another comment meta data area at the top of that file. Your child theme meta data area would look something like this:
Child Theme Meta Data
/* Theme Name: Twenty Thirteen Child Theme URI: http://wordpress.org/themes/twentythirteenchild Description: Twenty Thirteen Child Theme Author: http://wordpress.org/ Author URI: http://wordpress.org/ Template: twentythirteen Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready Text Domain: twentythirteenchild */
The above code came from the WordPress Codex Child Theme page (slightly modified).
Below, I’m going to go over each part of the parent and child theme meta data areas.
Breaking Down the Meta Data
Theme Name: This is the name of your theme. It should be descriptive and easily recognizable.
Theme URI: Where is your theme located? This area should identify that.
Author: This area is where you name the author of your theme. You can name a specific person or a group, such as a company.
Author URI: Building off the last field, you would offer the web address of the theme creator(s).
Description: How would you describe your theme to someone else? If a parent theme, be descriptive of its features. If a child theme, be sure to inform users of what parent this is a child of.
Version: Are you distributing this theme? Are to modifying it in house? If so, it may be a good idea to keep the theme’s version on file.
License: If you are selling this theme, if would be a good idea to describe its license here. Both parent themes and child themes should have the same license.
License URI: Display the URI of your theme license. Similar to above, both parent and child themes should display the same license URI.
Tags: If you plan on making this theme searchable in a theme index, good descriptive tags are important.
Template: If you are creating a child theme, you would include the name of the parent theme’s folder here. The child theme would inherit much of the parent theme.
Text Domain: My understanding is that this field is for various languages. If you are familiar with this field and its use, please explain in the comment section below.
Using Your Parent Theme’s CSS
The old word for this was “import.” The new one is “enqueue.” Instead of using the outdated process of importing the parent stylesheet into the child’s:
@import url("../twentythirteen/style.css");
You would now enqueue it in your child theme’s functions.php. In order to do this, you would need to create a functions.php in your child theme directory and place the following code in it:
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
function theme_enqueue_styles() {
wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
}
INDEX.PHP
The index.php file is a good one to have because it provides as a backup for all other templates. You can learn more about this by checking out my “Working With WordPress Templates” post.
If you decide that you aren’t going to do much customizing or engage in a lot of granular control of many other WordPress template pages on your site, you’ll likely want to keep the coding of your index.php file fairly high level, so it’ll capture all the necessary functions of every available page you plan to have on your website. Remember, if you only have your index.php file, it’s going to be responsible for the functionality of all pages. Although this isn’t the most ideal setup, it certainly is possible to have your website operate this way.
Here is an example of some code you might have in your index.php file:
<?php get_header(); ?>
<div class="page">
<?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
<div class="title">
<h1><?php the_title(); ?></h1>
</div>
<?php the_content(); ?>
<?php endwhile; else: ?>
<div class="title">
<h1>No Data Found</h1>
</div>
<p>Unfortunately, there is no content on this page.</p>
<?php endif; ?>
</div>
<?php get_sidebar(); ?>
<?php get_footer(); ?>
The above code will check to see if you have any content, and if you do, it’ll display it on your page. If not, visitors will receive the message of “Unfortunately, there is no content on this page.”
HEADER.PHP
If you take a look at the top portion of the code above, you’ll see a snippet that looks like this:
<?php get_header(); ?>
This function calls the header.php file and includes it into the index.php page. To learn more about WordPress functions, you can visit this page in the codex.
Since the index.php page will include the header.php, I thought it would be a good idea to show you an ultra stripped down version of a header.php file.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title><?php wp_title(); ?></title>
<?php wp_head(); ?>
</head>
<body <?php body_class(); ?>>
<div class="navigation">
<!-- navigation goes here -->
</div>
In the section above, you can see the very first function is wp_title() up in the title area. This pulls in the title you input in the back end admin area. The next function is the wp_head() function, which pulls the data you enqueued in your functions.php file. Such data might be your css and js files. The body_class() function adds CSS class names for the HMTL body tag and is dynamic, depending on which page you’re on. Of course, you can have many more functions in this file, but like I said above, I stripped things down for simplicity’s sake. Just know, the header.php file gets pulled into most files by using the get_header() function. WordPress automatically knows which file to pull in because it’s part of their naming convention.
FOOTER.PHP
Similar to the header.php file, the footer.php file gets pulled into index.php using the get_footer() function. You can see this above as well.
There potentially isn’t much to this file. There are a few reasons for it to exist though. The first reason is to simply close any markup that was opened, or initiated, in header.php. If you take a look above, you’ll see that we opened up the <html> and <body> tags and then in the example below, we closed them.
<footer>
<!-- footer information goes here -->
</footer>
<?php wp_footer(); ?>
</body>
</html>
Another common item found in footer files is the wp_footer() function. This function doesn’t output anything by itself, but is often used by developers as a hook to reference JavaScript files. If you don’t have this code in your footer.php file and someone attempts to load a plugin or the equivalent, it won’t work, if it relies on those referenced JavaScript files. Lastly, this function should be coded in right before the closing body tag.
SIDEBAR.PHP
Sidebars on WordPress installs are generally active areas. They hold all sorts of navigation, sign up forms and advertising. Primarily, when coding the sidebar.php file, you’d want to make it widget friendly because those widgets are the things that folks use to include the items I just mentioned. I’ve written some sample sidebar code below:
<div class="sidebar"> <?php if ( ! dynamic_sidebar( 'primary' ) ): ?> <!-- sidebar information goes here --> <?php endif; ?> </div>
As you can see, that’s pretty straightforward. Basically, all we’re doing is calling in the primary sidebar, if it exists, using the dynamic_sidebar() function. If it doesn’t exist, you could certainly add a bit of text there that says something to that effect. It would be up to you whether it’s hard coded or dynamic.
—–
Well, that’s it for today. My fingers are tired and now I’ve got to go through this post to edit it and add some links to all the WordPress functions and other items I talked about. Until next time!
Leave a Reply