NYCPHP Meetup

[Hans Zaunere]

Jeff wrote:

> FUNDAMENTALS #1: Site Structure:  Where to Locate Includes?
> 
> Index.php is always located in a website's document root, /var/www/html/
> on a Linux box.
> Where should includes be located?

Personally, I find it depends on my environment:

   -- dedicated server, application not intended for distribution (ie, an intranet, private e-commerce site):  /usr/local/lib/php

   -- any application intended for distribution, or working in a shared public server: inline with the document root, or a subdirectory thereof, depending on the number of files.


I always name my includes with the extension of .inc


> Here are some possibilities:
> * in the same directory, /var/www/html/
> * in a subdirectory of document root, /var/www/html/includes/
> * in a parallel directory to document root, /var/www/includes
> 
> What are the advantages and disadvantages of each possibility?
> IN THE SAME DIRECTORY
> * simple
> * but confusing and cluttered if there are more than just a few
> IN A SUBDIRECTORY
> * provides a logical place for them
> * but exposes them to browsers
> IN A PARALLEL DIRECTORY
> * provides a logical place for them
> * doesn't expose them to browsers
> * but perhaps write privileges are not available (or needed?)

Protecting from browser exposure has a couple of options as well.

  -- if the app is open source anyway, what do I care?  To protect sensitive information, I create a drop-in application.php file.  It's a single file, aware of all the needed params, containing configuration options, DB connections, etc, and either in a protected directory or parsed by php anyway.  It contains *no* logic except to determine where includes are, possibly bring a DB connection online, or to create other menial aspects of the app's environment.

  -- if the app's source shouldn't be open to the public, it'll be on a dedicated server anyway  :)  Then, you can do it right; setup a nice hierarchy outside of the web root (/usr/local/lib/php) and use an auto included application file (ie, auto.logic.inc).  I also sometimes set environment variables in the apache .conf file, with additional helper paths and so forth.  This is particularly helpful if you have many sister projects on a single vhost (ie, /reports has it's own include dir, automatically determined by an environment variable set in a <Directory> directive in httpd.conf).

> What does exposure matter?
> If the include file contains html, it will be visible in the calling
> file's source code.
> If it contains php code (like a database connection), it will never be 
> visible anyway.

One fallacy I've seen in using the extension .php for included files, as to limit their visibility, is that while the browser may not see any output, that file is still being executed.  So, if you have more than just functions or classes, bits and pieces of the app are running, which may be *much* worse than someone getting the DB password or looking at your code in some form.

> Are there important principles here, or is location just a matter of 
> preference?

I think it's most important to just be cognitive of where your files are, and of what types they are (executeable, or includeable).  I like .inc for included files, and .php for *real* php files (ie, those that are executed).

H