joshua schachter's blog

I used to worry a lot about this too. Then I realized inside my painstakingly customized wordpress, the most useful thing i would do is compose html in textedit and copy-and-paste it in. And this seemed to work pretty well.

Comments are definitely an issue though.

The issues with editing in the browser have always frustrated me, which is why I became a fan of Posterous for editing. It allows me to move my editing to my text editor (Emacs) in a way that is rather fluid. In the past I focused on writing in things like reStructuredText and, more recently, org-mode, but generally using Posterous has been a nice place to draft blogs. My own system then pulls in the feed and adds them to a simple sqlite database. This happens using a simple cron job. Past that it is just a simple WSGI app using Mako.

One thing that I think makes the entire system work well is the ability to separate as you say. I've never been a fan of generating sites b/c there seems to come a point where that compilation step is too expensive or is required for minor updates. I think my system has actually worked out as a good middle ground in terms of avoiding more complicated dynamic storage, while still keeping the updating reasonable.

One idea I've tried in the past is to use something like XSLT in the browser for templating. The idea is to simply give the browser the resources and let it put things together. While in theory this seemed like a good idea, the lack of coupling made it really difficult. That is not to say one could use something like XSLT on the server (which I've also done), but generally it was simpler to use a data structure and a templating library like Mako than always working within a specific format such as Atom.

Good article!

I'd love to see some standard APIs defined for each of the areas you call out, then it would be possible to assemble the publishing platform that works best for each individual. Maybe some people want to edit in Google Docs, use a publicly available template to define style (there's no reason it necessarily to be 'installed' anywhere, just reference it by id and version), publish on their shared host, and manage comments with Disqus. Or whatever.

I recently ditched Wordpress for Jekyll which gets part of the way there. I use Git as the repo, edit with whatever I want (usually TextMate), handle comments with Disqus, let Jekyll do the generation/styling, and Nginx serves the generated content from a static directory on a VPS. I like it better than having one monolithic tool that does everything, but it would be nice if I could selectively switch out Git or Jekyll or Disqus with other components that offered the same functionality and honored the same API.

When I think of webhooks, I think of these kinds of loosely coupled pieces. You could easily build simple components for each that provide their own API, and use webhooks to connect them up. Standard interfaces can evolve after or alongside that.

WordPress isn't perfect, but it's a pretty good base for doing the sorts of things most people are probably looking to do with their sites. And as far as text-editing goes, the amount of work they've put into, ummm, "cleaning up" TinyMCE, is unmatched by any other platform.

I think the two problems people tend to have with WordPress are a) security and b) the lack of decoupling, as you mention. With regard to the former, many shared hosts like Dreamhost do automatic daily backups as well as automatic WordPress updates, so between those two things, you're reasonably safe. It's generally people who pay no attention to the specifics of their install/backup/update situation that get burned (and that's a lot of people). With regard to the decoupling, I use a plug-in called FeedWordPress which allows me to post entries from any system which can generate an RSS feed. Currently, I have Tumblr, Delicious, and Twitter plugged in there, but you could easily plug Posterous or anything else in as well. I like the setup because I don't feel like I'm manually touching WordPress every time I want to publish. I touch whatever I want to touch and FeedWordPress just sucks it all in via cron.

Once I started updating WordPress with Subversion, life became a breeze. It solves two problems---preserving a few minor edits I've made to core files, and single command update.

Though there are some good ideas in this post, it smells a little like you're throwing the baby out with the bathwater. Or maybe Maciej is.

Benefits to integration:

Authoring - integrated editor+publishing means I can preview a post exactly as it will look when it's published, in its template, with working extensions.

Storage - indexing is not complicated until you want to do quasi-dynamic things like tagging posts

Templating - it's hard to untangle this from authoring (for previews), extensions and plugins, comments, etc

Feeds - aren't they just another template?

Comments - I find it hard to believe after spending nearly 5 years helping people move their comments off Haloscan and into WordPress, people are advocating externally hosted comment systems again. Here's one benefit for integrating comment content with the post---it gets indexed by search engines, which almost always benefits me.

Anyway, my twenty-seven cents. ;)

I chose Flock for the authoring tool, mainly because you can drag images (from flock) into the WYSIWYG editor as you're writing your entry. Then Flock talks wordpress-XMLRPC to a bridge I wrote which stores the entries in atomojo.

The problems with that are 1) flock omits the paragraph html tags, since I guess it thinks WP is going to recreate them, and 2) atomojo kind of sucks. It is exactly designed for the kind of storage you're talking about, and then it serves the feeds (direct to atom clients, or to my blog renderer which takes atom as input). But it has a pile of security junk that was hard to work around, and it quietly replaces certain entry tags with its own values.

Anyway, the API for most of these pieces should be APP (http://www.atomenabled.org/developers/protocol/). Even if atomojo is funky, the formats and standards are fine. I look forward to replacing my atomojo database someday with some other APP-talking server and merely removing my id/slug workarounds.

Other features in my setup:
- a heavily-masked atom feed for clients that aren't logged into the private blog
- an independent comment system using RDF for the storage (so it can store comments on more than just blog posts, and it can cooperate with the security setup of the other tools)

I think one of the hard parts here is that a lot of us want to run our own, customizable apps on our own servers or cloud environments, while still being able to share plugins and not have to deal with upgrade/security hassles.

The other requirements you've listed are obviously technically doable on a variety of platforms, but implementing them would basically leave you on an unmaintained fork of an existing tool, and even the maintained trunks of (for example) WordPress aren't exactly bastions of good security.

Seems like if we had a good core for an update manager with fundamental CMS abilities, a healthy ecosystem would provide the rest of these features.

Oh, the other thing missing should be a lesson learned from Delicious: Templates ought to be "default public". Meaning, if I see a view of your blog, whether that's a feed or a customized template, I should be able to enter that URL and my blog tool will autodiscover your page's template and install it in my system. Thus, just like me tagging my links adds value for everyone, me customizing my templates adds value for everyone.

I've got a lot of these.

If you really want to own the stack and avoid client-side includes then throw in analytics, spam filtering, moderation, aggregation of feeds, and OpenID hosting.

I had the same problem! My solution was to fork pico blog for app engine and add tons of features. I am working on making it have close to the features of wordpress. At least in the common use cases of using it for blogging with popular social media plugins.

The first release just gets the app to work out of the box. I'll be releasing a new version soon with a plethora of new features. Hope you like it. Tell people please!

http://developeradvocate.appspot.com/id/2/AppEngineBlog-(AEB)-is-Born!

Memepool is a classic example of why a weblog doesn't need all that excessive Web 2.0 RSS-based crap.

I wish you'd resurrect it.