$ cd ~/.ssh/ – Find and navigate to your ssh directory ($ indicates prompt)
$vim config – open/edit your config file

Add an entry similar to the following:

Host mywpeuser
Hostname git.wpengine.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/key_file
IdentitiesOnly yes


Repeat that step for additional users/keys replacing Host and IdentityFile with the appropriate info where host indicates an arbitrary name that helps to identify the host/user and IdentityFile indicates the path to your ssh key.

Next you’ll want to add or re-add your remote to the local repo like this:
$ git add remote production mywpeuser:production/install-name.git.

This will allow you to push to multiple git remotes across different WPE accounts using different keys while avoiding any conflicts that may occur if you follow the instructions in the WPE dashboard verbatim, i.e. $git add remote production git@git.wpengine.com:production/install.git

Note: The instructions in WPE are not incorrect by any means they might just not work perfectly depending on your set up and considering the potential for multiple keys in use. Also note that the above applies in any case where you might find yourself needing to manage multiple identities on a single system.

If that all makes sense to you and helps then this is probably as far as you need to read. If however you’re interested in why I’m writing this then read on.

Why am I worrying about multiple keys on WPE?

That’s a longer and less exciting story that ultimately boils down to my weirdness about naming conventions and how things appear to a client.

On a related note. If there is one feature I’d like to see on WPE it would be better key management for the end user. If adding my key to the system makes it globally available then I’d personally like to be able to have a central user management feature that would allow me to remove said key from an install regardless of whether or not I have continued access to that install.

Anyway, hope the above helps.

Here are a couple of very, to moderately easy methods for ensuring that your scripts and styles are being served in a way that allows you to squeeze a little extra performance out of your theme. (In some cases a lot extra.)

Minify and combine where possible.

Tools like Grunt and Gulp make it extremely easy to maintain an uncompressed development copy of your scripts while loading a minified version for optimal performance.

Here’s an example Gruntfile that watches both the main.css file as well as the main.js file for changes and creates a minified version with the help of grunt-contrib-cssmin and grunt-contrib-uglify.

If you are using 3rd party libraries in your theme or plugin always be sure to grab the minified version. If for some reason it’s not provided with the package, consider minifying it yourself. Again you can use Grunt if that’s part of your workflow, or try one of the many online compressors.

Keep in mind that if you are developing a theme with the intention that it will be submitted to WordPress.org for review, you will need to provide an uncompressed version of all scripts and styles.

Be mindful of where you are loading.

I see this issue a lot…  Use conditionals, use templates tags, use the appropriate hooks, custom code it (shouldn’t need to ), but make sure that you’re only enqueueing scripts where they are needed.

For example, I recently had a look at a theme that required a handful of scripts and styles be loaded on it’s custom options page. The developer correctly targeted the admin dashboard but could have taken it one step further by ensuring that the scripts where being enqueued on the options page only. Instead they were being loaded on every page which results in an entirely avoidable performance hit for the dashboard.

There’s a great, albeit brief overview in the codex here with a more in depth tutorial here.

Look to Core

WordPress core comes with a few dozen pre-packaged scripts and popular libraries; I suggest you look there before considering a 3rd party library. You won’t always find what you need but you’d be surprise how often you will, especially when it comes to providing functionality in the dashboard.

Off topic: Some people will scream, replace core libraries with a CDN version for performance. I’m not going to express my opinion one way or the other. But, should you decide to replace core libraries (e.g. jQuery) be mindful of how you’re doing it as well as how it will be maintained. Replacing core libraries can and will break things if not properly maintained.

Delay Loading

CSS will in most cases need to be loaded in the head of the page document (but not always), that is not however always the case with js files. Test and consider delaying the load of javascript until the bulk of the page renders by enqueueing your scripts in the footer by setting $in_footer to true.

e.g.

Clean up after yourself.

If you started with my-fancy-navigation.js and, after developing for a while decide that my-other-fancy-navigation.js is going to do a job better… job, don’t forget to remove the first.

This seems obvious but I’ve seen it a number of times in taking over a project. Spend an hour trying to understand why abc.js is being loaded to the page only to find out that it was replaced by xyz.js at some point but never removed. (Also, why not just remove the file all together. No need to ship the project with code remnants.)

Be Tidy

Kind of like the above. When you’re writing your css be tidy. Remove unused or unnecessary classes, things change, it’s going to happen. Try to reuse rather than reinvent, consider reusable classes where possible. This takes a little more thinking about the project as a whole but it’s worth the extra effort.

Why? Because this will not only lead to more maintainable code but it will also (hopefully) cut down on file size allowing you to serve a smaller and speedier website. Every little bit counts.

That’s a wrap.

A few tips for your consideration when you start the next WordPress theme or plugin project.

Background
Recently I was involved in a project where the about (team) page required a nice smooth scroll that would link an employee’s headshot to an anchored position further down the page where more info about the employee could be found. We also wanted to keep in place a nice human readable hash so that the bio could be linked to directly (for those of you asking why we’re not using the_ID() to accomplish this).

With a few anchor links and a little jQuery this is typically pretty easy to pull off but it gets a little more challenging when you have consider the loop and intend to keep things dynamic.

After exploring Genesis and racking my brain for a bit I came up with a pretty decent solution.

The Solution
Employees are a custom post type, Genesis layout enabled, employees entered individually.

For each employee I enter a unique identifier in the Layout Settings – Custom Post Class. Could be the person’s last name or maybe their title, whatever works. Example “smith”.

With the class assigned above now accessible from within the loop it’s just a matter of using it to set up your anchors.

Usage will probably vary so I won’t go into detail with the code but here’s the general scenario.

For the page we created a custom template. In that template we have two loops. The first loop sets up a grid of all employees, headshot, name and title. Inside that loop we create the anchor link by echoing the custom post class and adding a hash, see step 1.

Further down the page we have the second loop. Single column, each employee listed out with additional information like their bio, a short video etc. Here we do the same thing only this time we echo out the custom post class as a div id wrapping each employee.

Code example truncated for brevity:

With that you have your anchor links set up!

Next I of course invoked some jquery to set up my smooth scroll, I prefer http://jpederson.com/Creep.js/, and we’re good to go.

But for some that might seem like overkill when you only require a single additional widget area on a single page template, and for that purpose I’d agree. This is how I handle swapping out sidebars in a Genesis child theme.

Context:
For the project that I’ll be using as an example I had a custom post type that required a custom post template to display the single posts for this post type. On these pages I needed a new widget area that would accommodate several widgets specific to the posts.

Step 1
First thing you’ll want to do is register your new widget area, pretty basic knowledge required. For example:

Step 2
The following two functions are added to my child theme’s custom single template, e.g. single-custom_post.php. Keep in mind that my custom post type required a custom template for other reasons so I am adding these functions directly to the template. This isn’t necessarily required as these functions could be used in your functions.php with some modification.

Please read the code comments for an explanation of each.

You should now have a fully functional custom widget area on your single-post_type.php custom template.

And like I said, for anything more complex I’d definitely recommend that you check out the plugin I mentioned above.

You’ll likely start by taking inventory of what you have, carefully organizing all existing content into topic areas using content type labels or taxonomy.

If you’re anything like me you this is right around the time that you start feeling anxious and overwhelmed, staring at content, trying to figure out where to start.

What if this process could be made easier by starting inside of WordPress?

In a recent project we started by exporting a copy of the existing site content. We then set up a “clean”, default installation of WordPress and imported the content. This is where we would start, and by going completely bare with the installation there was only one thing we could focus on – content.

Next, we installed the Custom Page Labels Plugin. We dove in, reviewing each piece of content,  fleshing out a structure, using Custom Page Labels to tag each piece of content with it’s respective type or taxonomy.

For example:

You might do this in conjunction with a page/child page structure.

Easy to visualize, easy to identify within the admin pages list, and easy to edit when you change your mind.

This is only a small part of your information architecture project but it does prove to be an interesting and unexpected use case for the Custom Page Labels plugin.

It’s in beta and it’s up on GitHub. Honest, have a look https://github.com/jeremyjaymes/charlene.

I’ll write a more comprehensive post regarding this version but here’s what I’ll say for now. The theme has been completely reworked from top to bottom, this is not to be considered an upgrade from V1 or older. It is however very similar with most of the same features so the transition should be fairly painless.

Here’s what’s on tap:

• HTML5 and Responsive
• Post Formats Included
• No more theme options
• A few sensible customization options using the theme customizer
• New default font
• Same content focused layout

You can see the demo here http://papertreedesign.com/themes, it will be updated as I push new changes.

Which brings me to my next note. As mentioned above it is available on GitHub and I have enabled support for the GitHub Updater, so if you’re feeling brave and would like to give it a go please feel free but I do not recommend running it on a production site just yet. That said, if you do happen to play around with the theme a bit I would love to get your feedback, you can email me jeremy[at]papertreedesign.com.

That’s all for now.

Update 7/30/2014

I’ve been pushing some pretty steady updates over the past week, we’re getting closer. If anyone out there has taken the leap and activated the theme I’d love to get your feedback.

Update 09/10/2014

Charlene V2 is now considered stable. I’m hoping to have it approved for .org within the next week or two but for now you can grab a copy here and/or see a demo here. All feedback is welcome and appreciated!

Why?

Not all page titles are as simple or as identifiable as “About Us” or “Home Page”. More often they’re carefully crafted and even a bit lengthy. For example, about us becomes “Our Amazing Widget Company Employs Only the Best and the Brightest.”

Now imagine you’re a busy site admin, in fact site admin is only one of your many roles. It’s been a few weeks since you last logged into the site, you’ve got a handful of edits ready and you need to move quickly. You gather your edits, login and head over to the pages screen.

Hmm, wait, what’s our about page titled again? Which one is the home page? Now you’re opening tabs, clicking quick edit to check page slugs. This is taking a bit longer than I’d hoped.

This plugin, in my opinion, creates a simple solution. It adds a single meta box to the page edit screen allowing you to tag the page with a simple descriptive label. That label is displayed in a custom column so that you the developer and your site authors can quickly jump in and identify the pages that need editing.

Interested? You can find it here https://github.com/jeremyjaymes/custom-page-labels

The screenshots should clear up any confusion.

Oh and this is the first WordPress plugin I’ve put for public release, go easy on me. I welcome your comments and questions.

I do plan to submit it to the plugin repository in the near future I’d just like to make sure I have ample time to review before doing so.

Lastly, if you’re interested in receiving occasional updates about development, new releases and upcoming projects, consider signing up for my newsletter.

e.g. Click to Download | PDF

Background: In this particular example our Case Studies are going to be a custom post type and the file attachments (downloads) are going to be added to each individual custom post type using custom fields. These custom fields are generated using the excellent Custom Metaboxes and Fields for WordPress.

This bit of information is important because by using Custom Metaboxes and Fields we are able to easily retrieve the attachment ID, which is what we really need to make this work. (see this example)

So, keep that in mind, the following can be used as long as you have that attachment ID.

Explanation: The above assumes that we’re in a loop of some sort and have already retrieved our attachment id, e.g. $file_id = get_post_meta( get_the_ID(), '_my_download_id', 1).

Then we use wp_get_attachment_url( $file_id ); to get the url for our attachment. We need this to generate the actual download link but we also want to save it as a variable so that we can use it in the wp_check_filetype( $file_url ) function. wp_check_filetype() returns an array of values containing the extension and mime type.

We then use the $filetype variable to output the extension with $filetype['ext'].

I might expand on this a bit more in the future to explain in detail how this was used but there should be enough there to be potentially useful.

As WordPress developers we have a handful of methods at our disposal to recover that ID  but those options are not always that easy to explain to our clients.

So let’s make it easier.

Solution: Add the Tax ID as a custom column in the WordPress admin.

In the first function we set up our new column with the header “ID”. We decided to filter the entire default list since you’ll notice that we also omitted the standard description column. For our particular use case we would not be using taxonomy descriptions so we decided to reduce the column clutter and remove it all together.

In the second function we go ahead and return our taxonomy ID for use in the new custom column.

Finally we use the appropriate hooks for adding and managing our custom columns.

The sortable column may not be useful as it just sorts the taxonomies by ID but I’ve included it here none the less.

In the end you end up with something like you see in the screenshot on the right, a much easier method for retrieving the ID associated with individual custom taxonomies.

Specifically I needed to add itemtype=”photo” to thumbnail images associated with a “Place” in a custom place listings template but these are implementation specific details that will vary based on your needs.

As it turns out, adding microdata to WordPress thumbnail images using the_post_thumbnail function is actually quite easy. You can accomplish this by using the $attr parameter of the_post_thumbnail function.

In the example below “image-size” is the required thumbnail size parameter and itemprop is the microdata attribute pair specified in the $attr parameter.

Again, these values will depend on your requirements.

This is a very simple, no frills implementation but it get’s the job done.