What is CGI and What is FastCGI?

There was a long rant in the wp-testers mailing list today talking about how we weren’t helpful to someone who was getting a “500 Internal Server Error” message after installing WordPress.  After complaining about our helpfulness and some bragging about past income levels, the poster said:

Quickly about the Internal Server Error.  It most probably has to do with using fast graphics on a server.  Older version of Apache like 1.333 are still in use with major hosting sites.  Using fast graphics with this slopped together code from wordpress will quite often cause  500 errors by causing the server to time out on you.

I think the writer misunderstood the meaning of FastCGI.  I wrote this reply/post to help clarify it for him and for myself as well:

We old school programmers remember the term CGI as “Computer Graphics Interface” and how it related to the initial concepts that matured into the video card drivers supplied with Windows. In DOS, the games you ran each came with their own hand written drivers for the most popular cards. CGI was a standard for writing these drivers. I still have a CGI programming book on my shelf that talks about programming for the Trident, Matrox and Tseng Labs video cards. As a side note, CGI in the movie industry refers to Computer Generated Images – also graphics related.

But when talking about Web Servers, CGI is the Common Gateway Interface. It really has little or nothing to do with graphics. The CGI is basically how the server turns website requests into the execution of console programs and the passing of the results back to the browser. In my experience, straight CGI programming is most often done in PERL, but doesn’t have to be. CGI programs are separate and independent from the Apache server. They are executed and return a result. That’s it.

FastCGI is an extended version of the CGI that is optimized for speed and scalability. It has also been extended to allow the web server to run on one machine and the CGI calls to execute on another.

Where all this comes into play with PHP (and WordPress) is that PHP can be connected with Apache (or lighttpd or w/e) in different ways. It can be a module interfacing through Apache API calls. Or it could also be a CGI application. If connected to Apache via CGI, the PHP code is executed by the server as console calls to a separate PHP application. Since FastCGI is compatible with CGI, FastCGI can also be a chosen interface between PHP and Apache or whatever webserver you are using.

As all of this changes how PHP and your webserver talk, over the years there have been bugs in WP that were specific to FastCGI servers. However, a 500 Internal Server Error is simply the server saying “OK This is all screwed up and I have no idea what to do now.”. Yeah, maybe that has something to do with how FastCGI is setup, but it is even more likely that you are simply missing a bracket or comma in your .htaccess file.

So even if this question had been in the right forum, we couldn’t have helped the person.  When the question is ‘My server says “Something is screwed up”. How do I fix it?’, the best response we can offer will start with  “Ummmmm”.

Also, I’ve come to understand this stuff just through passing conversations with SysAdmins and random reading. So please correct me if I am wrong on any of this.

How do you get the current directory name in PHP?

I ran into a situation where I wanted to get the name of the directory I was in, in PHP. To be clear, I didn’t want the full path, just the directory/folder name

To be clear, if I was working in the directory:
/home/username/public_html/addonname

I wanted to have addonname returned.

I worked out two solutions.

The first solution used the getcwd() function which returns the full directory path as shown above but to use the basename function to get the part I needed. It worked so… “echo basename(getcwd());” returns “addonname” in this scenario.

That would meet my needs perfectly. I believe that matches my requirements in spirit, but was not literally correct. That statement returned the current working directory, but not the directory where the file was located. In fact, PHP 4 and PHP 5 differ when getcwd() is called from the command line. If you are in the ‘/’ directory and execute “php /test/talktome.php“, a php 4 getcwd() in that file will return the path “/test” while PHP 5 will correctly return ‘/’.

To resolve this, this next call works even better:
echo basename(dirname(__FILE__));

Does anyone want to do some speed tests to see which is faster after 10,000 calls? Let us know your results.

PHPMyAdmin announces drop of PHP 4 support.

I was just over at the PHPMyAdmin site and saw this quote:

 Welcome to phpMyAdmin 2.11, which will probably be the last series supporting PHP 4.

Notice the “probably” stuck in there.  They are testing the waters.

If phpMyAdmin is dropping the whole PHP 4 line, it just might push the WordPress adoption time a bit further.  Where phpMyAdmin goes, I have to think,  the ISPs will not be slow to follow.