Note: I’m not maintaining this open source project anymore. There was a pretty cool reception to it and I didn’t have time to maintain it for just myself. I still think it’s a good idea, though. 🙂
About five months ago I left the riveting world of WordPress development for the greener pastures of helping a government startup manage its website, and while I’ve become pretty taken with Jekyll lately, there will always be a part of me that loves WordPress. And so, like a good hacker, I started a side project I’m calling rePress (a name that, admittedly, needs work—see below).
The first two of these solutions are WordPress plugins, and the second generates content from an API. This combines the two ideas by creating generator plugin for Jekyll sites that relies on the REST API currently being integrated into WordPress Core. Right now that API is only available as a plugin, but it will one day (soon, I think) require only a clean WordPress installation.
Once you have the API exposed, you need only point Jekyll to the root endpoint and run jekyll build on your server or your local environment. Right now it will grab the 9 most recent posts and parse out the published title, date, tags, authors, and excerpts, and, of course, the post content and generate HTML files with proper Jekyll frontmatter. This has a couple benefits: it allows you to import your WordPress posts without exporting any files and it allows you to choose whether to write Jekyll Markdown or use the WordPress editing interface.
It definitely has a long way to go, but it’s something I’ve been excited about creating pretty much since the REST API project was first announced. I’ll be pushing updates to GitHub, and would love any suggestions you have. In particular, I kind of hate the name I came up with, but all the original ideas like JekyllPress, StaticPress, and Hyde all mean other things related to Jekyll and WordPress. So here I am, with a name that means subdue by force which is not at all what this does or is intended to do. I’m open to name suggestions but know that it’ll probably change at some point.
I ended up working from home today. Even though I probably could have made it up the less-icy-than-expected hill our apartment is on by bike, I like working from home and the weather was a convenient excuse. I like it because my internet connecting is always surprisingly faster than dealing with the arms race-like environment of enterprise WiFi and I get to choose how much to interact with my co-workers and how much to focus.
One of my favorite parts of working form home is my turntable. At the office it’s really easy to sit for more than two hours with on my figeting in the desk chair for movement. I have Rdio on blast when I’m trying to ignore the din of my surroundings and to facilitate that developer hyperfocus we all know and maybe love. At home, I have Rdio too, and I have my full iTunes library which is cool. But I also have a turntable that forces me to get up and stretch my legs once every 22ish minutes. I also get to listen to the same artist for a stretch.
The timesavings are probably negligible. On the one hand records don’t buffer and playback isn’t beholden to someone else’s UI decisions. But the time spent on those things is balanced (or possibly overtaken) by gawking at the record collection looking for the next sheet of vinyl to spin. But the real advantage is in taking my eyes off of my screen for a few minutes a couple times an hour. I pop on the record and by the time side A ends I’ve either been productive or gone down a rabbit hole. If the former, I get a break to digest what I did before transitioning to the next thing; if the latter, I get a chance to rescue myself. Either way, I get a brief mode switch. Flip the record and repeat.
I can’t work from home everyday, nor do I really want to. In light of that,
I’m hoping to find a way to recreate this cadence at the office.
I’ve been thinking a lot about static site generators lately. We use Jekyll at 18f, a generator platform I had previously only used in the context of Octopress and very briefly and fleetingly at CFPB. My past life as a
WordPress developer effectively ended in September when I began shifting careers a bit to go back to my pervious role of hybrid communications-web developer, and begin a new adventure building a full website without a CMS, without a database.
The most challenging part of this has been thinking about data and content first. In my experience developing on WordPress a request to put something new into the website usually involved one of two things: adding more custom fields and relying on the intentionally lackluster UI to accomplish that, or creating a new menu on a wp-admin screen. If you’re going the latter route you have to think about form validation, design, and what the appropriate method for saving might be just when building the menu. Displaying the saved content to the user requires a whole other step of ensuring you have the right information coming
out of the database.
Jekyll (which I’m using as a stand-in for any static site generator) simplifies that whole system by abstracting away the UI altogether. Let’s use guest authors as an example. Here’s the problem: you have an author on a blog post who is not a regular contributor and maybe they’ll never write a post again. In WordPress I’ve seen this problem solved two ways:
Create a new user in your system, give them a minimal role, and assign post authorship ex post facto
Create a custom field called, e.g., guest-autho and use template logic to replace the name in the byline
Both of these have problems. In the first, you’re adding users with no relationship to the rest of the site. In the second, you’re adding extra data
to a post, and confusing data at that. Either way, the semantic representation of the post in the database is messy.
How to approach this in Jekyll? The easiest way is to just use the author’s name in the author field of the post front matter. But this solution is not
without it’s problems either. On the 18F site we keep all our team members in a long YAML file inside the _data directory and we reference post authorship out of that file and wrote a little Jekyll plugin to fill in their full name and (maybe someday in the future) extra information about the author. If we have guest authors we have to break that pattern or write logic into either the template or the plugin to address it.
In this example, both WordPress and Jekyll fail to give you a perfect
solution. On the one hand, WordPress (and most CMSs) give you that “about the author” information out of the box, especially if you go with option 1. But in exchange you get a new problem Jekyll’s minimalist, database-free paradigm seems to answer: authors needn’t relate to any part of the system except the posts they author.
I’m not sure which is best. I loved hacking away at WordPress even when it drove me mad. It gives you 90% of what you need out of the box, and querying a database is convenient, especially if you’re site is really complex. By not having a database, Jekyll forces you think broadly about what data you really need for a post and for your site because everything is built before a user loads their first webpage. As we’ve scaled 18f.gsa.gov
from basically a blog to a more functional site, these questions haven’t held us back as much as they have forced us to think differently about the problem.