This can be true and it's great if everyone made their source code widely available. However, not all of us work in an 'open' environment. I just want to point out that '.inc' can be viewed as plain text so if work for one of those big scary corporations, where you don't own the code you write (they do), it might be a good idea not to use '.inc'.

I remember a few years ago a company got utterly hacked because they had their db connection in /includes/connection.inc <--- bad idea

root p/w was in the file... was bad.


Can anyone confirm? I've never seen anything to change that behavior - although I've never actually looked.

Too restrictive. Includes are a great place to put site-specific variables and those globals that can't be avoided as well. I routinely put things like mysql username/password, url name (both with and without the www prefix), webmaster email address, absolute path, https: url name, and other site-specific things in an include called config.php. Then, throughout my code, when these things come up I refer to the variable name.

This greatly enhances portability and maintainability; any change appears instantly site-wide.

I *could* put these things into a class then invoke the class, but given the overhead associated with setting up then reading a class in an interpreted environment, I never do so.

This information should be stored in a directory that is above the root of the website so that no web browser can access it. It can still be included in a script by referring to it by absolute path.

Yea, I can confirm.
What do you suppose this does?

I agree with you that there are exceptions to what I said, but I believe that these should be exceptions and not the rule. Making the code clear and easy to read should be the goal and adding some structure to the code helps with that. For example your header.php and footer.php are clear examples of where this works.

Finally, the overhead of the interpreter can be reduced via pre-compiling and caching.

How do you precompile PHP?

Whilst there are such products around that talk about compiling php I was thinking more along the lines of the Zend Cache which (as I understand it) pre compiles the code and then stores it in RAM, whereas there are some other solutions that grab all the different files save them as a single large cached file which will be used to run from. This second approach is much easier to implement but it really only saves time on the opening of files, the code still needs to run through the PHP compiler.

Have a look in the manual for bcompiler.