Interactive Developer Blog

In this ever-changing industry in which we work in

Posted on May 28, 2013March 21, 2016 by Evan Mullins

I’m constantly excited by the web design industry because as it is such a young field, we are still making up the rules and discovering as a community what processes are best. At the same time, the technology driving the field is changing so fast that just when we start to settle into a routine it all gets flipped on it’s head and we’re reconsidering everything again.

Have humans ever had to change up what they do as fast and often as we do? Our craft exists in a never-ending state of flux. It won’t settle down for a while, if ever.

Sometimes I dream about being able to master something without the ground constantly shifting under my feet. The status quo feels like a warm blanket sometimes; who wouldn’t want their world to act more or less predictably?

via The Pastry Box Project | 7 February 2013, Ben Sauer of Clear Left.

Leveling Up Your Authorship Skills with Google Plus

Posted on April 17, 2013March 21, 2016 by Evan Mullins

Otto has a great post over on make.wordpress explaining how to associate your WordPress plugins with yourself as the author in Google search results. I just tried it, easy, and it worked.

While Google+ may not be the hot social area on the block, it does seem to have some benefits. Studies show that listings with a specified author receive much more clicks and attention than those that do not.

Who doesn’t want more attention to their hand-crafted WordPress plugins? More traffic? More readers? More leads? More collaborators…?

I think it makes the listing much more attractive as well, of course, that all depends on your mug too =)

Plugin authors developers are “contributors” to WordPress and should be benefiting from these Google author listings.

Go set up your WordPress profile with a link to Google+ as well as a link to your WordPress profile on your Google+ profile.

This gives Google the data they need to give you “credit” for your work in their search listings. Not that this by any means guarantees that your listings will include this data, but it does do all the set up so it is possible.

Google also provides a Rich Snippet Tool to preview and test that all your associations are set up properly. So don’t stop at WordPress. To me, this is all related to branding, and in having a consistent showing and presence across the web.

Presenting at WordCamp Atlanta – Child Themes

Posted on March 15, 2013August 29, 2014 by Evan Mullins

The presentation? Your firstborn child theme. Child themes 101+2.

I’m speaking at wordcamp atlanta this afternoon about themes and child themes. I’ll update this post with post-presentation notes.

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.

Slides on slideshare

Presentation video via wordpress.tv

Hooks, In a Nutshell – WP Daily

Posted on February 22, 2013August 29, 2014 by Evan Mullins

I’ve published another article over on wpdaily.co exploring the concept of hooks. I remember when starting out that people kept mentioning hooks and filters and actions and… it took a while to grasp what they each meant. I think the first time I started to grasp it was when I read the codex and saw this:

You can sometimes accomplish the same goal with either an action or a filter. For example, if you want your plugin to change the text of a post, you might add an action function to publish_post (so the post is modified as it is saved to the database), or a filter function to the_content (so the post is modified as it is displayed in the browser screen).

And realized that actions and filters are each kinds of hooks. In the post I use a metaphor of procedural programming as people standing in a line waiting to register at the DMV. I hope it will help you understand hooks a little bit better. read it now at Hooks, In a Glorious Nutshell – WP Daily.

Hooks, In a Glorious Nutshell

Posted on February 21, 2013August 29, 2014 by Evan Mullins

Are you familiar with hooks, actions and filters?

If not, then this might be your seriously-simple primer. Let me quickly give you some thoughts about hooks, actions and filters. You can probably take it from there.

Order of Operations

Websites and any programming (procedural at least) has an order that things are done in. They are done in this same order every time and many pains are made to ensure this.

Think of something simple that you engage with every single day, like starting a car. Insert keys, turn keys, hold for a brief moment, and then release. Car starts. There is no alternative way to do this with your current vehicle (unless you buy a new one with those fancy “auto start” features). This is a procedure, and order of how things are done.

If something is out of order in can confuse and confound the programming. Especially a website, and WordPress is no different. Things all happen in a certain order when a page is created on the sever via php and delivered to the client as html.

The server reads the php and goes through all the commands pulling data from the database and placing it in the proper place. This is great and keeps everything running smoothly and webpages loading nicely and properly.

So, Hooks…

Imagine now that you wanted to alter or modify how something, somewhere happened (vague, I know) and needed to interrupt or have access to this execution order. This is where hooks come in.

Think of this execution order as a line or queue at the DMV or at a busy clinic. Everyone comes in and takes a number and sits down to wait their turn. Everyone has their own agenda in this case with their individual business not too dependent on each other, and things will move much much slower than your website, but focus on the ordering concept.

Imagine this is your program, everyone has their data and they bring it to the forefront at the needed time and deposit it or something is done with it. A single file line of ‘actions’ that need doing to accomplish the goal of the program/site/business.

This is similar to a program, website or in our case WordPress. Think about the time each number is called. There is a little space before the person with that number gets to the desk, then they do their business, and there is a time after they leave the desk before the next number is called.

These brief time periods are hooks. In programming sometimes they are set aside and a hook is built into the code, so you can do something before the person gets to the desk, or something with the data they bring after they have brought it.

Where Now?

Now that you’ve got the very basics of hooks and how this works, it’s time for you to learn to build your own, or at least experiment a little.

For starters:

Get goin’!

Speaker at WordCamp Atlanta 2013

Posted on February 20, 2013August 29, 2014 by Evan Mullins

I’m excited to be speaking at WordCamp Atlanta again this year! The time is quickly approaching for WordCamp Atlanta 2013, March 15-16.

I spoke last year and discussed the process of going from Photoshop PSD to WordPress Theme, here are my slides and notes for that WordCamp Presentation.

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!

Speaker Lineup | WordCamp Atlanta.

WP Features: Theme or Plugin

Posted on February 15, 2013August 29, 2014 by Evan Mullins

Reading my wpdaily.co updates today and saw this post talking about WordPress theme features. Eric explains the debate:

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.

Thoughts?

Packery Preview, from Metafizzy & descended from Masonry

Posted on February 11, 2013August 29, 2014 by Evan Mullins

David Desandro / metafizzy, maker of masonry and isotope of which I’m a big fan and user of has been busy with a new project called Packery.

Packery, looks to be a child of Masonry. As you would expect it seems to be pushing things much further and addressing a few pain points of masonry. He’s boasting in this blog post that it will optionally support grid layouts, and give you the option to go grid-less for a more haphazard looking layout. It will allow filling holes and adding elements on the fly, but most impressively… We’ll have drag and drop support (including touch support and multitouch support)! You drag an item around the grid (or non grid) and watch live as elements reposition to embrace the newly placed item! Very cool and I can’t wait to play with it.

Read up on the Packery preview from Desandro on his Metafizzy Blog.

On Going Responsive (responding to Where to Start)

Posted on February 8, 2013August 29, 2014 by Evan Mullins

I needed to write this up about going responsive in response after reading Where to Start (by Trent Walton of Paravel) about getting started with responsive web design. Thanks for sharing your thoughts Trent, I agree whole heartedly. In my experience it is the same. I wanted to share his post and also add my commentary for the parts that I really think Trent is spot on. Some dynamite points.

Longer On-Ramps Have Benefits

I believe Trent is talking about the on-ramp of beginning to create responsive sites. But when I first read the headline about the benefits of a lengthy on-ramp I was thinking about the ‘pre-design’ work that goes into a website. All that work that comes before design and has always been super beneficial to proceed thoughtfully with content strategies, sketching, architecture, wireframes and prototypes. This ‘on-ramp’ stage is even more important in RWD. The time well spent upfront before getting into designs and especially programming really really pays off. Think through all scenarios and purposes and requirements of the site before you hit the ground running. Or else you may get to the finish line realizing you forgot the baton. This is so important concerning responsive from the beginning, when making wireframes for example, we really must think about the available space to render the content.

Design

It’s no longer for prescribing exactly what a site should look like. Instead, it’s used for quick layout exploration and asset creation. As for which view/layout size one should start with, I don’t think it matters. Remember, a single photoshop comp will only express a sliver of the layout potential a fully-flexible responsive site has. It’s impossible to accurately assess a responsive layout in .JPG form.

Yes! Agencies (and clients alike, but I feel that the agencies and developers need to lead the way) need to move past the relic ideal of pixel perfect websites. Not that they should look bad, but they should not all look the same. The nature of the web is to be flexible, right? Let’s embrace progressive enhancements and move on when old browsers don’t see it as nice as current browsers.

CSS

All my values are relative (em, rem, etc.) and based on the 100% 16px base, so I can move code around without losing proportion.

Yes, Again! We need to be relative and fluid all the time. We’ve all picked up some bad habits along the way, but RWD can be seen as a good excuse to remove these.

Breakpoints should always be dictated by our content. Not by `insert popular device of the day`. We should be starting to learn that we shouldn’t rely on any specific device or measurement, because they change all the time. Let’s FORGET device resolutions at the media query stage. These dimensions should be thought out earlier and influence our content strategy. Nothing wrong with using 480 as a breakpoint if it makes sense for your content, but don’t force a square peg into a circle hole. Who knows, next year all these circle holes may become triangles (or spheres) and then we’re stuck shoehorning the square we started with again or starting over. Weird analogy, but I’m just going to let it be.

Regarding Grids, I agree here too. It seems that when using a grid for Responsive Web Design I feel constrained to the grid more than I should. Plus I think it takes the fun out of the process of laying out the content as prescribed. I love the idea of ‘content coreography’ too. It really adds to the sense the required craftsmanship by the developers/designers behind the site well done RWD. It also makes me think of site creators as the directors who layout and present data and lead the story telling of the site.

I’ve said it before, but I’m constantly excited by the web design industry because as it is such a young field, we are still making up the rules and discovering as a community what processes are best. At the same time, the technology driving the field is changing so fast that just when we start to settle into a routine it all gets flipped on it’s head and we’re reconsidering everything again.

Please read Trent’s full article as I’m sure it’s packed with good nuggets for you too.

When making the transition to building responsive websites, the hardest part can be getting started.
I get my fair share of questions about how to choose a direction and chart out the first few steps from industry comrades and potential clients. It can seem daunting, so I thought I’d attempt to sum up a few of my own current thoughts on the matter.

via Where to Start | Trent Walton.

Add Parent Page Slug and Parent Template to WordPress Body Class

Posted on February 8, 2013August 29, 2014 by Evan Mullins

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?