NYCPHP Meetup

[Paul Houle]

Tom Melendez wrote:
>> Using an absolute path gets you none of the troubles you mentioned with
>> relative path, and none of the caching problems you'd get with an
>> absolute URL.
>
> The only trouble I have found with absolute paths is that it makes the
> assumption of DocumentRoot and where your files are to it.  If all of
> your environments (dev, staging, qa, production, running off media,
> whatever) are set up the same way, no problems.
    No matter who you are,  you need to find an answer to these problems.

    One answer is to always use a new virtual host to deploy a new 
instance of a system.  It's easy to do this with Apache.  At my last 
job,  I developed a system for packaging an entire virtual host in a 
single directory -- each directory would have a "conf",  "htdocs" and 
"logs" directory.  We'd add "lib",  "var",  "scripts" and similar 
directories if they were appropriate.  The httpd.conf file would include 
a "vhosts.conf" file that simply includes the virtual host configuration 
files from the vhost directories.  The vhost directories go in a 
structure like

/usr/local/apache/sites/www.site.com

    In this scheme,  most web sites have three "primary" configuration 
parameters.  These are:  (1) the virtual hostname,  (2) the location of 
the "sites" directory,  and (3) connection information for the 
database.  A site built to this scheme can often be moved or cloned in 
under five minutes.

    If you work this way,  a good practice with URLs is to base them all 
"relative to the virtual host",  which means like

/img/logo.gif
/css/main.css

    this way you know that every resource on the site can reference 
every other access without recomputing URLs.

    Another good practice is to use the "root" directory sparingly.  
It's OK to have

/robots.txt
/favicon.ico

    and other filenames that are mandated by outside conventions,  but 
install a CMS in it's own directory,  say

/a/

    where you let your CMS do whatever it wants.  The reason is that you 
might switch to another CMS in a few years,  which you can
install under

/b/

    When you decomission CMS A,  you build something (URL rewriting 
rules,  a script,  whatever) that redirects /a/ -> /b/ as accurately as 
possible.

----

    Unfortunately,  not everybody can use the above scheme.  It's not as 
easy to pull off with Microsoft IIS,  and some people don't have good 
control of their DNS.  Also,  general-purpose software (say PHPBB or 
Wordpress) will be installed in subdirectories by people,  so it needs 
to be able to live "whereever"  (using <base href> can help,  but opens 
it's own bunch of problem.)  No matter what,  software should configure 
the toplevel URL and the toplevel of the app in the filesystem in a 
single place,  in a file that's unique to each instance of the app 
(often the one file ~NOT~ in the version control system)