Sunlight Foundation

TL;DR I want to write a new CMS and force people to use Markdown. Should I?

As Ali mentioned in a previous post, we are embarking on an effort to redesign and reorganize SunlightFoundation.com. Part of the reorg involves consolidating our "brands" back under the Sunlight Foundation umbrella so that our content reflects what we do and not our organizational structure. The plan is to merge our existing labs and reporting blogs into technology and reporting channels on our main blog.

With this, though, comes some major technical challenges. One such challenge is having to merge content from a myriad of existing CMSs. We have one blog running on our own django-blogdor application, another running a forked version of django-blogdor (don't ask), and two more blogs running WordPress on the backend but using django-wordpress for the public facing Django-based site. Once the blogs are dumped into an Atom-based format (with custom elements for additional metadata) they can be reimported into the new content management system. What that system will be is a decision that causes me constant angst.

We could just use WordPress like we are now where a private instance is used for authoring and Django pulls from the WP database for presentation on the public site. There are some requirements that would require us to develop WordPress plugins to keep track of additional metadata and make an internal version of django-wordpress that is aware of the plugin tables. To make things even more complicated, there isn't a good way to map Django models to WP tag/taxonomy tables since Django models cannot handle compound keys. This results in quite a bit of database overhead when tags on a large number of posts are accessed. Another option would be to take this a step further and create a generic RESTful API around the WP database that our public site can use. This approach, which would allow us to swap WordPress out for other blog engines at will, is being used by Talking Points Memo.

But if we have to do all of this development just to use WordPress as a backend content store, why use it at all? Why shouldn't we just reinvent the wheel and write our own CMS? The actual management of content isn't hard; django-blogdor can do this just fine and would require only minimal improvement. The hard part, which WordPress does well, is the authoring interface.

Ah, the authoring interface. That brings us to the biggest source of contention. Whenever I discuss this project with the rest of the organization, I'm always told that a WYSIWYG editor is crucial. While I understand the need to insert media and add headings, I'm less sympathetic to other forms of visual styling such as the changing of font colors. I find myself increasingly convinced that content creators should be using Markdown to author their posts in a tool that has WYSIWYG-like helpers for inserting chunks of markup or HTML. Not only does this produce cleaner HTML that is more fault tolerant to future changes, but it creates a clear separation between the creation of content and it's visual display. Plus Markdown is just easy; you can pick it up in a few minutes. More complicated visual needs can and should be handled by our design team or built into the CMS. I want to free our authors from having to worry about presentation and focus on what they do best, writing good content. How considerate of me!

So I come to you, dear reader, for advice on what we should do.

• Am I being unreasonable here with my urge to write yet-another-CMS? Feel free to tell me to shut up, suck it up, and make it work with WordPress.
• Is it snobbish and elitist to expect content creators to use either Markdown or learn HTML rather than use a WYSIWYG editor?
• Any better suggestions?