Jump to content

Recommended Posts

I know how to use $_SERVER['DOCUMENT_ROOT'] with the include function to grab a file.

 

I've tried using a similar approach to grab an image:

 

<img src="<?php echo $_SERVER['DOCUMENT_ROOT'];?>/images/logo.png">

 

This does not work. The above code is part of my header page (header.php) which itself is included (by way of PHP INCLUDE) on every page of my site. The problem is that the header page will be included in the pages found in subdirectories like /forum or /blog (or sub-sub-directories like /forum/theme/theme1) which is why I'm using the shortcut to the relative path.

 

Q1 - In this case, should I just type in the absolute path without defining it using PHP?

Q2 - I want all my images to be stored in the /images folder in my root directory. If I have subdirectories like /forum and /blog (also sitting in my root directory where /images is) calling on images stored in the aforementioned /image folder will this affect load time? i.e. Is it better to just make a copy of the /images folder from my root directory to the specific subdirectories (e.g. /forum/theme/theme1/images) for better load time? Bare in mind that SMF and Wordpress have their own image folders for each specific theme.

 

In a nutshell, do I opt for using duplicated image files in each directory, sub-directory, sub-sub-directory etc. containing an /image folder or do I try and use some nifty approach to defining my paths so that all images are sourced from the one /image folder in my root (home) directory (and if so, what's wrong with my above code)?.  :o:shrug:

 

My terminology could be off so when I say 'my root directory' I mean my upper most layer where my home page is to be found.  :shy:

 

When you include a path for an include file it is relative to the server, whereas the path for an image is relative to the browser. Two completely different things. Assuming your images folder is at the root of the site folder you can just use the following:

 

<img src="images/logo.png">

 

Without the leading forward slash. Then it tells the browser that the path is relative from the root of the site. If you use the leading forward slash then the path is relative from the location of the document being viewed.

After trial and error the following is my understanding of how paths work based on what you've explained. Let me know if I'm incorrect (a humble request, not a demand  :P):

 

The use of a forward slash before the path of an image determines whether the path is relative or absolute. The use of a forward slash before the path of an include file in PHP will produce an error if you are attempting to define an absolute path as you would an image path but will work if you are defining a relative path so long as the relevant subdirectories or files exist. To correctly define an absolute path for an included file either use the full extent of the path or use a predefined variable as part of a string of the path. Incidentally, adding forward slash before an absolute path for included file will not produce an error message.

 

The use of a forward slash before the path of an include file in PHP will produce an error if you are attempting to define an absolute path as you would an image path

"As you would an image path", Normally they are defined relative to the current file, What are you going on about it creating an error?

include('/http://site.com/image/script.php');

Will obviously produce an error. As for relativity the slash is not even needed unless you require recursion.

 

 

As for "How it effects load time." Do you want to assign the 0.2MS to your server or their browser for path calculation?

For images, js and css you can use $_SERVER['HTTP_HOST']. eg;

 

<img src="<?php echo $_SERVER['HTTP_HOST'];?>/images/logo.png">

 

This would produce http://yourdomainname.com/images/logo.png

 

Or, simply use relative paths to your images, js or css files. Of course if your img tags are within php files that are going to be included by other files the urls need to be relative to the calling php file.

I’ll be the first to admit that I’m having a blonde moment but I need to understand this nonetheless. I’m getting totally confused on how the forward slash behaves. Can someone please correct me on my understanding of image paths. I'm not going to bother with the file include paths until I can grasp this much:

 

[*]My understanding of the presence of a preceding forward slash in a path is that it always means 'relative to the location of the html document'.

[*]My understanding of the absence of a preceding forward slash in a path is that it always means 'relative to the root of the site folder'.

 

I've been using variations of the following HTML document to create the below study and test the effects of the preceding forward slash on an image path:

<img src="someimagefolder/someimage.jpg"> 
<img src="/someimagefolder/someimage.jpg">

 

paths.png

 

If someone could just answer the two questions in the image then I'm sure I'll be able to bridge the gap. Thanks in advance.

 

I've also included the table as a word document.

 

 

 

 

 

 

 

[attachment deleted by admin]

You're critically missing the point of a relative/absolute path.

 

Your question is invalid. Preceding slash or NOT it will display the same result and parse as the same path, this has behavior has been defined for, ~50 years?

 

Are you sure that is your reproduction code? In *nix, paths are defined by the root (IE: "/" ) and HTML 2.0> provides the <base> element to overcome relative url paths. It should not default to root, it is not web browser behaviour.

You're critically missing the point of a relative/absolute path.

 

I'm more than aware of that. I wouldn't be stuck in this rut on such a rudimentary issue otherwise. I've tried my best to disseminate the logic but even when I did it's still not adding up (to me at least).

 

Your question is invalid. Preceding slash or NOT it will display the same result and parse as the same path, this has behavior has been defined for, ~50 years?

 

If you look at mjdamatos post, is he not implying something different or have I misinterpreted what he's saying?

 

Are you sure that is your reproduction code?

 

I'm not too sure what you're asking. I've attached the original word document and the gist of the HTML I was working with to derive the results. I've literally just finished it by way of trial and error.

 

In *nix, paths are defined by the root (IE: "/" ) and HTML 2.0> provides the <base> element to overcome relative url paths. It should not default to root, it is not web browser behaviour.

 

I'm using cPANEL. Might that have something to do with it?

 

 

I'm not sure what he's going on about, but he's not talking about HTML. An include file such as in PHP will be effected by that behaviour, but in HTML the browser would and should base the relative url based on the current viewed document.

 

root/a/file.html 

root/b/file.html

root/c/image.png

 

You can either to access the image:

      A) Use an absoute path, 'root/c/image.png' or '/root/c/image.png'

or    B) Use a relative path, '../c/image.png'

 

Either way, a trailing slash will be the same within HTML specification.

Your question is invalid. Preceding slash or NOT it will display the same result and parse as the same path, this has behavior has been defined for, ~50 years?

 

What? In relation to images, js and css a path starting with a slash / refers to the servers document root. So an image in '/foo/img.jpg' is within a sub-directory (of the servers document root) called foo (http://domain.com/foo/img.jpf).

 

However, if you have a document within /foo and (from within that document) you source an image from 'foo/img.jpg' you will actually be referring to an image within /foo/foo/img.jpg. That is, a sub-directory (of the document root) called foo with another sub-directory called foo (http://domain.com/foo/foo/img.jpg).

 

So,  'foo/img.jpg' &  '/foo/img.jpg' do NOT necessarily point to the same location.

What? In relation to images, js and css a path starting with a slash / refers to the servers document root. So an image in '/foo/img.jpg' is within a sub-directory (of the servers document root) called foo (http://domain.com/foo/img.jpf).

 

But what if I have two subdirectories:  http://domain.com/foo/img.jpg and http://domain.com/bar/document.html?

 

Can you explain to me what's happening if the html document in bar consists of:

 

<img src="foo/img.jpg"><!-- without / -->
<img src="/foo/img.jpg"><!-- with / -->

 

The first path without the slash (foo/img.jpg) doesn't work. Why not? Should it not lead to http://domain.com/foo/img.jpg since the absence of the slash should mean 'relative to the root of the site folder'?

 

The second path with the slash (/foo/img.jpg) does work. Why? Should it not lead to http://domain.com/foo/foo/img.jpg since the presence of the slash should mean 'relative to the location of the html document'?

 

(This is the problem I was trying to describe in scenario four of study(table) I provided above)

 

 

foo/img.jpg - path is relative to the directory of the content the user is looking at.  I.e., if you have a page at the following path:

 

http://mydomain.com/news/today.html

 

foo/img.jpg would actually be the path of http://mydomain.com/news/foo/img.jpg

 

/foo/img.jpg - path is relative to the web root.  All instances of this are actually http://mydomain.com/foo/img.jpg

foo/img.jpg - path is relative to the directory of the content the user is looking at.  I.e., if you have a page at the following path:

 

http://mydomain.com/news/today.html

 

foo/img.jpg would actually be the path of http://mydomain.com/news/foo/img.jpg

 

/foo/img.jpg - path is relative to the web root.  All instances of this are actually http://mydomain.com/foo/img.jpg

 

Fine. You're saying the following:

  • no slash is relative to the directory of the content.
  • slash is relative to the webroot.

 

mjdamato, another guru, at the beginning of the post said the exact opposite is the case here:

 

Assuming your images folder is at the root of the site folder you can just use the following: <img src="images/logo.png">. Without the leading forward slash. Then it tells the browser that the path is relative from the root of the site.

 

He's saying that:

  • no slash is relative to web root.

 

You're saying:

  • slash is relative to web root.

 

Whose right and whose wrong or are you both right and I'm missing out on something?

 

 

 

Just tested it.  I'm right.  See here, and look at the source:

 

http://www.helgaseibert.com/test/blah.html

 

EDIT: the second attempt - without the leading slash - looks for closets.jpg within the test folder.  It doesn't exist, so it displays the image's alt attribute value instead.

 

Are you familiar with *nix file systems?  Most servers run on an Apache server on a *nix system.  The way paths work is exactly the same as the *nix file system because, well, that's what you're using under the hood.

Yeah, I got it backwards. So sue me. Personally, I don't get a wrapped up in these types of details. If I'm writing new code and it doesn't work it takes two seconds to see that the path was defined incorrectly and to fix it. Sorry for the confusion.

Just tested it.  I'm right.  See here, and look at the source:

 

http://www.helgaseibert.com/test/blah.html

 

Cheers for the demo. Makes perfect sense.

 

Would I be correct to assume that '/' has the same effect on the paths I define for files using the include function?

 

I  understand how to use predefined variables for ABSOLUTE paths for file includes...

 

<?php include($_SERVER['DOCUMENT_ROOT'].”/somefolder/somedocument.html”);?>

 

and as Thorpe pointed out for an image, js or css it would be...

 

<img src="<?php echo $_SERVER['HTTP_HOST'];?>/images/logo.png">

 

... but let's say I want to define the path for a file include RELATIVELY. Will the '/' behave in the same manner as your demo or as you put it, will it be relative to directory of the content?

 

<?php include(“somefolder/somedocument.html”); ?>

 

Furthermore, will the path with '/' be relative to webroot?:

 

<?php include(“/somefolder/somedocument.html”); ?>

 

Are you familiar with *nix file systems?  Most servers run on an Apache server on a *nix system.  The way paths work is exactly the same as the *nix file system because, well, that's what you're using under the hood.

 

No, but I'll look into it: http://lifehacker.com/273016/learn-the-nix-filesystem

 

Personally, I don't get a wrapped up in these types of details. If I'm writing new code and it doesn't work it takes two seconds to see that the path was defined incorrectly and to fix it.

 

I see where your coming from. It's easier to discern by execution rather than in theory to be fair. I just wanted to nail it down before I began planning out my subdirectories and how I'm handling my image files. My main concern was that if I use absolute paths to one universal image directory in my webroot then my images might load slower for the subdirectories (e.g. /blog) than if I instead had individual image folders sitting in each subdirectory.

 

<img src="<?php echo $_SERVER['HTTP_HOST'];?>/images/logo.png">

 

Thanks for this, Thorpe.

 

 

 

@Nightslyr: Never mind about the file include paths. I forgot that the file include path is relative to the server. The path only seems to work with the predefined $_SERVER variable so I guess it's always  going to be an absolute path.

 

<?php include($_SERVER['DOCUMENT_ROOT']."/include/metadata.php"); ?>

 

 

 

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.