In this episode, your humble narrator reveals himself to either be stupid or brilliant.
As some of you guys know by now, unlike every other sane person out there, I don't use WordPress for my Web publishing needs. Rather, I use what was once a very competitive product called Movable Type. There has been a lot to like about it, and that's why I've stuck with it in the face of almost total abandonment of the program by the blogosphere.
So why has just about every blogger drawing breath and with a body above room temperature opted for WordPress over Movable Type? Blame the way MT passed through the hands of a number of different owners, and ended up having its open source version dead-ended in favor of a commercial-only licensing scheme. I'm now stuck on the open source version of MT — one that has no upgrade path save for paying a $600 license fee (for a five-user license, four users of which I will never use) or moving to ... WordPress.
OK, what's so terrible about WordPress? Mostly, it's the way WordPress handles — or rather, doesn't handle — static files. It doesn't really have a static publishing solution; instead, it has a caching plugin that creates a static cache for the site, and serves that. I've toyed with this and found that it works very well for some things and very badly for others, mainly because at its core WordPress assumes everything is dynamic.
With support ending for my version of Movable Type, with WordPress being not as viable as I'd like as a migration target, and other solutions like Ghost (which, from what I can tell, also doesn't do static publishing) being too new and unformed to consider or just plain user-unfriendly, I'm now contemplating the unthinkable: roll my own solution.
Here's my rationale, which is either eminently sensible or hilarious. The amount of work required for me to make Movable Type do what I want is, on a man-hours perspective, not much smaller than creating something from scratch that does do what I want, that is actually documented (the docs for MT's innards are years out of date, horribly opaque in the "the source is the documentation" vein, and, well, terrible) and is in a language I actually understand and would care to develop with (Python rather than Perl).
A number of existing static-blogging solutions do exist for Python, but they're built mainly for the command-line set. I can drop back to a command line if I elect to, but I honestly don't want to do it for my daily blogging needs. I get why people would want to store posts in individual files rather than in a database, but again, that's not how I want to do it. (I'm also not the biggest fan of Markdown.)
To that end, work has started — slow, intermittent work — on making this happen. I've created a GitHub repository for the project, tentatively titled "MeTal" (ha!), with commits to come once I have a minimum viable product.
Will this result in something that other people will want to use? Maybe. Open source software is the history of scratching one's own itch, and if there turn out to be even a dozen other people who are itching for something that's along the lines of what I'm coming up with, great. But the one thing I know for certain is that nobody else is going to dig me out of the hole I'm in. It's time to grab a shovel.
Here are the goals I'm aiming for:
- Pure Python. No binary wheels, no external dependencies, no other libs needed, no need to create a virtualenv and install packages. Unpack and go.
- Friendly GUI and powerful command-line both available. (Distraction-free editor for that full-screen feeling, too.)
- Runs locally or remotely. Host on a server, or keep it on your local machine and sync changes elsewhere.
- You choose where you want your data to live. Page data can be kept in the database or synced with external files. Same with themes and templates.
- Static publishing. (Dynamic may be added later, if there's a real need for it.)
- Queued building behavior allows for scaling to many thousands of pages with no more effort than if you were running a dynamically built site.
- Media management is built-in, but optional.
- Tagging, categories, and search all included, but also optional.
- Minimal attack surface. Single point of function entry for all actions, so you don't have to secure a bunch of different scripts. You don't even have to run it on your web server; you can run it locally and rsync the changes. (Some functions, like tag search, require an instance running on a server.)
- Works with MySQL, SQLite, or other backends thanks to the peewee lib.
- Manage multiple sites and multiple blogs within sites from the same installation.
- Theming and templating engine.
- Plugin architecture with a host of common and useful plugins included (e.g., Disqus comments, Google tools, etc.)
- Granular permissions to allow people to post but not edit, or edit but not change settings.
- Change tracking for all objects.
- Key/value store for objects, so that you can associate arbitrary data with objects.
- MIT licensed, so you can go buckwild with it in your own projects if you like.
(Crazy, they called me. They all laughed when I sat down at the keyboard ... )