Is it possible to run Movable Type under Apache HTTP Server?
That was the question posted to Quora which seemed strange to me given that Apache is the web server most used by MT end users, developers and even (to my knowledge) every single core developer who has even worked on MT. Not to mention the rest of the world! I'd love to know what spurred on the question and what web server people generally use in the author's world.
Anyhow, the reason I'm writing is mainly because the REST of my answer which is a rant about still-persistent use of CGI by some administrators/developers. *facepalm*
My answer, after the jump, just in case Quora goes the the bit graveyard one day...
Absolutely! The LAMP(P) stack[1] has always been the primary development environment for Movable Type's internal developers (and most external ones). Hence the best supported and least buggy. Not only is it possible, but it's highly recommended![2]
May I digress? I'm gonna digress...
Word of warning: AVOID CGI AT ALL COSTS!
[tl;dr CGI belongs in a museum, not your server. Use FastCGI or PSGI with MT]
The overly bold and capitalized warning above is true, really, regardless of your choice of web server. Or for that matter, your choice of software or the programming language that it's written in.
The CGI protocol is almost quite literally as old as the web. At the time that it was introduced, it was AMAZEBALLS!!!!! Seriously, it made people's heads explode, half-skulls overflowing with ideas for new, heretofore-impossible feats of technical wizardry. For at last, this new web thing could be INTERACTIVE! >**splode**<
However, putting that in perspective, this was also a time when a cutting-edge, "cool" web page[3] contained six hundred animated GIFs and technicolor, eyeball-hemorrhaging, rotating horizontal rules, best (nay: only) suited for a unicorn strip club. That is to say, the bar was set low...
In the nearly twenty years since its release upon an unsuspecting world, very little has changed with the CGI protocol. Twenty years may be a selling point for a bottle of scotch but in technology terms, we call that deceased. And yet, for some reason[4], it continues on. Like a bad penny. Like that stupid Energizer bunny—except instead of a drum, it ceaselessly beats on your server until it crumbles.
At this point, no one should be using CGI. Period. It's not only socially acceptable but absolutely encouraged to laugh and point at anyone suggesting its use or—*faints*—actually using it. Or, most especially, at developers who write software and documentation which enables people to continue to use this relic. Yes, most especially them....
On the other hand, there have been (!)Exciting(!)New(!)Technologies(!) which are far, far, FAR more performant, stable, secure, extensible, hair-preserving and generally happy-making. Two of those, most relevant to Movable Type, are FastCGI and PSGI. Both are absolutely supported by the software (see Movable Type 6 System Requirements) and take very little additional work to set up and configure.
FastCGI is an older, more established technology that is well battle-tested by the more intelligent, professional segment of the web. PSGI is the new upstart which has gained tremendous traction with the vanguard of technological elite, mostly due to it's incredibly portability and extensibility.
But really, compared to CGI, you can't go wrong with either one and your payoff for heeding my words is an exponential jump in all that is good and pure in this world and up to a 1000% decrease in its evils, of all sorts. Trust me on this. It's the right thing to do...
Pointless Footnotes
[1] - LAMP(P) - Linux, Apache, MySQL, Perl (and PHP! ;-) Yes, Movable Type has both Perl and PHP subsystems
[2] - Though if you require ultra-high performance and scalability, there are variations I might strongly suggest.
[3] - Yes, we used the word cool un-ironically back then. As in "Cool Site of the Day". Those were the days...
[4] - *cough*apache*cough*mod_cgi*ahem*... Sorry. Don't know what came over me. What was I saying?
Long-time perl and Movable Type developer. Principal of Endevver (http://endevver.com). Former MT Product Manager at Six Apart. Co-founder and Board Member of the Open Melody Software Group (http://openmelody.org)
The fact that CGI refuses to die until this day indicates that there are use cases or scenarios in which CGI is more apt than the alternatives.
Or does it indicate that people haven't done a good enough job in promoting the alternatives? :-)
There are few reasons CGI is still used based on my experience:
There's also a lot of cheap hosting accounts that provide PHP and CGI, but not a lot else.
Somehow I am missing the arguments why to avoid CGI (being old is not an argument)...
Possibly relevant past blog entries: https://blogs.perl.org/users/steven_haryanto/2012/12/cgi-is-dead-long-live-cgi.html https://blogs.perl.org/users/maddingue/2012/07/is-pcli-possible.html (see Aristotle's comment)
CGI still lives for the same reasons as inetd still lives: services that are queried only infrequently (with a "frequently" being defined by the sysadmin), keeping a process in memory is wasteful.
Exactly. CGI is the only sensible thing for your checkers club's guest book page, so to say.
“Use PSGI instead of CGI” is nonsensical. CGI is a valid option for deploying a PSGI app (as long as it’s been written to start up quickly – but that’s on the app’s author, not PSGI). C.f. Plack::Handler::CGI.
The nice thing about using PSGI this way is that you don’t have to make a choice between CGI, FCGI, a standalone server, mod_perl, or what have you. You can deploy it as a CGI if that’s convenient. Or you can deploy it as a persistent process of some kind if you need or prefer it that way.
Or blogs.perl.org comments, of which there are a handful per day. Man, I need to look at this CGI thing...