1. WordPress is very proud of its quick-setup process, and caching needs to be configured away from the defaults on a non-trivial number of systems.
2. Using caching makes your blog less dynamic. Things like "latest comments" don't update immediately across your site. Users who haven't explicitly installed caching don't necessarily understand why this isn't a bug.
So WordPress makes it really easy to install a caching plugin, and lets the tiny number of blogs that get enough traffic to need it install it themselves.
Though not written in Python, I'm a fan of Jekyll (https://github.com/mojombo/jekyll). You write your entries in Markdown, it converts them to HTML, sets up links and embedded content, and then publishes them to your server via Git to be served up by Apache, Nginx, etc.
When I last used Hyde, a few months ago, I liked it. But beware there are (were?) two very different versions of it, and the documentation is (was?) pretty weak.
It uses Jinja2. This is awesome but you will be confused if you don’t read the Jinja2 designers' guide.
I really like the simplicity of this approach. It reminds me of late 90s, when I used Makefiles to compile complex web pages from a set of templates.
But it seems like static site generators became a fad recently, like Rails a few years ago, and this makes me slightly skeptical. It's always suspicious when somebody claims there is only one right way to do something. When it comes to me, feel free to have a backend for your blog. This certainly has some advantages, just don't forget about performance.
I don't know if it's just a fad - what more is a blog backend with a cache plugin doing than generating static HTML?
It's more like the universally accepted "right way of doing things" being taken a step further. Why should the system that generates the HTML be the same one that serves it?
> But it seems like static site generators became a fad recently,
The year 1994 called and would like to talk to you about your backward flowing sense of time and fads. :)
In all seriousness... when the Web was born (on Tim Berner-Lee's computer) it was pretty much just static HTML reached by HTTP. Then folks added static file generation, optionally, behind the scenes. Then techniques like CGI to make it dynamic each request, typically from a C program or Perl script. Anyway... Turns out, not all old ways are bad. For certain use cases, just plain HTML-over-HTTP, totally static, works fine. And hard to beat it's performance and resource usage.
Fashion often returns, and this doesn't apply only to apparel. Thanks for a history lesson, but I never claimed this is a wrong approach, just not the only reasonable one.
There used to be Zine (http://zine.pocoo.org/) - it was basically WordPress in Python, but it never picked up sufficient community and now it's dead. Now, if you want a server-side blog in Python, the standard solution is to write one yourself in Django.
I haven't seen any blogging platforms written in Python that requires hundreds of queries to render a homepage like Wordpress does in PHP. If your site is running on a single modest server, needs 190 queries to render a page, has zero caching, and gets a spike in traffic then it will go down like a sack of bricks. That same scenario with <10 queries is a completely different story.
Yes to Blogofile. Because your operating system already has a caching technique: the filesystem.
(obviously not applicable to user-customizable content)
Edit: uh oh, after reading other comments more carefully, now I'm going to have to evaluate Hyde as an alternative (in the 'python static-generation' space). too many apparently-viable alternatives! option paralysis may set in!
These changes are both awesome. Particularly the one to submodule update. I have a project setup where not everyone has access to all its submodules. Prior to this, people would have to manually run update for each submodule they were allowed to access. Otherwise it would fail part way through on the ones they didn't have access to. Great news!
Turns out the problem was an issue between APC and WP Super Cache. After WPSC tried to run garbage collection on cache files (a cron, configured in the plugin's settings), the server would end up then returning a 500 error. I'm still not entirely sure why, but I disabled APC for now and things are running as they should.
Sorry, it wasn't my intention to be misleading. I'll give it more thought next time. I see how "changes" could be deemed with a negative connotation in that context.
