__SELF__?

I love the __FILE__ constant; it's been enormously useful. Is there a
constant that would be the equivalent of $PHP_SELF? That's also a useful
value, but according to the docs, "...may or may not [exist] in $_SERVER."
In a distributed app, may or may not doesn't fly. I'm surprised, if there
isn't a reliable way to retrieve this value.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: __SELF__?

Alan Little wrote:[color=blue]
> I love the __FILE__ constant; it's been enormously useful. Is there a
> constant that would be the equivalent of $PHP_SELF? That's also a useful
> value, but according to the docs, "...may or may not [exist] in $_SERVER."
> In a distributed app, may or may not doesn't fly. I'm surprised, if there
> isn't a reliable way to retrieve this value.
>[/color]

Alan,

If it's supplied by the web server, it's available. But PHP cannot guarantee
what the servers give PHP.

For instance, Apache and IIS both supply it. But Acme Instant Web Server might not.

__FILE__, OTOH, is under complete control of PHP, so PHP can guarantee its
existence.

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

re: __SELF__?

Alan Little wrote:[color=blue]
> I love the __FILE__ constant; it's been enormously useful. Is there a
> constant that would be the equivalent of $PHP_SELF? That's also a useful
> value, but according to the docs, "...may or may not [exist] in $_SERVER."
> In a distributed app, may or may not doesn't fly. I'm surprised, if there
> isn't a reliable way to retrieve this value.
>
> --
> Alan Little
> Phorm PHP Form Processor
> http://www.phorm.com/[/color]

PHP_SELF should always be present in a web environment. It's a PHP
variable (it's called PHP_SELF after all). The individual SAPI modules
are responsible for setting it, which they all do.

re: __SELF__?

Alan Little wrote:[color=blue]
>
> I love the __FILE__ constant; it's been enormously useful.
> Is there a constant that would be the equivalent of $PHP_SELF?
> That's also a useful value, but according to the docs, "...may
> or may not [exist] in $_SERVER."[/color]

This is a sweeoing generalization; under Apache and IIS,
$_SERVER['PHP_SELF'] is always available.

Cheers,
NC

re: __SELF__?

Alan Little wrote:[color=blue]
>
> I love the __FILE__ constant; it's been enormously useful.
> Is there a constant that would be the equivalent of $PHP_SELF?
> That's also a useful value, but according to the docs, "...may
> or may not [exist] in $_SERVER."[/color]

This is a sweeping generalization; under Apache and IIS,
$_SERVER['PHP_SELF'] is always available.

Cheers,
NC

re: __SELF__?

On 2006-05-10, Alan Little <alan@n-o-s-p-a-m-phorm.com> wrote:[color=blue]
> I love the __FILE__ constant; it's been enormously useful. Is there a
> constant that would be the equivalent of $PHP_SELF? That's also a useful
> value, but according to the docs, "...may or may not [exist] in $_SERVER."
> In a distributed app, may or may not doesn't fly. I'm surprised, if there
> isn't a reliable way to retrieve this value.[/color]

Why would you want the value? I still have to see my first good reason
to use it ;) (In case you want to redirect a user to the same place
where he came from after a form submit, using '#' as value for the
action is as good and it doesn't has the potential security issues as
$_SERVER['PHP_SELF'] has...)

--
Met vriendelijke groeten,
Tim Van Wassenhove <http://timvw.madoka.be>

re: __SELF__?

Tim Van Wassenhove:
[color=blue]
> Why would you want the value? I still have to see my first good reason
> to use it ;) (In case you want to redirect a user to the same place
> where he came from after a form submit, using '#' as value for the
> action is as good and it doesn't has the potential security issues as
> $_SERVER['PHP_SELF'] has...)[/color]

I remember a similar discussion a while ago, and I went away thinking
there was something wrong with my PHP. I still don't know what
PHP_SELF is meant to be.

I see two relevant bug reports:

http://bugs.php.net/bug.php?id=13606 - says there was a documentation
problem, but the problem seems to persist

http://bugs.php.net/bug.php?id=18330 - I don't know what to make of
that dismissal

--
Jock

re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of
Jerry Stuckle of comp.lang.php make plain:
[color=blue]
> Alan Little wrote:[color=green]
>> I love the __FILE__ constant; it's been enormously useful. Is there a
>> constant that would be the equivalent of $PHP_SELF? That's also a
>> useful value, but according to the docs, "...may or may not [exist]
>> in $_SERVER." In a distributed app, may or may not doesn't fly. I'm
>> surprised, if there isn't a reliable way to retrieve this value.
>>[/color]
> If it's supplied by the web server, it's available. But PHP cannot
> guarantee what the servers give PHP.
>
> __FILE__, OTOH, is under complete control of PHP, so PHP can guarantee
> its existence.[/color]

I understand; that's what I like about __FILE__. I was wondering if there
were a similar constant with the same value as $PHP_SELF.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of
Chung Leong of comp.lang.php make plain:
[color=blue]
> Alan Little wrote:[color=green]
>> I love the __FILE__ constant; it's been enormously useful. Is there a
>> constant that would be the equivalent of $PHP_SELF? That's also a
>> useful value, but according to the docs, "...may or may not [exist]
>> in $_SERVER." In a distributed app, may or may not doesn't fly. I'm
>> surprised, if there isn't a reliable way to retrieve this value.[/color]
>
> PHP_SELF should always be present in a web environment.[/color]

I agree, but it isn't always. I've run into trouble relying on it in Phorm.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of NC of
comp.lang.php make plain:
[color=blue]
> Alan Little wrote:[color=green]
>>
>> I love the __FILE__ constant; it's been enormously useful.
>> Is there a constant that would be the equivalent of $PHP_SELF?
>> That's also a useful value, but according to the docs, "...may
>> or may not [exist] in $_SERVER."[/color]
>
> This is a sweeping generalization; under Apache and IIS,
> $_SERVER['PHP_SELF'] is always available.[/color]

I wish it were, but I've encountered instances where it wasn't.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of Tim
Van Wassenhove of comp.lang.php make plain:
[color=blue]
> On 2006-05-10, Alan Little <alan@n-o-s-p-a-m-phorm.com> wrote:[color=green]
>> I love the __FILE__ constant; it's been enormously useful. Is there a
>> constant that would be the equivalent of $PHP_SELF? That's also a
>> useful value, but according to the docs, "...may or may not [exist]
>> in $_SERVER." In a distributed app, may or may not doesn't fly. I'm
>> surprised, if there isn't a reliable way to retrieve this value.[/color]
>
> Why would you want the value? I still have to see my first good reason
> to use it ;)[/color]

It allows a script to find out where it's installed (which can also be
done with __FILE__ of course), and for an included file or a function to
know where it's being called from.
[color=blue]
> (In case you want to redirect a user to the same place
> where he came from after a form submit, using '#' as value for the
> action is as good and it doesn't has the potential security issues as
> $_SERVER['PHP_SELF'] has...)[/color]

Another great reason for it to be a constant, like __FILE__.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of Alan
Little of comp.lang.php make plain:
[color=blue]
> Carved in mystic runes upon the very living rock, the last words of
> Tim Van Wassenhove of comp.lang.php make plain:
>[color=green]
>> On 2006-05-10, Alan Little <alan@n-o-s-p-a-m-phorm.com> wrote:
>>[color=darkred]
>>> I love the __FILE__ constant; it's been enormously useful. Is there
>>> a constant that would be the equivalent of $PHP_SELF?[/color]
>>
>> Why would you want the value? I still have to see my first good
>> reason to use it ;)[/color]
>
> It allows a script to find out where it's installed (which can also be
> done with __FILE__ of course),[/color]

Actually, I misspoke. $PHP_SELF gives the URL path; __FILE__ gives the
filesystem path. So, the path info of $PHP_SELF can be useful, as well.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: __SELF__?

Alan Little wrote:[color=blue]
> Carved in mystic runes upon the very living rock, the last words of
> Jerry Stuckle of comp.lang.php make plain:
>
>[color=green]
>>Alan Little wrote:
>>[color=darkred]
>>>I love the __FILE__ constant; it's been enormously useful. Is there a
>>>constant that would be the equivalent of $PHP_SELF? That's also a
>>>useful value, but according to the docs, "...may or may not [exist]
>>>in $_SERVER." In a distributed app, may or may not doesn't fly. I'm
>>>surprised, if there isn't a reliable way to retrieve this value.
>>>[/color]
>>
>>If it's supplied by the web server, it's available. But PHP cannot
>>guarantee what the servers give PHP.
>>
>>__FILE__, OTOH, is under complete control of PHP, so PHP can guarantee
>>its existence.[/color]
>
>
> I understand; that's what I like about __FILE__. I was wondering if there
> were a similar constant with the same value as $PHP_SELF.
>[/color]

Not that's guaranteed to be provided by every host. $_SERVER['PHP_SELF'] (the
real name - it's a member of the $_SERVER array) is good because it's always the
name of the page being displayed. That has to be gotten from the server.

But I wouldn't worry about it. It's available in Apache and IIS. Those account
for > 99% of the servers on the web.

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

re: __SELF__?

Alan Little wrote:[color=blue]
> Carved in mystic runes upon the very living rock, the last words of NC of
> comp.lang.php make plain:
>
>[color=green]
>>Alan Little wrote:
>>[color=darkred]
>>>I love the __FILE__ constant; it's been enormously useful.
>>>Is there a constant that would be the equivalent of $PHP_SELF?
>>>That's also a useful value, but according to the docs, "...may
>>>or may not [exist] in $_SERVER."[/color]
>>
>>This is a sweeping generalization; under Apache and IIS,
>>$_SERVER['PHP_SELF'] is always available.[/color]
>
>
> I wish it were, but I've encountered instances where it wasn't.
>[/color]

Can you be more specific? I've never seen a case on Apache or IIS where it
isn't available.

Perhaps someone overwrite the $_SERVER array?

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

re: __SELF__?

On Thu, 11 May 2006 08:43:28 -0400, Jerry Stuckle wrote:[color=blue][color=green][color=darkred]
>>>>I love the __FILE__ constant; it's been enormously useful. Is there a
>>>>constant that would be the equivalent of $PHP_SELF? That's also a
>>>>useful value, but according to the docs, "...may or may not [exist] in
>>>>$_SERVER."
>>>
>>>This is a sweeping generalization; under Apache and IIS,
>>>$_SERVER['PHP_SELF'] is always available.[/color]
>>
>>
>> I wish it were, but I've encountered instances where it wasn't.
>>[/color]
> Can you be more specific? I've never seen a case on Apache or IIS where
> it isn't available.
>
> Perhaps someone overwrite the $_SERVER array?[/color]

Or PHP configured as a CLI binary (AFAIK $_SERVER is only available to
apache modules and ISAPI modules).

Cheers,


Andy

--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.org | PHP editor for Gnome 2
http://www.andyjeffries.co.uk | Personal site and photos

re: __SELF__?

Alan Little wrote:[color=blue]
> Carved in mystic runes upon the very living rock, the last words of
> Chung Leong of comp.lang.php make plain:
>[color=green]
> > Alan Little wrote:[color=darkred]
> >> I love the __FILE__ constant; it's been enormously useful. Is there a
> >> constant that would be the equivalent of $PHP_SELF? That's also a
> >> useful value, but according to the docs, "...may or may not [exist]
> >> in $_SERVER." In a distributed app, may or may not doesn't fly. I'm
> >> surprised, if there isn't a reliable way to retrieve this value.[/color]
> >
> > PHP_SELF should always be present in a web environment.[/color]
>
> I agree, but it isn't always. I've run into trouble relying on it in Phorm.[/color]

Under what situation do you not see PHP_SELF? It's obviously possible
that a certain version of a SAPI module is buggy. The point is it's
supposed to be there.

re: __SELF__?

Alan Little wrote:[color=blue][color=green]
> > (In case you want to redirect a user to the same place
> > where he came from after a form submit, using '#' as value for the
> > action is as good and it doesn't has the potential security issues as
> > $_SERVER['PHP_SELF'] has...)[/color]
>
> Another great reason for it to be a constant, like __FILE__.
>
> --
> Alan Little
> Phorm PHP Form Processor
> http://www.phorm.com/[/color]

__FILE__ is actually a language construct--hence its place in the list
of reserved words.

I think Tim is right about PHP_SELF not being terribly useful. I use
it often enouogh myself, but can't really offer any rational reason to
do so. It's some weird, subconscious mistrust of the browser, I think.

re: __SELF__?

On 2006-05-10, John Dunlop <usenet+2004@john.dunlop.name> wrote:[color=blue]
> Tim Van Wassenhove:
>[color=green]
>> Why would you want the value? I still have to see my first good reason
>> to use it ;) (In case you want to redirect a user to the same place
>> where he came from after a form submit, using '#' as value for the
>> action is as good and it doesn't has the potential security issues as
>> $_SERVER['PHP_SELF'] has...)[/color]
>
> I remember a similar discussion a while ago, and I went away thinking
> there was something wrong with my PHP. I still don't know what
> PHP_SELF is meant to be.[/color]

[snip bug reports]

Here is an example of possible abuse of forms that use
$_SERVER['PHP_SELF']: http://blog.phpdoc.info/archives/13-XSS-Woes.html

--
Met vriendelijke groeten,
Tim Van Wassenhove <http://timvw.madoka.be>

re: __SELF__?

Andy Jeffries wrote:[color=blue]
> On Thu, 11 May 2006 08:43:28 -0400, Jerry Stuckle wrote:
>[color=green][color=darkred]
>>>>>I love the __FILE__ constant; it's been enormously useful. Is there a
>>>>>constant that would be the equivalent of $PHP_SELF? That's also a
>>>>>useful value, but according to the docs, "...may or may not [exist] in
>>>>>$_SERVER."
>>>>
>>>>This is a sweeping generalization; under Apache and IIS,
>>>>$_SERVER['PHP_SELF'] is always available.
>>>
>>>
>>>I wish it were, but I've encountered instances where it wasn't.
>>>[/color]
>>
>>Can you be more specific? I've never seen a case on Apache or IIS where
>>it isn't available.
>>
>>Perhaps someone overwrite the $_SERVER array?[/color]
>
>
> Or PHP configured as a CLI binary (AFAIK $_SERVER is only available to
> apache modules and ISAPI modules).
>
> Cheers,
>
>
> Andy
>[/color]

Good point, Andy. I never use PHP as a CLI, and completely forgot that one.

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

re: __SELF__?

Andy Jeffries wrote:[color=blue]
>
> Or PHP configured as a CLI binary (AFAIK $_SERVER is only available to
> apache modules and ISAPI modules).[/color]

I'm pretty sure that $_SERVER, along with $_GET, $_POST, and $_COOKIE
are available in PHP-CLI. They're built fairly deep inside PHP.
There's no easy way to rip them out. It's certainly not worth the
effort, as you'll only end up breaking things.

Only session and file support support are removed from CLI if I
remember correctly.

re: __SELF__?

>> Or PHP configured as a CLI binary (AFAIK $_SERVER is only available to[color=blue][color=green]
>> apache modules and ISAPI modules).[/color]
>
>I'm pretty sure that $_SERVER, along with $_GET, $_POST, and $_COOKIE
>are available in PHP-CLI. They're built fairly deep inside PHP.[/color]

But even if $_GET, $_POST, $_COOKIE, and $_REQUEST exist in PHP-CLI,
there's absolutely nothing to put in them. If the point is that
you could add something to them, ok, but I'm not sure that's a good
thing.

$_SERVER['argv'], at least, exists. $_SERVER in the CLI version also
seems to pick up environment variables from its invoker.
[color=blue]
>There's no easy way to rip them out. It's certainly not worth the
>effort, as you'll only end up breaking things.
>
>Only session and file support support are removed from CLI if I
>remember correctly.[/color]

Gordon L. Burditt

re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of
Chung Leong of comp.lang.php make plain:
[color=blue]
> Alan Little wrote:[color=green]
>> Carved in mystic runes upon the very living rock, the last words of
>> Chung Leong of comp.lang.php make plain:
>>[color=darkred]
>> > Alan Little wrote:
>> >> I love the __FILE__ constant; it's been enormously useful. Is
>> >> there a constant that would be the equivalent of $PHP_SELF? That's
>> >> also a useful value, but according to the docs, "...may or may not
>> >> [exist] in $_SERVER." In a distributed app, may or may not doesn't
>> >> fly. I'm surprised, if there isn't a reliable way to retrieve this
>> >> value.
>> >
>> > PHP_SELF should always be present in a web environment.[/color]
>>
>> I agree, but it isn't always. I've run into trouble relying on it in
>> Phorm.[/color]
>
> Under what situation do you not see PHP_SELF? It's obviously possible
> that a certain version of a SAPI module is buggy. The point is it's
> supposed to be there.[/color]

Well, to be honest I never did any real troubleshooting on it, and it was
quite a while ago. I used to rely on it in Phorm, and there were 2 or 3
times users had problems because it wasn't set.

I'm just surprised that whoever thought of the __FILE__ constant didn't
think to make this one as well, both for reasons of reliability and
security.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of
Chung Leong of comp.lang.php make plain:
[color=blue]
> Alan Little wrote:[color=green][color=darkred]
>> > (In case you want to redirect a user to the same place
>> > where he came from after a form submit, using '#' as value for the
>> > action is as good and it doesn't has the potential security issues
>> > as $_SERVER['PHP_SELF'] has...)[/color]
>>
>> Another great reason for it to be a constant, like __FILE__.[/color]
>
> I think Tim is right about PHP_SELF not being terribly useful. I use
> it often enouogh myself, but can't really offer any rational reason to
> do so.[/color]

I think the uses I listed are pretty rational.
[color=blue]
> It's some weird, subconscious mistrust of the browser, I think.[/color]

How do you mean? I don't see how the browser enters into it.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: __SELF__?

Chung Leong wrote:
[color=blue]
> Under what situation do you not see PHP_SELF?[/color]

http://bugs.php.net/bug.php?id=31892

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

re: __SELF__?

Alan Little wrote:
[color=blue]
> I understand; that's what I like about __FILE__. I was wondering if there
> were a similar constant with the same value as $PHP_SELF.[/color]

A PHP script *can never _know_* what URL it was requested at. (Nor can a
Perl script, nor any other scripting language.)

For example:

http://server2.example.org/foo.php contains the following:

<?php
echo $_SERVER['PHP_SELF'];
?>

http://server1.example.org/.htaccess contains the following:

RewriteEngine on
RewriteRule ^(.*)\.php$ http://server2.example.org/foo.php

Now I visit "http://server1.example.org/bar.php", the script will echo
back to me "foo.php".

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

re: __SELF__?

Alan Little wrote:[color=blue]
> I think the uses I listed are pretty rational.[/color]

Not to be overly critical, but you just cited PHP_SELF's function as
its ration d'etre. We all know it let you figure out what URI caused
the script to fire. The question is why you'd want to know that.
[color=blue]
> How do you mean? I don't see how the browser enters into it.[/color]

Some people, myself include, like to put insert PHP_SELF into a form
tag's action attribute when the form submits back to the same script.
You could just as well leave attribute blank. But somehow it seems
kooky. The same with anchor tags. For linking to the current page but
with different GET parameters, one could just start the href attribute
with a question mark. Yet many people, myself include again, would
stick it PHP_SELF. It's driven by a sort of fear that the browser
wouldn't build the full URL from the relative parts correctly.

re: __SELF__?

Alan Little wrote:[color=blue]
> I'm just surprised that whoever thought of the __FILE__ constant didn't
> think to make this one as well, both for reasons of reliability and
> security.[/color]

It's not that surprising if you consider the architecture. PHP is
consisted of the PHP framework and the Zend engine. __FILE__, along
with __CLASS__, and __FUNCTION__, live in application-agnostic Zend
land. The information they hold is readily already to the language
parser. PHP_SELF on the other hand has to live in PHP-SAPI land, since
that's information from the web server. It's possible to implement what
you described, but then we would end up with cross-talk between
components that are supposed to be independent.

Again, __FILE__ is not a constant. It's a language construct. Its value
changes--unlike a constant.

re: __SELF__?

Tim Van Wassenhove:
[color=blue]
> Here is an example of possible abuse of forms that use
> $_SERVER['PHP_SELF']: http://blog.phpdoc.info/archives/13-XSS-Woes.html[/color]

Ta for the link, Tim. So PHP_SELF is essentially user input.

Still don't know exactly what it is. I think it's something between
the (surface) URL and the filename, after the URL has undergone any
rewriting, because it can have both parts that are present in the URL
but absent in the filename and parts that are present in the filename
but absent in the URL. My half-assed testing doesn't lead me to an
answer.

It's easier to say what it isn't: it isn't the last seg. of the
(surface) URL-path, nor is it the filename.

--
Jock

re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of Chung
Leong of comp.lang.php make plain:
[color=blue]
> Alan Little wrote:[color=green]
>> I think the uses I listed are pretty rational.[/color]
>
> Not to be overly critical, but you just cited PHP_SELF's function as
> its ration d'etre. We all know it let you figure out what URI caused
> the script to fire. The question is why you'd want to know that.[/color]

Ah, ISWYM.

A couple of examples:

1. Phorm plugins use it to ensure they're being called from Phorm.
I encourage users to secure their plugins directory with .htaccess
or equivalent for their server, but users don't always do as they're
encouraged. The idea is to prevent

http://www.example.com/phorm/plugins/someplugin.php

2. I have a homebrew template processor I use in all my applications.
The calling script can, of course, specify the template, but if it
doesn't, the default is (for example) example.html if called from
example.php. Using $PHP_SELF works fine for me, but I've been thinking
of making it generally available.
[color=blue][color=green]
>> How do you mean? I don't see how the browser enters into it.[/color]
>
> Some people, myself include, like to put insert PHP_SELF into a form
> tag's action attribute when the form submits back to the same script.
> You could just as well leave attribute blank. But somehow it seems
> kooky. The same with anchor tags. For linking to the current page but
> with different GET parameters, one could just start the href attribute
> with a question mark. Yet many people, myself include again, would
> stick it PHP_SELF. It's driven by a sort of fear that the browser
> wouldn't build the full URL from the relative parts correctly.[/color]

Ah, I see.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of
Chung Leong of comp.lang.php make plain:
[color=blue]
> Alan Little wrote:[color=green]
>> I'm just surprised that whoever thought of the __FILE__ constant
>> didn't think to make this one as well, both for reasons of
>> reliability and security.[/color]
>
> It's not that surprising if you consider the architecture. PHP is
> consisted of the PHP framework and the Zend engine. __FILE__, along
> with __CLASS__, and __FUNCTION__, live in application-agnostic Zend
> land. The information they hold is readily already to the language
> parser. PHP_SELF on the other hand has to live in PHP-SAPI land, since
> that's information from the web server. It's possible to implement
> what you described, but then we would end up with cross-talk between
> components that are supposed to be independent.[/color]

OK, that makes sense. I guess I hadn't fully thought out the thing I was
wishing for. For the things I've used it for, I haven't been interested
so much in the URL path as in the file name, which of course is knowable
internally. A construct like __FILE__ which would hold the name of the
main script, with or without filesystem or URL path info, would be
useful.
[color=blue]
> Again, __FILE__ is not a constant. It's a language construct. Its value
> changes--unlike a constant.[/color]

Terminology corrected. Thanks.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: __SELF__?

Alan Little wrote:[color=blue]
> A couple of examples:
>
> 1. Phorm plugins use it to ensure they're being called from Phorm.
> I encourage users to secure their plugins directory with .htaccess
> or equivalent for their server, but users don't always do as they're
> encouraged. The idea is to prevent
>
> http://www.example.com/phorm/plugins/someplugin.php[/color]

<?php include("my_usual_rant_about_using_includes_as_fun ctions.php");
?>

I don't really get why it's necessary to use PHP_SELF for this suppose.
Surely it's easier to do a define('IN_PHORM', 1) and then check for
the presence of the constant. Even easier is to have all these plug-ins
of yours call a function within Phorm. If the script is accessed
directly, it automatically blows up.
[color=blue]
> 2. I have a homebrew template processor I use in all my applications.
> The calling script can, of course, specify the template, but if it
> doesn't, the default is (for example) example.html if called from
> example.php. Using $PHP_SELF works fine for me, but I've been thinking
> of making it generally available.[/color]

Still, you don't really need to know the actually URI. All you need is
the filename, which you can obtain reliably through debug_backtrace().

Having an application "know where it is" tend to cause problems during
deployment. Recently I've had to proxy a few sites through Apache
mod_proxy and the presence of absolute URLs was a major headache.

re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of
Chung Leong of comp.lang.php make plain:
[color=blue]
> Alan Little wrote:[color=green]
>> A couple of examples:
>>
>> 1. Phorm plugins use it to ensure they're being called from Phorm.
>> I encourage users to secure their plugins directory with .htaccess
>> or equivalent for their server, but users don't always do as
>> they're encouraged. The idea is to prevent
>>
>> http://www.example.com/phorm/plugins/someplugin.php[/color]
>
> <?php include("my_usual_rant_about_using_includes_as_fun ctions.php");
> ?>[/color]

I'm not sure how this applies to plugins (then again, I'm not familiar
with your usual rant about using includes as functions :)
[color=blue]
> I don't really get why it's necessary to use PHP_SELF for this
> suppose. Surely it's easier to do a define('IN_PHORM', 1) and then
> check for the presence of the constant. Even easier is to have all
> these plug-ins of yours call a function within Phorm. If the script is
> accessed directly, it automatically blows up.[/color]

I hadn't thought of those methods, both excellent. Thank you.
[color=blue][color=green]
>> 2. I have a homebrew template processor I use in all my applications.
>> The calling script can, of course, specify the template, but if it
>> doesn't, the default is (for example) example.html if called from
>> example.php. Using $PHP_SELF works fine for me, but I've been
>> thinking of making it generally available.[/color]
>
> Still, you don't really need to know the actually URI.[/color]

True -- see my other post from yesterday.
[color=blue]
> All you need is the filename, which you can obtain reliably through
> debug_backtrace().[/color]

I wasn't aware of this function. Thanks again.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: __SELF__?

Alan Little wrote:[color=blue]
> I'm not sure how this applies to plugins (then again, I'm not familiar
> with your usual rant about using includes as functions :)[/color]

As I understood it, your plugins are basically naked code sitting in
files that get included. That's why direct access through a web
address is a problem. If the code is wrapped in a function or in a
class, then you wouldn't have that problem, as nothing would happen
when PHP processes the file.

re: __SELF__?

Chung Leong wrote:
[color=blue]
> Surely it's easier to do a define('IN_PHORM', 1) and then check for
> the presence of the constant.[/color]

Better still:

define('PHORM_VERSION', 2.001);

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of Chung
Leong of comp.lang.php make plain:
[color=blue]
> Alan Little wrote:[color=green]
>> I'm not sure how this applies to plugins (then again, I'm not familiar
>> with your usual rant about using includes as functions :)[/color]
>
> As I understood it, your plugins are basically naked code sitting in
> files that get included.[/color]

Correct.
[color=blue]
> That's why direct access through a web address is a problem. If the
> code is wrapped in a function or in a class, then you wouldn't have
> that problem, as nothing would happen when PHP processes the file.[/color]

OK. When you said, "using includes as functions", I took it to mean
having a bit of code that's called from various places in the main code,
and putting it in an included file, rather than a function. I once had a
date-selector generator that I did that with, but long ago converted it
to a function. I'm not trying to be a smart@$$, I just didn't see how
that applied to plugins.

But as far as wrapping the code in a function or class in order to
prevent it being executed directly, that's another way of doing it, but I
like the define() approach better; I just include the file and it's done,
rather than having to include it and then invoke the function.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: __SELF__?

Alan Little wrote:[color=blue]
> OK. When you said, "using includes as functions", I took it to mean
> having a bit of code that's called from various places in the main code,
> and putting it in an included file, rather than a function. I once had a
> date-selector generator that I did that with, but long ago converted it
> to a function. I'm not trying to be a smart@$$, I just didn't see how
> that applied to plugins.[/color]

Whether the code is included once or many times is unimportant. The key
deficencies of includes are the lack of a clear interface and the lack
of variable scoping. For your plug-ins, how are the authors supposed to
know what variables are available? I mean their code would just inherit
the entire global scope. How do you prevent them from accidently
overwriting variables?

re: __SELF__?

On Thu, 11 May 2006 12:36:19 -0700, Chung Leong wrote:[color=blue][color=green]
>> Or PHP configured as a CLI binary (AFAIK $_SERVER is only available to
>> apache modules and ISAPI modules).[/color]
>
> I'm pretty sure that $_SERVER, along with $_GET, $_POST, and $_COOKIE are
> available in PHP-CLI. They're built fairly deep inside PHP. There's no
> easy way to rip them out. It's certainly not worth the effort, as you'll
> only end up breaking things.[/color]

Sorry, you're right, $_SERVER is available, what I meant was that I didn't
think $_SERVER[PHP_SELF] was available to CLI. Having actually tested it,
I'm pleased to say I'm wrong and it is indeed available to CLI PHP.
[color=blue]
> Only session and file support support are removed from CLI if I remember
> correctly.[/color]

Actually it creates session files in the current folder if you start a
session from a CLI script (made that mistake with an import script) and it
certainly does contain file support (same import script reads local files).

Cheers,


Andy

--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.org | PHP editor for Gnome 2
http://www.andyjeffries.co.uk | Personal site and photos

re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of
Chung Leong of comp.lang.php make plain:
[color=blue]
> Alan Little wrote:[color=green]
>> OK. When you said, "using includes as functions", I took it to mean
>> having a bit of code that's called from various places in the main
>> code, and putting it in an included file, rather than a function. I
>> once had a date-selector generator that I did that with, but long ago
>> converted it to a function. I'm not trying to be a smart@$$, I just
>> didn't see how that applied to plugins.[/color]
>
> Whether the code is included once or many times is unimportant. The
> key deficencies of includes are the lack of a clear interface and the
> lack of variable scoping. For your plug-ins, how are the authors
> supposed to know what variables are available? I mean their code would
> just inherit the entire global scope. How do you prevent them from
> accidently overwriting variables?[/color]

Good points. So far I've been the only one to write plugins, so it hasn't
been a problem, and I've considered operating in the global scope a plus.

Of course, a lot of what we've discussed in this thread is moot, as far
as Phorm is concerned. The next release will be v4, which is a complete
re-build from the ground up, and is done as a class, so things are much
more encapsulated.

But you've certainly given me some things to think about. Thanks.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/