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,
sizes. Together these provide for most of what I am interested in: swapping source imagery at different resolutions.
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.
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.
When I started using Chinese characters on this blog I quickly ran into several issues:
- WordPress incorporates actual Chinese characters into permalinks e.g. the slug for a post titled ‘Wuchang temple 武昌宮’ will be
http://synapticism.com/wuchang-temple-武昌宮. This works well enough but isn’t great if you prefer URLs that are easy to remember and type.
- 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…
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.
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.
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 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.
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.