Apparently they were introduced in Apache 2.3, and they are wicked useful, it turns out. At least, wicked useful if what you want to do is figure out what the URL of a to a specific file on the server is, assuming that you have only its path and some other file’s URL.
What follows seems to be empirically correct, but I welcome corrections:
DOCUMENT_ROOT is the system file path to the root of the web server’s document directory (usually something like
But, imagine that per-user web directories have been enabled on your server. That is, if my user is foo, then there is a directory
/home/foo/public_html in which all of foo’s web documents are stored (and served from). This is (probably) outside of the main server document root directory. The URL of foo’s web files would be something like
And this is where our variables enter the story.
CONTEXT_PREFIX is the portion of the
REQUEST_URI that triggered the server to serve up a file outside of the document root. And
CONTEXT_DOCUMENT_ROOT is the root directory that that particular CONTEXT_PREFIX is rooted at. Nota bene: conveniently
CONTEXT_DOCUMENT_ROOT contains the path the document root for whichever context this particular script was accessed through (so it would be the same as
DOCUMENT_ROOT within the server’s document root, while
CONTEXT_PREFIX would be an empty string, since there is no context prefix within the server’s document root.
Consider this extended example:
User foo has placed files in that user’s public_html directory. There are nested directories within that public_html directory, and we are accessing a file at this URL:
This file is stored at the following path in the file system:
Thus, a sampling of relevant server variables (presented in
$_SERVER for the PHP users amongst us) would be:
Alternatively, a similar example within the server’s document root:
is a URL that access a file at:
This results in the following values:
(the empty string)
For giggles, I cooked up some code to generate the URL of particular directory based on this information. I used the following little snippet to do this in
DataUtilities::overlap() in battis/data-utilities:
Seth Battis March 30th, 2016
Posted In: How To
A few days ago (well, maybe a couple weeks ago), I was chatting with one of my colleagues about how I go about testing out new plugins and themes for WordPress µ before loading them on our school blog server. It seems like documenting my process might be generally helpful, so…
To start with, I decided (after ten years of mucking out Apache config files and PHP extensions and custom MySQL installs — thank you so, so much Marc Liyange for your timely and helpful installers!), that I was a grown-up and could spend $60 on a tool that makes my life easier: I run MAMP Pro on my MacBook. This means that I have a generic Apache/PHP/MySQL stack that supports commonly-used PHP extensions, Apache configurations, etc. I have redirected the document root of my install to my regular user’s Sites directory in OS X (~/Sites) so that I have ready access to the backend files of for my test installs. The net result: WordPress’ famous “Five Minute Install” is now true of almost any LAMP-based web application — I had a five-minute install of Drupal, Moodle, Joomla… you name it.
I’ve also settled into using Coda ($99) to edit HTML/PHP source code, since I particularly like the built-in terminal and publishing management features.
I actually included nicknames so that I could control for how different themes displayed usernames (since I’m thinking about FERPA and how it may apply to our students on our school blogserver).
chown -R seth ~/Sites; chgrp -R www ~/Sites; chmod -R 775 ~/Sites). This means that I usually don’t run into problems with web apps that want to move or create files. This is also, of course, totally insecure. Que sera, sera.
Seth Battis May 18th, 2010
Posted In: How To