Frustrated with PHP’s "include"

[steve]

I am quite frustrated with php’s include, as I have spent a ton of
time on it already... anyone can tell me why it was designed like this
(or something I don’t get)?

The path in include is relative NOT to the immediate script that is
including it, but is relative to the top-level calling script.

In practice, this means that you have to constantly worry and adjust
paths in includes, based on the startup scripts that call these
lower-level scripts.

Why is the include path not simply relative to the script that is
immediately including?

--
http://www.dbForumz.com/ This article was posted by author's request
Articles individually checked for conformance to usenet standards
Topic URL: http://www.dbForumz.com/PHP-Frustrat...ict132935.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbForumz.com/eform.php?p=443884

[J.O. Aho]

steve wrote:

I am quite frustrated with php’s include, as I have spent a ton of
time on it already... anyone can tell me why it was designed like this
(or something I don’t get)?

The path in include is relative NOT to the immediate script that is
including it, but is relative to the top-level calling script.

In practice, this means that you have to constantly worry and adjust
paths in includes, based on the startup scripts that call these
lower-level scripts.

Why is the include path not simply relative to the script that is
immediately including?

You can always give the full path, in which case you don't have to worry about
things.

As I have understod, the include in PHP works more like a merge.
//Aho

[neur0maniak]

steve wrote:

I am quite frustrated with php’s include, as I have spent a ton of
time on it already... anyone can tell me why it was designed like this
(or something I don’t get)?

The path in include is relative NOT to the immediate script that is
including it, but is relative to the top-level calling script.

In practice, this means that you have to constantly worry and adjust
paths in includes, based on the startup scripts that call these
lower-level scripts.

Why is the include path not simply relative to the script that is
immediately including?

You can set your include path in your script anyway. So you can include
relative to any of your most common include paths...

[steve]

"neur0mania k" wrote:

steve wrote:

I am quite frustrated with php’s include, as I have spent a ton of time on it already... anyone can tell me why it was designed like

this

(or something I don’t get)?

The path in include is relative NOT to the immediate script that is including it, but is relative to the top-level calling script.

In practice, this means that you have to constantly worry and adjust paths in includes, based on the startup scripts that call these
lower-level scripts.

Why is the include path not simply relative to the script that is
immediately including?

You can set your include path in your script anyway. So you can
include
relative to any of your most common include paths...

J.O. and neur0maniak,
Thanks for your responses. While it can be managed, it is still a
huge maintenance pain. I am hoping that some php developers would
respond as to why not make script inclusion simply relative to the
including script, avoiding all the maintenance problems.

--
http://www.dbForumz.com/ This article was posted by author's request
Articles individually checked for conformance to usenet standards
Topic URL: http://www.dbForumz.com/PHP-Frustrat...ict132935.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbForumz.com/eform.php?p=443945

[eclipsboi]

On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
<us****@neur0ma niak.co.uk> wrote:

steve wrote:

I am quite frustrated with php’s include, as I have spent a ton of
time on it already... anyone can tell me why it was designed like this
(or something I don’t get)?

The path in include is relative NOT to the immediate script that is
including it, but is relative to the top-level calling script.

In practice, this means that you have to constantly worry and adjust
paths in includes, based on the startup scripts that call these
lower-level scripts.

Why is the include path not simply relative to the script that is
immediately including?

You can set your include path in your script anyway. So you can include
relative to any of your most common include paths...

What I like to do, and YMMV on your server, is to create an .htaccess
file containing at least one line:

php_value include_path "/full/path/to/my/includes"

You can of course append more than one search path with a colon (:),
but the point is to tell PHP where you plan on keeping your files to
include.

Then, no matter what file you do an include from, no matter where that
file resides, if you use simply:

include("myincl ude.php");

And myinclude.php is in /full/path/to/my/includes, then it will be
included flawlessly (provided no script errors on your part).

Even if you can't use .htaccess, you can create a header file to work
around this, somewhat to the effect of:

header.php:
<?
// Fill these out to your specs:
$system = ini_get("includ e_path");
$include = "/path/to/include:/more/search";

// Each file you wish to include:
$include_files = array(
"file1.php" ,
"file2.php" ,
"file3.php"
);

ini_set("includ e_path", $system . ":" . $include);

foreach ($include_files as $file)
{
include("$file" );
}
?>

This is untested, but maybe you get the idea for something you can do
on your own... good luck.

[Edward Alfert]

eclipsboi <ec*******@hotm ail.com> wrote in
news:e4******** *************** *********@4ax.c om:

On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
<us****@neur0ma niak.co.uk> wrote:

steve wrote:

I am quite frustrated with php’s include, as I have spent a ton of
time on it already... anyone can tell me why it was designed like this
(or something I don’t get)?

The path in include is relative NOT to the immediate script that is
including it, but is relative to the top-level calling script.

In practice, this means that you have to constantly worry and adjust
paths in includes, based on the startup scripts that call these
lower-level scripts.

Why is the include path not simply relative to the script that is
immediately including?

You can set your include path in your script anyway. So you can include
relative to any of your most common include paths...

What I like to do, and YMMV on your server, is to create an .htaccess
file containing at least one line:

php_value include_path "/full/path/to/my/includes"

You can of course append more than one search path with a colon (:),
but the point is to tell PHP where you plan on keeping your files to
include.

Then, no matter what file you do an include from, no matter where that
file resides, if you use simply:

include("myincl ude.php");

And myinclude.php is in /full/path/to/my/includes, then it will be
included flawlessly (provided no script errors on your part).

I like your .htaccess entry, but how does it impact performance of the
webserver or delay of processing php scripts?

Have you notice and degradation in performance?
--
Edward Alfert
http://www.rootmode.com/
Multiple Domain Hosting and Reseller Hosting Plans
Coupon Code (Recurring $5/month Discount): newsgroup

[steve]

"Edward Alfert" wrote:

eclipsboi <ec*******@hotm ail.com> wrote in
news:e4******** *************** *********@4ax.c om:

On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
<us****@neur0ma niak.co.uk> wrote:

steve wrote:
I am quite frustrated with php’s include, as I have spent a ton of time on it already... anyone can tell me why it was designed like this (or something I don’t get)?

The path in include is relative NOT to the immediate script that is including it, but is relative to the top-level calling script.
In practice, this means that you have to constantly worry and adjust paths in includes, based on the startup scripts that call these lower-level scripts.

Why is the include path not simply relative to the script that is immediately including?
You can set your include path in your script anyway. So you can includerelative to any of your most common include paths...
What I like to do, and YMMV on your server, is to create an

.htaccess

file containing at least one line:

php_value include_path "/full/path/to/my/includes"

You can of course append more than one search path with a colon

(,

but the point is to tell PHP where you plan on keeping your files

to

include.

Then, no matter what file you do an include from, no matter where

that

file resides, if you use simply:

include("myincl ude.php");

And myinclude.php is in /full/path/to/my/includes, then it will

be

included flawlessly (provided no script errors on your part).

I like your .htaccess entry, but how does it impact performance of

the
webserver or delay of processing php scripts?

Have you notice and degradation in performance?

This would work as long as the included filename is unique. If one
has 4-5 files called index.php in different directories, then the
solution would not work.

--
http://www.dbForumz.com/ This article was posted by author's request
Articles individually checked for conformance to usenet standards
Topic URL: http://www.dbForumz.com/PHP-Frustrat...ict132935.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbForumz.com/eform.php?p=443980

[Edward Alfert]

steve <Us************ @dbForumz.com> wrote in
news:10******** *****@news.supe rnews.com:

"Edward Alfert" wrote:

eclipsboi <ec*******@hotm ail.com> wrote in
news:e4******** *************** *********@4ax.c om:

On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
<us****@neur0ma niak.co.uk> wrote:

>steve wrote:
>> I am quite frustrated with php’s include, as I have spent

a ton of

>> time on it already... anyone can tell me why it was

designed like this

>> (or something I don’t get)?
>>
>> The path in include is relative NOT to the immediate

script that is

>> including it, but is relative to the top-level calling

script.

>>
>> In practice, this means that you have to constantly worry

and adjust

>> paths in includes, based on the startup scripts that call

these

>> lower-level scripts.
>>
>> Why is the include path not simply relative to the script

that is

>> immediately including?
>>
>
>You can set your include path in your script anyway. So you

can include

>relative to any of your most common include paths...

What I like to do, and YMMV on your server, is to create an

.htaccess

file containing at least one line:

php_value include_path "/full/path/to/my/includes"

You can of course append more than one search path with a colon

(,

but the point is to tell PHP where you plan on keeping your files

to

include.

Then, no matter what file you do an include from, no matter where

that

file resides, if you use simply:

include("myincl ude.php");

And myinclude.php is in /full/path/to/my/includes, then it will

be

included flawlessly (provided no script errors on your part).

I like your .htaccess entry, but how does it impact performance of

the

webserver or delay of processing php scripts?

Have you notice and degradation in performance?

This would work as long as the included filename is unique. If one
has 4-5 files called index.php in different directories, then the
solution would not work.

Good point...

In that scenario I assume it would retrieve the first matching file in
the order that they paths are listed.
--
Edward Alfert
http://www.rootmode.com/
Multiple Domain Hosting and Reseller Hosting Plans
Coupon Code (Recurring $5/month Discount): newsgroup

[eclipsboi]

On 24 Jul 2004 22:49:10 GMT, Edward Alfert <ea*****@rootmo de.com>
wrote:

I like your .htaccess entry, but how does it impact performance of the
webserver or delay of processing php scripts?

Have you notice and degradation in performance?

I've never seen any impact to performance, as it's not doing enough to
impact it at all. I use a combination of include_path,
auto_prepend_fi le to limit the time I spend with includes. The
auto_prepend_fi le is as it sounds, it auto includes one file for every
script that's called from under the .htaccess. I put all my global
stuff in that file and work from there--I will never do it any other
way.

[eclipsboi]

On Sat, 24 Jul 2004 23:00:02 -0000, steve
<Us************ @dbForumz.com> wrote:

This would work as long as the included filename is unique. If one
has 4-5 files called index.php in different directories, then the
solution would not work.

I think you're missing the point of what it does. Of course you can't
have more than one file called the same thing, so you would change how
you name your files. Personally, I name my files based on what they
do:

mysql.inc
functions.inc
classes.inc
cart.inc
etc...

And before you mention about .inc files being sent to the web browser
as plain text, check out this solution you can put in your .htaccess:

<FilesMatch "inc">
Order deny,allow
Deny from all
</FilesMatch>

If you had more than one extension you didn't want people viewing in
their browser, you can change it to:

<FilesMatch "(inc|tpl|ext)" >

And when a user tries to view your .inc (or whatever) file, they get
an access forbidden message.

Sometimes when embracing an outside change, you have to look inside
yourself for some change also. If you absolutely need to keep your
files with the same names, try creating wrappers for them:

<?
include("/path/to/index.php");
?>

I do this on rare occasions, mostly for the sake of SEO, but the point
is it works, with very little to no impact on performance. I also use
symlinks, but I understand that Windows users don't have that option.
So wrappers is a universally Good Idea(TM) IMPO.

It's spiffy, really; give it a try, you might like it.