My method was adapted from this write-up by Shaun Inman. It seems Shaun is quietly solving all the world’s problems while no one is looking.

A commenter on Shaun’s thread mentioned that some ISPs may have readfile() functionality turned off as apparently it takes up some amount of memory. The virtual() command also did not work for me and the error message I got indicated that function definitely wasn’t supported. But then again, I’m no PHP expert so user error is a distinct possibility.

The include() function was the only way I found to get the cgi and the php firing together. Any of you PHP-heads out there care to comment on the use of include() vs. virtual() vs. readfile() ? Wolf?

There’s your problem. PHP doesn’t execute within a .cgi page, not even if you addtype it in your .htaccess — it has to be a .php file.

Again, more once I get the last few kinks worked out. :)

Anybody have any insights on which is better to use from a processor standpoint, readfile(), include(), implode(), or virtual()?

Before someone accuses me of trying to suck another MT user over to WP, let me just note that I only am making this comment because Mike wrote, “The first is that it doesn’t offer dynamic page serving, so I must recompile my entire site after making a change. I can live with this problem as recompiling is just a question of hitting a button and waiting awhile.” I grew to hate dynamic page-serving while I was a Greymatter user, and that’s why I never switched to MT.

There are many reasons not to use WP and to use MT; I’m just throwing the idea out there.

Personally, I’m totally cool with you trying to suck people over to WordPress. I’m interested in using whatever tool is best for the job, and the only reason I used MT to begin with is that I had some experience with it, so it was easy to implement. Perhaps I should do an audit of WordPress before this blog gets too big.

You did mention however that you didn’t switch to MT because you don’t like dynamic page-serving. MT doesn’t have dynamic page serving. It requires you to compile everything when you republish.

The first is that it doesn’t offer dynamic page serving…

This is not strictly true. For some time now Movable Type’s been shipping with a script that allows you to dynamically generate pages. It’s not officially supported and it’s not terribly well documented, even unofficially, but it’s there.

“With the release of Movable Type 3.0, I’m not sure why Six Apart didn’t get rid of the default popup commenting system.” We have. We made lots of nice changes like that (such as yyyy/mm/dd/dirified_title.html post archives) but we don’t enforce them on existing site’s templates because, well, you know why. We also move comments inline on individual archives, but there’s a question about whether we should require individual archives for users who might otherwise opt not to have them.

Personally, I’d recommend Shaun’s readfile solution, that seems most robust, at least for now. Finally, I think we’re in a position to smooth out a lot of these little niggling things that (honest to god) probably bother us even more than they bother you. Thanks for doing all the work of documenting this, though, I’m glad to pass the link on to people.

The cost of dynamic pages is highly exaggerated. I speak from experience of running a service (Ping-O-Matic) that generates well over a hundred thousand queries per day. MySQL is incredibly fast, and it gets better with every release. I also run a few other high traffic fully dynamic sites (based on WordPress) and nearly every page is generated in under a tenth of a second, most under a twentieth. Google reports a few random searches as taking 0.11-0.41 seconds. If my pages are as fast or faster than Google and cause no perceptible load on the server then I’m not worried about anything.

I’ve implemented techniques very similar to these for the recent redesign of Stopdesign for search/results pages. The thing I most like (now that a majority of the site is powered by MT) is the ability to filter out or include certain sections of the site. The fact that most of the template is now driven by my own PHP and HTML means much more customization, and the ability to make the content look less like a default MT search (no offense to Jay).

I had comment preview pages rendering in the same fashion, but comment error pages were another beast that I couldn’t figure out. Actually, it was determining whether to show an error page, or to redirect back to the entry page with the new comment added. So instead, I’ve masked the ugly URLs (my cgiwrap URLs are even longer than the standard MT paths) via mod_rewrite.

window.location.replace(‘#comments’);

where #comments is the div’s id where i had my comments

¿any better idea?

sorry for my bad-english.