PHP include best practices question

Question 1

I have been learning syntax for PHP and practicing it. I come from a .NET background so masterpages always made things pretty easy for me when it came to headers and footers.

So far I have a mainHeader.php and mainFooter.php which have my head menu and my footer html. I created a mainBody.php and at the top I put

<?php include "mainHeader.php" ?>

and for the footer I put

<?php include "mainFooter.php" ?>

This worked perfectly and made me smile because my pages all came together nicely. the mainHeader has my <html> and <body> and my mainFooter has my closing tags for those.

Is this good practice?

Question 2

I include my views from my controllers. I also define file locations to make maintenance easier.

config.php

define('DIR_BASE',      dirname( dirname( __FILE__ ) ) . '/');
define('DIR_SYSTEM',    DIR_BASE . 'system/');
define('DIR_VIEWS',     DIR_SYSTEM . 'views/');
define('DIR_CTLS',      DIR_SYSTEM . 'ctls/');
define('DIR_MDLS',      DIR_SYSTEM . 'mdls/');
define('VIEW_HEADER',   DIR_VIEWS . 'header.php');
define('VIEW_NAVIGATION',   DIR_VIEWS . 'navigation.php');
define('VIEW_FOOTER',   DIR_VIEWS . 'footer.php');

Now i have all the info i need just by including config.php.

controller.php

require( '../config.php' );
include( DIR_MDLS . 'model.php' );

$model = new model();
if ( $model->getStuff() ) {
    $page_to_load = DIR_VIEWS . 'page.php';
}
else {
    $page_to_load = DIR_VIEWS . 'otherpage.php';
}

include( VIEW_HEADER );
include( VIEW_NAVIGATION );
include( DIR_VIEWS . $page_to_load );
include( VIEW_FOOTER );

Question 3

I talked to the database architect from wordpress.com, the hosting service for WordPress. He said that they started out with one database, hosting all customers together. The content of a single blog site really isn't that much, after all. It stands to reason that a single database is more manageable.

This did work well for them until they got hundreds and thousands of customers, they realized that they needed to scale out, running multiple physical servers and hosting a subset of their customers on each server. When they add a server, it would be easy to migrate individual customers to the new server, but harder to separate data within a single database that belongs to an individual customer's blog.

As customers come and go, and some customers' blogs have high-volume activity while others go stale, the rebalancing over multiple servers becomes an even more complex maintenance job. Monitoring size and activity per individual database is easier too.

Likewise doing a database backup or restore of a single database containing terrabytes of data, versus individual database backups and restores of a few megabytes each, is an important factor. Consider: a customer calls and says their data got SNAFU'd due to some bad data entry, and could you please restore the data from yesterday's backup? How would you restore one customer's data if all your customers share a single database?

Eventually they decided that splitting into a separate database per customer, though complex to manage, offered them greater flexibility and they re-architected their hosting service to this model.

So, while from a data modeling perspective it seems like the right thing to do to keep everything in a single database, some database administration tasks become easier as you pass a certain breakpoint of data volume.

Question 4

The easiest way for the generic "PHP app running on an Apache server that you may or may not fully control" situation is to put your includes in a directory and deny access to that directory in your .htaccess file. To save people the trouble of Googling, if you're using Apache, put this in a file called ".htaccess" in the directory you don't want to be accessible:

Deny from all

If you actually have full control of the server (more common these days even for little apps than when I first wrote this answer), the best approach is to stick the files you want to protect outside of the directory that your web server is serving from. So if your app is in /srv/YourApp/, set the server to serve files from /srv/YourApp/app/ and put the includes in /srv/YourApp/includes, so there literally isn't any URL that can access them.

Question 5

You can't include php files relatively to your webroot that way, cause if you use the slash as first character, the reference will go much deeper than just your document root. So, instead of using your basepath, you could do something like this :

<?php 
   $path = $_SERVER['DOCUMENT_ROOT'];
   $path .= "/yourpath/yourfile.php";
   include_once($path);
?>

Question 6

This has been a fun topic of discussion on . There appear to be varying "religious views" on the topic.

I agree with Microsoft's recommendation: Use a sub-domain of the company's already-registered Internet domain name.

So, if you own foo.com, use ad.foo.com or some such.

The most vile thing, as I see it, is using the registered Internet domain name, verbatim, for the Active Directory domain name. This causes you to be forced to manually copy records from the Internet DNS (like www) into the Active Directory DNS zone to allow "external" names to resolve. I've seen utterly silly things like IIS installed on every DC in an organization running a web site that does a redirect such that someone entering foo.com into their browser would be redirected to www.foo.com by these IIS installations. Utter silliness!

Using the Internet domain name gains you no advantages, but creates "make work" every time you change the IP addresses that external host names refer to. (Try using geographically load-balanced DNS for the external hosts and integrating that with such a "split DNS" situation, too! Gee-- that would be fun...)

Using such a subdomain has no effect on things like Exchange email delivery or User Principal Name (UPN) suffixes, BTW. (I often see those both cited as excuses for using the Internet domain name as the AD domain name.)

I also see the excuse "lots of big companies do it". Large companies can make boneheaded decisions as easily (if not moreso) than small companies. I don't buy that just because a large company makes a bad decision that somehow causes it to be a good decision.

PHP include best practices question

Answers

php,include