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]

Re: Frustrated with PHP’s "include&q uot;

steve wrote:[color=blue]
> 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?
>[/color]

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]

Re: Frustrated with PHP’s "include&q uot;

steve wrote:[color=blue]
> 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?
>[/color]

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

[steve]

Re: Re: Frustrated with PHP’s "include&q uot;

"neur0mania k" wrote:[color=blue]
> steve wrote:[color=green]
> > I am quite frustrated with php’s include, as I have spent a ton[/color][/color]
of[color=blue][color=green]
> > time on it already... anyone can tell me why it was designed like[/color]
> this[color=green]
> > (or something I don’t get)?
> >
> > The path in include is relative NOT to the immediate script that[/color][/color]
is[color=blue][color=green]
> > including it, but is relative to the top-level calling script.
> >
> > In practice, this means that you have to constantly worry and[/color][/color]
adjust[color=blue][color=green]
> > 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?
> >[/color]
>
> You can set your include path in your script anyway. So you can
> include
> relative to any of your most common include paths...[/color]

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]

Re: Frustrated with PHP’s "include&q uot;

On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
<usenet@neur0ma niak.co.uk> wrote:
[color=blue]
>steve wrote:[color=green]
>> 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?
>>[/color]
>
>You can set your include path in your script anyway. So you can include
>relative to any of your most common include paths...[/color]

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]

Re: Frustrated with PHP’s &quot;include&q uot;

eclipsboi <eclipsboi@hotm ail.com> wrote in
news:e4p5g05r32 56nm9fa2d8gosf2 9bnrsk6ip@4ax.c om:
[color=blue]
> On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
> <usenet@neur0ma niak.co.uk> wrote:
>[color=green]
>>steve wrote:[color=darkred]
>>> 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?
>>>[/color]
>>
>>You can set your include path in your script anyway. So you can include
>>relative to any of your most common include paths...[/color]
>
> 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).[/color]


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]

Re: Re: Frustrated with PHP’s &quot;include&q uot;

"Edward Alfert" wrote:[color=blue]
> eclipsboi <eclipsboi@hotm ail.com> wrote in
> news:e4p5g05r32 56nm9fa2d8gosf2 9bnrsk6ip@4ax.c om:
>[color=green]
> > On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
> > <usenet@neur0ma niak.co.uk> wrote:
> >[color=darkred]
> >>steve wrote:
> >>> I am quite frustrated with php’s include, as I have spent[/color][/color]
> a ton of[color=green][color=darkred]
> >>> time on it already... anyone can tell me why it was[/color][/color]
> designed like this[color=green][color=darkred]
> >>> (or something I don’t get)?
> >>>
> >>> The path in include is relative NOT to the immediate[/color][/color]
> script that is[color=green][color=darkred]
> >>> including it, but is relative to the top-level calling[/color][/color]
> script.[color=green][color=darkred]
> >>>
> >>> In practice, this means that you have to constantly worry[/color][/color]
> and adjust[color=green][color=darkred]
> >>> paths in includes, based on the startup scripts that call[/color][/color]
> these[color=green][color=darkred]
> >>> lower-level scripts.
> >>>
> >>> Why is the include path not simply relative to the script[/color][/color]
> that is[color=green][color=darkred]
> >>> immediately including?
> >>>
> >>
> >>You can set your include path in your script anyway. So you[/color][/color]
> can include[color=green][color=darkred]
> >>relative to any of your most common include paths...[/color]
> >
> > What I like to do, and YMMV on your server, is to create an[/color]
> .htaccess[color=green]
> > 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[/color]
> (,[color=green]
> > but the point is to tell PHP where you plan on keeping your files[/color]
> to[color=green]
> > include.
> >
> > Then, no matter what file you do an include from, no matter where[/color]
> that[color=green]
> > file resides, if you use simply:
> >
> > include("myincl ude.php");
> >
> > And myinclude.php is in /full/path/to/my/includes, then it will[/color]
> be[color=green]
> > included flawlessly (provided no script errors on your part).[/color]
>
>
> I like your .htaccess entry, but how does it impact performance of[/color]
the[color=blue]
>
> webserver or delay of processing php scripts?
>
> Have you notice and degradation in performance?
>
>[/color]

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]

Re: Re: Frustrated with PHP’s &quot;include&q uot;

steve <UseLinkToEmail @dbForumz.com> wrote in
news:10g5qfija5 bef6a@news.supe rnews.com:
[color=blue]
> "Edward Alfert" wrote:[color=green]
> > eclipsboi <eclipsboi@hotm ail.com> wrote in
> > news:e4p5g05r32 56nm9fa2d8gosf2 9bnrsk6ip@4ax.c om:
> >[color=darkred]
> > > On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
> > > <usenet@neur0ma niak.co.uk> wrote:
> > >
> > >>steve wrote:
> > >>> I am quite frustrated with php’s include, as I have spent[/color]
> > a ton of[color=darkred]
> > >>> time on it already... anyone can tell me why it was[/color]
> > designed like this[color=darkred]
> > >>> (or something I don’t get)?
> > >>>
> > >>> The path in include is relative NOT to the immediate[/color]
> > script that is[color=darkred]
> > >>> including it, but is relative to the top-level calling[/color]
> > script.[color=darkred]
> > >>>
> > >>> In practice, this means that you have to constantly worry[/color]
> > and adjust[color=darkred]
> > >>> paths in includes, based on the startup scripts that call[/color]
> > these[color=darkred]
> > >>> lower-level scripts.
> > >>>
> > >>> Why is the include path not simply relative to the script[/color]
> > that is[color=darkred]
> > >>> immediately including?
> > >>>
> > >>
> > >>You can set your include path in your script anyway. So you[/color]
> > can include[color=darkred]
> > >>relative to any of your most common include paths...
> > >
> > > What I like to do, and YMMV on your server, is to create an[/color]
> > .htaccess[color=darkred]
> > > 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[/color]
> > (,[color=darkred]
> > > but the point is to tell PHP where you plan on keeping your files[/color]
> > to[color=darkred]
> > > include.
> > >
> > > Then, no matter what file you do an include from, no matter where[/color]
> > that[color=darkred]
> > > file resides, if you use simply:
> > >
> > > include("myincl ude.php");
> > >
> > > And myinclude.php is in /full/path/to/my/includes, then it will[/color]
> > be[color=darkred]
> > > included flawlessly (provided no script errors on your part).[/color]
> >
> >
> > I like your .htaccess entry, but how does it impact performance of[/color]
> the[color=green]
> >
> > webserver or delay of processing php scripts?
> >
> > Have you notice and degradation in performance?
> >
> >[/color]
>
> 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.[/color]

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]

Re: Frustrated with PHP’s &quot;include&q uot;

On 24 Jul 2004 22:49:10 GMT, Edward Alfert <ealfert@rootmo de.com>
wrote:
[color=blue]
>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?[/color]

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]

Re: Frustrated with PHP’s &quot;include&q uot;

On Sat, 24 Jul 2004 23:00:02 -0000, steve
<UseLinkToEmail @dbForumz.com> wrote:
[color=blue]
>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.[/color]

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.

[eclipsboi]

Re: Frustrated with PHP’s &quot;include&q uot;

On 24 Jul 2004 23:16:10 GMT, Edward Alfert <ealfert@rootmo de.com>
wrote:
[color=blue]
>steve <UseLinkToEmail @dbForumz.com> wrote in
>news:10g5qfija 5bef6a@news.sup ernews.com:
>[color=green]
>>
>> 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.[/color]
>
>Good point...
>
>In that scenario I assume it would retrieve the first matching file in
>the order that they paths are listed.[/color]

In this scenario, yes. I believe it stops searching at the first
occurance of whatever file you include. See my other post for ways
around this issue.

[eclipsboi]

Re: Frustrated with PHP’s &quot;include&q uot;

On Sat, 24 Jul 2004 23:33:26 GMT, eclipsboi <eclipsboi@hotm ail.com>
wrote:
[color=blue]
>
><FilesMatch "(inc|tpl|ext)" >
>[/color]

I'm sorry to reply to my own, but I just realized I was not very clear
with the above directive. Let me clarify about FilesMatch a little. In
this scenario I am using a regular expression, and in my example it
means .inc, or .tpl, or .ext files. For each file type you don't want
someone to access via their web browser you put a | and then the
extension (without the period). This tells apache to match on the
first extension that produces a true.

So, basically if a user hits my website via
http://www.myserver.com/includes/myinclude.inc,
http://www.myserver.com/templates/mytemplate.tpl, or even
http://www.myserver.com/somefile.ext they will get a forbidden
message, but could still go to http://www.myserver.com/index.php with
no problems. In turn, PHP can still access these files as needed,
because it doesn't go through Apache to get to them (except with
fsockopen, fopen, and/or curl--all of which would get access forbidden
because they'd go through apache).

If this is still unclear, I invite you to email me for a (hopefully
better) explanation.

[Chung Leong]

Re: Frustrated with PHP?s &quot;include&q uot;

"steve" <UseLinkToEmail @dbForumz.com> wrote in message
news:10g5ct6bkt t76bd@news.supe rnews.com...[color=blue]
> 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:[/color]
http://www.dbForumz.com/PHP-Frustrat...ict132935.html[color=blue]
> Visit Topic URL to contact author (reg. req'd). Report abuse:[/color]

http://www.dbForumz.com/eform.php?p=443884

As I've explained before, it's because include/require in PHP4 is a runtime
operation.

See earlier thread:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=Oeednfm_d_-j8PPdRVn-gg%40comcast.com&rnum=1&prev=/groups%3Fq%3Druntime%2Binclude%2Bchernyshev

sky%40hotmail.c om%26ie%3DUTF-8%26hl%3Den

[Ian.H]

Re: Re: Frustrated with PHP¢s &quot;include&q uot;

On Sat, 24 Jul 2004 22:36:16 +0000, steve wrote:


[ snip ]

[color=blue][color=green]
> > You can set your include path in your script anyway. So you can
> > include
> > relative to any of your most common include paths...[/color]
>
> 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.[/color]


Hmm not seeing this myself. I develop on a system albeit the same OS, the
paths are different and many apps I write are installable within any site
(ie: I have no idea what one filesystem is like from the next). To keep
things clean and simple, I use code such as:


<?php
define('SITE_RO OT', dirname(__FILE_ _));
require_once(SI TE_ROOT . '/../libs/foo.class.php') ;

[ ... ]
?>


If foo here needs to include a file too, it auto has access to the
SITE_ROOT constant so is able to easily get the correct path required,
whether it being installed into '/foo/bar' or
'/foo/bar/baz/foo/bar/baz/foo/bar/baz' etc etc.

The SITE_ROOT constant will "never change". By this I mean, that wherever
the script(s) reside, SITE_ROOT will always point to the calling script..
so unless you decide to change the locations of individual files, I see no
problem.

I also use a "registry" where I dump all my includes and then include this
single file (using the above method). This means then that if I _do_
change the location of a single file, I only have 1 entry to ammend rather
than one entry in every file that it's used. The registry file simply
looks something like:


<?php
$local_libs = array(
'foo',
'bar'
);
foreach ($local_libs as $l_lib) {
require_once(SI TE_ROOT . "/../libs/$l_lib.class.ph p");
}

$global_include s = array(
'foo',
'baz'
);
foreach ($global_includ es as $g_inc) {
require_once("$ g_inc.php");
}
?>


The $local_libs will include the files shipped with the code, the
$global_include s includes the files stored within '/usr/local/lib/php' (or
wherever the php.ini includes path points to).



Regards,

Ian


XP: stripped
FU: c.l.php

--
Ian.H
digiServ Network
London, UK

http://digiserv.net/

[Anders K. Madsen]

Re: Frustrated with PHP’s &quot;include&q uot;

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

[snip][color=blue]
>
> 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.
>[/color]

I'm sorry, but if you use index.php as name for your include files -
and even use more of them - I have a really hard time feeling sorry for
you.

Personally, to keep my code clean and easy understandable, I try not to
let included files include other files. It's _generally_ (not always -
I'm not trying to troll here or anything) a bad idea. It will often
(not saying it always does) turn out to be a serious mess, and you
somewhat lose control over your code, since you might include tons of
libs that aren't necessary, thus only slowing the code-execution.
I usually have one include-dir, from which I include all that needs to
be included, one by one. Then I can easily chose if I really want to
connect to MySQL in the given script or if I really wan't to load 2kb
worth of classes and methods just to do a simple HTTP redirect.

Personally I prefer using
require_once $_SERVER['DOCUMENT_ROOT'] . '/lib/class.MyLib.php ';
Then you don't rely on corectly configured include_paths and such.

Personally I've never had any problems with including files in PHP, and
I don't see why anyone should have so.
Not if they just take a minute to lay out their applications in a
directory structure. And it's actually not a whole lot of people who
do that... I've seen tons and tons of web applications with directory
layouts that would make my room look like surgery clinic.

So instead of complaining about the way PHP does things, you should try
and see what you could do to omit these things, so e.g. the include_path
in htaccess could be a good solution. (And no, you can't really feel it
regarding performance... At least, I can't, and I'm on a 633 MHz Intel
Celeron w/ 128 MB RAM.
Putting a little effort into it, you could go about rearranging your
include structure, so it would make your job easier.

But it's your call, so I'll leave that up to you.

Best regards,
Madsen

P.S. I'm very sorry if some of what I've written is utter nonsense, but
I'm very, very, very tired (after coding for like 42 consecutive hours
(Learning Ruby at the moment).

Hope I haven't offended anyone or said anything utterly
wrong/ridiculous/off-topic/foolish.

G'night! ;)

--
Anders K. Madsen --- http://lillesvin.linux.dk

"There are 10 types of people in the world.
Those who understand binary - and those who don't."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBAwVmlNH Je/JASHcRAnPBAJ99q uvqhV/8Y8mjigaQImq+1C NPKwCffBZw
AJiLEM3JLGvqsHl JcHzF3L8=
=/zGR
-----END PGP SIGNATURE-----