Posted on

Going out with a bang!

We’re already halfway into the month of October, so this post is a little later than planned. I’ve just got back from a short break with my family and I’m recharged and ready to create new blog posts and plugins (or complete existing ones) until the end of the year. I thought it might be fun to post a little about what I have in store for what’s left of 2016.

Elegant Forms

I haven’t touched Elegant Forms since I blogged about it but I am recommitted to completing and releasing the plugin before 2016 ends. The one area that Divi is sorely lacking in is a better form module so I hope to bring this to the community as soon as possible.

Admin Title

On of the great ideas that came out of the Divi Theme Users group was a plugin that automatically updates the admin title of a module based on a specific field in the module itself. I coded up a proof of concept on the night of the discussion but it pretty much stayed there, so I want to revisit and release this little plugin as soon as possible, specifically for all the site builders out there.

New Directions

I want to start moving into Divi Layout and Child Theme creation. As I am not a designer I have to rely on the work of others to help fuel this, so today Atlantic Wave released a bunch of Elegant Themes inspired layouts for Divi. I have a few child themes I am working on that I also plan to release in the very near future, also inspired by the Elegant Themes demo designs, but with a little Atlantic Wave development twist.

Development

As always, I constantly on the lookout for new ideas and new areas of development. If you have a plugin or theme development idea you would like to work on, feel free to get in touch.

Posted on

The Basics of a WordPress Theme

In the first part of my article on child themes I explained a little about the history of WordPress themes and child themes, what they are and why you should use them. After sharing the post in a couple of online groups I am a part of, I received a fairly good positive response to the topic and my thoughts on it. One thing that also stood out from some of the comments was that a lot of Divi users don’t necessarily know how a WordPress theme works in the first place.

Everything I am writing about is (pretty much) included in the WordPress Theme Handbook, specifically the articles on the Template Files, Template Hierarchy and Child Themes. If you can afford the time to read through the handbook I highly recommend it. However it can sometimes be a little technical, so it’s often easier to get a ‘primer’ on the topic, to give you the relevant information you need in a manageable size. So, based on the responses to my first article I’ve chosen to first write this article to explain a little about how WordPress themes work.

Understanding the basics

To be able to understand child themes, first we need to understand WordPress themes. This means we need to talk a little about the Template Files and the Template Hierarchy. I’m not going to go into too much detail, but in short it’s the way in which WordPress looks for and loads the various template files in your theme to render content.

Template Files

Any WordPress theme has a base set of template files that is uses to render content for different sections of your WordPress site. If you take a look at the files inside a ‘standard’ WordPress themes (like those found on WordPress.org) you will see that, at their base level, all themes are made up of of two things, a style sheet and a bunch of php files, also known as templates. Theses templates include, but are not limited to, files like the header.php, footer.php, archive.php, single.php page.php and sidebar.php. Each of these templates performs a different type of task within your WordPress theme. The templates themselves are also divided into different template types, depending on what they do.

Template partials are template files that will be included inside another template file. For example the header and footer template files are partials. They will be included (and reused) inside other template files to render specific sections of a page, in this case the header and the footer of the site.

Examples:

  • header.php – contains all code to render the header
  • footer.php – contains all code to render the footer
  • sidebar.php – contains all code to render the sidebar

The common WordPress template files are the templates that will render the specific content of your site they related to. They can be very specific (rendering a specific category of posts, or a specific page) or very generic (for example the index.php file which will be used whenever a specific template file doesnt exist for the content being rendered)

Examples

  • page.php – contains the code to render a page
  • archive.php – contains the code to render any blog post archive (or list)
  • single.php – contains the code to render any individual post

If you read up in the Template Files section of the theme developer handbook you can learn what each one does.

Template Hierarchy.

The next thing to understand is the template hierarchy. This is the way in which WordPress will look for a series of template files to render the specific piece of content. If the first template in the list doesn’t exist it will keep going down the list until it finds a template it can use. The easiest way to explain this is to take a look at a WordPress blog.

On a standard WordPress blog, you usually have a ‘list view’ (list of blog items, a thumbnail image, an excerpt and some form of link to the full article) and then an ‘article view’ (the actual article itself, including any content for that article). So, that means that you would need at least two templates, one to render the list view and one to render the article view. This means that the WordPress engine will look for a template for each view and use it to render the content. For the list view, WordPress will look for a ‘archive.php’ file in your template folder to render the list view and a ‘single.php’ file in your template folder for the article view.
So your archive.php would contain some HTML to display the list view as well as a WordPress Loop to render the list of blog posts, and the single.php would contain HTML specific to the article view, as well as some PHP to get the relevant article content for display.

Now, if you are a theme developer you are probably swearing at me right now, and that’s fine. That last statement is not 100% correct but I am simplifying it a bit, bear with me.

So great, there is a template for list views and a template for article views, what now? Well, lets say that you want to have links to a list of blog posts per category and you want a different display for each category list view. Whenever a user views blogs under a certain category you want to include a description of that category above the list view. Well you could do this in two ways. Either you would add some code to your archive.php to check if the user is browsing a list of blog posts per category and show that description or you can use the category specific templates in the template hierarchy and create a different template per category. For example, if you had a category with the slug ‘products’ and you created a template in your theme called category-products.php, whenever the user browses to the products blog category, WordPress would use that template file to render the products category blog items. This is useful because it means you don’t have to add extra processing to your archive.php template file and you can just service products category specific content to the user, just by adding a template file.

The other important thing to understand is that for each level of WordPress, from pages to posts, categories to tags, there is a hierarchy in place as to what gets loaded. So for example, when WordPress renders a list of blog posts, it first looks for a category specific template (either by slug or by id) then a general category template, then the archive template and then finally the index template. So in our products category example above (lets say the product category id was 5) WordPress would look for the following template files, in this order, to use to render the list:

  • category-products.php
  • category-5.php
  • category.php
  • archive.php
  • index.php

That’s 6 levels of template hierarchy that you could use to render things differently for different points of just your blog!

The same goes for blog posts, you have the following set of templates at your disposal when developing a theme. Lets say I was rendering a page with the slug (or name) ‘my-page’ which has an id of 7. WordPress would look for the following templates, in this order, to render the page content:

  • a custom template file – (The page template assigned to the page in WP admin).
  • page-my-page.php
  • page-7.php
  • page.php
  • singular.php
  • index.php

Each template is the fallback to the previous template, with index.php being the final template for pretty much all sections of a WordPress site. You can probably see now why any theme developers reading this article were a little annoyed at my oversimplification of the theme hierarchy earlier ;-).

To get a better understanding of the different levels of template types available to you, as well the order in which WordPress loads them, I highly suggest you read Hierarchy in Detail section of the Theme developers handbook.

So what does this mean in terms of Divi. Well the base of the Divi theme is a small subset of the template partials and common template files. Divi doesnt have (for example) category based templates or even an archive template in its template file list. Because Divi has modules which render the blog lists and pages. Divi tends to use the templates towards the end of the hierarchy (single.php page.php and index.php) to render all content, because the modules are handling all the grunt work. However we need to have an understanding of what these template files do and how they can be ‘overridden’ using the hierarchy to be able to build our child theme.