Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #13421 > unrolled thread

404 error

Back to article view | Back to comp.lang.php

Contents

  404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-22 12:41 -0400
    Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-22 12:58 -0400
      Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-22 13:25 -0400
        Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-22 13:32 -0400
          Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-22 14:35 -0400
          Re: 404 error Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-04-22 14:42 -0400
            Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-22 14:56 -0400
              Re: 404 error Anders Wegge Keller <wegge@wegge.dk> - 2014-04-23 08:56 +0200
                Re: 404 error Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-04-23 13:12 +0200
                  Re: 404 error Anders Wegge Keller <wegge@wegge.dk> - 2014-04-23 13:23 +0200
                    Re: 404 error Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-04-23 13:36 +0200
                    Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-23 08:09 -0400
                Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-23 08:08 -0400
            Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-23 13:12 -0400
              Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-23 14:50 -0400
                Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-23 20:19 -0400
    Re: 404 error Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-04-22 23:26 +0200
      Re: 404 error Christoph Michael Becker <cmbecker69@arcor.de> - 2014-04-23 14:21 +0200
        Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-23 09:12 -0400
          SCRIPT_NAME (was: 404 error) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-04-23 21:46 +0200
            Re: SCRIPT_NAME Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-23 16:36 -0400
            Re: SCRIPT_NAME Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-04-24 00:27 +0200
              Re: SCRIPT_NAME Christoph Michael Becker <cmbecker69@arcor.de> - 2014-04-25 00:35 +0200
        Re: 404 error Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-04-23 15:56 +0200
          Re: 404 error Christoph Michael Becker <cmbecker69@arcor.de> - 2014-04-23 18:00 +0200
            Re: 404 error Christoph Michael Becker <cmbecker69@arcor.de> - 2014-04-23 21:38 +0200
    Re: 404 error Doug Miller <doug_at_milmac_dot_com@example.com> - 2014-04-22 22:04 +0000
      Re: 404 error The Natural Philosopher <tnp@invalid.invalid> - 2014-04-23 00:11 +0100
      Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-22 20:22 -0400
    Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-23 12:39 -0400
      Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-23 14:22 -0400
        Re: 404 error Denis McMahon <denismfmcmahon@gmail.com> - 2014-04-23 21:28 +0000

Page 1 of 2  [1] 2  Next page →

#13421 — 404 error

I have two sites on different hosts.

Both use identical code to display a "last modified" message.  The code 
is in a standard footer which is included (via PHP) on ever site page.

I just noticed something odd.  At my site <http://edmullen.net> it works 
just fine.  The first link below shows a standard page with the footer 
message.  The second will produce an error page since the link doesn't 
exist on the site.  On the error page the date info is simply not displayed.

<http://edmullen.net/index.php>

<http://edmullen.net/bogus.php>

Fine so far.  The other site has different results.

<http://guitarsnotguns.org/>

<http://guitarsnotguns.org/rot.php>

Notice the error message and incorrect date in the footer.

I'm guessing it's a server configuration issue.  Any thoughts?

BTW, here's the PHP I use on both sites:

<?php
$current_file_name = ($_SERVER['REQUEST_URI']);
$current_path = ($_SERVER['DOCUMENT_ROOT']);
$full_name = $current_path.$current_file_name;
$last_modified = filemtime($full_name);
print("This page last changed: ");
print(date("F j, Y - h:i A", $last_modified));
?>

Thanks.

-- 
Ed Mullen
http://edmullen.net/
A fool-proof method for sculpting an elephant: First, get a huge block 
of marble; then chip away everything that doesn't look like an elephant.

[toc] | [next] | [standalone]

#13422

On 4/22/2014 12:41 PM, Ed Mullen wrote:
> I have two sites on different hosts.
>
> Both use identical code to display a "last modified" message.  The code
> is in a standard footer which is included (via PHP) on ever site page.
>
> I just noticed something odd.  At my site <http://edmullen.net> it works
> just fine.  The first link below shows a standard page with the footer
> message.  The second will produce an error page since the link doesn't
> exist on the site.  On the error page the date info is simply not
> displayed.
>
> <http://edmullen.net/index.php>
>
> <http://edmullen.net/bogus.php>
>
> Fine so far.  The other site has different results.
>
> <http://guitarsnotguns.org/>
>
> <http://guitarsnotguns.org/rot.php>
>
> Notice the error message and incorrect date in the footer.
>
> I'm guessing it's a server configuration issue.  Any thoughts?
>
> BTW, here's the PHP I use on both sites:
>
> <?php
> $current_file_name = ($_SERVER['REQUEST_URI']);
> $current_path = ($_SERVER['DOCUMENT_ROOT']);
> $full_name = $current_path.$current_file_name;
> $last_modified = filemtime($full_name);
> print("This page last changed: ");
> print(date("F j, Y - h:i A", $last_modified));
> ?>
>
> Thanks.
>

If the file doesn't exist, how can you get its time?

It looks like you're including your footer in the failing page, but not 
in the working one.  This is not a PHP issue.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13423

Jerry Stuckle wrote:
> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>> I have two sites on different hosts.
>>
>> Both use identical code to display a "last modified" message.  The code
>> is in a standard footer which is included (via PHP) on ever site page.
>>
>> I just noticed something odd.  At my site <http://edmullen.net> it works
>> just fine.  The first link below shows a standard page with the footer
>> message.  The second will produce an error page since the link doesn't
>> exist on the site.  On the error page the date info is simply not
>> displayed.
>>
>> <http://edmullen.net/index.php>
>>
>> <http://edmullen.net/bogus.php>
>>
>> Fine so far.  The other site has different results.
>>
>> <http://guitarsnotguns.org/>
>>
>> <http://guitarsnotguns.org/rot.php>
>>
>> Notice the error message and incorrect date in the footer.
>>
>> I'm guessing it's a server configuration issue.  Any thoughts?
>>
>> BTW, here's the PHP I use on both sites:
>>
>> <?php
>> $current_file_name = ($_SERVER['REQUEST_URI']);
>> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>> $full_name = $current_path.$current_file_name;
>> $last_modified = filemtime($full_name);
>> print("This page last changed: ");
>> print(date("F j, Y - h:i A", $last_modified));
>> ?>
>>
>> Thanks.
>>
>
> If the file doesn't exist, how can you get its time?
>

Agreed.  Not expecting to.

> It looks like you're including your footer in the failing page, but not
> in the working one.  This is not a PHP issue.
>
>

The footer is in the two good links above. The failing pages above do 
not exist:  They're links to a non-existant file.  Hence the 404 result.

What I'm asking about is how the two hosts' servers handle it.  The 
first displays the custom 404 page WITHOUT showing the date in the 
footer.  No idea why.

The second host shows the 404 page but throws an error where the "date 
modified" info should be.  Obviously

-- 
Ed Mullen
http://edmullen.net/
Zen master to hot dog vendor: "Make me one with everything."

[toc] | [prev] | [next] | [standalone]

#13424

Ed Mullen wrote:
> Jerry Stuckle wrote:
>> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>> I have two sites on different hosts.
>>>
>>> Both use identical code to display a "last modified" message.  The code
>>> is in a standard footer which is included (via PHP) on ever site page.
>>>
>>> I just noticed something odd.  At my site <http://edmullen.net> it works
>>> just fine.  The first link below shows a standard page with the footer
>>> message.  The second will produce an error page since the link doesn't
>>> exist on the site.  On the error page the date info is simply not
>>> displayed.
>>>
>>> <http://edmullen.net/index.php>
>>>
>>> <http://edmullen.net/bogus.php>
>>>
>>> Fine so far.  The other site has different results.
>>>
>>> <http://guitarsnotguns.org/>
>>>
>>> <http://guitarsnotguns.org/rot.php>
>>>
>>> Notice the error message and incorrect date in the footer.
>>>
>>> I'm guessing it's a server configuration issue.  Any thoughts?
>>>
>>> BTW, here's the PHP I use on both sites:
>>>
>>> <?php
>>> $current_file_name = ($_SERVER['REQUEST_URI']);
>>> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>> $full_name = $current_path.$current_file_name;
>>> $last_modified = filemtime($full_name);
>>> print("This page last changed: ");
>>> print(date("F j, Y - h:i A", $last_modified));
>>> ?>
>>>
>>> Thanks.
>>>
>>
>> If the file doesn't exist, how can you get its time?
>>
>
> Agreed.  Not expecting to.
>
>> It looks like you're including your footer in the failing page, but not
>> in the working one.  This is not a PHP issue.
>>
>>
>
> The footer is in the two good links above. The failing pages above do
> not exist:  They're links to a non-existant file.  Hence the 404 result.
>
> What I'm asking about is how the two hosts' servers handle it.  The
> first displays the custom 404 page WITHOUT showing the date in the
> footer.  No idea why.
>
> The second host shows the 404 page but throws an error where the "date
> modified" info should be.  Obviously
>

Oops. Hit send too fast.

I was going to say that obviously there is something different about the 
servers set up.

I agree, it's probably not a PHP issue.  Just thought the smart folks 
here might have an idea.


-- 
Ed Mullen
http://edmullen.net/
"A conscience is like a boat or a car. If you feel you need one, rent 
it." - J.R. Ewing

[toc] | [prev] | [next] | [standalone]

#13425

On 4/22/2014 1:32 PM, Ed Mullen wrote:
> Ed Mullen wrote:
>> Jerry Stuckle wrote:
>>> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>>> I have two sites on different hosts.
>>>>
>>>> Both use identical code to display a "last modified" message.  The code
>>>> is in a standard footer which is included (via PHP) on ever site page.
>>>>
>>>> I just noticed something odd.  At my site <http://edmullen.net> it
>>>> works
>>>> just fine.  The first link below shows a standard page with the footer
>>>> message.  The second will produce an error page since the link doesn't
>>>> exist on the site.  On the error page the date info is simply not
>>>> displayed.
>>>>
>>>> <http://edmullen.net/index.php>
>>>>
>>>> <http://edmullen.net/bogus.php>
>>>>
>>>> Fine so far.  The other site has different results.
>>>>
>>>> <http://guitarsnotguns.org/>
>>>>
>>>> <http://guitarsnotguns.org/rot.php>
>>>>
>>>> Notice the error message and incorrect date in the footer.
>>>>
>>>> I'm guessing it's a server configuration issue.  Any thoughts?
>>>>
>>>> BTW, here's the PHP I use on both sites:
>>>>
>>>> <?php
>>>> $current_file_name = ($_SERVER['REQUEST_URI']);
>>>> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>>> $full_name = $current_path.$current_file_name;
>>>> $last_modified = filemtime($full_name);
>>>> print("This page last changed: ");
>>>> print(date("F j, Y - h:i A", $last_modified));
>>>> ?>
>>>>
>>>> Thanks.
>>>>
>>>
>>> If the file doesn't exist, how can you get its time?
>>>
>>
>> Agreed.  Not expecting to.
>>
>>> It looks like you're including your footer in the failing page, but not
>>> in the working one.  This is not a PHP issue.
>>>
>>>
>>
>> The footer is in the two good links above. The failing pages above do
>> not exist:  They're links to a non-existant file.  Hence the 404 result.
>>
>> What I'm asking about is how the two hosts' servers handle it.  The
>> first displays the custom 404 page WITHOUT showing the date in the
>> footer.  No idea why.
>>
>> The second host shows the 404 page but throws an error where the "date
>> modified" info should be.  Obviously
>>
>
> Oops. Hit send too fast.
>
> I was going to say that obviously there is something different about the
> servers set up.
>
> I agree, it's probably not a PHP issue.  Just thought the smart folks
> here might have an idea.
>
>

Then check in a server-related newsgroup.  This isn't a PHP problem.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13426

On Tuesday 22 April 2014 13:32, in comp.lang.php, "Ed Mullen"
<ejEVOMER@edmullen.net> wrote:

> Ed Mullen wrote:
>> Jerry Stuckle wrote:
>>> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>>> I have two sites on different hosts.
>>>>
>>>> Both use identical code to display a "last modified" message.  The code
>>>> is in a standard footer which is included (via PHP) on ever site page.
>>>>
>>>> I just noticed something odd.  At my site <http://edmullen.net> it
>>>> works
>>>> just fine.  The first link below shows a standard page with the footer
>>>> message.  The second will produce an error page since the link doesn't
>>>> exist on the site.  On the error page the date info is simply not
>>>> displayed.
>>>>
>>>> <http://edmullen.net/index.php>
>>>>
>>>> <http://edmullen.net/bogus.php>
>>>>
>>>> Fine so far.  The other site has different results.
>>>>
>>>> <http://guitarsnotguns.org/>
>>>>
>>>> <http://guitarsnotguns.org/rot.php>
>>>>
>>>> Notice the error message and incorrect date in the footer.
>>>>
>>>> I'm guessing it's a server configuration issue.  Any thoughts?
>>>>
>>>> BTW, here's the PHP I use on both sites:
>>>>
>>>> <?php
>>>> $current_file_name = ($_SERVER['REQUEST_URI']);
>>>> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>>> $full_name = $current_path.$current_file_name;
>>>> $last_modified = filemtime($full_name);
>>>> print("This page last changed: ");
>>>> print(date("F j, Y - h:i A", $last_modified));
>>>> ?>
>>>>
>>>> Thanks.
>>>>
>>>
>>> If the file doesn't exist, how can you get its time?
>>>
>>
>> Agreed.  Not expecting to.
>>
>>> It looks like you're including your footer in the failing page, but not
>>> in the working one.  This is not a PHP issue.
>>>
>>>
>>
>> The footer is in the two good links above. The failing pages above do
>> not exist:  They're links to a non-existant file.  Hence the 404 result.
>>
>> What I'm asking about is how the two hosts' servers handle it.  The
>> first displays the custom 404 page WITHOUT showing the date in the
>> footer.  No idea why.
>>
>> The second host shows the 404 page but throws an error where the "date
>> modified" info should be.  Obviously
>>
> 
> Oops. Hit send too fast.
> 
> I was going to say that obviously there is something different about the
> servers set up.
> 
> I agree, it's probably not a PHP issue.  Just thought the smart folks
> here might have an idea.


My (semi-educated) guess:

On edmullen.net, your php.ini file sets the error_reporting value to
E_ERROR, while on guitarsnotguns.org, the php.ini file sets the
error_reporting value to E_WARNING

E_ERROR settings will halt execution of the php script; if
filemtime($full_name) encounters a "file not found" error, the script
stops, and does not execute the subsequent printf() statements.


E_WARNING settings will not halt execution of the php script; if
filemtime($full_name) encounters a "file not found" error, the script
continues and tries execute the subsequent printf() statements.

Compare the php.ini settings (both explicit and implicit-default) from both
sites, especially the error_reporting and display_errors values, to see how
you've set PHP to handle errors.

HTH
-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#13428

On 4/22/2014 2:42 PM, Lew Pitcher wrote:
> On Tuesday 22 April 2014 13:32, in comp.lang.php, "Ed Mullen"
> <ejEVOMER@edmullen.net> wrote:
>
>> Ed Mullen wrote:
>>> Jerry Stuckle wrote:
>>>> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>>>> I have two sites on different hosts.
>>>>>
>>>>> Both use identical code to display a "last modified" message.  The code
>>>>> is in a standard footer which is included (via PHP) on ever site page.
>>>>>
>>>>> I just noticed something odd.  At my site <http://edmullen.net> it
>>>>> works
>>>>> just fine.  The first link below shows a standard page with the footer
>>>>> message.  The second will produce an error page since the link doesn't
>>>>> exist on the site.  On the error page the date info is simply not
>>>>> displayed.
>>>>>
>>>>> <http://edmullen.net/index.php>
>>>>>
>>>>> <http://edmullen.net/bogus.php>
>>>>>
>>>>> Fine so far.  The other site has different results.
>>>>>
>>>>> <http://guitarsnotguns.org/>
>>>>>
>>>>> <http://guitarsnotguns.org/rot.php>
>>>>>
>>>>> Notice the error message and incorrect date in the footer.
>>>>>
>>>>> I'm guessing it's a server configuration issue.  Any thoughts?
>>>>>
>>>>> BTW, here's the PHP I use on both sites:
>>>>>
>>>>> <?php
>>>>> $current_file_name = ($_SERVER['REQUEST_URI']);
>>>>> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>>>> $full_name = $current_path.$current_file_name;
>>>>> $last_modified = filemtime($full_name);
>>>>> print("This page last changed: ");
>>>>> print(date("F j, Y - h:i A", $last_modified));
>>>>> ?>
>>>>>
>>>>> Thanks.
>>>>>
>>>>
>>>> If the file doesn't exist, how can you get its time?
>>>>
>>>
>>> Agreed.  Not expecting to.
>>>
>>>> It looks like you're including your footer in the failing page, but not
>>>> in the working one.  This is not a PHP issue.
>>>>
>>>>
>>>
>>> The footer is in the two good links above. The failing pages above do
>>> not exist:  They're links to a non-existant file.  Hence the 404 result.
>>>
>>> What I'm asking about is how the two hosts' servers handle it.  The
>>> first displays the custom 404 page WITHOUT showing the date in the
>>> footer.  No idea why.
>>>
>>> The second host shows the 404 page but throws an error where the "date
>>> modified" info should be.  Obviously
>>>
>>
>> Oops. Hit send too fast.
>>
>> I was going to say that obviously there is something different about the
>> servers set up.
>>
>> I agree, it's probably not a PHP issue.  Just thought the smart folks
>> here might have an idea.
>
>
> My (semi-educated) guess:
>
> On edmullen.net, your php.ini file sets the error_reporting value to
> E_ERROR, while on guitarsnotguns.org, the php.ini file sets the
> error_reporting value to E_WARNING
>
> E_ERROR settings will halt execution of the php script; if
> filemtime($full_name) encounters a "file not found" error, the script
> stops, and does not execute the subsequent printf() statements.
>
>
> E_WARNING settings will not halt execution of the php script; if
> filemtime($full_name) encounters a "file not found" error, the script
> continues and tries execute the subsequent printf() statements.
>
> Compare the php.ini settings (both explicit and implicit-default) from both
> sites, especially the error_reporting and display_errors values, to see how
> you've set PHP to handle errors.
>
> HTH
>

Incorrect.  An error will ALWAYS stop execution of the script, no matter 
what the error_reporting value is.  And a warning will NEVER stop 
execution of the script, no matter what the error_reporting value is.

All this does is control what level of message is reported; it does not 
affect execution in any way.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13438

Jerry Stuckle <jstucklex@attglobal.net> writes:

> Incorrect.  An error will ALWAYS stop execution of the script, no
> matter what the error_reporting value is.  And a warning will NEVER
> stop execution of the script, no matter what the error_reporting value
> is.

filemtime

(PHP 4, PHP 5)
filemtime — Gets file modification time

...

Errors/Exceptions ¶

Upon failure, an E_WARNING is emitted.

-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

[toc] | [prev] | [next] | [standalone]

#13439

Anders Wegge Keller wrote:

> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> Incorrect.  An error will ALWAYS stop execution of the script, no
>> matter what the error_reporting value is.  And a warning will NEVER
>> stop execution of the script, no matter what the error_reporting value
>> is.
> 
> filemtime
> 
> (PHP 4, PHP 5)
> filemtime — Gets file modification time
> 
> ...
> 
> Errors/Exceptions ¶
> 
> Upon failure, an E_WARNING is emitted.

What are you getting at?


PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

[toc] | [prev] | [next] | [standalone]

#13440

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Anders Wegge Keller wrote:
> 
> > Jerry Stuckle <jstucklex@attglobal.net> writes:
> >> Incorrect.  An error will ALWAYS stop execution of the script, no
> >> matter what the error_reporting value is.  And a warning will NEVER
> >> stop execution of the script, no matter what the error_reporting value
> >> is.
> > 
> > filemtime
> > 
> > (PHP 4, PHP 5)
> > filemtime — Gets file modification time
> > 
> > ...
> > 
> > Errors/Exceptions ¶
> > 
> > Upon failure, an E_WARNING is emitted.
> 
> What are you getting at?

 Pointing out the futility of discussing E_ERROR in this case.

/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

[toc] | [prev] | [next] | [standalone]

#13441

Anders Wegge Keller wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Anders Wegge Keller wrote: 
>> > Jerry Stuckle <jstucklex@attglobal.net> writes:
>> >> Incorrect.  An error will ALWAYS stop execution of the script, no
>> >> matter what the error_reporting value is.  And a warning will NEVER
>> >> stop execution of the script, no matter what the error_reporting value
>> >> is.
>> > 
>> > filemtime
>> > 
>> > (PHP 4, PHP 5)
>> > filemtime — Gets file modification time
>> > 
>> > ...
>> > 
>> > Errors/Exceptions ¶
>> > 
>> > Upon failure, an E_WARNING is emitted.
>> 
>> What are you getting at?
> 
>  Pointing out the futility of discussing E_ERROR in this case.

But the point made here was that error_reporting settings do not influence 
php’s behavior with regard to the program flow per se, only which 
errors/warnings/notices will be reported by php.  The opposite had been 
assumed by Lew Pitcher.

One should not misconstrue the generic format of the documentation or the 
identifiers or values of error constants as proof that errors, warnings and 
notices would be *functionally* the same.


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#13443

On 4/23/2014 7:23 AM, Anders Wegge Keller wrote:
> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>
>> Anders Wegge Keller wrote:
>>
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>> Incorrect.  An error will ALWAYS stop execution of the script, no
>>>> matter what the error_reporting value is.  And a warning will NEVER
>>>> stop execution of the script, no matter what the error_reporting value
>>>> is.
>>>
>>> filemtime
>>>
>>> (PHP 4, PHP 5)
>>> filemtime — Gets file modification time
>>>
>>> ...
>>>
>>> Errors/Exceptions ¶
>>>
>>> Upon failure, an E_WARNING is emitted.
>>
>> What are you getting at?
>
>   Pointing out the futility of discussing E_ERROR in this case.
>
> /Wegge
>
> Leder efter redundant peering af dk.*,linux.debian.*
>

So?  Just trying to make yourself heard?


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13442

On 4/23/2014 2:56 AM, Anders Wegge Keller wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> Incorrect.  An error will ALWAYS stop execution of the script, no
>> matter what the error_reporting value is.  And a warning will NEVER
>> stop execution of the script, no matter what the error_reporting value
>> is.
>
> filemtime
>
> (PHP 4, PHP 5)
> filemtime — Gets file modification time
>
> ...
>
> Errors/Exceptions ¶
>
> Upon failure, an E_WARNING is emitted.
>

Which has absolutely nothing to do with what I said...


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13450

Lew Pitcher wrote:
> On Tuesday 22 April 2014 13:32, in comp.lang.php, "Ed Mullen"
> <ejEVOMER@edmullen.net> wrote:
>
>> Ed Mullen wrote:
>>> Jerry Stuckle wrote:
>>>> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>>>> I have two sites on different hosts.
>>>>>
>>>>> Both use identical code to display a "last modified" message.  The code
>>>>> is in a standard footer which is included (via PHP) on ever site page.
>>>>>
>>>>> I just noticed something odd.  At my site <http://edmullen.net> it
>>>>> works
>>>>> just fine.  The first link below shows a standard page with the footer
>>>>> message.  The second will produce an error page since the link doesn't
>>>>> exist on the site.  On the error page the date info is simply not
>>>>> displayed.
>>>>>
>>>>> <http://edmullen.net/index.php>
>>>>>
>>>>> <http://edmullen.net/bogus.php>
>>>>>
>>>>> Fine so far.  The other site has different results.
>>>>>
>>>>> <http://guitarsnotguns.org/>
>>>>>
>>>>> <http://guitarsnotguns.org/rot.php>
>>>>>
>>>>> Notice the error message and incorrect date in the footer.
>>>>>
>>>>> I'm guessing it's a server configuration issue.  Any thoughts?
>>>>>
>>>>> BTW, here's the PHP I use on both sites:
>>>>>
>>>>> <?php
>>>>> $current_file_name = ($_SERVER['REQUEST_URI']);
>>>>> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>>>> $full_name = $current_path.$current_file_name;
>>>>> $last_modified = filemtime($full_name);
>>>>> print("This page last changed: ");
>>>>> print(date("F j, Y - h:i A", $last_modified));
>>>>> ?>
>>>>>
>>>>> Thanks.
>>>>>
>>>>
>>>> If the file doesn't exist, how can you get its time?
>>>>
>>>
>>> Agreed.  Not expecting to.
>>>
>>>> It looks like you're including your footer in the failing page, but not
>>>> in the working one.  This is not a PHP issue.
>>>>
>>>>
>>>
>>> The footer is in the two good links above. The failing pages above do
>>> not exist:  They're links to a non-existant file.  Hence the 404 result.
>>>
>>> What I'm asking about is how the two hosts' servers handle it.  The
>>> first displays the custom 404 page WITHOUT showing the date in the
>>> footer.  No idea why.
>>>
>>> The second host shows the 404 page but throws an error where the "date
>>> modified" info should be.  Obviously
>>>
>>
>> Oops. Hit send too fast.
>>
>> I was going to say that obviously there is something different about the
>> servers set up.
>>
>> I agree, it's probably not a PHP issue.  Just thought the smart folks
>> here might have an idea.
>
>
> My (semi-educated) guess:
>
> On edmullen.net, your php.ini file sets the error_reporting value to
> E_ERROR, while on guitarsnotguns.org, the php.ini file sets the
> error_reporting value to E_WARNING
>
> E_ERROR settings will halt execution of the php script; if
> filemtime($full_name) encounters a "file not found" error, the script
> stops, and does not execute the subsequent printf() statements.
>
>
> E_WARNING settings will not halt execution of the php script; if
> filemtime($full_name) encounters a "file not found" error, the script
> continues and tries execute the subsequent printf() statements.
>
> Compare the php.ini settings (both explicit and implicit-default) from both
> sites, especially the error_reporting and display_errors values, to see how
> you've set PHP to handle errors.
>
> HTH
>

Indeed.  When I do phpinfo on both hosts:

edmullen.net - error_reporting = 22517
guitarsnotguns.org - error_reporting = 30711

I haven't yet figured out how to get access to the php.ini file on 
DreamHost, GNG's hosting service.  Their documentation/help is somewhat 
byzantine.

Thanks, Lew.

P.S. Googled and found that if I put this in the custom error pages as 
the first line in "include" script it stops the error.  The date is 
still wrong but that's less annoying.

<?php error_reporting(22517); ?>



-- 
Ed Mullen
http://edmullen.net/
All those who believe in psychokinesis raise my hand.

[toc] | [prev] | [next] | [standalone]

#13452

On 4/23/2014 1:12 PM, Ed Mullen wrote:
> Lew Pitcher wrote:
>> On Tuesday 22 April 2014 13:32, in comp.lang.php, "Ed Mullen"
>> <ejEVOMER@edmullen.net> wrote:
>>
>>> Ed Mullen wrote:
>>>> Jerry Stuckle wrote:
>>>>> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>>>>> I have two sites on different hosts.
>>>>>>
>>>>>> Both use identical code to display a "last modified" message.  The
>>>>>> code
>>>>>> is in a standard footer which is included (via PHP) on ever site
>>>>>> page.
>>>>>>
>>>>>> I just noticed something odd.  At my site <http://edmullen.net> it
>>>>>> works
>>>>>> just fine.  The first link below shows a standard page with the
>>>>>> footer
>>>>>> message.  The second will produce an error page since the link
>>>>>> doesn't
>>>>>> exist on the site.  On the error page the date info is simply not
>>>>>> displayed.
>>>>>>
>>>>>> <http://edmullen.net/index.php>
>>>>>>
>>>>>> <http://edmullen.net/bogus.php>
>>>>>>
>>>>>> Fine so far.  The other site has different results.
>>>>>>
>>>>>> <http://guitarsnotguns.org/>
>>>>>>
>>>>>> <http://guitarsnotguns.org/rot.php>
>>>>>>
>>>>>> Notice the error message and incorrect date in the footer.
>>>>>>
>>>>>> I'm guessing it's a server configuration issue.  Any thoughts?
>>>>>>
>>>>>> BTW, here's the PHP I use on both sites:
>>>>>>
>>>>>> <?php
>>>>>> $current_file_name = ($_SERVER['REQUEST_URI']);
>>>>>> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>>>>> $full_name = $current_path.$current_file_name;
>>>>>> $last_modified = filemtime($full_name);
>>>>>> print("This page last changed: ");
>>>>>> print(date("F j, Y - h:i A", $last_modified));
>>>>>> ?>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>
>>>>> If the file doesn't exist, how can you get its time?
>>>>>
>>>>
>>>> Agreed.  Not expecting to.
>>>>
>>>>> It looks like you're including your footer in the failing page, but
>>>>> not
>>>>> in the working one.  This is not a PHP issue.
>>>>>
>>>>>
>>>>
>>>> The footer is in the two good links above. The failing pages above do
>>>> not exist:  They're links to a non-existant file.  Hence the 404
>>>> result.
>>>>
>>>> What I'm asking about is how the two hosts' servers handle it.  The
>>>> first displays the custom 404 page WITHOUT showing the date in the
>>>> footer.  No idea why.
>>>>
>>>> The second host shows the 404 page but throws an error where the "date
>>>> modified" info should be.  Obviously
>>>>
>>>
>>> Oops. Hit send too fast.
>>>
>>> I was going to say that obviously there is something different about the
>>> servers set up.
>>>
>>> I agree, it's probably not a PHP issue.  Just thought the smart folks
>>> here might have an idea.
>>
>>
>> My (semi-educated) guess:
>>
>> On edmullen.net, your php.ini file sets the error_reporting value to
>> E_ERROR, while on guitarsnotguns.org, the php.ini file sets the
>> error_reporting value to E_WARNING
>>
>> E_ERROR settings will halt execution of the php script; if
>> filemtime($full_name) encounters a "file not found" error, the script
>> stops, and does not execute the subsequent printf() statements.
>>
>>
>> E_WARNING settings will not halt execution of the php script; if
>> filemtime($full_name) encounters a "file not found" error, the script
>> continues and tries execute the subsequent printf() statements.
>>
>> Compare the php.ini settings (both explicit and implicit-default) from
>> both
>> sites, especially the error_reporting and display_errors values, to
>> see how
>> you've set PHP to handle errors.
>>
>> HTH
>>
>
> Indeed.  When I do phpinfo on both hosts:
>
> edmullen.net - error_reporting = 22517
> guitarsnotguns.org - error_reporting = 30711
>
> I haven't yet figured out how to get access to the php.ini file on
> DreamHost, GNG's hosting service.  Their documentation/help is somewhat
> byzantine.
>
> Thanks, Lew.
>
> P.S. Googled and found that if I put this in the custom error pages as
> the first line in "include" script it stops the error.  The date is
> still wrong but that's less annoying.
>
> <?php error_reporting(22517); ?>
>
>
>

If you INSIST on using this footer, good programming requires you to 
check for the presence of the file (see file_exists) before calling 
filemtime().  If it doesn't exist, don't call filemtime and don't 
display the time.

But why even include the footer in you error page?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13458

Jerry Stuckle wrote:
> On 4/23/2014 1:12 PM, Ed Mullen wrote:
>> Lew Pitcher wrote:
>>> On Tuesday 22 April 2014 13:32, in comp.lang.php, "Ed Mullen"
>>> <ejEVOMER@edmullen.net> wrote:
>>>
>>>> Ed Mullen wrote:
>>>>> Jerry Stuckle wrote:
>>>>>> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>>>>>> I have two sites on different hosts.
>>>>>>>
>>>>>>> Both use identical code to display a "last modified" message.  The
>>>>>>> code
>>>>>>> is in a standard footer which is included (via PHP) on ever site
>>>>>>> page.
>>>>>>>
>>>>>>> I just noticed something odd.  At my site <http://edmullen.net> it
>>>>>>> works
>>>>>>> just fine.  The first link below shows a standard page with the
>>>>>>> footer
>>>>>>> message.  The second will produce an error page since the link
>>>>>>> doesn't
>>>>>>> exist on the site.  On the error page the date info is simply not
>>>>>>> displayed.
>>>>>>>
>>>>>>> <http://edmullen.net/index.php>
>>>>>>>
>>>>>>> <http://edmullen.net/bogus.php>
>>>>>>>
>>>>>>> Fine so far.  The other site has different results.
>>>>>>>
>>>>>>> <http://guitarsnotguns.org/>
>>>>>>>
>>>>>>> <http://guitarsnotguns.org/rot.php>
>>>>>>>
>>>>>>> Notice the error message and incorrect date in the footer.
>>>>>>>
>>>>>>> I'm guessing it's a server configuration issue.  Any thoughts?
>>>>>>>
>>>>>>> BTW, here's the PHP I use on both sites:
>>>>>>>
>>>>>>> <?php
>>>>>>> $current_file_name = ($_SERVER['REQUEST_URI']);
>>>>>>> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>>>>>> $full_name = $current_path.$current_file_name;
>>>>>>> $last_modified = filemtime($full_name);
>>>>>>> print("This page last changed: ");
>>>>>>> print(date("F j, Y - h:i A", $last_modified));
>>>>>>> ?>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>
>>>>>> If the file doesn't exist, how can you get its time?
>>>>>>
>>>>>
>>>>> Agreed.  Not expecting to.
>>>>>
>>>>>> It looks like you're including your footer in the failing page, but
>>>>>> not
>>>>>> in the working one.  This is not a PHP issue.
>>>>>>
>>>>>>
>>>>>
>>>>> The footer is in the two good links above. The failing pages above do
>>>>> not exist:  They're links to a non-existant file.  Hence the 404
>>>>> result.
>>>>>
>>>>> What I'm asking about is how the two hosts' servers handle it.  The
>>>>> first displays the custom 404 page WITHOUT showing the date in the
>>>>> footer.  No idea why.
>>>>>
>>>>> The second host shows the 404 page but throws an error where the "date
>>>>> modified" info should be.  Obviously
>>>>>
>>>>
>>>> Oops. Hit send too fast.
>>>>
>>>> I was going to say that obviously there is something different about
>>>> the
>>>> servers set up.
>>>>
>>>> I agree, it's probably not a PHP issue.  Just thought the smart folks
>>>> here might have an idea.
>>>
>>>
>>> My (semi-educated) guess:
>>>
>>> On edmullen.net, your php.ini file sets the error_reporting value to
>>> E_ERROR, while on guitarsnotguns.org, the php.ini file sets the
>>> error_reporting value to E_WARNING
>>>
>>> E_ERROR settings will halt execution of the php script; if
>>> filemtime($full_name) encounters a "file not found" error, the script
>>> stops, and does not execute the subsequent printf() statements.
>>>
>>>
>>> E_WARNING settings will not halt execution of the php script; if
>>> filemtime($full_name) encounters a "file not found" error, the script
>>> continues and tries execute the subsequent printf() statements.
>>>
>>> Compare the php.ini settings (both explicit and implicit-default) from
>>> both
>>> sites, especially the error_reporting and display_errors values, to
>>> see how
>>> you've set PHP to handle errors.
>>>
>>> HTH
>>>
>>
>> Indeed.  When I do phpinfo on both hosts:
>>
>> edmullen.net - error_reporting = 22517
>> guitarsnotguns.org - error_reporting = 30711
>>
>> I haven't yet figured out how to get access to the php.ini file on
>> DreamHost, GNG's hosting service.  Their documentation/help is somewhat
>> byzantine.
>>
>> Thanks, Lew.
>>
>> P.S. Googled and found that if I put this in the custom error pages as
>> the first line in "include" script it stops the error.  The date is
>> still wrong but that's less annoying.
>>
>> <?php error_reporting(22517); ?>
>>
>>
>>
>
> If you INSIST on using this footer, good programming requires you to
> check for the presence of the file (see file_exists) before calling
> filemtime().  If it doesn't exist, don't call filemtime and don't
> display the time.
>
> But why even include the footer in you error page?
>

Indeed, see my other reply in this thread.


-- 
Ed Mullen
http://edmullen.net/
As I said before, I never repeat myself.

[toc] | [prev] | [next] | [standalone]

#13432

Ed Mullen wrote:

> <http://edmullen.net/index.php>
> <http://edmullen.net/bogus.php>
> 
> Fine so far.  The other site has different results.
> […]
> http://guitarsnotguns.org/rot.php
> 
> Notice the error message and incorrect date in the footer.

It is not an error message, it is a *warning*.
 
> I'm guessing it's a server configuration issue.  Any thoughts?
> 
> BTW, here's the PHP I use on both sites:
> 
> <?php
> $current_file_name = ($_SERVER['REQUEST_URI']);
> $current_path = ($_SERVER['DOCUMENT_ROOT']);

It is pointless and confusing for people accustomed to writing PHP code to 
put the RHS into parentheses here.

> $full_name = $current_path.$current_file_name;
> $last_modified = filemtime($full_name);

Look closely at that warning.  This approach is not going to work reliably 
because the HTTP request URI does not need to have anything to do with the 
file path of the resource.  In fact, there does not even need to be a real 
file for a URI, the served content could have been generated entirely by PHP 
(and usually is).  As a result, in those cases filemtime() returns FALSE …

> print(date("F j, Y - h:i A", $last_modified));

… which date() converts to 0 (UNIX epoch) – as it expects an int (UNIX 
timestamp), not a boolean value, for the second argument – and formats that 
accordingly to “December 31, 1969” (not “January 1, 1970 - 12:00 AM” 
probably because of timezone issues), which is then send to stdout by 
print().  (You should use “echo” instead, unless in an expression where you 
need “print”’s return value.  Think sh, not perl.)

,----
| $ php -r 'echo date("F, j Y - h:i A", filemtime("Slartibartfast")) . 
| "\n";'
| PHP Warning:  filemtime(): stat failed for Slartibartfast in Command line 
| code on line 1
| PHP Stack trace:
| PHP   1. {main}() Command line code:0
| PHP   2. filemtime() Command line code:1
| January, 1 1970 - 01:00 AM
|
| $ php -v
| PHP 5.5.11-3 (cli) (built: Apr 19 2014 16:46:26) 
| Copyright (c) 1997-2014 The PHP Group
| Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
|     with XCache v3.1.0, Copyright (c) 2005-2013, by mOo
|     with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend 
| Technologies
|     with Xdebug v2.2.4, Copyright (c) 2002-2014, by Derick Rethans
|     with XCache Optimizer v3.1.0, Copyright (c) 2005-2013, by mOo
|     with XCache Cacher v3.1.0, Copyright (c) 2005-2013, by mOo
|     with XCache Coverager v3.1.0, Copyright (c) 2005-2013, by mOo
`----

(I am in UTC+2 now because of European Summer Time, and date.timezone is set 
to “Europe/Zurich”; the latter would account for the one-hour advance.)

You might be looking for filemtime(__FILE__) instead.

<http://php.net/phpinfo>
<http://php.net/filemtime>
<http://php.net/date>
<http://php.net/print>
<http://php.net/echo>
<http://php.net/manual/en/language.constants.predefined.php>


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#13444

Thomas 'PointedEars' Lahn:

> Look closely at that warning.  This approach is not going to work reliably 
> because the HTTP request URI does not need to have anything to do with the 
> file path of the resource.  In fact, there does not even need to be a real 
> file for a URI, the served content could have been generated entirely by PHP 
> (and usually is).  As a result, in those cases filemtime() returns FALSE …

ACK.

> You might be looking for filemtime(__FILE__) instead.

__FILE__ contains the filepath of the currently *included* file; in Ed's
case the following should be more appropriate:

  filemtime($_SERVER['SCRIPT_NAME']);

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#13445

On 4/23/2014 8:21 AM, Christoph Michael Becker wrote:
> Thomas 'PointedEars' Lahn:
>
>> Look closely at that warning.  This approach is not going to work reliably
>> because the HTTP request URI does not need to have anything to do with the
>> file path of the resource.  In fact, there does not even need to be a real
>> file for a URI, the served content could have been generated entirely by PHP
>> (and usually is).  As a result, in those cases filemtime() returns FALSE …
>
> ACK.
>
>> You might be looking for filemtime(__FILE__) instead.
>
> __FILE__ contains the filepath of the currently *included* file; in Ed's
> case the following should be more appropriate:
>

True - which in this case would be the footer, not the requested page.

>    filemtime($_SERVER['SCRIPT_NAME']);
>

Unfortunately, this, too, may or may not have any relationship to the 
file system.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13454 — SCRIPT_NAME (was: 404 error)

Jerry Stuckle wrote:

> On 4/23/2014 8:21 AM, Christoph Michael Becker wrote:
>> Thomas 'PointedEars' Lahn:
>>
>>> Look closely at that warning.  This approach is not going to work
>>> reliably
>>> because the HTTP request URI does not need to have anything to do
>>> with the
>>> file path of the resource.  In fact, there does not even need to be a
>>> real
>>> file for a URI, the served content could have been generated entirely
>>> by PHP
>>> (and usually is).  As a result, in those cases filemtime() returns
>>> FALSE …
>>
>> ACK.
>>
>>> You might be looking for filemtime(__FILE__) instead.
>>
>> __FILE__ contains the filepath of the currently *included* file; in Ed's
>> case the following should be more appropriate:
>>
> 
> True - which in this case would be the footer, not the requested page.
> 
>>    filemtime($_SERVER['SCRIPT_NAME']);
>>
> 
> Unfortunately, this, too, may or may not have any relationship to the
> file system.

Indeed, you're right.  Thanks for pointing that out.

I was mislead by the ambiguous documentation in the PHP manual[1], which
states:

| Contains the current script's path.

The CGI 1.1 specification[2] clarifies this:

| The SCRIPT_NAME variable MUST be set to a URI path (not URL-encoded)
| which could identify the CGI script

[1] <http://www.php.net/manual/en/reserved.variables.server.php>
[2] <https://tools.ietf.org/html/rfc3875#section-4.1.13>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web