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)
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
