Content Manager that Produces Static HTML

Is there a mainstream product that can do this?

[kaled]

I have not needed a content management until now and am looking for something suitable for a big project that would be updated several times each day.

I see no need for the site to be fully dynamic - that would just use up CPU-cycles and/or slow it down. I envisage a system of templates and online editing tools that allow changes to be made (and archives to be kept). When a change is made, this would create a new, static-html version of the page. (I believe this also offers the potential to compress pages using "deflate").

It seems to me that this approach should result in more or less the fastest/most efficient delivery of data possible. However, having looked, I can't find any products work this way. Perhaps there is a good reason for this (that involves caching?) or perhaps it is simply an approach that has been overlooked.

If necessary, I could write my own system using perl, but that would be a lot of effort that I would like to avoid.

Any and all suggestions will be much appreciated.

Kaled.

[bill]

A very good static CMS system can be found in MovableType. It's perl, so you could look through what they've done. MT can handle dynamic pages as well.

I've used it as a CMS from small sites up through industrial site size. You can break the site up into portions and statically publish what you need.

[ergophobe]

Other than Moveable Type, no recommendations. I have a vague memory that Typo3 might have this ability too, but that's a very vague memory, so quite possible wrong.

Mostly, I just wanted to make some general comments about yoru general queries.

I think the reason for most CMS not generating static pages on your average open source project is
- nobody felt like bothering (could explain more cases than I suspect)
- on a really active community-style site where content is being added and comments thrown in a lot, the desire to have "recent articles" sidebars and so on and so forth, it just wouldn't be possible to regenerate a static site fast enough. In that case, the overhead becomes tremendous and intelligent caching (cahcing pieces of pages, rather than pages) makes more sense.

So most community-oriented CMS opt to apply varying degrees and types of caching, both at the server level and at the application layer. With really aggressive caching, you start to lose some of the advantages of a dynamic site and get closer to the situation where you're regenerating a static site. So there are a lot of gradations really.

In most cases, the big cost of a dynamic site is going to be the database interactions. Caching can dramatically reduce the number of queries, but usually still have a few.

Finally, you have a lot of options for compression, and a dynamic site doesn't eliminate any of these possibilities, but it is a bandwidth versus CPU cycles tradeoff. So you can still have Apache compress you're pages before sending them out, but you'll be eating CPU cycles.

AFAIK, compression always has to be done on the fly, whether static or dynamic, so the static/dynamic issue doesn't really come into play except in the sense that your dynamic site is eating CPU cycles and so is compression. But the browser needs to tell the server in the request headers whether or not it can accept compressed pages and then the server decides based on that whether to compress the page or not.

[kaled]

Thanks for the feedback...

MovableType is probably somewhat larger than I require but might be a good decision long-term if the site becomes successful.

The reason I think static generation is sensible is that I envisage precisely the same pages being delivered each time until an edit is submitted (perhaps thousands of views per edit). If the server caching were fully integrated with the content management then I guess there would be no discernable difference in performance, but I've not read anything so far that suggests this happens.

It seems that creating a WYSIWYG editor with javascript is reasonably straightforward so I may be able to create a simple but sufficient system using perl to submit changes. I'll give this some thought. I'm also considering creating some static content immediately to kick things off (to try to get back-links, PR, etc).

Kaled.

[ergophobe]

If you want to look into something simpler than MoveableType, Wordpress has WP-Super-Cache, which generates static HTML files to non-authenticated users. I don't know if it just uses mod_rewrite cookie detection and assumes that if there's a cookie that it needs to check authenitication, it needs to serve up the semi-cached version or if there's some scripting logic in all cases. It might be worth exploring though.

Matt Mullenweg recently claimed [drupal.org] that a $100 server using the memcached and Batcache plugins can handle 20,000,000 page views per day with Wordpress. The official Batache page [wordpress.org] says that WP-Super-Cache is even faster.

Of course, I have no idea whether those claims are realistic or not, but there it is.

[kaled]

Thanks, that might be the perfect solution. At least I feel better now that I know that someone in the field has at least considered the same problem and come to a similar conclusion to me. I was beginning to wonder if maybe my priorities were a little bit skewed!

WordPress may also be ideal since it is explicitly listed as supported by the host I'm thinking of using.

Kaled.

[ergophobe]

<rant class="a-bit-off-topic">
Hosts often (perhaps generall) just list apps as supported for marketing, not because it says much of anything about them versus other hosts or the apps named versus other apps. If the host offers PHP and MySQL and a few other things that almost all hosts do, then all of the open source CMSes built on a LAMP platform will run and the support you get won't necessarily be better from one who lists it as supported compared to one who just tells you what the server config is.

Commonly, another meaning of "supported" means that they have Fantastico which allows almost single-click installs of various apps, of which WP is the most popular.

Frankly, I prefer to not use that option, having done so a couple of times, because it chooses helpful database names like wrdp1 and wrdp2 and did a few annoying things that actually made long-term maintenance harder, not easier.

Install it manually the first time as instructed by the provider (in this case WP) and put in an automated upgrade plugin. If you don't launch until WP 2.7 (now in beta), the automated upgrade will be built in anyway.
</rant>

[kaled]

Thanks for the suggestion with regard to installing Wordpress. I'll bear it in mind when/if the time comes.

I think I'll roughly design the site - that should give me a better idea of what I need. I'll also be able to get some feedback/suggestions from other people. I know from experience that new ideas take a while to form properly and this one is way outside my usual domain.

Kaled.

[bill]

Keep in mind that there are a number of WordPress vulnerabilities out there as well. Its popularity has made it a real target. You can really hide an MT installation away to the point that nobody could tell what generated the pages. WP seems to leave a lot of telltale cruft about.

[kaled]

That's definitely something to consider. I had not thought of hacking with respect to content-management systems. I have been wondering what the best way to store usernames and passwords would be if I wrote something myself but that's as far as I got! (If a hacker can access a password file, they can probably access the script that reads it too so I concluded that mega-strong encryption is pointless.)

On a slight tangent, do hosts typically allow fully-compiled code to run on their servers? I was looking at freepascal a few days ago with a view to migrating some code from Delphi. Since it can produce code for a number of platforms including Windows and Linux, I could probably throw something together pretty quickly. Using fully compiled code should be faster and is potentially more secure.

Also, if I did write my own system based on generating static-html, does it sound reasonable to use javascript and/or iframes to handle any necessary dynamic content that is required on a page (such as displaying the username)?

I anticipate providing a contact form and online content submission/editing. I may add forum capabilities later but I don't see this as essential to begin with. This could be hosted separately.

Kaled.

[ergophobe]

number of WordPress vulnerabilities out there as well

This prompted me to start another thread on pros and cons of CMS. [webmasterworld.com]

Anytime you put something online that can be accessed via public HTTP access, you're running a greater risk and when it has a common signature like WP does, it's even higher. Your site will be probed for various vulnerabilities. Even a site running on Unix will get probed daily for IIS vulnerabilities. Daily (at least that's what my logs show).

If you're going to run WP, a good backup strategy is essential, because eventually you could even fall to a dictionary attack. Since most WP sites have relatively small databases, even with hundreds of posts, I just have a script running on all WP sites that I have or maintain for others that backs up the DB and sends it to the owner's gmail account daily. You can make years of archives before you run out of space. It's a poor man's way to have some peace of mind with something like WP on you server.

[kaled]

RE : Pros and cons - my site will have multiple authors (I hope) so I definitely need something. If truly successful (a very big if) it will become high profile so whilst I did not initially consider security to be a big issue, I agree that I should do so - thanks for pointing that out.

It will be interesting to see how the new offering [webmasterworld.com] from MS fairs in this regard.

Kaled.