473,326 Members | 2,125 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Frustrated with PHP’s "include"

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
Jul 17 '05 #1
43 5023
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
Jul 17 '05 #2
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...
Jul 17 '05 #3
"neur0maniak" 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
Jul 17 '05 #4
On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
<us****@neur0maniak.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("myinclude.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("include_path");
$include = "/path/to/include:/more/search";

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

ini_set("include_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.
Jul 17 '05 #5
eclipsboi <ec*******@hotmail.com> wrote in
news:e4********************************@4ax.com:
On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
<us****@neur0maniak.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("myinclude.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

Jul 17 '05 #6
"Edward Alfert" wrote:
eclipsboi <ec*******@hotmail.com> wrote in
news:e4********************************@4ax.com:
On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
<us****@neur0maniak.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("myinclude.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
Jul 17 '05 #7
steve <Us************@dbForumz.com> wrote in
news:10*************@news.supernews.com:
"Edward Alfert" wrote:
eclipsboi <ec*******@hotmail.com> wrote in
news:e4********************************@4ax.com:
On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
<us****@neur0maniak.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("myinclude.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

Jul 17 '05 #8
On 24 Jul 2004 22:49:10 GMT, Edward Alfert <ea*****@rootmode.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_file to limit the time I spend with includes. The
auto_prepend_file 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.
Jul 17 '05 #9
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.
Jul 17 '05 #10
On 24 Jul 2004 23:16:10 GMT, Edward Alfert <ea*****@rootmode.com>
wrote:
steve <Us************@dbForumz.com> wrote in
news:10*************@news.supernews.com:

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.


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.
Jul 17 '05 #11
On Sat, 24 Jul 2004 23:33:26 GMT, eclipsboi <ec*******@hotmail.com>
wrote:

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


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.
Jul 17 '05 #12
"steve" <Us************@dbForumz.com> wrote in message
news:10*************@news.supernews.com...
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

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=e...e%2Bchernyshev
sky%40hotmail.com%26ie%3DUTF-8%26hl%3Den
Jul 17 '05 #13
On Sat, 24 Jul 2004 22:36:16 +0000, steve wrote:
[ snip ]

> 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.

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_ROOT', dirname(__FILE__));
require_once(SITE_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(SITE_ROOT . "/../libs/$l_lib.class.php");
}

$global_includes = array(
'foo',
'baz'
);
foreach ($global_includes as $g_inc) {
require_once("$g_inc.php");
}
?>
The $local_libs will include the files shipped with the code, the
$global_includes 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/

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

[snip]

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'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)

iD8DBQFBAwVmlNHJe/JASHcRAnPBAJ99quvqhV/8Y8mjigaQImq+1CNPKwCffBZw
AJiLEM3JLGvqsHlJcHzF3L8=
=/zGR
-----END PGP SIGNATURE-----

Jul 17 '05 #15
steve wrote:
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.


dirname(__FILE__) will get you the path from your included files. I don't
really see it as a "huge maintenance pain." Having include path relative to
included files may have a negative effect as well for systems that include
different modules or language files (with the same filenames) depending on
which top script is including them. So, it goes both ways.
Jul 17 '05 #16
"Chung Leong" wrote:
"steve" <Us************@dbForumz.com> wrote in message
news:10*************@news.supernews.com...
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

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=e...e%2Bchernyshev
sky%40hotmail.com%26ie%3DUTF-8%26hl%3Den


Chung, thanks for the link. I visited the thread, and it is obviously
a concern with others as well!

I quote you:
----------------------------
The fact that it’s an runtime operation makes a big difference.
Suppose I
write a function that include a file:

function CustomInclude($path) {
include($path);
echo "<!-- including $path -->";
}

And suppose I place this function in
/chung/utilities/useless/functions.php.
When I pass a relative path to this function in some project, I
certainly
wouldn’t want the path to be relative to the file containing the
function.
---------------------------

Can you explain the above. I am having a hard time with it. The main
argument was about why php designers did it this way, and that is my
focus. You are saying that it had to be done this way.

--
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=444024
Jul 17 '05 #17
"Ian.H" wrote:
On Sat, 24 Jul 2004 22:36:16 +0000, steve wrote:
[ snip ]

> 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.

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_ROOT’, dirname(__FILE__));
require_once(SITE_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(SITE_ROOT . "/../libs/$l_lib.class.php");
}

$global_includes = array(
’foo’,
’baz’
);
foreach ($global_includes as $g_inc) {
require_once("$g_inc.php");
}
?>
The $local_libs will include the files shipped with the code, the
$global_includes 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, inclusion of SITE_ROOT would certainly solve the problem.
Thanks.

I am also focusing on why php was designed this way, and if there is a
need to include a directive, let’s call it: "relative_include" which
does away with all this house keeping stuff. Kind of like you don’t
have to define the dimensions of an array, I am hoping we don’t have
to do stuff like this in PHP. I am discussing it in another thread of
this topic with Chung...

--
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=444025
Jul 17 '05 #18
"Zurab Davitiani" wrote:
steve wrote:
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.


dirname(__FILE__) will get you the path from your included files. I
don’t
really see it as a "huge maintenance pain." Having include path
relative to
included files may have a negative effect as well for systems that
include
different modules or language files (with the same filenames)
depending on
which top script is including them. So, it goes both ways.


Thanks, Zurab. It is not a maintenance problem if the code is all
written by you and under your control. But imagine you have a system
(a CMS), and now you want to include a new modules written by someone
else. One has to dig into that code, and fix all the include
problems. I have found this to be one of the biggest weaknesses in
incorporating new code.

--
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=444049
Jul 17 '05 #19
steve wrote:
"Zurab Davitiani" wrote:
> steve wrote:
>
> > 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.

>
> dirname(__FILE__) will get you the path from your included files. I
> don’t
> really see it as a "huge maintenance pain." Having include path
> relative to
> included files may have a negative effect as well for systems that
> include
> different modules or language files (with the same filenames)
> depending on
> which top script is including them. So, it goes both ways.


Thanks, Zurab. It is not a maintenance problem if the code is all
written by you and under your control. But imagine you have a system
(a CMS), and now you want to include a new modules written by someone
else. One has to dig into that code, and fix all the include
problems. I have found this to be one of the biggest weaknesses in
incorporating new code.

I know I'm old and extremely grey, but what about things like 'coding
standards' and 'design documents'?

This problem has been around since time began, and communication of one
kind or another is the only way forward.

$0.02

Steve
Jul 17 '05 #20
"Steve" wrote:
steve wrote:
"Zurab Davitiani" wrote:
> steve wrote:
>
> > 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.
>
> dirname(__FILE__) will get you the path from your included
files. I > don’t
> really see it as a "huge maintenance pain." Having include
path > relative to
> included files may have a negative effect as well for systems that > include
> different modules or language files (with the same filenames)
> depending on
> which top script is including them. So, it goes both ways.
Thanks, Zurab. It is not a maintenance problem if the code is all written by you and under your control. But imagine you have a

system
(a CMS), and now you want to include a new modules written by

someone
else. One has to dig into that code, and fix all the include
problems. I have found this to be one of the biggest weaknesses in incorporating new code.

I know I’m old and extremely grey, but what about things like
’coding
standards’ and ’design documents’?

This problem has been around since time began, and communication of
one
kind or another is the only way forward.

[quote:a6c7f5feb4="Steve"]steve wrote:
"Zurab Davitiani" wrote:
> steve wrote:
>
> > 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.

>
> dirname(__FILE__) will get you the path from your included files.

I > don’t
> really see it as a "huge maintenance pain." Having include path
> relative to
> included files may have a negative effect as well for systems that > include
> different modules or language files (with the same filenames)
> depending on
> which top script is including them. So, it goes both ways.


Thanks, Zurab. It is not a maintenance problem if the code is all
written by you and under your control. But imagine you have a

system (a CMS), and now you want to include a new modules written by someone else. One has to dig into that code, and fix all the include
problems. I have found this to be one of the biggest weaknesses in
incorporating new code.
I know I’m old and extremely grey, but what about things like ’coding
standards’ and ’design documents’?

This problem has been around since time began, and communication of
one
kind or another is the only way forward.

$0.02

Steve[/quote:a6c7f5feb4]
02
Steve


Steve, document standards are great... and in this case, my hope is
that the language itself can be "reformed" so that such standards
are not needed. If the language had a "include_relative" directive,
it would solve the problem. I am still waiting to hear why we cannot
have such a thing. They could easily put it in PHP5+.

steve

--
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=444124
Jul 17 '05 #21

"steve" <Us************@dbForumz.com> wrote in message
news:10*************@news.supernews.com...
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.
EXACTLY! That is the way it was designed to work and the way it has been
working for many years. If all the other PHP developers can live with it
then why can't you?
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.
I certainly don't. I have several applications which exist in their own
directory, so each top-level script starts in one of these directories. If I
want to include() another file it must either exist in the directory of the
current top-level script, or it must exist in one of the directories
specified on the include_path entry in the php.ini file. If I specify
'./sub/filename.php' in an include() then that is relative to the directory
of the current top-level script. If this were changed in PHP to be relative
to the current include() file then would break a huge number of existing
scripts.
Why is the include path not simply relative to the script that is
immediately including?


I suggest you change your approach to one that reflects the way that PHP
actually works. Trying to force PHP to do what it was not designed to do and
then bitching about it is not a sensible idea.

--
Tony Marston

http://www.tonymarston.net
Jul 17 '05 #22
"steve" <Us************@dbForumz.com> wrote in message
news:10*************@news.supernews.com...
Can you explain the above. I am having a hard time with it. The main
argument was about why php designers did it this way, and that is my
focus. You are saying that it had to be done this way.


It's a logical consequence of include/require being a runtime operation.
When you include a file, the code inside execute within the runtime context
of the running script (i.e. PHP_SELF). It inherits all the global variables,
opened database connections, current paths, and so forth. In short, that
code behaves no differently than it would if it were copy-and-pasted
directly into the running script.

Example 1:

$msg = "hello world";
include("include/echo.php");

where include/echo.php contains <? echo $msg; ?> behaves in the same way as

$msg = "hello world";
echo $msg;

Example 2:

chdir("cows/images");
include("include/open.php");

where include/open.php contains <? readfile("portrait.jpg"); ?> behaves the
same as

chdir("cows/images");
readfile("portrait.jpg");

Example 3:

echo "Include start....";
include("include/include.php");

where include/include.php contains <? include("hello.php"); ?> behaves the
same as

echo "Include start....";
include("hello.php");

precisely because include() treats relative path as relative to the running
script. The two snippets In example 3 would behave differently if relative
paths were made to be relative to the current file (include/hello.php would
get included instead of hello.php).

Does that answer your question?
--
Obey the Clown - http://www.conradish.net/bobo/
Jul 17 '05 #23
> Why is the include path not simply relative to the script that is
immediately including?


In my projects I include paths like this:
include("../home/util.php");

Does it help ?

DG

Jul 17 '05 #24
"Tony Marston" wrote:
"steve" <Us************@dbForumz.com> wrote in message
news:10*************@news.supernews.com...
EXACTLY! That is the way it was designed to work and the way it has
been
working for many years. If all the other PHP developers can live with it
then why can’t you? Tony, I have to live with what is there now (is there a choice?). The
point is where the language is going. As an "open language", the
user community can influence its development.

If you look at Chung’s message, there is at least another long thread
on the same subject, so believe me, I am not alone in this.

"Tony Marston" wrote:
If this were changed in PHP to be relative
to the current include() file then would break a huge number of
existing
scripts.
No, you simply intro. something like "include_relative", and leave
"include" alone as is.

"Tony Marston" wrote:
Why is the include path not simply relative to the script that is
immediately including?
I suggest you change your approach to one that reflects the way

that PHP
actually works. Trying to force PHP to do what it was not designed to do and
then bitching about it is not a sensible idea.


Bitching is good. Gets new things developed. If no one bitches,
nothing new gets done.

--
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=444295
Jul 17 '05 #25
On Sun, 25 Jul 2004 17:38:12 -0000, steve
<Us************@dbForumz.com> wrote:
"Tony Marston" wrote:
"steve" <Us************@dbForumz.com> wrote in message
news:10*************@news.supernews.com...
EXACTLY! That is the way it was designed to work and the way it has
been
working for many years. If all the other PHP developers can livewith
it
then why can’t you?

Tony, I have to live with what is there now (is there a choice?). The
point is where the language is going. As an "open language", the
user community can influence its development.

It may be open to suggestion, but it doesn't necessarily mean
everything suggested will get thrown in--think of the mess.
If you look at Chung’s message, there is at least another long thread
on the same subject, so believe me, I am not alone in this.
If 1,000 people started saying that the sky was orange, would that
make them right? I think in this situation, while your concerns with
how you think include _should_ work are respectable, they are still
incorrect coding either way you dice the onion. As Friday the 13th and
Nightmare on Elm Street has taught us all, there is no safety in
numbers. ;)
"Tony Marston" wrote:

If this were changed in PHP to be relative
to the current include() file then would break a huge number of
existing
scripts.
No, you simply intro. something like "include_relative", and leave
"include" alone as is.

That's just more namespace that gets used; new bugs get thrown in;
more to maintain. Just because I use my big honking flat head
screwdriver to pry open things doesn't mean I think they should change
it's design to more suit being a prybar. If you (and I mean you in a
general sense) used the available tools as designed, with as little
straying from their original intent as possible, then I gaurentee you
that you wouldn't have [as many] problems like you, and others,
describe. It's a matter of form versus function. In this case,
function is winning out. (no pun intended)
"Tony Marston" wrote:
Why is the include path not simply relative to the script that is
immediately including?


I suggest you change your approach to one that reflects the way

that
PHP
actually works. Trying to force PHP to do what it was not designed

to
do and
then bitching about it is not a sensible idea.


Bitching is good. Gets new things developed. If no one bitches,
nothing new gets done.

Yes, speaking up and voicing opinions is great. Bitching is bad; it
sets a negative tone and doesn't get as many positive results. :)

Jul 17 '05 #26

"steve" <Us************@dbForumz.com> wrote in message
news:10*************@news.supernews.com...
"Tony Marston" wrote:
> "steve" <Us************@dbForumz.com> wrote in message
> news:10*************@news.supernews.com...
> EXACTLY! That is the way it was designed to work and the way it has
> been
> working for many years. If all the other PHP developers can live

with
> it
> then why can't you?

Tony, I have to live with what is there now (is there a choice?). The
point is where the language is going. As an "open language", the
user community can influence its development.


But if PHP is changed to make it work the way that YOU want it to it would
break thousands of scripts that have been written to conform to the way that
it currently works. What you are seeking to do can be done in other ways, so
change your approach to fit in with the way that PHP works.

--
Tony Marston

http://www.tonymarston.net

Jul 17 '05 #27
"Chung Leong" wrote:
"steve" <Us************@dbForumz.com> wrote in message
news:10*************@news.supernews.com...
Can you explain the above. I am having a hard time with it. The main
argument was about why php designers did it this way, and that is

my
focus. You are saying that it had to be done this way.


It’s a logical consequence of include/require being a runtime
operation.
When you include a file, the code inside execute within the runtime
context
of the running script (i.e. PHP_SELF). It inherits all the global
variables,
opened database connections, current paths, and so forth. In short,
that
code behaves no differently than it would if it were

copy-and-pasted directly into the running script.

Example 1:

$msg = "hello world";
include("include/echo.php");

where include/echo.php contains <? echo $msg; ?> behaves in the
same way as

$msg = "hello world";
echo $msg;

Example 2:

chdir("cows/images");
include("include/open.php");

where include/open.php contains <? readfile("portrait.jpg"); ?>
behaves the
same as

chdir("cows/images");
readfile("portrait.jpg");

Example 3:

echo "Include start....";
include("include/include.php");

where include/include.php contains <? include("hello.php"); ?>
behaves the
same as

echo "Include start....";
include("hello.php");

precisely because include() treats relative path as relative to the
running
script. The two snippets In example 3 would behave differently if
relative
paths were made to be relative to the current file (include/hello.php would
get included instead of hello.php).

Does that answer your question?


Chung,
Thanks for the examples. I can see that the issue is more complex
than I originally thought, but not less of an issue (IMHO). To make
relative work, a whole lot of php commands would also have to have a
relative version (perhaps with "-rel" as prefix in their names) to
make relative linking, relative directory referencing, etc. work.

I still believe this is a major issue. When you are trying to
incorporate a script developed elsewhere inside your overall script,
you have to look at all the inclues, fix things to make it work. I
have found this to be a major headache.

But it seems that the majority of posters on this thread do not
believe it is a major issue (or maybe they have not an integration of
an external and large script into something else). In any case, I
have raised the issue, and will leave it at that.

--
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=444363
Jul 17 '05 #28
Tony Marston wrote:
But if PHP is changed to make it work the way that YOU want it to it would
break thousands of scripts that have been written to conform to the way
that it currently works. What you are seeking to do can be done in other
ways, so change your approach to fit in with the way that PHP works.


I don't necessarily buy into his argument, but he did say they could simply
add include_relative rather than change the way include works. Other than a
relatively minor issue of how it would affect require_once and
include_once, depending on how relative paths get resolved (if at all), I
can't think of what other effect it would have on existing scripts.
Jul 17 '05 #29
"Zurab Davitiani" <ag*@mindless.com> wrote in message
news:Qt*****************@newssvr21.news.prodigy.co m...
Tony Marston wrote:
But if PHP is changed to make it work the way that YOU want it to it would break thousands of scripts that have been written to conform to the way
that it currently works. What you are seeking to do can be done in other
ways, so change your approach to fit in with the way that PHP works.
I don't necessarily buy into his argument, but he did say they could

simply add include_relative rather than change the way include works. Other than a relatively minor issue of how it would affect require_once and
include_once, depending on how relative paths get resolved (if at all), I
can't think of what other effect it would have on existing scripts.


Well, if you want include_relative then go code it yourself. The runtime
nature of include/require allows you to do that.
Jul 17 '05 #30
"Chung Leong" wrote:
"Zurab Davitiani" <ag*@mindless.com> wrote in message
news:Qt*****************@newssvr21.news.prodigy.co m...
Tony Marston wrote:
But if PHP is changed to make it work the way that YOU want it to it
would break thousands of scripts that have been written to conform to the way that it currently works. What you are seeking to do can be done in other ways, so change your approach to fit in with the way that

PHP works.

I don’t necessarily buy into his argument, but he did say

they could
simply
add include_relative rather than change the way include works.

Other than
a
relatively minor issue of how it would affect require_once and
include_once, depending on how relative paths get resolved (if at

all), I
can’t think of what other effect it would have on existing

scripts.

Well, if you want include_relative then go code it yourself. The
runtime
nature of include/require allows you to do that.


Thanks, Chung. It can be done via coding. It is a problem [still]
when you want to integrate a 3rd party script with many calls insider
your own script. Not everyone does it the same way.

--
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=444479
Jul 17 '05 #31
Chung Leong wrote:
I don't necessarily buy into his argument, but he did say they could

simply
add include_relative rather than change the way include works. Other than

a
relatively minor issue of how it would affect require_once and
include_once, depending on how relative paths get resolved (if at all), I
can't think of what other effect it would have on existing scripts.


Well, if you want include_relative then go code it yourself. The runtime
nature of include/require allows you to do that.


*I* don't want include_relative, because *I* don't agree with him that it's
needed; my reply was to Tony's comment about the effect on the existing
scripts.

But since you brought it up, "code it yourself" suggestion does not solve
the problem of consistency and maintenance of projects and scripts written
by others.

The way I see it, the steve's argument is that something like
include_relative will, at least to some degree, make developers write more
consistent scripts and keep different projects from doing it themselves
using different methods. I do see that argument, but I don't know that I
agree with it.
Jul 17 '05 #32
"Zurab Davitiani" wrote:
Chung Leong wrote:
I don’t necessarily buy into his argument, but he did say they could
simply
add include_relative rather than change the way include works.
Other than
a
relatively minor issue of how it would affect require_once and
include_once, depending on how relative paths get resolved (if

at all), I can’t think of what other effect it would have on existing
scripts.

Well, if you want include_relative then go code it yourself. The

runtime
nature of include/require allows you to do that.


*I* don’t want include_relative, because *I* don’t agree
with him that it’s
needed; my reply was to Tony’s comment about the effect on the
existing
scripts.

But since you brought it up, "code it yourself" suggestion does

not solve
the problem of consistency and maintenance of projects and scripts
written
by others.

The way I see it, the steve’s argument is that something like
include_relative will, at least to some degree, make developers write more
consistent scripts and keep different projects from doing it
themselves
using different methods. I do see that argument, but I don’t
know that I
agree with it.


Zurab, at least one person agrees with *some* of the things I am
"trying" to say::

Yes, my goal is consistency, and ease of integration of one large
script inside another. Actually I have contacted the person who
integrated phpbb (a huge script) inside phpnuke (another huge script).
He will be able to tell us if this was an issue. My main concern is
bringing a ton of good scripts out there, and integrating them into
your own, without doing all the kludgy stuff to make relative/absolute
paths work.

I like to treat a piece of script I receive as "black box". Don’t
want to know how the developer did all the path, and don’t want to
hack into their code --and render future versions of that code
"un-integrateable".

The people who object, I believe, have not done such a thing, or have
not done it on a large scale (but will await the developer’s
response...).

--
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=444498
Jul 17 '05 #33
I think the best way to deal with this is to define
global constant like ROOT_PATH which
contains full path to your root folder and then
always use includes like this
include ("../definitions.inc") // contains definition of ROOT_PAHT
// and is only incude having
relative path
include (ROOT_PATH . "/dir1/dir2/include.php")...
when you install your script on web server you only need to
define ROOT_PATH.....

Tomy.

Edward Alfert wrote:
eclipsboi <ec*******@hotmail.com> wrote in
news:e4********************************@4ax.com:
On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
<us****@neur0maniak.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("myinclude.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?

Jul 17 '05 #34

"steve" <Us************@dbForumz.com> wrote in message
news:10*************@news.supernews.com...
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

I use a little script that looks for the include folder and then creates a
$incdir variable.
This is then used in each script.

include_once("$incdir/databaseconnectionorsomething.php");

Regards
Richard Grove

Jul 17 '05 #35

"Zurab Davitiani" <ag*@mindless.com> wrote in message
news:Qt*****************@newssvr21.news.prodigy.co m...
Tony Marston wrote:
But if PHP is changed to make it work the way that YOU want it to it would break thousands of scripts that have been written to conform to the way
that it currently works. What you are seeking to do can be done in other
ways, so change your approach to fit in with the way that PHP works.
I don't necessarily buy into his argument, but he did say they could

simply add include_relative rather than change the way include works. Other than a relatively minor issue of how it would affect require_once and
include_once, depending on how relative paths get resolved (if at all), I
can't think of what other effect it would have on existing scripts.


It would affect a lot of scripts that I have written. My web application is
made up of a series of subsystems each of which exists in its own directory.
I have all my common code in a separate INCLUDE directory which is specified
on the include_path entry in the php.ini file.

Each subsystem directory has a subdirectory called 'screens', but the entry
in this subdirectory is loaded from a script which exists in the INCLUDE
directory. So regardless of where the script which issues the
"include(./screens/something.inc)" actually exists, the file is relative to
the subsystem directory not the INCLUDE directory. In other words all
relative paths start from PHP_SELF.

This is the way that PHP was designed to work and I have designed my code
accordingly. So people who expect PHP to work contrary to the way it was
designed and then keep bitching about it are not going to get very far. My
advice is - learn how PHP works and design your code accordingly.

--
Tony Marston

http://www.tonymarston.net

Jul 17 '05 #36

"steve" <Us************@dbForumz.com> wrote in message
news:10*************@news.supernews.com...
"Chung Leong" wrote:
> "Zurab Davitiani" <ag*@mindless.com> wrote in message
> news:Qt*****************@newssvr21.news.prodigy.co m...
> > Tony Marston wrote:
> >
> > > But if PHP is changed to make it work the way that YOU want > it to it
> would
> > > break thousands of scripts that have been written to conform

> to the way
> > > that it currently works. What you are seeking to do can be

> done in other
> > > ways, so change your approach to fit in with the way that

> PHP works.
> >
> > I don't necessarily buy into his argument, but he did say

> they could
> simply
> > add include_relative rather than change the way include works.

> Other than
> a
> > relatively minor issue of how it would affect require_once and
> > include_once, depending on how relative paths get resolved (if at

> all), I
> > can't think of what other effect it would have on existing

> scripts.
>
> Well, if you want include_relative then go code it yourself. The
> runtime
> nature of include/require allows you to do that.


Thanks, Chung. It can be done via coding. It is a problem [still]
when you want to integrate a 3rd party script with many calls insider
your own script. Not everyone does it the same way.


Then the person who designed and built these 3rd party scripts should have
done his job properly.

--
Tony Marston

http://www.tonymarston.net
--
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=444479
Jul 17 '05 #37
Tony Marston wrote:
"Zurab Davitiani" <ag*@mindless.com> wrote in message
I don't necessarily buy into his argument, but he did say they could simply
add include_relative rather than change the way include works. Other than

a
relatively minor issue of how it would affect require_once and
include_once, depending on how relative paths get resolved (if at all), I
can't think of what other effect it would have on existing scripts.


<snip> This is the way that PHP was designed to work and I have designed my code
accordingly. So people who expect PHP to work contrary to the way it was
designed and then keep bitching about it are not going to get very far. My
advice is - learn how PHP works and design your code accordingly.


My advice - try reading or understanding what you are replying to. What
steve suggested was an additional include_relative directive that would
have *no effect* on existing include calls; include behavior itself would
*not* change; it would simply be an additional functionality added by
include_relative.

At least that's what steve suggested, and I tried to point out.

Now, I personally don't agree that include_relative will help significantly
in making scripts consistent, but I do understand his argument.
Jul 17 '05 #38
steve wrote:
Yes, my goal is consistency...


<snip>

I don't think something like include_relative will help in consistency.

First, because the include (and require) can be used for different purposes
for PHP scripts - including content, and including function libraries and
classes (and their dependencies). Because one (or similar) calls can be
used for different purposes developers are still likely to use their own
wrappers around them. i.e., custom include functions for including content,
and function library or class package "manager" type wrappers. Maybe PHP5's
__autoload could attempt to alleviate some of this but, again, nobody's
required to use it, so it probably won't.

Second, it (include_relative) would be just one more way to accomplish the
same thing as you already can. So, it in fact would probably add to
inconsistency as some will stick to the current method of resolving from
absolute paths while others would pick the new relative method, resulting
in a bigger mess.

That's the way I see it anyway.
Jul 17 '05 #39

"Zurab Davitiani" <ag*@mindless.com> wrote in message
news:o9******************@newssvr29.news.prodigy.c om...
Tony Marston wrote:

<snip>
This is the way that PHP was designed to work and I have designed my code accordingly. So people who expect PHP to work contrary to the way it was
designed and then keep bitching about it are not going to get very far. My advice is - learn how PHP works and design your code accordingly.


My advice - try reading or understanding what you are replying to. What
steve suggested was an additional include_relative directive that would
have *no effect* on existing include calls; include behavior itself would
*not* change; it would simply be an additional functionality added by
include_relative.


The OP was complaining that he saw no reason why the include() function
should work the way that it does (i.e. relative to the top-level script) and
that it should be changed to work the way that HE wants it to (i.e. relative
to the current script). The option to have a separate include_relative()
function came later. If the authors of PHP see any merit in this new
function I am sure they will take steps to incorporate it into their code,
but as others have pointed out it would be far quicker to write your own
user-defined function to handle relative includes.

--
Tony Marston

http://www.tonymarston.net

Jul 17 '05 #40
.oO(eclipsboi)
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"


JFTR: This only works when PHP runs as an Apache module, you can't use
it for the CGI version.

Micha
Jul 17 '05 #41
On Mon, 26 Jul 2004 17:57:56 +0100, Michael Fesser <ne*****@gmx.net>
wrote:
.oO(eclipsboi)
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"


JFTR: This only works when PHP runs as an Apache module, you can't use
it for the CGI version.

Micha


I understand different situations may not work for my suggestion,
hence the YMMV comment. It was just one suggestion out of many that
I've seen. You could easily break it down to keeping it all very
simple. :)
Jul 17 '05 #42
I manage several sites that each have many contributors.

I simply laid down the rules for everyone to follow ... for example ...

"All links, images, flash objects, form actions etc... are to be referred to
by their full UNC path name ...

therefore http://www.mydomain.com/style.css is acceptable where as
../style.css or style.css are not.

A number of internet and intranet addresses are defined in the
definitions.php file which will assist you ... such as

$mydomain = http://www.mydomain.com/;

This way all they have to do to include a file is include($mydomain .
"myfile.php");

Paul.
Jul 17 '05 #43
On Tue, 27 Jul 2004 17:09:10 +0100, Paul C-T wrote:
I manage several sites that each have many contributors.

I simply laid down the rules for everyone to follow ... for example ...

"All links, images, flash objects, form actions etc... are to be referred to
by their full UNC path name ...

therefore http://www.mydomain.com/style.css is acceptable where as
./style.css or style.css are not.

What about '/styles.css'? Would perform the exact same task without
limiting the coder to a specific domain name.


A number of internet and intranet addresses are defined in the
definitions.php file which will assist you ... such as

$mydomain = http://www.mydomain.com/;

This way all they have to do to include a file is include($mydomain .
"myfile.php");

Paul.

Sounds overly complicated and a PITA to me.. as it means I'd have to
change at least one value between my dev server and my live server.

Regards,

Ian

--
Ian.H
digiServ Network
London, UK
http://digiserv.net/

Jul 17 '05 #44

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: steve | last post by:
Hi, I need to do conditional script "include", but like to pull the code from db instead of a file. How do I do that? Reason: I like to implement some complex regex logic, and make it table...
4
by: martijn | last post by:
H! I'm trying to find a python function to use like this: -- maincode.py Include "apythonscript_function.py" -- end
18
by: Steven Borrelli | last post by:
Hello, I am using the <?php include() ?statement on my website for organizational purposes. However, one of my includes contains some PHP code. Is there any way for the server to actually...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.