| fopen Problem [message #175242] |
Mon, 29 August 2011 00:21  |
Call Me Tom
Messages: 9
Registered: August 2011
Karma: 0
|
Junior Member |
|
|
I have the following statement in om=ne of my PHP scripts:
$rep_file = @fopen($report,"r");
Until recently the the file opened properly on my local test system
and my web host. My web host has upgraded to a newer version of PHP
and I noticed that the core configuration parameter "allow_url_fopen"
is coded off. My test system, which still works, is coded on. I
assume that this is the source of my problem and am hoping one of you
will suggest a work around.
Please keep in mind that I have minimal PHP experience and that I have
no control over the host configuration.
Thanks,
Tom
|
|
|
|
| Re: fopen Problem [message #175244 is a reply to message #175242] |
Mon, 29 August 2011 00:43  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 8/28/2011 8:21 PM, Call Me Tom wrote:
> I have the following statement in om=ne of my PHP scripts:
>
> $rep_file = @fopen($report,"r");
>
> Until recently the the file opened properly on my local test system
> and my web host. My web host has upgraded to a newer version of PHP
> and I noticed that the core configuration parameter "allow_url_fopen"
> is coded off. My test system, which still works, is coded on. I
> assume that this is the source of my problem and am hoping one of you
> will suggest a work around.
>
> Please keep in mind that I have minimal PHP experience and that I have
> no control over the host configuration.
>
> Thanks,
> Tom
What's in $report?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: fopen Problem [message #175245 is a reply to message #175242] |
Mon, 29 August 2011 00:44 |
Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
|
Member |
|
|
On 8/28/11 8:21 PM, Call Me Tom wrote:
> I have the following statement in om=ne of my PHP scripts:
>
> $rep_file = @fopen($report,"r");
>
> Until recently the the file opened properly on my local test system
> and my web host. My web host has upgraded to a newer version of PHP
> and I noticed that the core configuration parameter "allow_url_fopen"
> is coded off. My test system, which still works, is coded on. I
> assume that this is the source of my problem and am hoping one of you
> will suggest a work around.
>
> Please keep in mind that I have minimal PHP experience and that I have
> no control over the host configuration.
>
> Thanks,
> Tom
If $report has a value like "http://example.com/page", than yes, that is
the source of your problem.
If $report is referring to a "normal" file path to a file on the server
(like "subdir/file" or "/home/usr/me/myfile") then it isn't.
|
|
|
|
| Re: fopen Problem [message #175246 is a reply to message #175245] |
Mon, 29 August 2011 03:04 |
Call Me Tom
Messages: 9
Registered: August 2011
Karma: 0
|
Junior Member |
|
|
On Sun, 28 Aug 2011 20:44:27 -0400, Richard Damon
<news(dot)x(dot)richarddamon(at)xoxy(dot)net> wrote:
> On 8/28/11 8:21 PM, Call Me Tom wrote:
>> I have the following statement in om=ne of my PHP scripts:
>>
>> $rep_file = @fopen($report,"r");
>>
>> Until recently the the file opened properly on my local test system
>> and my web host. My web host has upgraded to a newer version of PHP
>> and I noticed that the core configuration parameter "allow_url_fopen"
>> is coded off. My test system, which still works, is coded on. I
>> assume that this is the source of my problem and am hoping one of you
>> will suggest a work around.
>>
>> Please keep in mind that I have minimal PHP experience and that I have
>> no control over the host configuration.
>>
>> Thanks,
>> Tom
>
> If $report has a value like "http://example.com/page", than yes, that is
> the source of your problem.
>
> If $report is referring to a "normal" file path to a file on the server
> (like "subdir/file" or "/home/usr/me/myfile") then it isn't.
$report is
http://www.corporateairamerica.com/logbooks/CAA001/CAA00120110826160800.txt
This text file is in a subdirectory of my home directory. Instead of
using the above format, can I refer to the file in the fopen as simply
/logbooks/CAA001/blahblah.txt ?
Tom
|
|
|
|
| Re: fopen Problem [message #175247 is a reply to message #175246] |
Mon, 29 August 2011 03:09 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 8/28/2011 11:04 PM, Call Me Tom wrote:
> On Sun, 28 Aug 2011 20:44:27 -0400, Richard Damon
> <news(dot)x(dot)richarddamon(at)xoxy(dot)net> wrote:
>
>> On 8/28/11 8:21 PM, Call Me Tom wrote:
>>> I have the following statement in om=ne of my PHP scripts:
>>>
>>> $rep_file = @fopen($report,"r");
>>>
>>> Until recently the the file opened properly on my local test system
>>> and my web host. My web host has upgraded to a newer version of PHP
>>> and I noticed that the core configuration parameter "allow_url_fopen"
>>> is coded off. My test system, which still works, is coded on. I
>>> assume that this is the source of my problem and am hoping one of you
>>> will suggest a work around.
>>>
>>> Please keep in mind that I have minimal PHP experience and that I have
>>> no control over the host configuration.
>>>
>>> Thanks,
>>> Tom
>>
>> If $report has a value like "http://example.com/page", than yes, that is
>> the source of your problem.
>>
>> If $report is referring to a "normal" file path to a file on the server
>> (like "subdir/file" or "/home/usr/me/myfile") then it isn't.
>
> $report is
> http://www.corporateairamerica.com/logbooks/CAA001/CAA00120110826160800.txt
>
> This text file is in a subdirectory of my home directory. Instead of
> using the above format, can I refer to the file in the fopen as simply
> /logbooks/CAA001/blahblah.txt ?
>
> Tom
You can, but the results may be different.
The first question would be - why are you opening using a URL? It's not
normal to open a file from your own server like this, but there are
valid reasons for doing it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: fopen Problem [message #175248 is a reply to message #175247] |
Mon, 29 August 2011 04:19 |
Call Me Tom
Messages: 9
Registered: August 2011
Karma: 0
|
Junior Member |
|
|
On Sun, 28 Aug 2011 23:09:19 -0400, Jerry Stuckle
<jstucklex(at)attglobal(dot)net> wrote:
> On 8/28/2011 11:04 PM, Call Me Tom wrote:
>> On Sun, 28 Aug 2011 20:44:27 -0400, Richard Damon
>> <news(dot)x(dot)richarddamon(at)xoxy(dot)net> wrote:
>>
>>> On 8/28/11 8:21 PM, Call Me Tom wrote:
>>>> I have the following statement in om=ne of my PHP scripts:
>>>>
>>>> $rep_file = @fopen($report,"r");
>>>>
>>>> Until recently the the file opened properly on my local test system
>>>> and my web host. My web host has upgraded to a newer version of PHP
>>>> and I noticed that the core configuration parameter "allow_url_fopen"
>>>> is coded off. My test system, which still works, is coded on. I
>>>> assume that this is the source of my problem and am hoping one of you
>>>> will suggest a work around.
>>>>
>>>> Please keep in mind that I have minimal PHP experience and that I have
>>>> no control over the host configuration.
>>>>
>>>> Thanks,
>>>> Tom
>>>
>>> If $report has a value like "http://example.com/page", than yes, that is
>>> the source of your problem.
>>>
>>> If $report is referring to a "normal" file path to a file on the server
>>> (like "subdir/file" or "/home/usr/me/myfile") then it isn't.
>>
>> $report is
>> http://www.corporateairamerica.com/logbooks/CAA001/CAA00120110826160800.txt
>>
>> This text file is in a subdirectory of my home directory. Instead of
>> using the above format, can I refer to the file in the fopen as simply
>> /logbooks/CAA001/blahblah.txt ?
>>
>> Tom
>
> You can, but the results may be different.
>
> The first question would be - why are you opening using a URL? It's not
> normal to open a file from your own server like this, but there are
> valid reasons for doing it.
I didn't write the program so I don't know if there is a valid reason.
This is how it is used -
When a pilot clicks on his ID, a page is loaded that shows all his
flights in the format of a 3 col table. The columns being
Date/To/from. If the pilot then clicks on the date another page is
displayed showing the complete detail of that specific flight. The
text file in question is that complete log. It is output using
$rep_file = @fopen($report,"r");
while (!feof($rep_file))
{ $output = @htmlspecialchars(fgets($rep_file, 1024));
echo("$output<br />");
}
@fclose($rep_file);
Hope this helps.
Tom
|
|
|
|
| Re: fopen Problem [message #175250 is a reply to message #175248] |
Mon, 29 August 2011 11:36 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 8/29/2011 12:19 AM, Call Me Tom wrote:
> On Sun, 28 Aug 2011 23:09:19 -0400, Jerry Stuckle
> <jstucklex(at)attglobal(dot)net> wrote:
>
>> On 8/28/2011 11:04 PM, Call Me Tom wrote:
>>> On Sun, 28 Aug 2011 20:44:27 -0400, Richard Damon
>>> <news(dot)x(dot)richarddamon(at)xoxy(dot)net> wrote:
>>>
>>>> On 8/28/11 8:21 PM, Call Me Tom wrote:
>>>> > I have the following statement in om=ne of my PHP scripts:
>>>> >
>>>> > $rep_file = @fopen($report,"r");
>>>> >
>>>> > Until recently the the file opened properly on my local test system
>>>> > and my web host. My web host has upgraded to a newer version of PHP
>>>> > and I noticed that the core configuration parameter "allow_url_fopen"
>>>> > is coded off. My test system, which still works, is coded on. I
>>>> > assume that this is the source of my problem and am hoping one of you
>>>> > will suggest a work around.
>>>> >
>>>> > Please keep in mind that I have minimal PHP experience and that I have
>>>> > no control over the host configuration.
>>>> >
>>>> > Thanks,
>>>> > Tom
>>>>
>>>> If $report has a value like "http://example.com/page", than yes, that is
>>>> the source of your problem.
>>>>
>>>> If $report is referring to a "normal" file path to a file on the server
>>>> (like "subdir/file" or "/home/usr/me/myfile") then it isn't.
>>>
>>> $report is
>>> http://www.corporateairamerica.com/logbooks/CAA001/CAA00120110826160800.txt
>>>
>>> This text file is in a subdirectory of my home directory. Instead of
>>> using the above format, can I refer to the file in the fopen as simply
>>> /logbooks/CAA001/blahblah.txt ?
>>>
>>> Tom
>>
>> You can, but the results may be different.
>>
>> The first question would be - why are you opening using a URL? It's not
>> normal to open a file from your own server like this, but there are
>> valid reasons for doing it.
>
> I didn't write the program so I don't know if there is a valid reason.
> This is how it is used -
> When a pilot clicks on his ID, a page is loaded that shows all his
> flights in the format of a 3 col table. The columns being
> Date/To/from. If the pilot then clicks on the date another page is
> displayed showing the complete detail of that specific flight. The
> text file in question is that complete log. It is output using
>
> $rep_file = @fopen($report,"r");
> while (!feof($rep_file))
> { $output = @htmlspecialchars(fgets($rep_file, 1024));
> echo("$output<br />");
> }
> @fclose($rep_file);
>
> Hope this helps.
>
> Tom
Not really. A lot depends on what's in the file.
When you open a file locally, you get the file just as it exists on the
server. However, when you open it via a URL, you get the file after it
has been processed by the server.
As an example - if this file contained php code, opening it locally you
get the file containing the php code. However, opening it via the URL
would cause the PHP code to be executed and you would get the results of
the code.
Not knowing what the original programmer wanted makes this difficult.
However, from your description it sounds like a database would have been
much more appropriate to hold the data, I would suspect whoever wrote
it in the first place probably had no idea what he/she was doing and
there are a lot more problems in the application.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: fopen Problem [message #175251 is a reply to message #175246] |
Mon, 29 August 2011 11:37 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 29/08/2011 5:04, Call Me Tom escribió/wrote:
>> If $report has a value like "http://example.com/page", than yes, that is
>> the source of your problem.
>>
>> If $report is referring to a "normal" file path to a file on the server
>> (like "subdir/file" or "/home/usr/me/myfile") then it isn't.
>
> $report is
> http://www.corporateairamerica.com/logbooks/CAA001/CAA00120110826160800.txt
>
> This text file is in a subdirectory of my home directory. Instead of
> using the above format, can I refer to the file in the fopen as simply
> /logbooks/CAA001/blahblah.txt ?
If it's really a plain text file and it belongs to your site, the only
sensible way to open it is through the file system, i.e., providing its
path (absolute or relative) on the server's disc. The other syntax is
opening an HTTP connection and retrieving the file from the network.
The difference is exactly the same that exists between opening a
document from your hard disc and loading a web site in your browser.
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: fopen Problem [message #175254 is a reply to message #175242] |
Mon, 29 August 2011 20:45 |
A
Messages: 17
Registered: June 2011
Karma: 0
|
Junior Member |
|
|
> $rep_file = @fopen($report,"r");
>
> Until recently the the file opened properly on my local test system
> and my web host. My web host has upgraded to a newer version of PHP
> and I noticed that the core configuration parameter "allow_url_fopen"
> is coded off. My test system, which still works, is coded on. I
> assume that this is the source of my problem and am hoping one of you
> will suggest a work around.
>
> Please keep in mind that I have minimal PHP experience and that I have
> no control over the host configuration.
You may remove the @ before fopen which supresses error and see exact error
it prints out.
But if your allow_url_fopen is set to off you don't have much options as it
seems that this parameter cannot be set from ini_set or from .htaccess file
but only from php.ini file for security reasons.
Alternative is to use curl to open remote content.
<?php
function get_data($url)
{
$ch = curl_init();
$timeout = 5;
curl_setopt($ch,CURLOPT_URL,$url);
curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch,CURLOPT_CONNECTTIMEOUT,$timeout);
$data = curl_exec($ch);
curl_close($ch);
return $data;
}
$output =
@htmlspecialchars(get_data( http://www.corporateairamerica.com/logbooks/CAA001/CAA00120110826160800.txt'));echo("$output<br
/>");?>
|
|
|
|
| Re: fopen Problem [message #175255 is a reply to message #175250] |
Mon, 29 August 2011 23:15 |
Call Me Tom
Messages: 9
Registered: August 2011
Karma: 0
|
Junior Member |
|
|
On Mon, 29 Aug 2011 07:36:40 -0400, Jerry Stuckle
<jstucklex(at)attglobal(dot)net> wrote:
> On 8/29/2011 12:19 AM, Call Me Tom wrote:
>> On Sun, 28 Aug 2011 23:09:19 -0400, Jerry Stuckle
>> <jstucklex(at)attglobal(dot)net> wrote:
>>
>>> On 8/28/2011 11:04 PM, Call Me Tom wrote:
>>>> On Sun, 28 Aug 2011 20:44:27 -0400, Richard Damon
>>>> <news(dot)x(dot)richarddamon(at)xoxy(dot)net> wrote:
>>>>
>>>> > On 8/28/11 8:21 PM, Call Me Tom wrote:
>>>> >> I have the following statement in om=ne of my PHP scripts:
>>>> >>
>>>> >> $rep_file = @fopen($report,"r");
>>>> >>
>>>> >> Until recently the the file opened properly on my local test system
>>>> >> and my web host. My web host has upgraded to a newer version of PHP
>>>> >> and I noticed that the core configuration parameter "allow_url_fopen"
>>>> >> is coded off. My test system, which still works, is coded on. I
>>>> >> assume that this is the source of my problem and am hoping one of you
>>>> >> will suggest a work around.
>>>> >>
>>>> >> Please keep in mind that I have minimal PHP experience and that I have
>>>> >> no control over the host configuration.
>>>> >>
>>>> >> Thanks,
>>>> >> Tom
>>>> >
>>>> > If $report has a value like "http://example.com/page", than yes, that is
>>>> > the source of your problem.
>>>> >
>>>> > If $report is referring to a "normal" file path to a file on the server
>>>> > (like "subdir/file" or "/home/usr/me/myfile") then it isn't.
>>>>
>>>> $report is
>>>> http://www.corporateairamerica.com/logbooks/CAA001/CAA00120110826160800.txt
>>>>
>>>> This text file is in a subdirectory of my home directory. Instead of
>>>> using the above format, can I refer to the file in the fopen as simply
>>>> /logbooks/CAA001/blahblah.txt ?
>>>>
>>>> Tom
>>>
>>> You can, but the results may be different.
>>>
>>> The first question would be - why are you opening using a URL? It's not
>>> normal to open a file from your own server like this, but there are
>>> valid reasons for doing it.
>>
>> I didn't write the program so I don't know if there is a valid reason.
>> This is how it is used -
>> When a pilot clicks on his ID, a page is loaded that shows all his
>> flights in the format of a 3 col table. The columns being
>> Date/To/from. If the pilot then clicks on the date another page is
>> displayed showing the complete detail of that specific flight. The
>> text file in question is that complete log. It is output using
>>
>> $rep_file = @fopen($report,"r");
>> while (!feof($rep_file))
>> { $output = @htmlspecialchars(fgets($rep_file, 1024));
>> echo("$output<br />");
>> }
>> @fclose($rep_file);
>>
>> Hope this helps.
>>
>> Tom
>
> Not really. A lot depends on what's in the file.
>
> When you open a file locally, you get the file just as it exists on the
> server. However, when you open it via a URL, you get the file after it
> has been processed by the server.
>
> As an example - if this file contained php code, opening it locally you
> get the file containing the php code. However, opening it via the URL
> would cause the PHP code to be executed and you would get the results of
> the code.
>
> Not knowing what the original programmer wanted makes this difficult.
> However, from your description it sounds like a database would have been
> much more appropriate to hold the data, I would suspect whoever wrote
> it in the first place probably had no idea what he/she was doing and
> there are a lot more problems in the application.
Thanks for your help. The file in question was intended to be printed
as is. So, I was able to change from a URL to a file reference in the
fopen function. All seems to be working correctly.
Thanks again,
Tom
|
|
|
|
| Re: fopen Problem [message #175263 is a reply to message #175246] |
Tue, 30 August 2011 23:30 |
sheldonlg
Messages: 166
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 8/28/2011 11:04 PM, Call Me Tom wrote:
> On Sun, 28 Aug 2011 20:44:27 -0400, Richard Damon
> <news(dot)x(dot)richarddamon(at)xoxy(dot)net> wrote:
>
>> On 8/28/11 8:21 PM, Call Me Tom wrote:
>>> I have the following statement in om=ne of my PHP scripts:
>>>
>>> $rep_file = @fopen($report,"r");
>>>
>>> Until recently the the file opened properly on my local test system
>>> and my web host. My web host has upgraded to a newer version of PHP
>>> and I noticed that the core configuration parameter "allow_url_fopen"
>>> is coded off. My test system, which still works, is coded on. I
>>> assume that this is the source of my problem and am hoping one of you
>>> will suggest a work around.
>>>
>>> Please keep in mind that I have minimal PHP experience and that I have
>>> no control over the host configuration.
>>>
>>> Thanks,
>>> Tom
>>
>> If $report has a value like "http://example.com/page", than yes, that is
>> the source of your problem.
>>
>> If $report is referring to a "normal" file path to a file on the server
>> (like "subdir/file" or "/home/usr/me/myfile") then it isn't.
>
> $report is
> http://www.corporateairamerica.com/logbooks/CAA001/CAA00120110826160800.txt
>
> This text file is in a subdirectory of my home directory. Instead of
> using the above format, can I refer to the file in the fopen as simply
> /logbooks/CAA001/blahblah.txt ?
>
> Tom
Try "logbooks/CAA001/blahblah.txt"
or better yet,
dirname(__FILE__) . "/logbooks/CAA001/blahblah.txt"
--
Shelly
|
|
|
|
| Re: fopen Problem [message #175264 is a reply to message #175246] |
Wed, 31 August 2011 00:04 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 8/28/2011 11:04 PM, Call Me Tom wrote:
> On Sun, 28 Aug 2011 20:44:27 -0400, Richard Damon
> <news(dot)x(dot)richarddamon(at)xoxy(dot)net> wrote:
>
>> On 8/28/11 8:21 PM, Call Me Tom wrote:
>>> I have the following statement in om=ne of my PHP scripts:
>>>
>>> $rep_file = @fopen($report,"r");
>>>
>>> Until recently the the file opened properly on my local test system
>>> and my web host. My web host has upgraded to a newer version of PHP
>>> and I noticed that the core configuration parameter "allow_url_fopen"
>>> is coded off. My test system, which still works, is coded on. I
>>> assume that this is the source of my problem and am hoping one of you
>>> will suggest a work around.
>>>
>>> Please keep in mind that I have minimal PHP experience and that I have
>>> no control over the host configuration.
>>>
>>> Thanks,
>>> Tom
>>
>> If $report has a value like "http://example.com/page", than yes, that is
>> the source of your problem.
>>
>> If $report is referring to a "normal" file path to a file on the server
>> (like "subdir/file" or "/home/usr/me/myfile") then it isn't.
>
> $report is
> http://www.corporateairamerica.com/logbooks/CAA001/CAA00120110826160800.txt
>
> This text file is in a subdirectory of my home directory. Instead of
> using the above format, can I refer to the file in the fopen as simply
> /logbooks/CAA001/blahblah.txt ?
>
> Tom
To answer your other question (sorry I missed it before) - use the
superglobals. A way which is only dependent on the location relative to
your server root directory (and not the location of the file calling it,
for instance) is
$_SERVER['DOCUMENT_ROOT'] . '/logbooks/CAA001/blahblah.txt'.
dirname(__FILE__) is a very bad way to to it - it is dependent on the
location of the script opening the file and will break if you move the
script to a different directory.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: fopen Problem [message #175277 is a reply to message #175264] |
Wed, 31 August 2011 10:49 |
A
Messages: 17
Registered: June 2011
Karma: 0
|
Junior Member |
|
|
> $_SERVER['DOCUMENT_ROOT'] . '/logbooks/CAA001/blahblah.txt'.
>
> dirname(__FILE__) is a very bad way to to it - it is dependent on the
> location of the script opening the file and will break if you move the
> script to a different directory.
if I understood the question correctly the file is *NOT* on his own server
because he allow_url_fopen configuration setting.
dirname(__FILE__) is very useful. I tend to keep all my scripts in a
relative file/folder structure so I WANT to move them and keep the paths
properly in place.
|
|
|
|
| Re: fopen Problem [message #175278 is a reply to message #175277] |
Wed, 31 August 2011 11:22 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 8/31/2011 6:49 AM, A wrote:
>> $_SERVER['DOCUMENT_ROOT'] . '/logbooks/CAA001/blahblah.txt'.
>>
>> dirname(__FILE__) is a very bad way to to it - it is dependent on the
>> location of the script opening the file and will break if you move the
>> script to a different directory.
>
> if I understood the question correctly the file is *NOT* on his own server
> because he allow_url_fopen configuration setting.
> dirname(__FILE__) is very useful. I tend to keep all my scripts in a
> relative file/folder structure so I WANT to move them and keep the paths
> properly in place.
>
>
Whether it is his own server or not is immaterial as it has no effect on
my statement.
And obviously you have not tried $_SERVER['DOCUMENT_ROOT'] = which also
allows you to keep your scripts in a file/folder structure. The
difference being dirname(__FILE__) changes depending on the calling
script's location = move the calling script and your code breaks.
For this reason it's a bad idea to use it to access other files unless
that file is *totally dependent* on the calling script and will *always*
be in the same relative location to the calling script. But such
assumptions also make the files more tightly coupled, creating
unnecessary dependencies.
$_SERVER['DOCUMENT_ROOT'] always points at the root directory of the
website and is independent of the calling script's location.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: fopen Problem [message #175283 is a reply to message #175278] |
Wed, 31 August 2011 12:59 |
sheldonlg
Messages: 166
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 8/31/2011 7:22 AM, Jerry Stuckle wrote:
> On 8/31/2011 6:49 AM, A wrote:
>>> $_SERVER['DOCUMENT_ROOT'] . '/logbooks/CAA001/blahblah.txt'.
>>>
>>> dirname(__FILE__) is a very bad way to to it - it is dependent on the
>>> location of the script opening the file and will break if you move the
>>> script to a different directory.
>>
>> if I understood the question correctly the file is *NOT* on his own
>> server
>> because he allow_url_fopen configuration setting.
>> dirname(__FILE__) is very useful. I tend to keep all my scripts in a
>> relative file/folder structure so I WANT to move them and keep the paths
>> properly in place.
>>
>>
>
> Whether it is his own server or not is immaterial as it has no effect on
> my statement.
>
> And obviously you have not tried $_SERVER['DOCUMENT_ROOT'] = which also
> allows you to keep your scripts in a file/folder structure. The
> difference being dirname(__FILE__) changes depending on the calling
> script's location = move the calling script and your code breaks.
>
> For this reason it's a bad idea to use it to access other files unless
> that file is *totally dependent* on the calling script and will *always*
> be in the same relative location to the calling script. But such
> assumptions also make the files more tightly coupled, creating
> unnecessary dependencies.
>
> $_SERVER['DOCUMENT_ROOT'] always points at the root directory of the
> website and is independent of the calling script's location.
>
If you, like most people, move a file it is not only that single file.
It is a whole directory tree. Using $_SERVER['DOCUMENT_ROOT'] would
then break the code whereas dirname(__FILE__) would not. I don't know
about you, but I don't just wake up one morning and say "gee, I think
I'll move that file". If I move anything, it is an entire directory
tree. If I have to move just a single file, I do a grep for that
filename and I also look inside that file for dependencies. How about you?
--
Shelly
|
|
|
|
| Re: fopen Problem [message #175288 is a reply to message #175283] |
Wed, 31 August 2011 17:39 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 8/31/2011 8:59 AM, sheldonlg wrote:
> On 8/31/2011 7:22 AM, Jerry Stuckle wrote:
>> On 8/31/2011 6:49 AM, A wrote:
>>>> $_SERVER['DOCUMENT_ROOT'] . '/logbooks/CAA001/blahblah.txt'.
>>>>
>>>> dirname(__FILE__) is a very bad way to to it - it is dependent on the
>>>> location of the script opening the file and will break if you move the
>>>> script to a different directory.
>>>
>>> if I understood the question correctly the file is *NOT* on his own
>>> server
>>> because he allow_url_fopen configuration setting.
>>> dirname(__FILE__) is very useful. I tend to keep all my scripts in a
>>> relative file/folder structure so I WANT to move them and keep the paths
>>> properly in place.
>>>
>>>
>>
>> Whether it is his own server or not is immaterial as it has no effect on
>> my statement.
>>
>> And obviously you have not tried $_SERVER['DOCUMENT_ROOT'] = which also
>> allows you to keep your scripts in a file/folder structure. The
>> difference being dirname(__FILE__) changes depending on the calling
>> script's location = move the calling script and your code breaks.
>>
>> For this reason it's a bad idea to use it to access other files unless
>> that file is *totally dependent* on the calling script and will *always*
>> be in the same relative location to the calling script. But such
>> assumptions also make the files more tightly coupled, creating
>> unnecessary dependencies.
>>
>> $_SERVER['DOCUMENT_ROOT'] always points at the root directory of the
>> website and is independent of the calling script's location.
>>
>
> If you, like most people, move a file it is not only that single file.
> It is a whole directory tree. Using $_SERVER['DOCUMENT_ROOT'] would then
> break the code whereas dirname(__FILE__) would not. I don't know about
> you, but I don't just wake up one morning and say "gee, I think I'll
> move that file". If I move anything, it is an entire directory tree. If
> I have to move just a single file, I do a grep for that filename and I
> also look inside that file for dependencies. How about you?
>
I, like most GOOD programmers, keep included files in their own
directories, based on the file type. For instance, common PHP include
files are kept in one directory; class files in another, and protected
documents in a third (all outside the document root). That way there is
a common access to ALL files from anywhere in the site.
Only the actual web pages themselves are in the document root and its
subdirectories. And changing those changes the URL accessing the files.
No, I seldom move ANY files. Rather, I create a plan BEFORE I start
writing any code - it's all part of the design.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]