2009/2/18 PJ :
> Paul M Foster wrote:
>> On Wed, Feb 18, 2009 at 12:05:21PM -0500, PJ wrote:
>>
>>> Stuart wrote:
2009/2/18 PJ :
> Stuart wrote:
>
>>
>>
>>
>>> What confused me here is that often, in examples, there are all sorts of
>>> references to files
Johnny wrote:
Hi Thodoris,
In my opinion, the best use is to include your file with relative urls,
like :
I believe that it best.
Including the hostname use to cause a dns lookup in some browsers which
made it slower but I don't believe that is the case anymore.
Doing the full path rel
Paul M Foster wrote:
> On Wed, Feb 18, 2009 at 12:05:21PM -0500, PJ wrote:
>
>> Stuart wrote:
>>> 2009/2/18 PJ :
>>>
Stuart wrote:
>>>
>>>
>
>
>
>>>
>> What confused me here is that often, in examples, there are all sorts of
>> references to files and there seems to be no standa
Bastien Koert wrote:
> On Wed, Feb 18, 2009 at 12:05 PM, PJ wrote:
>
>> Stuart wrote:
>>> 2009/2/18 PJ :
>>>
Stuart wrote:
>>>
>>>
This generates a Fatal error: Cal to undefined function dirname()
>>
>>> The dirname function is present in both PHP 4 and 5 and does
On Wed, Feb 18, 2009 at 12:05:21PM -0500, PJ wrote:
> Stuart wrote:
> > 2009/2/18 PJ :
> >
> >> Stuart wrote:
> >>
> >
> >
> >
> >
> What confused me here is that often, in examples, there are all sorts of
> references to files and there seems to be no standard as to how to refer
> to
---
Use FreeOpenSourceSoftwares, Stop piracy, Let the developers live. Get
a Free CD of Ubuntu mailed to your door without any cost. Visit :
www.ubuntu.com
--
On
On Wed, Feb 18, 2009 at 12:05 PM, PJ wrote:
> Stuart wrote:
> > 2009/2/18 PJ :
> >
> >> Stuart wrote:
> >>
> >
> >
> >> This generates a Fatal error: Cal to undefined function dirname()
>
> >>
> >
> > The dirname function is present in both PHP 4 and 5 and does not rely
> > on
Stuart wrote:
> 2009/2/18 PJ :
>
>> Stuart wrote:
>>
>
>
>> This generates a Fatal error: Cal to undefined function dirname()
>>
>
> The dirname function is present in both PHP 4 and 5 and does not rely
> on any external libraries. Are you sure you're spel
PJ wrote:
> Stuart wrote:
>> 2009/2/17 PJ :
>>
>>> Stuart wrote:
>>>
2009/2/17 PJ :
> Dotan Cohen wrote:
>
>
So put it all in one place:
>>> include "path.inc";
print"";
?>
Full URL
Thodoris a écrit :
Here's a question related to my last post. When specifying a link in a
HTML file (like to the css or an image file), there are two ways of
doing it. One is to simply include the relative path to the file
(relative to the doc root), like:
/graphics/my_portrait.gif
Or you can
---
Use FreeOpenSourceSoftwares, Stop piracy, Let the developers live. Get
a Free CD of Ubuntu mailed to your door without any cost. Visit :
www.ubuntu.com
--
On
2009/2/18 PJ :
> Stuart wrote:
> This generates a Fatal error: Cal to undefined function dirname()
The dirname function is present in both PHP 4 and 5 and does not rely
on any external libraries. Are you sure you're spelling it right?
http://php.net/dirname
> I must be really den
Stuart wrote:
>>>
This generates a Fatal error: Cal to undefined function dirname()
I must be really dense...
What I don't understand in the above is this - dirname refers to what
directory? -- the directory of the file that is including? what if the
directory is the root directory of t
Stuart wrote:
> 2009/2/17 PJ :
>
>> Stuart wrote:
>>
>>> 2009/2/17 PJ :
>>>
>>>
Dotan Cohen wrote:
>>> So put it all in one place:
>>>
>>> >> include "path.inc";
>>> print"";
>>> ?>
>>>
>>> Full URLs don't break when users save
2009/2/18 PJ :
> Stuart wrote:
>> 2009/2/17 PJ :
>>
>>> Stuart wrote:
>>>
2009/2/17 PJ :
> Dotan Cohen wrote:
>
>
So put it all in one place:
>>> include "path.inc";
print"";
?>
Full URLs don't break when
2009/2/17 PJ :
> Stuart wrote:
>> 2009/2/17 PJ :
>>
>>> Dotan Cohen wrote:
>>>
>> So put it all in one place:
>>
>> > include "path.inc";
>> print"";
>> ?>
>>
>> Full URLs don't break when users save the pages to disk.
>>
> That would be fine if the pages wer
PJ wrote:
my server is FreeBSD 7.0
My situation is this: I am evolving www.ptahhotep.com from pure HTML to
php-mysql-css (not an easy task for a newbie :-) )
The challenge is to set up the web site on my local server and then move
it all to my web host.
Unless I am mistaken, I am pretty sure I
Stuart wrote:
> 2009/2/17 PJ :
>
>> Dotan Cohen wrote:
>>
> So put it all in one place:
>
> include "path.inc";
> print"";
> ?>
>
> Full URLs don't break when users save the pages to disk.
>
That would be fine if the pages weren't being c
Michael A. Peters wrote:
> PJ wrote:
>> Michael A. Peters wrote:
>>> PJ wrote:
>>>
I hope I'm not out of place here, but I have a problem that seems
to be
related.
I am using some include statements for page headers with the pages in
various directories on the site. The pro
PJ wrote:
Michael A. Peters wrote:
PJ wrote:
I hope I'm not out of place here, but I have a problem that seems to be
related.
I am using some include statements for page headers with the pages in
various directories on the site. The problem is this... if I put
relative statements in the page (
Michael A. Peters wrote:
> PJ wrote:
>
>>>
>> I hope I'm not out of place here, but I have a problem that seems to be
>> related.
>> I am using some include statements for page headers with the pages in
>> various directories on the site. The problem is this... if I put
>> relative statements in th
2009/2/17 PJ :
> Dotan Cohen wrote:
So put it all in one place:
>>> include "path.inc";
print"";
?>
Full URLs don't break when users save the pages to disk.
>>> That would be fine if the pages weren't being crafted in Dreamweaver,
>>> where inserting links like th
> Easy to solve.
>
> ini_set("include_path",
> "/srv/domain/phpinclude:/srv/domain/record_include:/srv/domain/process_include");
>
> Then just call it without path - IE
>
> include('foo.inc');
>
> php will first look for foo.inc in /srv/domain/phpinclude, then in
> /srv/domain/record_include, etc.
> > Alternatively, $_SERVER['PHP_SELF']) could be switch()ed for known
> > values, and $path be set accordingly with hardcoded values.
>> Didn't notice this thread passing from the list. I will look into it.
>
> But sometimes you need to detect where something is located and that's the
> point of t
PJ wrote:
I hope I'm not out of place here, but I have a problem that seems to be
related.
I am using some include statements for page headers with the pages in
various directories on the site. The problem is this... if I put
relative statements in the page (header.php) like ../images/file.jpg
Dotan Cohen wrote:
>>> So put it all in one place:
>>>
>>> >> include "path.inc";
>>> print"";
>>> ?>
>>>
>>> Full URLs don't break when users save the pages to disk.
>> That would be fine if the pages weren't being crafted in Dreamweaver,
>> where inserting links like that is a pain.
>>
>
> For th
for that matter, you could use variables to specify the relative path to make
it absolute within each of the production and dev environments.
Another possible solution I can think is building configuration files
that could include the paths and parse them to find the path every time
y
I know it's been said before, but beware of relying on this value just
for the sole purpose of deciding where things are located, as without a
bit of error checking on it, it can be used for injection attacks and
what-not, although, sadly, I forget the exact post recently that had the
link that
Lewis Wright wrote:
> But that's where mistakes are often made. It also means you need to
> maintain a different live version to that of your development version.
> If find it much easier to have relative paths and then there's no
> build process needed to go live, I can just upload it.
>
> 2009/2
But that's where mistakes are often made. It also means you need to
maintain a different live version to that of your development version.
If find it much easier to have relative paths and then there's no
build process needed to go live, I can just upload it.
2009/2/17 Michael A. Peters :
> Virgil
Virgilio Quilario wrote:
> The difference is in manageability.
> Copying the scripts to another domain and you're using full url for
> your src and href when referring to local images or css or pages, will
> give you trouble and you must change all of them to your new domain.
which takes about 3
On Tue, Feb 17, 2009 at 11:22:32AM +, Stuart wrote:
> 2009/2/17 Paul M Foster :
>
> Maintaining identical development, staging and live environments is
> one of the key components of reliable, repeatable and streamlined
> development, testing and deployment, but if you're happy with what
>
> Here's a question related to my last post. When specifying a link in a
> HTML file (like to the css or an image file), there are two ways of
> doing it. One is to simply include the relative path to the file
> (relative to the doc root), like:
>
> /graphics/my_portrait.gif
>
> Or you can include
2009/2/17 Paul M Foster :
> On Mon, Feb 16, 2009 at 08:49:06PM +, Stuart wrote:
>
>> 2009/2/16 Paul M Foster :
>
>
>
>> >
>> > Agreed. But here's the real reason, in my case. We develop the pages on
>> > an internal server, which has the URL http://pokey/mysite.com. When we
>> > move the pages
On Mon, Feb 16, 2009 at 08:49:06PM +, Stuart wrote:
> 2009/2/16 Paul M Foster :
> >
> > Agreed. But here's the real reason, in my case. We develop the pages on
> > an internal server, which has the URL http://pokey/mysite.com. When we
> > move the pages to the live server at mysite.com, all
2009/2/16 Paul M Foster :
> On Mon, Feb 16, 2009 at 07:39:29PM +0200, Thodoris wrote:
>
>>
>>> Here's a question related to my last post. When specifying a link in a
>>> HTML file (like to the css or an image file), there are two ways of
>>> doing it. One is to simply include the relative path to t
Tim-Hinnerk Heuer
http://www.ihostnz.com
Mike Ditka - "If God had wanted man to play soccer, he wouldn't have given
us arms."
2009/2/17 Paul M Foster
> On Mon, Feb 16, 2009 at 07:39:29PM +0200, Thodoris wrote:
>
> >
> >> Here's a question related to my last post. When specifying a link in a
>
> I know it's been said before, but beware of relying on this value just
> for the sole purpose of deciding where things are located, as without a
> bit of error checking on it, it can be used for injection attacks and
> what-not, although, sadly, I forget the exact post recently that had the
> lin
On Mon, 2009-02-16 at 20:19 +0200, Thodoris wrote:
> > On Mon, Feb 16, 2009 at 07:39:29PM +0200, Thodoris wrote:
> >
> >
> >>> Here's a question related to my last post. When specifying a link in a
> >>> HTML file (like to the css or an image file), there are two ways of
> >>> doing it. One is t
>> So put it all in one place:
>>
>> > include "path.inc";
>> print"";
>> ?>
>>
>> Full URLs don't break when users save the pages to disk.
>
> That would be fine if the pages weren't being crafted in Dreamweaver,
> where inserting links like that is a pain.
>
For that you'd have to ask on the Dre
On Mon, Feb 16, 2009 at 08:09:51PM +0200, Dotan Cohen wrote:
> > Agreed. But here's the real reason, in my case. We develop the pages on
> > an internal server, which has the URL http://pokey/mysite.com. When we
> > move the pages to the live server at mysite.com, all the URLs would have
> > to be
On Mon, Feb 16, 2009 at 07:39:29PM +0200, Thodoris wrote:
Here's a question related to my last post. When specifying a link in a
HTML file (like to the css or an image file), there are two ways of
doing it. One is to simply include the relative path to the file
(relative to the doc root), l
> Agreed. But here's the real reason, in my case. We develop the pages on
> an internal server, which has the URL http://pokey/mysite.com. When we
> move the pages to the live server at mysite.com, all the URLs would have
> to be rewritten. Ugh.
>
> Paul
>
So put it all in one place:
";
?>
Full
On Mon, Feb 16, 2009 at 07:39:29PM +0200, Thodoris wrote:
>
>> Here's a question related to my last post. When specifying a link in a
>> HTML file (like to the css or an image file), there are two ways of
>> doing it. One is to simply include the relative path to the file
>> (relative to the doc r
Here's a question related to my last post. When specifying a link in a
HTML file (like to the css or an image file), there are two ways of
doing it. One is to simply include the relative path to the file
(relative to the doc root), like:
/graphics/my_portrait.gif
Or you can include the full UR
Should be the same as the dns request is cached and a request needs to be
made anyway.
You could argue that relative URLs are less secure, but i cannot really see
why. Well i guess someone can easier steal your source but it doesnt get
much harder with absolute URLs.
Tim-Hinnerk Heuer
http://www
> My casual observation seems to indicate that the former will load faster
> than the latter. But has anyone done any benchmarking on it?
Did you clear the cache between tests? That could explain the speed difference.
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
א-ב-ג-ד-ה-ו-ז-
Paul M Foster wrote:
> Here's a question related to my last post. When specifying a link in a
> HTML file (like to the css or an image file), there are two ways of
> doing it. One is to simply include the relative path to the file
> (relative to the doc root), like:
>
> /graphics/my_portrait.gif
Here's a question related to my last post. When specifying a link in a
HTML file (like to the css or an image file), there are two ways of
doing it. One is to simply include the relative path to the file
(relative to the doc root), like:
/graphics/my_portrait.gif
Or you can include the full URL,
49 matches
Mail list logo
