My old theme Twenty Twelve was getting a bit long in the tooth. Moreover, I had customized it extensively by direct editing, and that led to tiresome diff/search/replace exercises whenever WordPress released an update. So during the last week I gradually moved first this blog and then my static website over to Twenty Sixteen. This is another official WordPress theme, meaning it’s reasonably well-made and well-supported, including by Jetpack and other plugins. The look is quite similar to Twenty Twelve, and this time I added my usual batch of tweaks through a proper child theme.
These changes are also much fewer, as I’ve given up trying to fight either the theme’s built-in layout sizes or its use of Google web fonts. The latter are ubiquitious today and evidently most people don’t mind the extra bandwidth hit. Twenty Sixteen has some fine choices, too: Merriweather, a beautiful serif font, for body text; Montserrat, a stark sans-serif contrast for headlines; and Inconsolata, a blatant Consolas clone, for monospace text. Moreover, the fallback for Merriweather is Georgia which is my own local preference anyway.
Quirks & Observations
I did encounter some issues while installing and customizing Twenty Sixteen (version 1.4). Here’s a quick rundown for readers who consider this theme for their own blogs.
Syntax Highlighter MT — Twenty Sixteen apparently broke my existing syntax highlighter on mobile browsers. Turned out the plugin was out of date and abandoned. As described in the linked post, I replaced it with Prism.js via Prismatic. This appears to work fine, and is so simple to use that I also activated it on the static website.
Non-Scrolling <pre> — With the syntax highlighter out of action, I got a chance to see raw <pre> blocks – and noticed that Twenty Sixteen misformats them by default. Incredibly, style.css includes the following double declaration:
pre {
…
white-space: pre;
white-space: pre-wrap;
…
}Of course white-space can have only one value at a time, so pre-wrap immediately overwrites pre, causing <pre> blocks to use word wrap rather than a horizontal scrollbar! You must override this in your child theme to restore proper functionality.
Noisy <code> — Twenty Sixteen highlights <code> tags with a padded gray background. While not bad looking in itself, this creates a lot of visual noise if you frequently intersperse coding terms with regular text, as I do. So I moved this highlight from <code> to <kbd> which I use for documenting GUI elements. The extra visibility is helpful in that case.
No Excerpts — I like showing only excerpts on the home page and on category pages, automatically generated by WordPress via the_excerpt(). Twenty Sixteen flat out does not support this, not even through a child theme as far as I can tell. Oh sure, there’s a function twentysixteen_excerpt that you can override to force showing an excerpt whenever you like. But Twenty Sixteen will always show the full post below that excerpt regardless!
I found the solution in this post: you must directly edit template-parts/content.php in the original Twenty Sixteen directory. Don’t just copy & paste the code in the linked post, though: it’s outdated and needlessly duplicates code in the if/else branches. The branches should only comprise the first statement, replacing the_content with the_excerpt in the else branch. The wp_link_pages call doesn’t change and can reside after endif.
Full-Width Text — On a wide display such as a desktop browser, Twenty Sixteen normally reserves a generous left margin for the byline. You might never guess that this format depends on the post type! If the main <article> element is tagged type-page rather than type-post, the extra left margin disappears and the byline relocates to the bottom of the article. I found this trick very useful when leveraging the theme for my static pages whose lengthy articles can well use a wider line length.
Byline Issues — Annoyingly, the relocated byline for type-page articles uses a similar formatting as for type-post: entries appear below one another, rather than side-by-side as would be appropriate. This seems to be simply a bug since entries are divided by slashes on type-page, indicating they were intended to reside side-by-side.
I’ve fixed this in the XSLT that generates my static pages by emitting just one <span> containing all desired entries formatted manually. That way I could also show an updated entry which Twenty Sixteen internally defines but never displays, apparently because the authors didn’t get around to write a proper display format.