Includes and Functions

[VooDooRT]

Ok, as I posted earlier in a thread, and pointed out by MrAlaska, I've decided to make a whole NEW thread to generate some opinions on these matters.

Question 1) What are the benifits and downfalls of using functions as apposed to seperate files?

Question 2) What are the benifits and/or downfalls for using an include within an include. ie:

I require 1.php in all my files, but I also require 2.php.

So, within 1.php, I include 2.php, and in all my files, I include 1.php only.

Would it be better to include 1.php AND 2.php in all my files, or does it matter at all?

Opinions?

[frigidman]

Some feedback:

1) Functions rule. I usually make seperate files of tons of specialized functions, and just include that file when I want a php script to have access to that function set.

2) I havnt seen any ill effects from putting require/includes inside files that are require/include by other scripts. Just dont inadvertanlty require a file that is requiring that file and make a loop of destruction... hehe.

For example, I use a singular conf.inc file that has all sorts of global settings for an entire application suite (a website). I include this for every execution of any php under that website. Sometimes however, certain sections of the site have their own functions and things they commonly use. So I include that file as well for those particular phps. But I include it from the main conf.inc file with an 'if'.

example:

For apps that need a secondary function set... I put this on the top:

$ping_functions = true;
require_once('conf.inc');

For other apps that use a different function set, I would use like this:

$pong_functions = true;
require_once('conf.inc');

Or an app that needs all those functions:

$ping_functions = true;
$pong_functions = true;
require_once('conf.inc');

I keep the secondary functions in a secondar include file, because its easier on the resources of the server if you dont load EVERYTHING for every php execution. Instead I only load in things that are needed.

Inside the conf.inc it looked like this:

//bunch of configuration variable settings:
$conf['this'] = 'blah';
$conf['that'] = 'bleah';
//includes for specific function sets:
if ($ping_functions) include_once('ping_functions.inc');
if ($pong_functions) include_once('pong_functions.inc');
//then a bunch of common functions that must always exist...

Make sense?

[mrmufin]

Mo feedback:

1. Each include() statement means a disk hit. (Unless you're using a PHP caching utility which can help the web server store your PHP functions in memory; techniques like that have some special rules regarding include files. We'll assume that you're not using a caching package.) The problem that I've found with disk hits, is the amount of time it takes to pull a file off the disk tends to vary quite a bit. And, man, I time everything. At least the first few times around...

2. I've not had any problems with include_this.php calling include_that.php, which in turn calls include_other.php. But with my first point in mind (as well as frigidman's second point), for chrissakes, be careful with it!

Unlike frigidman, however, I'll typically cram all the 'custom functions' required by a site into a single include file, and just load that at the top. (Of course, I start with a huge file containing a gazillion and five functions in it, then as I need stuff for an application, I just rip into that mega-file and built the site-specific include file with just the functions the site requires.) I figger, if the site requires it, then the servers gotta pull it off the disk, then parse it, then do it, it might as well be done with one disk hit instead of multiple disk hits.

Make sense?

[MrAlaska]

This has generated interesting response, and some good points made.

For the benifit of those who may not have considered it, I think it should be mentioned that using .inc to name your include files may contain an exposure risk of your code (and any passwords it uses) to inquisitive visitors unless you instruct the server to serve .inc as a php file or store it in a protected folder. By default it will usually get served up as a text file if visitors are able to figure out the name.

[mrmufin]

Originally posted by MrAlaska
For the benifit of those who may not have considered it, I think it should be mentioned that using .inc to name your include files may contain an exposure risk of your code (and any passwords it uses) to inquisitive visitors unless you instruct the server to serve .inc as a php file or store it in a protected folder.

A worthy reminder, indeed. I never keep include files in the ~/htdocs/ path. Nor do I keep 'em in the configured PHP include_path. (Mainly because I've had more than one experience where some shared server administrator did all the users a 'favor' and upgraded the PHP interpreter and then spaced out and forgot to make the 'new' include_path config setting the same as the old setting.)

[frigidman]

I used ".inc" as an example. I don't like posting the exact names of my 'special' files... for obvious reasons =)

I store many things like passwords, and db access in external outside-web-dir directories with special permissions and the like.

Don't worry... I'm a paranoid flick like everyone else 😃

[MrAlaska]

Originally posted by frigidman Don't worry... I'm a paranoid flick like everyone else 😃

Not EVERYONE else. Being active and knowledgeable in a security aware forum such as this one I figured you had your files protected, but I am amazed at the people who don't sometimes. I attended an ASP/VB class taught by a respected author/conslultant who actually does know his stuff. When he started using .inc in his examples he was stopped in his tracks when pointed out the security risk. It had just not occured to him before.

I don't remember who pointed it out to him, but for some reason he calls me a trouble maker ever since.