Adding page sidebar to WordPress Twenty Seventeen theme.

The WordPress Twenty Seventeen theme was exactly what I needed to update the look and feel of the Visible Orbit project website, except for one thing: No sidebar on pages, only posts. For  the Visible Orbit website, having the site information and navigation visible on the page-heavy site is quite important:

Getting the sidebar to show on pages seems to be a popular question online. Besides just hacking the source, the only nicely packaged solution is this plugin by Joachim Jensen. However, for that to render correctly, you have to set page layout to “one column”, but that setting is exposed only if your front page is static, which is not the case for the Visible Orbit site.

Enter Twenty Seventeen VisOrb, a super simple child theme I made for the project which is able to fix this issue even for sites with “latest posts” as the front page, the WordPress default. Simply unpack the whole twentyseventeen-visorb directory in your wp-content/themes folder, and select the theme from the Appearance – Themes menu.


Publish to WordPress with Emacs 24 and org2blog

I’ve recently discovered the absolute joy that is writing and publishing wordpress blog posts using Emacs 24 and org2blog. Because it took me a while to get everything (including source code syntax highlighting by the WordPress SyntaxHighlighter plugin) going, I wanted to document the whole procedure step-by-step, using org2blog of course!

I’m using Emacs 24.3 (from the PPA) with Prelude on Ubuntu 12.04.4.

Installing required packages

org-mode is already installed in Emacs 24 with Prelude. However, we need to install org2blog and some extra dependencies.

M-x package-install RET xml-rpc
M-x package-install RET metaweblog
M-x package-install RET org2blog
M-x package-install RET htmlize

metaweblog and xml-rpc are two direct dependencies of org2blog. htmlize is to support the syntax highlighting of source code by SyntaxHighlighter on WordPress.

Configuring Emacs

I added the following to my ~/.emacs.d/init.el. Read the comments, copy and modify!

Note the org2blog/wp-use-sourcecode-shortcode variable: If you set this to nil, Emacs and org2blog will pre-colour your source code blocks in HTML and upload that. If you set it to =’t=, org2blog will make use of the SyntaxHighlighter Evolved shortcodes, meaning that the WordPress plugin, if installed and configured correctly as shown in the next section, will be used to syntax highlight.

Option 1 is the easiest, but the colours in option 2 are often more readable. If you’re taking option 2, make sure that your org2blog is newer than 2014-05-26, as there was a bug in the HTML encoding of certain characters.

;; default is ~/org/ — I’m putting orgmode’s default dir with my other notes
(setq org-directory "~/sync/notes/org/")
;; and you need this, else you’ll get symbol void errors when doing
;; fill paragraph
(setq org-list-allow-alphabetical t)

(require ‘org2blog-autoloads)
(require ‘netrc)

;; in my ~/.netrc/ I have:
;; machine wp-cpbotha login my_username password my_password
;; machine wp-vxlabs login my_username password my_password
;; so let’s parse out each of the lines into a separate variable
(setq wp-cpbotha (netrc-machine (netrc-parse "~/.netrc") "wp-cpbotha" t))
(setq wp-vxlabs (netrc-machine (netrc-parse "~/.netrc") "wp-vxlabs" t))

;; I want to publish to both and
(setq org2blog/wp-blog-alist
:url ""
:username (netrc-get wp-cpbotha "login")
:password (netrc-get wp-cpbotha "password")
:default-title "Hello World"
:default-categories ("org2blog" "emacs")
:tags-as-categories nil)
:url ""
:username (netrc-get wp-vxlabs "login")
:password (netrc-get wp-vxlabs "password")
:default-title "Hello World"
:default-categories ("org2blog" "emacs"))))

;; has half the instructions, but was missing
;; `wp-use-sourcecode-shortcode` at the time of this writing, without
;; which this does not work at all.

;; * `M-x package-install RET htmlize` is required, else you get empty
;; code blocks
;; * with wp-use-sourcecode-shortcode set to ‘t, org2blog will use
;; shortcodes, and hence the SyntaxHighlighter Evolved plugin on your blog.
;; however, if you set this to nil, native Emacs highlighting will be used,
;; implemented as HTML styling. Your pick!
(setq org2blog/wp-use-sourcecode-shortcode ‘t)
;; removed light="true"
(setq org2blog/wp-sourcecode-default-params nil)
;; target language needs to be in here
(setq org2blog/wp-sourcecode-langs
‘("actionscript3" "bash" "coldfusion" "cpp" "csharp" "css" "delphi"
"erlang" "fsharp" "diff" "groovy" "javascript" "java" "javafx" "matlab"
"objc" "perl" "php" "text" "powershell" "python" "ruby" "scala" "sql"
"vb" "xml"
"sh" "emacs-lisp" "lisp" "lua"))

;; this will use emacs syntax higlighting in your #+BEGIN_SRC
;; <language> <your-code> #+END_SRC code blocks.
(setq org-src-fontify-natively t)

Optional: Configuring your WordPress to highlight lisp code

This is only necessary if you have (setq org2blog/wp-use-source-shortcode 't), i.e. you want your Syntaxhighlighter Evolved to do the highlighting.

There’s a lazy hack floating around that simply uses SyntaxHighlighter Evolved’s clojure support, but this yields results that are ever more ugly than what you see here.

Instead of that, we copy shBrushLisp.js (github) into your WP installation’s wp-content/plugins/syntaxhighlighter/ directory. Then edit syntaxhighlighter.php in that same directory, adding the following line with all the other third-party brush we_register_script lines:

wp_register_script('syntaxhighlighter-brush-lisp', plugins_url('shBrushLisp.js',__FILE__),array('syntaxhighlighter-core'),'1.0.0');

Finally, modify the brush aliases as follows:

$this->brushes = (array) apply_filters( 'syntaxhighlighter_brushes', array(
   'as3' => 'as3',
   <bunch of other aliases>,
   'lisp' => 'lisp',
   'emacs-lisp' => 'lisp',

Let’s publish!

Create a .org file. A minimal publishable file would look like this:

#+TITLE: Emacs 24, Prelude and org2blog and WordPress

Here is some text!

* Heading

Some more text!

Let's include an image:


Login to your wordpress installation with M-x org2blog/wp-login.

Before posting this to your blog, you can get a quick preview by doing C-c C-e h o or more verbosely M-x org-html-export-as-html. (On my setup, I hit the invalid function: org-with-silent-modifications bug at this point. To fix this, temporarily remove ANY org-mode config settings from your init.el, restart Emacs, then do a package-install package org to get the latest greatest, and then put back your temporarily removed configuration. See this post for ever so slightly more detail.)

You can now publish your post with M-x org2blog/wp-post-buffer, which will upload the post as a draft to your weblog. You’ll have the option of previewing the post via your WordPress site, and then using the usual WordPress mechanism for publishing that post. You can also post and publish directly from org2blog using M-x org2blog/wp-post-buffer-and-publish (or C-c p).

When you link to an image, that image will be uploaded to the WordPress media library and inserted into the post. BONUS! Here’s a screenshot of my Emacs editing this post:


Export Zotero PDFs with BibTeX key filenames

This is just in from the department of silly Zotero hacks:

I’ve recently started using the brilliant papercite wordpress plugin to publish a list of my academic publications. This is awesome, because I can just export my Zotero bibliography as BibTex, and hand the bib file over to papercite!

However, when one exports a bibliography from Zotero, the associated PDF files are exported with their full filenames (whatever these may be), whilst papercite expects all PDFs to be in a single directory, each named bibtex_cite_key.pdf, for example malan_voxel_2013.pdf.

Hmmm, how will we solve this?!

My precioussss bibtex citation key PDFs!

I know, let’s hack the Zotero translators/BibTex.js again!!

Around about line 2520 of BibTeX.js (this is with Zotero, in the function doExport(), you’ll find the following:

for(var i in item.attachments) {
    var attachment = item.attachments[i];
    if(Zotero.getOption("exportFileData") && attachment.saveFile) {
        attachment.saveFile(attachment.defaultPath, true);

Change it into the following:

for(var i in item.attachments) {
    var attachment = item.attachments[i];
    if(Zotero.getOption("exportFileData") && attachment.saveFile) {
        if (attachment.mimeType == 'application/pdf') {
            attachment.saveFile('/tmp/' + citekey + '.pdf', true);
        } else {
            attachment.saveFile(attachment.defaultPath, true);

After exporting any set of publications as BibTeX, with “Export Files” checked, you’ll find a tmp subdirectory in your export directory. This contains all of the associated PDF files, named according to the BibTeX citation key, which is exactly what papercite wants.

Let me know in the comments how this went!