This category features technical writing of a somewhat more in-depth nature than you'll find under "notes".

Roll your own SVG sprite sheets with Bower and Gulp

In this article I will show you how to integrate a custom set of open source icons into a project using Bower (a front-end package manager) and Gulp (a command line task runner). This isn’t exactly the sort of tutorial where you can copy and paste a bunch of code and get up and running—it is more a collection of working notes and scraps of code meant to point you in the right direction. I will assume readers have a basic understanding of modern front-end development tools and the command line. I happen to be using WordPress and PHP to implement the markup but also include some vanilla JavaScript that could be adapted for use pretty much anywhere.

Continue reading →

Getting up to speed with responsive images and Picturefill

This week I have challenged myself to get up to speed with responsive images and Picturefill, a polyfill for the upcoming HTML5 picture element as well as two new attributes for the img element. It wasn’t easy—there’s a surprising amount of reading and processing that needs to be done to understand the many problems and proposed solutions to responsive images on the web. Along the way I realized that I am not yet hugely interested in the art direction use case—which means I have focused more of my time on two less hyped img element attributes, srcset and sizes. Together these provide for most of what I am interested in: swapping source imagery at different resolutions.

Continue reading →

Adding term descriptions to the quick edit box in WordPress

Writing term descriptions for categories, tags, and custom taxonomies can be a real chore in WordPress. It is easy enough to edit term names and slugs with the quick edit box but if you’d like to edit descriptions it will be necessary to open up the full edit screen. This is less than optimal if we wish to write or maintain complex taxonomies with dozens or even hundreds of terms.

WordPress is highly customizable and extensible so there’s a way of making this easier. Of course, this being WordPress, things aren’t nearly as straight-forward as they could be. The problem, in this case, is that you cannot hook the quick_edit_custom_box action without the presence of a custom column. Since description is among the default columns this action is not called and there is no opportunity to modify the contents of the quick edit box. The current solution (as of version 4.0) is a bit of a hack: use a hidden custom column to trigger the quick_edit_custom_box action and output the necessary HTML.

Continue reading →

WordPress term descriptions in Markdown

Recently I wrote a little about using Markdown and WordPress together. This time around I’d like to share some tricks for using Markdown in term descriptions.

But first, a recap. Terms, in WordPress jargon, are objects in a taxonomy—a system of organizing content. WordPress ships with categories (which I don’t use) and tags (which I do—extensively). You can also implement custom taxonomies to organize content in whatever way you wish. I happen to organize some of my posts into series and many others by location but the sky’s the limit as far as custom WordPress taxonomies are concerned.

Continue reading →

Two simple Chinese language functions for bilingual WordPress blogs

When I started using Chinese characters on this blog I quickly ran into several issues:

  1. WordPress incorporates actual Chinese characters into permalinks e.g. the slug for a post titled ‘Wuchang temple 武昌宮’ will be武昌宮. This works well enough but isn’t great if you prefer URLs that are easy to remember and type.
  2. Pinyin tone markings aren’t available in most fonts. If you use pinyin in post titles your content will typically end up looking rather ugly, both on your blog (if you aren’t using a header font with the requisite characters) and on the rest of the web (whenever your content is shared).

In WordPress there are all kinds of different ways to approach problems like these. I am generally interested in a parsimonious solution that doesn’t involve a plugin or a lot of extra code. I’ll readily sacrifice perfection for “good enough”. Here’s what I came up with…

Continue reading →

Markdown in WordPress

Markdown is an awesome shorthand system to format text on the web. I have been using it for slightly more than a year now and absolutely love it. Peruse the syntax and you’ll see why—it’s easy to pick up and builds on many existing patterns of usage.

Using Markdown with WordPress is fairly straight-forward. You’ll need a plugin, of course, and there are many to choose from, as always. I currently use JP Markdown, a repackaging of the Markdown module from Jetpack, Automattic’s sprawling mega-plugin, which I am otherwise not interested in using.

Continue reading →

Local development with Bower

Recently I extracted a library of Sass mixins from one of my existing projects so that it could be reused in some of my other projects. Since I already use Bower to manage front-end dependencies I followed this guide to register my library as a Bower component, which isn’t very hard to do. Next, I added my library back into the original project by executing bower install [project].

Bower only recognizes released versions (i.e. those that have been tagged). This is fine if your component is tested and ready to ship but somewhat problematic if you wish to continue developing it locally, as I do. This article introduces bower link, a command that creates a symlink between locally developed Bower components and any other local project using Bower. Usage is easier than the somewhat arcane documentation would suggest; simply run bower link from the root directory of your new Bower component and follow up with bower link [project] from the root directory of whatever other project you’re working on.

Downgrading WordPress alpha from nightly builds to the latest stable release

Recently I noticed that one of my WordPress blogs was running an alpha version, automatically installing nightly builds. It seems I am not alone in noticing similar behavior, though I don’t think I was affected by the exact same bug.

At any rate, since I am not actively testing WordPress I went looking for a quick way to downgrade to the latest stable release without manually re-installing everything. I found this article, which offers a succinct solution: open up wp-includes/version.php and modify the $wp_version string to 3.9.1 (or whatever the stable version number is at the present moment). Back in the WordPress admin panel simply navigate to Dashboard > Updates and click Re-Install Now.

Dashicons on the WordPress front-end

Dashicons is an icon font designed for use on the WordPress admin panel. You may be tempted to use these icons in front-end theme and plugin development—after all, it’s easy to include Dashicons as a dependency when enqueuing your stylesheet.

There are several problems with Dashicons, however. Steve Ush has penned an excellent critique after opening an issue on GitHub outlining some of these problems, most of which pertain to the non-standard use of default CSS and various quirks of sizing and alignment. The authors of this icon font don’t seem to really grasp what the problems are—or maybe it is the WordPress community that is out of touch, recommending Dashicons for use on the front-end where it doesn’t belong. After all, one of the authors outright says it’s not intended as a general use icon font in this comment. (This might not have always been the case; see this Make WordPress thread for further discussions of Dashicons in the lead-up to version 3.8.)

The truth is that Dashicons are optimized for use in the WordPress admin panel, not the front-end. You are, of course, free to use this font in the front-end, but I would not advise it, particularly not with all the other options out there (check out Font Awesome, Genericons, Fontello, or IcoMoon for some options). The default CSS is annoying to override and there’s no real help for the weird alignment issues. There are, perhaps, a few valid use cases like this one, but on the whole there’s no advantage to using Dashicons on the front-end despite it being baked into the WordPress core. Just because it’s there doesn’t mean you should use it.

WordPress theme development with Gulp, Bower, and Sass

Update February 2015: this post is now out of date as the starter kit has evolved. I’m working on a new post to explain all the developments; in the meantime please check out the original repo on GitHub. Thanks!

WordPress theme development is remarkably more efficient with Gulp, a Node-based build system and task runner similar to Grunt. Gulp has been widely hyped in recent times—and no wonder, it’s a major time-saver. I found out about Gulp by way of this excellent introduction by Mark Goodyear, later adapting the build script in this post by Matt Banks for my own use.

Since then I have refined my workflow to the point where I figure it might be helpful for me to share my approach with the WordPress community. With this in mind I have prepared this starter kit (with source code on GitHub) to demonstrate how you can use Gulp with Bower and Sass to optimize your WordPress theme development workflow. This starter kit does not contain any actual WordPress theme files—it is meant to act as the scaffolding that surrounds your theme and supports your workflow.

Continue reading →