So, I’ve been really quiet on here for a bit.  I know, I know – I keep saying all these things about how I want to blog more and never do.  That’s my bad, for sure.

So, that said, I wanted to give you guys an update on how things are going.  People forget that behind all the code and graphics there’s a real person.  So, if you don’t care, then there’ll be more posts soon, but here’s what’s going on in the life of the  real studionashvegas – me (Mitch)!

BlogWorldExpo

BlogWorld is less than a month away, and I’m getting super excited for it.  I’ll be doing a BWEChat on Thursday, May 31st on Responsive Design to prepare for the event, so if you can mark your calendars – it should be a blast.  I’ll be in New York from Monday June 4 to either the 10th or the 11th – it depends on how my next item pans out!

(BTW, if you visit this link: snv.me/KCsvij and use the code ‘bwapvip10′ it should give you 10% off – good through May 15th!)

WordCampNYC

I’ve also been chosen to speak at New York’s WordCamp – i’m also speaking on Responsive Design, and will be approaching it more from a WordPress perspective.  No time yet, but if you’re in the NYC area (or not, because I’ve seen a LOT of people flying in from out of the country to drop in) then you should think about coming!

Mission: Moldova

This isn’t a conference, per se, but it is something very special to me.  Starting June 30th I’ll be out of the country for 2 weeks on a mission trip.  I’m going with Justice and Mercy Int’l to Moldova on a two week camp mission trip.  The first week I’ll be doing music class, possibly leading worship, and playing concerts in the park and/or camp with some of the student worship band members at church.  The second week I’ll be also leading music class, but may even be doing some technology mission work (setting up a computer lab in an orphanage, etc).  Moldova is near and dear to our heart, as we sponsor an orphan there.  If you are so inclined, please consider donating to our trip.  You can check the details here: http://www.missionmoldova.com

A Busy Summer

So that about wraps up my summer plans!  It should be a blast, and I’m sorry if there’s an event that I forgot or am missing (or one you’d like to have me speak at and you haven’t asked me – what are you waiting for?!).  The speaking page above has all of the information on my current schedule, so if you want to come say hello or discuss me coming to speak at your event, then by all means send me a note!

Today, hundreds of geeks woke up early, strapped on their laptop bags, and converged onto the Tequila Cowboy bar in Nashville for the 5th annual PodCamp unconference.  Nashville has a reputation for delivering some of the best unconferences in the nation, and today was no different.  Attendance was a bit smaller (~450 people), but I honestly enjoyed the smaller crowd, as it gave me a chance to get some elbow room in a typically crowded space.  The sessions were fantastic (and I actually went to quite a few today instead of just hanging out in the hallway), and there were people there from all different careers and walks of life to meet.

Session 1: Dave Delaney (SNIRL – Social Networking In Real Life)

I’ve always enjoyed hearing Dave speak, and I’m glad I listened in because I missed him speaking yesterday at GoToExplore in Nashville.  He talked about his career and how it propelled him (almost accidentally) into networking, but how online relationships quickly moved offline (as they should).  That’s why we do Geek Breakfasts and PodCamps and what-not; to foster relationships and then keep up with them via the Internet (between in-real-life visits!)

Session 2: Me (One Web to Rule Them All)

My session was next.  It went well, considering I usually do a WordPress session If anyone got video, let me know so I can post it and give you credit!

You can see the slides here:

Session 3: Laura Click (Building a Smart Social Media Strategy)

Laura was highly informative, and basically spoke of Social Media  as a tool.  She also mentioned how to avoid being a social media “personality” (a Diva, Whiner, etc).

Session 4: Wade Kwon (How to Win Awards and Influence Readers in 439 Days and 668 Posts)

I don’t think I’ve ever actually heard Wade speak, even though I’ve known him for over 3 years now.  He spoke of his creation of the Magic City Post, and how (through fostering his readers, posting diverse content, and providing content that people could use), he beat out the incumbent for best Local Web Site in Birmingham.

Session 5: Robin Wallace (STOP Social Media Pollution)

Her audience was highly engaged (and I found out later this was her first time speaking in public).  She spoke of how to deliver the right message on social sites, instead of posting irrelevant information.

Session 6: Cal Evans (Avoiding a Goat Rodeo)

Cal’s session was good for me, because it was geared toward people who hire developers.  I learned a few things that I could do better to engage my clients (as a developer), and I think I got a bit of understanding of what it’s like to be on both sides of the equation.

Session 7: John Ellis (Target Marketing: Brilliant or Creepy?)

John spoke about remarketing (where Google will serve ads to “persuade” you to either finish an order, unabandon a shopping cart, or sell you products based on your past purchase history).  Is it creepy? Is it brilliant? Who knows, but it works well.

So, there you have it – lots of great content from one of the best PodCamps I’ve been to in recent history.  I’m highly looking forward to BarCamp in the fall, and (sooner) WordCamp next week.  If you’re in town, I’ll be there speaking on Theme Development from Scratch, so make sure you get your tickets if you haven’t yet!

This series is meant to be an in-depth look at Responsive Design.  It covers the history, the how-to, and best practices on responsive design, taken from the view of someone who hates fluid layouts and has found a (seemingly) better solution.  This session will be expounded upon in detail at PodCampNashville, then again in more detail at BlogWorldExpo later this year.

In case you’re wondering, here’s the road map for this week’s series:

• Introduction
• What Are Media Queries
• The Elastic Grid
• Best Practices for Responsive Design
• Podcamp Session: Wrap Up!

When last we spoke I had mentioned that I ended up releasing my core theme onto GitHub, and I’ve already gotten some fantastic feedback!  I’d love to see what you guys are doing with it, because it’s a labor of love and it’s sort of strange just turning it out into the wild… so I want to see good results!

If you’ve looked at the theme, you may have an idea of what we’re going to talk about today, but if not, then let’s just dive right in.

I may have mentioned once or twice that I absolutely hate fluid layouts. With a firey passion that burns greater than a thousand suns, actually. When I saw all of the responsive layouts that were made with fluid backbones, I cringed.  There had to be a way to retain the design integrity of a fixed layout and have the nice fluidity of a responsive layout.

Enter the “Elastic Grid”

Picture your typical layout:

You’ve got logos (black), navigation (grey), a slider (light grey), and footer widgets/columnized content (dark grey).  Now, we need something that will hold a fixed amount of fluid… say, an aquarium:

So we’ve filled our aquarium with water, and are laying these items in it to “float” on the water… some are sitting on top of others, but for the most part you can see how the elements are stacked.  We can assume, by the way, that each of these elements are a specific size.  The upper logo, for example, is 2/16 of the full aquarium.  We’re still going to think in pixels, but we know how many pixels now.  The widgets are exactly 1/3 of the full width (this includes margin on both sides [except on the edges]).

Now, if we change the size of the container, the elements will change, but only slightly:

The elements may look a little shorter in width, but it still retains the same shape.  This is our goal for tablet layouts; keep as much content on the screen without having to scroll.

But what happens when we drastically shrink our aquarium?

This is where a lot of fluid layouts start to really bug me, and where a true responsive design really shines.  We’ve lost the original concept because the elements are just too skinny.  What should happen is that the elements should stack on top of each other when the content area starts to become too skinny to be readable.

Notice our logo now spans the whole content region?  That’s because the logo was small enough before that it really doesn’t change sizes – we may orient it differently, but it doesn’t shrink.  The navigation now floats under the logo (and may take up either multiple lines or one line per menu item).  The slider has shrunk in ratio to keep the images looking sharp, and the widgets now span the entire content width.  But, the difference between this and some fluid layouts is that this layout will never show up unless you’re on a small screen.

Remember this?

/* #Media Queries

================================================== */

/* Smaller than standard 960 (devices and browsers) */

@media only screen and (max-width: 959px) {}

/* Tablet Portrait size to standard 960 (devices and browsers) */

@media only screen and (min-width: 768px) and (max-width: 959px) {}

/* All Mobile Sizes (devices and browser) */

@media only screen and (max-width: 767px) {}

/* Mobile Landscape Size to Tablet Portrait (devices and browsers) */

@media only screen and (min-width: 480px) and (max-width: 767px) {}

/* Mobile Portrait Size to Mobile Landscape Size (devices and browsers) */

@media only screen and (max-width: 479px) {}

Now you can make more sense of what we’re doing.  This allows us to have a fixed layout that appears normal for both desktops and tablets, while giving us a stacked layout for phones (both tablet and landscape).  We get the best view for all devices, while keeping the integrity of the design.

Code Dump, Ahoy!

OK, now that you see the media queries, let’s look at some actual CSS:

/* #Base 960 Grid
================================================== */

.container { position: relative; width: 940px; margin: 0 auto; padding: 0 10px; }
.container .column,
.container .columns { float: left; display: inline; margin-left: 10px; margin-right: 10px; }
.row { margin-bottom: 20px; }

/* Nested Column Classes */
.column.alpha, .columns.alpha { margin-left: 0; }
.column.omega, .columns.omega { margin-right: 0; }

/* Base Grid */
.container .one.column,
.container .one.columns { width: 40px; }
.container .two.columns { width: 100px; }
.container .three.columns { width: 160px; }
.container .four.columns { width: 220px; }
.container .five.columns { width: 280px; }
.container .six.columns { width: 340px; }
.container .seven.columns { width: 400px; }
.container .eight.columns { width: 460px; }
.container .nine.columns { width: 520px; }
.container .ten.columns { width: 580px; }
.container .eleven.columns { width: 640px; }
.container .twelve.columns { width: 700px; }
.container .thirteen.columns { width: 760px; }
.container .fourteen.columns { width: 820px; }
.container .fifteen.columns { width: 880px; }
.container .sixteen.columns { width: 940px; }

.container .one-third.column { width: 300px; }
.container .two-thirds.column { width: 620px; }

/* Offsets */
.container .offset-by-one { padding-left: 60px; }
.container .offset-by-two { padding-left: 120px; }
.container .offset-by-three { padding-left: 180px; }
.container .offset-by-four { padding-left: 240px; }
.container .offset-by-five { padding-left: 300px; }
.container .offset-by-six { padding-left: 360px; }
.container .offset-by-seven { padding-left: 420px; }
.container .offset-by-eight { padding-left: 480px; }
.container .offset-by-nine { padding-left: 540px; }
.container .offset-by-ten { padding-left: 600px; }
.container .offset-by-eleven { padding-left: 660px; }
.container .offset-by-twelve { padding-left: 720px; }
.container .offset-by-thirteen { padding-left: 780px; }
.container .offset-by-fourteen { padding-left: 840px; }
.container .offset-by-fifteen { padding-left: 900px; }

Look familiar?  If you’re familiar with the 960 Grid system it should – the CSS is very similar.  What we’re doing is starting off with a grid.  A grid that we’ll change as soon as our size does.

On tablets, for example:

/* #Tablet (Portrait)
================================================== */

/* Note: Design for a width of 768px */

@media only screen and (min-width: 768px) and (max-width: 959px) {
.container { width: 748px; }
.container .column,
.container .columns { margin-left: 10px; margin-right: 10px; }
.column.alpha, .columns.alpha { margin-left: 0; margin-right: 10px; }
.column.omega, .columns.omega { margin-right: 0; margin-left: 10px; }
.alpha.omega { margin-left: 0; margin-right: 0; }

.container .one.column,
.container .one.columns { width: 28px; }
.container .two.columns { width: 76px; }
.container .three.columns { width: 124px; }
.container .four.columns { width: 172px; }
.container .five.columns { width: 220px; }
.container .six.columns { width: 268px; }
.container .seven.columns { width: 316px; }
.container .eight.columns { width: 364px; }
.container .nine.columns { width: 412px; }
.container .ten.columns { width: 460px; }
.container .eleven.columns { width: 508px; }
.container .twelve.columns { width: 556px; }
.container .thirteen.columns { width: 604px; }
.container .fourteen.columns { width: 652px; }
.container .fifteen.columns { width: 700px; }
.container .sixteen.columns { width: 748px; }

.container .one-third.column { width: 236px; }
.container .two-thirds.column { width: 492px; }

/* Offsets */
.container .offset-by-one { padding-left: 48px; }
.container .offset-by-two { padding-left: 96px; }
.container .offset-by-three { padding-left: 144px; }
.container .offset-by-four { padding-left: 192px; }
.container .offset-by-five { padding-left: 240px; }
.container .offset-by-six { padding-left: 288px; }
.container .offset-by-seven { padding-left: 336px; }
.container .offset-by-eight { padding-left: 384px; }
.container .offset-by-nine { padding-left: 432px; }
.container .offset-by-ten { padding-left: 480px; }
.container .offset-by-eleven { padding-left: 528px; }
.container .offset-by-twelve { padding-left: 576px; }
.container .offset-by-thirteen { padding-left: 624px; }
.container .offset-by-fourteen { padding-left: 672px; }
.container .offset-by-fifteen { padding-left: 720px; }
}

Notice how we keep the same classes, but just change their width.  It’s not quite a LESS approach, but it’s getting there.

And finally the drastic change for mobile:

/* #Mobile (Portrait)
================================================== */

/* Note: Design for a width of 320px */

@media only screen and (max-width: 767px) {
.container { width: 280px; }
.container .columns,
.container .column { margin: 0; }

.container .one.column,
.container .one.columns,
.container .two.columns,
.container .three.columns,
.container .four.columns,
.container .five.columns,
.container .six.columns,
.container .seven.columns,
.container .eight.columns,
.container .nine.columns,
.container .ten.columns,
.container .eleven.columns,
.container .twelve.columns,
.container .thirteen.columns,
.container .fourteen.columns,
.container .fifteen.columns,
.container .sixteen.columns,
.container .one-third.column,
.container .two-thirds.column { width: 300px; }

/* Offsets */
.container .offset-by-one,
.container .offset-by-two,
.container .offset-by-three,
.container .offset-by-four,
.container .offset-by-five,
.container .offset-by-six,
.container .offset-by-seven,
.container .offset-by-eight,
.container .offset-by-nine,
.container .offset-by-ten,
.container .offset-by-eleven,
.container .offset-by-twelve,
.container .offset-by-thirteen,
.container .offset-by-fourteen,
.container .offset-by-fifteen { padding-left: 0; }

}
/* #Mobile (Landscape)
================================================== */

/* Note: Design for a width of 480px */

@media only screen and (min-width: 480px) and (max-width: 767px) {
.container { width: 400px; }
.container .columns,
.container .column { margin: 0; }

.container .one.column,
.container .one.columns,
.container .two.columns,
.container .three.columns,
.container .four.columns,
.container .five.columns,
.container .six.columns,
.container .seven.columns,
.container .eight.columns,
.container .nine.columns,
.container .ten.columns,
.container .eleven.columns,
.container .twelve.columns,
.container .thirteen.columns,
.container .fourteen.columns,
.container .fifteen.columns,
.container .sixteen.columns,
.container .one-third.column,
.container .two-thirds.column { width: 420px; }
}

See how all the columns are just given the same width?  That was the whole idea – we stack on top of each other the elements that would float side-by-side in a larger container.

This code is taken directly from the Skeleton framework, in my opinion one of the best elastic grid frameworks out there, and by far the easiest to design for (especially if you’re used to the 960 grid!)

Tomorrow we (finally) finish the series by looking at some examples, and Saturday if you’re in Nashville you can pop by PodCampNashville for a wrapup!

The last few posts I’ve made on here were diving into the introductions of a Responsive Design (and I plan on finishing that series – work and life got the best of me), but since I started writing those I’ve taken the liberty upon myself to rewrite the boilerplate that I use on nearly every site I design and develop.  I’ve added functions here and there, but I’ve reached a bit of a stall as to what else I could do for it.

So, I’m turning it loose to see how other people use it.

Starting today, you can now download a copy of my “SNV Core Theme”.  It’s meant to be used as a child theme because I’m able to update it straight from the GitHub source – meaning, once I make an update, I can push it out automatically to everyone using it even though it’s not hosted on the repository.

Directions

Direct Download (Stable)

1. You can click on this link to download the theme.
2. Unzip it and upload it to your ‘wp-content/themes’ folder -OR- use the theme installer inside WordPress
3. Activate
4. You’ll need to create a child theme if you want to preserve the initial formatting.  Locate the folder name in your ‘themes’ folder – this is what you will use to define the Parent Theme in your child theme’s style.css file.
   (for more information on child themes, visit the WordPress Codex)

From Git

Use the command:

git clone git@github.com:studionashvegas/SNV-Core-Theme.git

to clone the repo.  Pull as needed.

Forking

Please, PLEASE fork this if you’re into this sort of thing.  You can visit the main repository site on GitHub. I’d love to see what other people are doing with this, and (if it’s OK) we may merge the changes into the main theme.  The layout is, for the most part, finished; now, I’m working on functionality!

Enjoy!

This series is meant to be an in-depth look at Responsive Design.  It covers the history, the how-to, and best practices on responsive design, taken from the view of someone who hates fluid layouts and has found a (seemingly) better solution.  This session will be expounded upon in detail at BlogWorldExpo later this year.

In case you’re wondering, here’s the road map for this week’s series:

• Monday: Introduction
• Tuesday: What Are Media Queries
• Wednesday: The Elastic Grid
• Thursday: Best Practices for Responsive Design
• Friday: Examples and Epilogue

Yesterday we mentioned the who and what behind responsive design – how it allows one website to (without relying on external services or subdomains) serve up the appropriate version of itself to the reader based on what device it’s viewed on (be it tablet or mobile phone).  But, how is this possible?  How does the system know what device you’re on?  The answer is very simple, and yet complex at the same time.

Media queries use a value and expression to define the specific medium that the content is shown on.  CSS2 already uses a very simple system of media querying: the “media” key:

<link rel="stylesheet" media="screen" href="example.css" />

CSS3 expounds upon this concept by allowing more flexible variables to be entered, such as color, width, etc.

Types of Queries

First off, one major difference between the old version and the new is that CSS3 queries can be run right in the stylesheet.  This means that instead of having a “mobile stylesheet”, you can use one stylesheet and organize your styles by screen type:

@media screen and (min-width: 400px) and (max-width: 700px) { … }

This allows you to have specific styles for only screens between 400px and 700px wide.  That said, there are a number of different queries you can run, based on a number of different set-ups:

• screen width
• device width (there is a difference)
• screen height
• device height
• color
• orientation (portrait vs landscape)
• aspect ratio
• device aspect ratio
• resolution
• scan (for televisions)
• grid (tty terminals, for example)

There’s a LOT of different variables here, but if you’re just starting out, the only one you really need to focus on is screen width, since you can set a lot of different values.

Most websites today are built on a system of 960 – whether that’s a grid or otherwise, it’s a fairly standard screen width.  Without going too far into what we talk about tomorrow, here’s a sneak peek at the system I use:

/* #Media Queries

================================================== */

/* Smaller than standard 960 (devices and browsers) */

@media only screen and (max-width: 959px) {}

/* Tablet Portrait size to standard 960 (devices and browsers) */

@media only screen and (min-width: 768px) and (max-width: 959px) {}

/* All Mobile Sizes (devices and browser) */

@media only screen and (max-width: 767px) {}

/* Mobile Landscape Size to Tablet Portrait (devices and browsers) */

@media only screen and (min-width: 480px) and (max-width: 767px) {}

/* Mobile Portrait Size to Mobile Landscape Size (devices and browsers) */

@media only screen and (max-width: 479px) {}

Notice how this allows you to have different CSS setups that tailor to the specific views.  It covers normal sizes, tablets, and landscape/portrait mobile phones.  Dropping this into your stylesheet will allow you to set up styles that are specific to those views.

However, setting up a specific media query for each site is cumbersome - it means that you have to basically design 5 different sites, and who has time for that?  What if there were a way to consolidate the different classes we need to automatically format themselves, and then use these values to tweak our existing design?

But I’m getting ahead of myself.  Tomorrow we’ll talk about why grid layouts are still important, and how we can marry the flexible and the rigid into something that works magically together.

This series is meant to be an in-depth look at Responsive Design.  It covers the history, the how-to, and best practices on responsive design, taken from the view of someone who hates fluid layouts and has found a (seemingly) better solution.  This session will be expounded upon in detail at BlogWorldExpo later this year.

According to the latest research, there are now 1.2 billion mobile Web users worldwide, with 25% of those users never even utilizing a desktop to view their Internet content.  Sure, there have been hacked together methods of displaying one page to your normal viewers and one for your mobile crowd, but for the most part it creates serious overhead for the organization (and serious confusion at times for your users).  What if there were one version of your website that you could serve up to readers, but instead of being shoehorned into a mobile app it would seamlessly mold and shape itself to be the perfect version of itself.  It would be one website on many platforms, instead of many versions of the same website.  This is called responsive design, and it’s a design trend that’s sweeping over the design community.

This idea of a reactive, or responsive design, is very new – less than two years old, in fact.  Ethan Marcotte coined the phrase in his article on “A List Apart” back in May of 2010.  He laid the foundation for a lot of the theories and practical ideas we use in a responsive design.  However, as the trend matured, one little problem kept arising.

Editors Note: This is where I’m supposed to tell you that this is my own opinion and all that stuff, so I guess that this next paragraph may be considered a bit… ranty.  You’ve been warned.

I hate fluid layouts.  Layouts that stretch and skew themselves to the entirety of the screen are awful, they’re ugly, and they are absolutely impossible to design for without a lot of thinking and planning.  For a web application, Gmail being an example, then a fluid layout is fantastic.  But for some reason trying to display brochure sites or blogs in a completely fluid layout usually ends up in a disaster.

Editors Note: End Rant

I am a grid designer.  I love using a system of classes that is predetermined to make the site bend and warp to my every will.  The 960 system has been my system of choice for years now and I was really reluctant to give it up, especially when I  knew that I was going to have to switch to a more fluid layout system, and I know a lot of other designers who are just as wary about switching.

When I see a fluid site, I think of a rubber band.  It’s nearly impossible to hold structure with a rubber band; the band actually takes on the structure of whatever it touches, and doesn’t allow you to plan for truly artistic designs, which the modern web is full of.

What if, instead of a rubber band, there was a studded band that would “snap” to various views, based on where you held it?  It would look like any normal website when done with a fullscreen view, but would immediately snap to the proper alignments when presented with a phone or tablet.  Turns out, there is a away to have a responsive design and a perfectly good looking normal website, all at the same time.

That is the new model I have adopted, and it’s one that will work for nearly any ground-up built design.

That said, stick with us, because here’s the roadmap for the week:

• Monday: Introduction
• Tuesday: What Are Media Queries
• Wednesday: The Elastic Grid
• Thursday: Best Practices for Responsive Design
• Friday: Examples and Epilogue

I hope you’ll stick with me as I explore responsive design.  In the mean time, I’m curious to see your thoughts on the idea of responsive design.  Is it worth even doing?  Should we be focusing on this concept of “one web”, or still segregating our devices?

This is a bit different than my usual post, since I’m looking more for feedback than I am trying to teach something.

My typical workflow for doing a WordPress theme is as follows:

1. Design PSD Mockups
2. Develop HTML/CSS from PSD
3. Weave WordPress boilerplate theme into HTML/CSS
4. Take it server-side
5. Finish up with functions and loops not already inserted

I know that somewhere in there is a spot for a version control system, but being on a Windows machine that has a few drawbacks… namely, since I’ve managed to get GIT working to sync up the entire WordPress install, once I run the sync it refuses to run locally (or vice versa).

My question is: are there any resources for developing themes with a version control system (like GIT) and [two part question] would I be better off only adding the theme folder as a repo and going from there?

Sometimes, when you’re taking WordPress beyond a typical blog setup, the need arises to leverage the accounts system in WordPress (to purchase items, to access information, etc).  Earlier on I told you how to check to see if a user is logged in, but when your only login box is in the back-end, that makes it hard.  The first time a client told me I needed to drop in a login box, I panicked.  Forms aren’t the most fun to work with, and getting it to work exactly right with WordPress can be a real pain.

Unless, there’s a function that does it for you.

<?php wp_login_form(); ?>

That’s it.  That single line of code will pull an entire login box to whatever template you have.  The best part?  You can style it however you like.  If you want, you can even create a page template called “Login”, put the form there, style it to match your site, and users may never even know the difference.

There are a few variables you can add in the form of an $args variable.

<?php $args = array(
'echo' => true,
'redirect' => site_url( $_SERVER['REQUEST_URI'] ),
'form_id' => 'loginform',
'label_username' => __( 'Username' ),
'label_password' => __( 'Password' ),
'label_remember' => __( 'Remember Me' ),
'label_log_in' => __( 'Log In' ),
'id_username' => 'user_login',
'id_password' => 'user_pass',
'id_remember' => 'rememberme',
'id_submit' => 'wp-submit',
'remember' => true,
'value_username' => NULL,
'value_remember' => false ); ?>

The important ones would be ‘redirect’ and the various labels.  Redirect allows you to specify where the user lands once they’ve logged in – default is the current page.  The labels change the username/password field labels to whatever you want.

Otherwise, it’s completely customizable.  Use it in sidebars, lightboxes, and even the footer; since you can style it, you can put it anywhere.

One caveat: if the user does anything wrong, it will take them to the typical WordPress login screen, so if you’re nervous about that sort of thing, you  may want to take proper precaution.  Branding the login page, and using a login redirection plugin to direct users once they’ve logged in will help any of the stragglers find their way.

One thing I continually notice as I surf the web is that people tend to cut corners when it comes to getting their sites up.  They continually forget to drop in small, polishing elements that make a dull website sparkle.  Favicons seem to be the most ignored of the bunch, as I see sites quite often that have kept their hosting account’s favicon or (even worse) don’t have one at all.

All In One Favicon is my go-to plugin of choice for giving my site’s a favicon.  Not only can you specify a different icon for your front end and back end (if you have lots of users, this becomes handy!) but you can also set the Apple Touch icons.  All of the directions are included, and everything runs on the image uploader, so you don’t have to worry about specifying paths, etc.

Conditional Tags are one of my all-time favorite tools to use when developing a WordPress theme.  It’s an intelligent use of programming logic that allows even non-coders to grasp the basics and, in turn, create complex and functional WordPress themes.  With the advent of custom post types, a method was needed to check for the presence of a certain post type, and display the data appropriately.  There’s not a true conditional tag, in the sense you fill in a parameter of a function and it works.  Instead, you have to use a separate function value and test for a match.  In English, here’s how to check for a specific post type:

<?php if ( 'book' == get_post_type() ) {

//code goes here for book-type content

} ?>

If you need to display an either/or content string, the code doesn’t change much:

<?php if ( 'book' == get_post_type() ) {

//code goes here for book-type content

} else {

//code goes here for all non book-type content

} ?>

A good example of this would be my portfolio page.  If both the portfolio post type and my normal blog posts were sharing a template, but I needed to add a Pinterest Button to my portfolio, but not to my blog posts, it may look something like this:

<?php if ( 'portfolio' == get_post_type() ) { ?>

<a href="http://pinterest.com/pin/create/button/?url=<?php echo urlencode(get_permalink($post->ID)); ?>&media=<?php echo $pinterestimage[0]; ?>&description=<?php the_title(); ?>" count-layout="horizontal">Pin It</a>

<?php } ?>

The only problem is there’s no way to use the bang symbol in front (like a typical post type) to show that it is NOT the value specified.  Instead, we have to change the operator from “Equals” to “Does Not Equal”, like so:

<?php if ( 'book' != get_post_type() ) {

//code goes here for non book-type content

} ?>

So, more than a few snippits to get you showcasing your post-type specific data quickly and easily.