To make the thing
fly work, we need to make one last modification to our virtual host configuration:
<VirtualHost *> ServerName fcgi.test.local FastCGIExternalServer /fcgi/www/fcgi -host 127.0.0.1:9000 AddHandler php-fastcgi .php Action php-fastcgi /virtualpath Alias /virtualpath /fcgi/www/fcgi DocumentRoot /srv/www/fcgi <Directory /srv/www/fcgi> AllowOverride All Order Allow,Deny Allow from all </Directoy> </VirtualHost>
directive instructs Apache to remap every call to /virtualpath to the new location /fcgi/www/fcgi and of course append all the stuff that was trailing the original path before. And alas, we now have a clean call to where our
To seperate our PHP code from the other stuff under the document root, we need to point the
to some directory other than the original document root. To get to that very directory, we need to add a new Handler with
so Apache knows that files with the extension .php are to be treated specially. Next we have to create the
we named as the handler for our PHP code. And finally we have to redirect the action to where our new FastCGIExternalServer thinks is his area of responsibility.
Do you spot the flaw?
Ok, that was easy: The (again, not so) virtual path for the
doesn’t exist yet. So let’s fix that one, too:
mkdir -p /fcgi cd /fcgi ln -s /srv/www
This will provide a symbolic link to our document root. The only reason for having it really is the need to seperate our PHP code from all the other stuff. So essentially we came back full circle here just to make Apache and
happy. Funny, isn’t it?
For must use cases, we’re finished here. However, there are some PHP apps out there that use deprecated internal variables and will refuse to work even after we fixed up almost everythin for them. To fix those remaining apps, too, we unfortunately need to modify either the app or PHP itself. So let’s deal with those, too.