Theme Development for Wordpress is one of those things that sounds a lot more difficult than it really is. In truth, to create a theme from a given HTML/CSS design is actually fairly simple. You essentially just need to split your design into different (specific) files and include a few lines of PHP to handle to output of your blog content. So let’s run through the basics.
For the purpose of this article, I’m going to assume you have at least some web development knowledge with a basic understanding of PHP. And that you have a coded HTML/CSS design to “theme up” all ready to go. If you don’t, that’s fine also as this is going to be more of a run through for you to understand the fundamental concepts as opposed to being in the form of a step by step tutorial.
First things first, all theme files need to be stored in their own folder within the yourdomain.com/wp-content/themes location. So if you were to make a theme folder called “MyTheme” to store your theme files it would be located at yourdomain.com/wp-content/themes/MyTheme.
Creating the above is enough to tell Wordpress that there is a new theme available and if you were to visit Appearance > Themes in your WP admin area you will see your new theme appearing as an option – albeit with lots of missing information. You’ll include such information in your style.css, but we’ll get to that later.
The more complex Wordpress themes on the market have literally hundreds of files. All performing a variety of functions but for the purpose of this overview we’ll just discuss the handful of core files needed in order to make your theme functional. You can then add more as you see fit should you wish to make several different templates for different pages etc.
The core files are listed below and you’ll need to retain the same naming convention (filenames) in order for your theme to become operational in its basic form.
The header will appear sitewide unless specified. You should be sure to call the wp_head() function in this file also as it will output all of the elements Wordpress needs to function fully. Although you can live without it if need be it is not recommended.
The wp_head() function will also take care of your page titles so they will be output dynamically based on the page/post at hand as opposed to having a static title across the board.
Like for like with header.php, this is where you’ll put all of the content you want to appear in the footer of your website. Again, appearing sitewide and you can also call the wp_footer() function. It works in the same way as wp_head().
This isn’t a required file as such but given most blogs have a sidebar I figured best to include it. It’s also much neater to keep all of your sidebar code (be it fixed on widgetized) in one single file.
You can choose to manually create widgets using common functions such as wp_get_recent_posts() in this file or you can opt to create a dynamic sidebar (shown here). But more on that below.
This is essentially your homepage. It will include “the loop” which we’ll discuss below and also make calls to the above header, footer and sidebar via the get_header(), get_footer() and get_sidebar() functions respectively.
You can simply put all of your HTML/CSS directly within this file if you don’t require any post outputs from Wordpress etc and move the loop for your blog to a new page/file. But for now I’m just going to assume you want your homepage to output a list of posts like a traditional blog would do.
This is basically a copy of index.php in terms of code but it is only called/used on a single blog post. So where as the loop might output your last 10 posts via your index.php file it will only output a single specific post via single.php – even though it is essentially the same code. It’s the filename that determines what content should be output. And obviously in terms of HTML/CSS you’ll have a different design for single posts as opposed to your homepage.
This performs in exactly the same way as single.php but is only called for pages e.g. NOT posts. Any new pages made will automatically use the page.php design. Any new posts will automatically use the single.php design.
In order to use a different page design entirely, you’d need to make a new .php file, give it a template header and then select that page template to use for each specific page within Wordpress. You can read more about that here.
You can read more about the loop in detail here but it is essentially the “guts” of your theme. It is the code that either lists out your latest blog post or calls single posts and pages making them appear within your design.
Anything outside of the loop will be called before and after it as required and everything within it will be called based on what the page is intending to show. For example if you output a <h1> tag within the loop and had your blog set to show 10 posts on your homepage/index – the <h1> tag would be output 10 times and so on.
If however you’re putting code within the loop via single.php or page.php it will only output the once. What is output depends on the file being used.
Wordpress will automatically look for a filename called style.css in your MyTheme folder. This is where it will get all the information about your theme to display in the Appearance > Themes section of your back end.
You can see via the Wordpress theme handbook how to form the header of your style.css. All the information you put in there will in turn display on your themes panel. Information such as theme name etc should always be included.
You can either choose to put all the CSS associated with your theme in this file or you can leave it blank and make a regular CSS call via your header.php file as you normally would with a traditional web design.
Most themes these days use several .css files within their design so lots of developers then to not include code in style.css directly and instead make additional calls as mentioned above.
You can either manually create them using common functions such as wp_get_recent_posts() to output a list of your recent posts or you can create what is called a “dynamic sidebar” which will allow you to drag and drop the built in widgets that come with Wordpress via the widgets panel.
You can read more about creating a widgetized sidebar here.
Most themes these days come with a widgetized sidebar as standard but for the purposes of learning/experimentation you should feel free to try including a bunch of functions yourself to see how it works. You can always move to a widgetized sidebar later once you have a clear understanding of how it works.
Standard widgets will typically have a header and footer to output the widget name etc.
If you want to create a nice preview image to go next to your theme when viewing it in the theme manager, all you need to do is create the image, name it screenshot.png and put it in your MyTheme folder. Like with style.css, Wordpress will automatically look in this location for the associated screenshot. It will combine this image with the text from your style.css header.
Obviously there are hundreds of thousands of ready-built Wordpress themes on the market but let’s be honest, if there are any that look even remotely “premium” then they’re going to be used elsewhere. Some of the most popular Wordpress themes on the market have over 300,000 downloads/sales – those themes could end up being present on millions of blogs. So sometimes you’re going to want to put your own stamp on things and create a design that is unique to you. Especially if you’re a commercial business.
Whilst the above is not going to teach you “step by step” how to make your own theme. I hope that it is a general enough overview in general to allow you to get started and understanding how everything goes together in general is going to stand you in good stead for when you get down to the specifics.
Truth be told, it’s difficult for a web application that doesn’t have some kind of identification, even if you don’t see it as a security measure in and of itself. The Internet is a kind of lawless land, and even on free services like Google’s, authentication ensures that abuses will...
Although data persistence is almost always a fundamental element of applications, Node.js has no native integration with databases. Everything is delegated to third-party libraries to be included manually, in addition to the standard APIs. Although MongoDB and other non-relational databases are the most common choice with Node because if you...