Home > Archive > PHP Language > July 2004 > Frustrated with PHP’s "include"
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
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-Frustra...pict132935.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbForumz.com/eform.php?p=443884
| |
| J.O. Aho 2004-07-24, 8:55 pm |
| 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 2004-07-24, 8:55 pm |
| 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...
| |
|
| "neur0maniak" wrote:
> steve wrote:
of[color=darkred]
> this
is[color=darkred]
adjust[color=darkred]
>
> 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-Frustra...pict132935.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbForumz.com/eform.php?p=443945
| |
| eclipsboi 2004-07-24, 8:55 pm |
| On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
<usenet@neur0maniak.co.uk> wrote:
>steve wrote:
>
>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.
| |
| Edward Alfert 2004-07-24, 8:55 pm |
| eclipsboi <eclipsboi@hotmail.com> wrote in
news:e4p5g05r3256nm9fa2d8gosf29bnrsk6ip@
4ax.com:
> On Sat, 24 Jul 2004 22:15:22 +0100, neur0maniak
> <usenet@neur0maniak.co.uk> wrote:
>
>
> 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
| |
|
| "Edward Alfert" wrote:
> eclipsboi <eclipsboi@hotmail.com> wrote in
> news:e4p5g05r3256nm9fa2d8gosf29bnrsk6ip@
4ax.com:
>
> a ton of
> designed like this
> script that is
> script.
> and adjust
> these
> that is
> can include
> .htaccess
> (,
> to
> that
> be
>
>
> 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-Frustra...pict132935.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbForumz.com/eform.php?p=443980
| |
| Edward Alfert 2004-07-24, 8:55 pm |
| steve <UseLinkToEmail@dbForumz.com> wrote in
news:10g5qfija5bef6a@news.supernews.com:
> "Edward Alfert" wrote:
> the
>
> 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 2004-07-24, 8:55 pm |
| On 24 Jul 2004 22:49:10 GMT, Edward Alfert <ealfert@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.
| |
| eclipsboi 2004-07-24, 8:55 pm |
| On Sat, 24 Jul 2004 23:00:02 -0000, steve
<UseLinkToEmail@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.
| |
| eclipsboi 2004-07-24, 8:55 pm |
| On 24 Jul 2004 23:16:10 GMT, Edward Alfert <ealfert@rootmode.com>
wrote:
>steve <UseLinkToEmail@dbForumz.com> wrote in
>news:10g5qfija5bef6a@news.supernews.com:
>
>
>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.
| |
| eclipsboi 2004-07-24, 8:55 pm |
| On Sat, 24 Jul 2004 23:33:26 GMT, eclipsboi <eclipsboi@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.
| |
| Anders K. Madsen 2004-07-25, 3:55 am |
| On Sat, 24 Jul 2004 23:00:02 -0000
steve <UseLinkToEmail@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."
| |
| Drazen Gemic 2004-07-25, 3:55 pm |
| > 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
| |
| eclipsboi 2004-07-26, 3:56 pm |
| On Mon, 26 Jul 2004 17:57:56 +0100, Michael Fesser <netizen@gmx.net>
wrote:
> .oO(eclipsboi)
>
>
>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. :)
|
|
|
|
|