I’ve made presentations at WordCamp Atlanta for the past two years. I’d been told the presentation was recorded and would be added to the repository of wordcamp presentations at wordpress.tv both times, long story short. They have both made it online now. Thanks to whoever posts them and Happy Birthday WP. Enjoy the presentations!
WordCamp Atlanta 2012 Evan Mullins: From PSD to WordPress Theme: Under the Skin
This presentation covers how to get from Photoshop to WordPress. There are many different roads to a theme. Covering a few possibilities and then cover getting from a design in Photoshop to an actual WordPress child theme while trying not to reinvent the wheel. http://wordpress.tv/2013/05/24/evan-mullins-from-psd-to-wordpress-theme-under-the-skin/
This year I’m speaking along the same lines but more specifically about how to create a child theme. Here is the description:
Your firstborn child theme. Child themes 101+2
Learn how to mod themes the right way. Using child themes you won’t loose your edits when there’s a theme update. (101) We’ll go over the advantages and how to set up a child theme. (102) Plus we’ll cover some tricks to make the process a bit easier.
Fear not, I’ll share slides and notes on this presentation as I can. First, I’ve got to go prepare.
Do you have any pain points or specific questions you’d want addressed regarding creating child themes I could work in and answer for you? Hope to see you there!
Generally-speaking, the conversations have always circled around features: There are those that believe every feature you could ever imagine should be included like text color, font selector, and more. On the flip-side, there are those that feel WordPress themes should be finite and extra features should only be added when it’s niche specific.
He says the the main problem is theme bloat, but I think it’s more about the lock-in effect some themes have on users. If they customize it or add content via functionality provided by the theme, then if they switch they no longer have access to it (although the content does persist in the database, there’s just no longer an interface to accessing it).
If users are stuck in your theme because it’s the only way they know how to show their content then it becomes problematic. I’m curious as to how often users are going around changing themes though. Are they changing themes for more/different functionality or for a new look? I find myself changing a theme every couple years or so to update the site, but that’s usually in a whole redesign phase and not just switching around for fun. Should theme switching be more frequent?
I also see it from the user perspective. They just want to purchase/install a theme and be running, they may not have the patience or expertise to 1) find the right plugin 2) install it and set it up, so they’d prefer it be in the theme as a package deal.
Partly, I don’t see it a problem including CPT info in a theme, because that’s where you have to style it anyways, right? Users want their post types, but they also want the templates and styles and functionality/integration with the site that go along with them, and I think a theme is the easiest place to keep all that for the developers as well as the users. Plugin shouldn’t have all the styles for the CPT content and can’t have the template files because then if they switch the theme the styles conflict with the new theme. They may end up having to learn CSS to switch the theme anyways. The users are going to want their data displayed properly as well as it be accessible on their site. So if a new theme would not properly display or integrate the CPT data, then why have it included at all.
Eric does offer some alternative solutions:
Offer a Support License purchase option that allows users to follow tutorials for their own customization.
Offer free downloadable plugins that work exclusively with your premium theme that adds easy functionality.
Offer tiered theme versions–beginner, advanced and developer.
I like the idea of including a plugin to add functionality, but I’d suggest that rather than making it exclusive, make it work with any theme, just make sure your theme supports it (along with other popular plugins).
There is talk about making extra theme functionality ‘opt-out’ for those experienced enough to do so. Set a variable in the functions.php file or even comment out a block of code to remove some customization options to it can be done via a plugin. This, although more work, seems like a good option. Providing the features by plugin makes sense, but asking beginner users to do that extra work seems like unnecessary friction.
Also, it’d be nice if WP had a built in UI for custom post types and custom taxonomies and even custom fields and meta boxes in core. Lay users could then easily create content types and manage data. WordPress would be a tool to create your own custom CMS. Theme developers could create post types as well and then WP would be smart enough to detect data in a CPT table and include the needed UI. Then the users could create/manage content types so if they installed a theme that created a custom post type, since it was now in the database, it would stay even if the theme changed. There are many rabbit holes here, but I feel like I’m onto something and would be excited to see WordPress go this direction.
Add CSS body classes for the parent page on all child pages and the parent page template on of a WordPress site with this body_class filter. Ever need to style all child pages of a parent page in the same way or have you wanted to access every child page of a parent page via css selectors for styling? What about selecting all pages that are descendants of a page which is using a specific template?
Building large websites gets complicated, even in WordPress. Large sites usually mean there are many subpages and sections to the website that may need to be styled similarly. I’ve found it helpful to add a page’s parent page slug to the body class to allow me to alter or target the page or group of pages via css. By default the themes I’ve used have been generous in adding classes to the html body element for easy css selection rules. Things like the post slug, page template, logged in status, page vs post (or custom post type), post id, author… you get the idea. While half the time I don’t need half of this and the other half the time I find myself needing more.
Place this code into your functions.php file and your html body element will have a couple additional classes if they apply. It will have a class delineating the slug for the parent page on all child pages as well as a class delineating the template used by the parent page. This lets me apply styles to a whole sibling-section of a site pretty easily by just targeting the parent-slug on the body. Also adding the template of the parent in case I needed to use that.
Walking through the code here we’re filtering the body_class function is how we are able to add this. We name our own function and give it a $classes parameter. Then throughout our function we can add classes to this $classes array and they will be output with the rest of the body classes. We need to hook into WordPress at the body_class function with add_filter and specify the hook and specify our own function to be called. In this case we grab the page properties of post_parent and the template of that parent. First set the post variable to reference the global scope, and then check to see if the post is a page with is_page. Then if the post object has a value for the parent (post_parent) we add the parent’s name to the classes array. Then we get the _wp_page_template meta data from the parent to find the template it’s using (if there is no template specified, then it returns default). This is added to our classes if it exists and then we return the classes array to the original body_class WP core function.
[cc lang=”php”]
/////////////////////////////////////////////////////////////////////////////////
// Body class adding page-parent
//
function cc_body_class( $classes ) {
global $post;
if ( is_page() ) {
// Has parent / is sub-page
if ( $post->post_parent ) {
# Parent post name/slug
$parent = get_post( $post->post_parent );
$classes[] = ‘parent-slug-‘.$parent->post_name;
// Parent template name
$parent_template = get_post_meta( $parent->ID, ‘_wp_page_template’, true);
if ( !empty($parent_template) )
$classes[] = ‘parent-template-‘.sanitize_html_class( str_replace( ‘.’, ‘-‘, $parent_template ), ” );
}
}
return $classes;
}
add_filter( ‘body_class’, ‘cc_body_class’ );
[/cc]
There are many more classes we can add to the body_class and like I said, sometimes you need more than what’s already provided and sometimes you need nothing. It all depends on the theme you’re using, what it provides and what your specific site and design require. What other classes have you wanted to see here? How have you filtered body_class to fit your site’s needs?
Add the viewport meta tag with a WordPress hook via your theme’s functions file to allow responsive web design and mobile-friendly themes
With all the responsive web design activity over the past few years, I hope that any theme or site we work on we’re able to make responsive to some extent. An important part of making a web site responsive is adding a viewport meta tag to your html. Without explicitly stating our viewport, the mobile browsers will scale down the website to fit into their ‘viewport’. This is a good thing, since if it was a full website and the browser didn’t scale it down, you’d only see the top left corner, or some small section of the site. This viewport was introduced by apple for iOS and has spread to most mobile devices since. There are viewport properties or parameters we can set with this meta tag such as width and scale and can even use some device aware variables (like ‘device-width’) to set these values.
A WordPress Meta Viewport Hook
I usually end up using the following hook to add a viewport meta tag to my head in wordpress. I set the viewport width to match the width of the device. Then I set the initial scale to 1. Some go and set the maximum-scale to 1 as well. This would prevent users from zooming in on your site. I advocate that we should allow users to zoom if they wish since it is a gesture they may be used to and may still need (no matter how nice your RWD is, they may need/want to see it bigger). RWD is about giving the user a better layout for whatever device they are on, not restricting how they view it.
[cc lang=”php”]
/////////////////////////////////////////////////////////////////////////////////
// Add viewport meta tag to head
//
function viewport_meta() {
?>
It seems that every site lately has some sort of slider in it. I'm interested in this plugin that will get the redundant work and even be responsive from the guy(s) at DevPress. I hope to be trying this out on my next project.
Here's a great little line of code to put into your wp theme's functions php file: add_filter('jpeg_quality', function($arg){return 100;}); This will make the jpg compression quality full so degradation will be minimal.
[UPDATE] I’m updating this post that originally just contained my slides with the meat of the presentation as well. I don’t think a presentation is expressed well at all with slides. So I’m going to write some things and link to places that I mentioned.
This presentation covers how to get from a photoshop design to a theme in WordPress. The sample theme I use in the presentation is actually live at http://psd2wp.circlecube.com. I’m not trying to teach css or html here. I more wanted to focus on the process I usually go through in creating a site or theme. Let’s work on this PDS template design called Corporate Clean, which was designed and published by Zsolt Kacso. I saw this done by a drupal theme shop and figured the wordpress world could use the same. (Also check out Corporate Clean for Drupal http://drupal.org/project/corporateclean and download the design they link to on that page: http://mttdownloads.s3.amazonaws.com/projects/kaolti/corporateclean_psds.zip)
First, What is a Theme?
It is all the files that control the front-end and visual side of a site. It is all the files that control the front-end and visual side of a site. Major benefit to a theme (or a CMS overall) is separating design and content, which is the goal of standards based web design. Themes are made up of a combination of files: css, html, php, javascript, images…
The basic structure of a theme is usually something like: Header, Content, Aside(s) and Footer.
We know what types of files or templates we need to include in our theme by using the Template Hierarchy is how WordPress determines which template to use on each page. It looks for template files with specific names in the current Theme’s directory and uses the first matching template file listed under the appropriate query section below. (See Joost De Valk’s Anatomy of a WordPress Theme Infographic).
A wordpress specific term that took me a while to get used to was “the loop”
There are many different roads to a WordPress theme.
All themes are not created equal. There are different type and diffrerent qualitiy levels of themes. We can group them into these main areas though (some of which overlap):
Free – benefit, it’s FREE. Only problem is there’s not a great vetting process and a lot of themes out there aren’t good quality themes you’d want on your site (even if they look nice from the front).
Premium – although WP is open source software as in free, not all themes are free, some will cost you.
From Scratch – It is possible to make a theme from the bottom. This could be beneficial if you have something specific you’re not likely to find out there already.
Customized – A direction many take is acquiring a theme (be it free or not) and them customizing it to make it suit them. Not a bad if you’re starting from something that is nicely done, and you know how to get from a to b.
Standalone – Traditionally all themes were standalone packages, and the theme folder will contain all associated files.
Parent-Child – Since WP 2.7 we’ve had the ability to have parent-child relationships in theming! This means that you can have a theme you want to base yours on and separate any modifications you make to it into a “child” theme that will inherit everything else from it’s “parent”.
Frameworks – Frameworks are themes that have been designed to be used as a starting point or a parent theme. Some have feature rich options pages that allow you to build a theme or site from within the WordPress admin. These really help theme developers to avoid repeating the same code in every theme they make. One caveat to this is that if you’re new to WP, you need to learn all the wordpress specific code as well as any additional code for the theme framework . It complicates the learning curve a bit, but it has long term benefits of speed and ease.
My preferred theme route is using a theme framework. My preferred framework is thematic. Thematic is the ultimate in SEO-ready themes, it is a highly extensible framework which features 13 widget-ready areas, drop-down menus, grid-based layout samples, plugin integration, shortcodes for your footer, and a whole lot more. Thematic as of now is about to get a significant update as well. Resources for thematic include forums, guides, diagrams, tutorials, thematic4you …
Before getting into the design, let’s talk one more fundamental wordpress term: hooks
Hooks are spots in the code that are flagged for us to easily customize how our site or theme functions. To visualize, think about all the thousands of lines of code that gets executed to load a page on a site (yes, there are thousands), and think of it like each line of code is like someone in line at the gracery store checkout . They’d be lined up in order of execution. Hooks are like people in the line that are holding a sign allowing you to cut in line at that precise position to run your own code. There are action hooks and filter hooks in wordpress. Action hooks are for executing your own action at that spot in line, and a filter is about changing something in the line right there. Like if you wanted to insert some ad at the end of every post. You could either add an action that would place it there, filter the post content and add it to the content itself (and you could even filter the content before it goes to the database, or before it’s rendered onto the page). More on action and filter hooks here.
Returning to that added complexity of using a framework, many frameworks will add their own hooks on top of the wordpress hooks. So on top of learning any wordpress hooks you also need to learn the ones specific to your chosen framework where you need to access them. So once you get used to using one framework it may be painful to leave and loose and invested learning in that one. Check these diagrams of thematic structure (blue mandela.com and visualizing.thematic4you.com) including hooks for an visual representation. And the thematic guide to filters and hooks.
Getting from a design in photoshop to an actual WordPress (thematic) child theme while trying not to reinvent the wheel.
The Technical – Actually making the theme
Once you install thematic in your wordpress site, look at the theme directory (/wp-content/themes/thematic/) and you’ll see that thematic comes with a ‘thematicsamplechildtheme’. It’s nice that they thought of this, it gives us a great starting place! We copy that folder, rename it to whatever we want, and place it in the theme directory (sibling to thematic itself). Like so:
The thematicsamplechildtheme has 3 files in it: the style.css, functions.php, readme.txt. I added the screenshot.png file (it will automatically get pulled into the backend as the image of the theme) and made some edits to the stylesheet. Later we’ll add all our styles to the css here, but for now we need to understand that the comment block in the file communicates the details of the theme to wordpress. We need to edit the css file so it reflects our theme properly. The block of text in the comment is formated in a specific way that wordpress will read it and it’s actually pretty self explanitory! All we need to do is update the details. Take special notice of the Template line (it’s what tells WordPress that this theme is a child theme using thematic as the parent), here’s what I’ve done:
Once we have this in place, we go to the appearance section in our wordpress dashboard and select our theme. Then we can then make our edits to our stylesheet and see them live on our site!
Before we go opening a can of CSS, let’s look at a couple things and think big picture. We haven’t yet mentioned what this ‘functions.php’ file is. This is the section where we will do any php related to our theme, in other words our hooks! That includes any wordpress or thematic hooks. This samle theme actually has a couple snippets we can uncomment and a sample filter.
Process & Workflow
My purpose in this presentation was never to show you how to slice a photoshop document into web ready images or how to write CSS. I just wanted to help people get more familiar with or started with building themes. I want to talk a little about my process because when I started theming, while I understood the tech (as in css/html) (although I still had and have lots to learn), the process around theming was somewhat of a mystery. I usually follow a loose workflow/cycle when I’m making a site:
Layout – Wireframe, get content areas (widgets) blocked out. Getting the right content in the right places, or creating the right places to put the content.
Structure – Info Archietecture, get the proper post types and think through any needed templates. Getting the right content types. Ideally we should put this code into a theme functionality plugin to separate the functionality from the visual style. Some think it’s best to put that into a plugin so the theme can be changed. But that’s beyond the scope of this presentation, so I’m just going to show you the code to do it and include it in the theme for now.
Style/Design – CSS, using images and styles to get things visual. Getting the right content looking right.
Interactive – JS, making any client-side scripts lively. Getting content interactive.
Population – The plain old and sometimes even boring, data entry.
Rinse and repeat! This is loose and a cycle, I jump through each of these phases numerous times for each element.
Each of these phases contain different tasks, I’ll include some examples and point out some resources. I don’t want to focus on the exact things to do for any and every situation, but talk more about the way to do things. Basically teach to fish, rather than feed you a few fish.
I think I’ll leave that for another day though. This has gotten quite long!
I’m proud to announce that I’ve been asked to speak at WordCamp Atlanta this year! WordCamp will be held this weekend and hosted at SCAD Atlanta! My session is titled: From PSD to WordPress Theme: Under the skin. Obviously, I’ll be focusing on themes. We’ll look at what they are, what they can do, how to make one and we’ll also go through the process of creating a theme in my presentation. I know that’s a lot, but I’ll do my best to get it all covered in my time. I’m really excited since this is my first speaking gig at a conference (and also a bit nervous). I’ll be sure to post my presentation slides here as well as submit them to the wordcamp site. I even hear they are attempting to record all sessions to post on wordpress.tv, so I may have a post with that too. Here’s the official session description:
We’ll cover how to get from photoshop to WordPress. There are many different roads to a theme. We’ll go over a few possibilities and then cover getting from a design in photoshop to an actual WordPress child theme while trying not to reinvent the wheel.
Are there any questions you want covered in the presentation? Ask quick and I’ll do my best to work them in!
I’ve been building lots of wordpress sites lately and have been loving the thematic framework. I install the theme and then make my edits in a custom child theme. I’ve begun seeing a few things I end up doing in nearly every site and I wanted to share them because finding out exactly how to do it was a bit like finding a needle in a haystack.
The first one I’ll share is related to creating an extra widget area. I know thematic already has a ton of widget areas. I needed a spot in the header to easily update and add elements. It’s a place that commonly holds links, search boxes, phone numbers etc, and normally it’s ok hard coding that into the theme. But what about when it changes? I always try to empower my clients with the option of making tweaks like this on their own. I have found that it keeps them happy, as they don’t get billed or have to wait for me, and it keeps me happy, since that’s really not what I want to spend my time doing. I try to make my sites the kind that I need to do the heavy lifting and some instruction at launch, but then the client is in control and can maintain the site. Of course I explain that if they break it and I have to come in to fix it, then those are billable hours, anyways… that’s another post for another day. I wanted to give the header area (normally to the right of the logo but above the navigation) a widget area. It turns out that it is really a simple few lines of code put into the child-themes functions.php file to do it!
// And this is our new function that displays the widgetized area
function thematic_header_aside() {
if (is_sidebar_active(‘header-aside’)) {
echo thematic_before_widget_area(‘header-aside’);
dynamic_sidebar(‘header-aside’);
echo thematic_after_widget_area(‘header-aside’);
}
}
[/cc]
I know I got this code from someone in some forum somewhere, but it was a long search, and I couldn’t find it again when I looked, so whoever you are, thanks! I usually end up putting a search widget in the header and a phone number or other contact links or rss links and it’s become pretty standard in my toolkit. Hope it helps!
I’m excited to be speaking at WordCamp Atlanta again this year! The time is quickly approaching for WordCamp Atlanta 2013, March 15-16.
Building large websites gets complicated, even in WordPress. Large sites usually mean there are many subpages and sections to the website that may need to be styled similarly. I’ve found it helpful to add a page’s parent page slug to the body class to allow me to alter or target the page or group of pages via css. By default the themes I’ve used have been generous in adding classes to the html body element for easy css selection rules. Things like the post slug, page template, logged in status, page vs post (or custom post type), post id, author… you get the idea. While half the time I don’t need half of this and the other half the time I find myself needing more.
Walking through the code here we’re filtering the 
With all the responsive web design activity over the past few years, I hope that any theme or site we work on we’re able to make responsive to some extent. An important part of making a web site responsive is adding a viewport meta tag to your html. Without explicitly stating our viewport, the mobile browsers will scale down the website to fit into their ‘viewport’. This is a good thing, since if it was a full website and the browser didn’t scale it down, you’d only see the top left corner, or some small section of the site. This 
The first one I’ll share is related to creating an extra widget area. I know thematic already has a ton of widget areas. I needed a spot in the header to easily update and add elements. It’s a place that commonly holds links, search boxes, phone numbers etc, and normally it’s ok hard coding that into the theme. But what about when it changes? I always try to empower my clients with the option of making tweaks like this on their own. I have found that it keeps them happy, as they don’t get billed or have to wait for me, and it keeps me happy, since that’s really not what I want to spend my time doing. I try to make my sites the kind that I need to do the heavy lifting and some instruction at launch, but then the client is in control and can maintain the site. Of course I explain that if they break it and I have to come in to fix it, then those are billable hours, anyways… that’s another post for another day. I wanted to give the header area (normally to the right of the logo but above the navigation) a widget area. It turns out that it is really a simple few lines of code put into the child-themes functions.php file to do it!