When I started using Chinese characters on this blog I quickly ran into several issues:
WordPress incorporates actual Chinese characters into permalinkse.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.
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.
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!
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.
I use GitHub for source control but don’t always want to publicize everything I am meddling with. GitHub offers private repo plans but since I’m usually not working with anyone else the economics of it don’t make sense for me.
Thankfully, it’s not hard to use Git and Dropbox to host private repos. This tutorial is short and sweet and worked beautifully for me. If you prefer something with a bit more explanation this post might suffice, or perhaps you’d like to check out Stack Overflow. At any rate, it’s not hard to get up and running—and now I have a good excuse to learn more command line Git!
Recently I noticed that pinyin tone marks weren’t rendering properly on my personal blog. The requisite characters did not appear to be included in the Google web font that I was using at the time. As such, my browser was falling back to whatever font listed in my font stack happened to contain that character. The result was a bit of a jumble, not something especially noticeable, but certainly of concern to anyone interested in web typography and Chinese language blogging.
Even so, I tried out most of Jetpack’s features, hoping to like at least some of them. After all, since Jetpack is actively developed and maintained by Automattic there is less of a need to vet each module as I would usually do with plugins by unknown authors. I was also curious about what sort of functionality would be included in such a super-plugin—perhaps there would be something useful in there that I hadn’t seen any need for before.
In the last few weeks I’ve experienced glitches in n the WordPress admin panel. Symptoms: post contents fail to load in the editor, toolbar and slug aren’t visible, taxonomies refuse to update, media library freezes on image upload, and so on. Very annoying, especially as it only happened some of the time.
I traced this back to script loading, specifically jQuery. The fix? Easy. Just add this to wp-config.php:
define( 'CONCATENATE_SCRIPTS', false );
Of course, I’d like to know what is really going on here, but since I have a hard time isolating the issue (sometimes it happens, sometimes not), I’m just going to go with this quick and dirty fix. I have also updated my WordPress configuration file boilerplate to include this setting.
Synaptic/dev is a technical blog focusing on web design and development. GitHub is home to all my open source software projects; open an issue over there if you're having any trouble or find me on Twitter for quick inquiries.
Drop down to the root of this domain and visit Synapticism to have a look at my more personal blog.