This blog has been running on Pelican’s default notmyidea theme for a long time. It works, but the look is dated and there was no way to take real control of layout or navigation without forking the theme. I wanted three things: a real templated theme (so I can change structure later), a layout that actually surfaces a sidebar, and a color scheme I’d enjoy looking at. Molokai has been my editor palette for years, so that was the destination.
The result is what you’re looking at now: the gum theme from getpelican/pelican-themes, with two small upstream fixes and a Molokai overlay applied as a CUSTOM_CSS_FILES layer. No theme fork required.
Why gum
Gum is one of the older community themes in getpelican/pelican-themes. It uses the (now-archived) Gumby Framework for its 12-column grid, and it ships with jQuery 1.9.1 + Modernizr 2.6.2, so it is showing its age. What it has going for it is honest structure: a base.html, real Jinja2 templates for index, article, page, archives, tags, categories, and a sidebar — all in plain HTML you can read in an afternoon. That makes it a good starting point for someone who plans to edit the templates themselves rather than treat the theme as a closed box.
The sidebar wasn’t showing
The first thing I noticed after switching was that gum’s sidebar didn’t render beside the content. It rendered, just not where you’d expect. The cause turned out to be a simple math mistake in the upstream templates:
<!-- theme-gum/templates/index.html -->
<div class="row">
<div class="eleven columns"> <!-- 11 -->
... article list ...
</div>
{% include 'sidebar.html' %} <!-- includes a "three columns" div -->
</div>
The sidebar is a three columns div. 11 + 3 = 14, which overflows Gumby’s 12-column grid, so the sidebar wraps below the content instead of sitting next to it. The fix is to make the content area nine columns so 9 + 3 = 12 fits cleanly. The same fix applies to article.html.
After that the sidebar shows up exactly where it was always meant to — categories, social links, the lot.
Code highlighting: regenerate pygment.css with .highlight scoping
Pelican’s markdown extension wraps code blocks in a .highlight div. Gum’s bundled pygment.css uses no parent class prefix, which means its rules apply to any .c, .k, .s token on the page — not just inside code blocks. That’s the kind of scoping bug that explodes in subtle ways once you write inline markdown that happens to contain those class names.
The fix is one shell command. Pygments ships with a built-in monokai style — the canonical syntax-highlighting form of Molokai:
pygmentize -S monokai -f html -a .highlight > theme-gum/static/pygment.css
The -a .highlight flag prefixes every rule with .highlight, so the colors only apply inside actual code blocks. Drop-in replacement.
The site palette: a CUSTOM_CSS_FILES overlay
For the rest of the site I didn’t want to edit gum’s style.css or gumby.css directly. Editing the theme’s own CSS means every future change is a merge conflict with upstream, and it muddies what’s structural vs. what’s cosmetic. Gum exposes a much cleaner hook: the CUSTOM_CSS_FILES setting. Any path listed there is loaded after the theme’s own CSS, so the last definition wins.
The strategy:
- Keep
gumby.css,style.css, andpygment.cssexactly as gum ships them (modulo the.highlightregeneration above). - Drop one new file —
molokai.css— intotheme-gum/static/. - Tell
pelicanconf.pyto load it viaCUSTOM_CSS_FILES.
# pelicanconf.py
THEME = 'theme-gum'
PLUGIN_PATHS = ['plugins']
CUSTOM_CSS_FILES = ['theme/molokai.css']
The file lives at theme-gum/static/molokai.css, which Pelican copies to output/theme/molokai.css — hence the relative path theme/molokai.css in the setting.
The overlay itself
The full Molokai palette goes in as CSS custom properties, then a small set of selectors maps them to gum’s actual structure:
:root {
--molokai-bg: #272822;
--molokai-bg-soft: #3e3d32;
--molokai-bg-deep: #1b1d1e;
--molokai-fg: #f8f8f2;
--molokai-comment: #75715e;
--molokai-red: #f92672;
--molokai-orange: #fd971f;
--molokai-yellow: #e6db74;
--molokai-green: #a6e22e;
--molokai-cyan: #66d9ef;
--molokai-purple: #ae81ff;
}
html, body {
background-color: var(--molokai-bg);
color: var(--molokai-fg);
}
#banner h1 a { color: var(--molokai-cyan); }
#banner h1 a strong { color: var(--molokai-orange); font-weight: normal; }
#navigation { background-color: var(--molokai-bg-deep); }
#navigation ul li a { color: var(--molokai-fg); }
#navigation ul li a:hover,
#navigation ul li.active a { color: var(--molokai-green); }
a { color: var(--molokai-cyan); }
a:hover { color: var(--molokai-green); }
.entry-title,
.entry-title a { color: var(--molokai-cyan); }
.entry-title a:hover { color: var(--molokai-green); }
.three.columns h4 { color: var(--molokai-red); }
.three.columns ul li a { color: var(--molokai-cyan); }
.btn, .btn.primary { background-color: var(--molokai-cyan) !important;
color: var(--molokai-bg) !important; }
.btn:hover { background-color: var(--molokai-green) !important; }
.tag-row .label,
.label.danger { background-color: var(--molokai-orange) !important;
color: var(--molokai-bg) !important; }
code { background-color: var(--molokai-bg-soft);
color: var(--molokai-orange); }
.highlight { background-color: var(--molokai-bg-deep) !important;
border: 1px solid var(--molokai-bg-soft); }
blockquote { border-left: 3px solid var(--molokai-purple);
background-color: var(--molokai-bg-soft); }
table th { background-color: var(--molokai-bg-soft);
color: var(--molokai-yellow); }
::selection { background: var(--molokai-yellow);
color: var(--molokai-bg); }
footer#credits { background-color: var(--molokai-bg-deep);
color: var(--molokai-comment); }
A handful of !important flags survive in there because gum’s gumby.css sets a few colors at high specificity on .btn variants and label classes. Those are the friction points; everything else flows from the palette variables.
What it costs
I want to be honest about the tradeoffs. Gum is old enough that it carries some weight you’d think twice about on a green-field theme:
- jQuery 1.9.1 (2013) and Modernizr 2.6.2 (2013) are loaded on every page. The site doesn’t actually need them.
- Gumby Framework is archived. The 12-column grid still works; I just can’t lean on the upstream for fixes.
- The bundled icon font (Entypo) is mostly unused.
For a personal blog with six articles, none of that matters yet. If I later want a leaner JS footprint, I’ll strip those scripts out of base.html as a separate change — but the Molokai work doesn’t depend on it.
Making it reusable
The molokai.css file in this post is a drop-in for anyone running the gum theme. Copy it into theme-gum/static/molokai.css, set CUSTOM_CSS_FILES = ['theme/molokai.css'] in your pelicanconf.py, and you’re done. The two upstream fixes (the column-grid math and the regenerated pygment.css) are independent of the palette and worth applying even if you’d rather pick a different color scheme.
The full bundle — gum templates with the column fix, the regenerated pygment.css, and molokai.css — is published as a standalone theme repo at gitlab.com/rubackedup-com/pelican-theme-gum-molokai. MIT licensed, same as upstream gum. Clone it as your theme-gum/ and you’re done in two lines of config.
What’s next on this blog
This is the first commit on a longer theme-refresh branch. Next on the list:
- Untrack
output/and__pycache__/(legacy committed build artifacts) - Drop gum’s empty
Pagesheading in the sidebar when there are no pages - Add OpenGraph and Twitter Card meta to
base.htmlso link previews stop looking awful - Decide whether to strip the jQuery/Gumby JS payload
None of those block the Molokai work, which is what I cared about most.