Re: [PHP-DEV] URL

[Manuzhai]

I think you want to use a simple frameset as the index of your site, then
load all of your pages inside the frameset. This way, the address will still
look like your domain, and it's really easy to do.

Actually this is not the right list to ask, though. PHP-DEV is for
developing PHP itself, not developing with PHP. Please refer to php-general
for further questions.

"Marco Tabini" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Well, you could use mod_rewrite or simply point the default page of your
website to a particular URL, but that will only work for one page--you
can't hide all the pages behind the same URL, because the server
wouldn't know how to address them.


On Thu, 2002-10-10 at 16:38, ^|CoOL|^ cRþSH wrote:
> how can i hide the complete URL on my site and only show the domain.. well
> im colombian , thats because my english aint the best, but maybe this
> example can help..
>
> URL : http://foros.solocodigo.com/post.php?action=newthread&fid=10
>
> but i want only to show this
>
> URL : http://foros.solocodigo.com/
>
> THNX!"
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bundled gd

[Sander Roobol]

On Fri, Oct 11, 2002 at 12:49:07AM +0300, Jani Taskinen wrote:
> On Thu, 10 Oct 2002, Tit "Black" Petric wrote:
> >since gd is supposed to be bundled and packed together with php4.3 i just
> >wanted to know if the patch for imagettftext for the truecolor rendering
> >will be applied to its source, or if its allready has been - i wouldnt want
> >it to be missed by accident
> >
> >if it is not then http://www.coupin.net/gd-freetype/ has the diff/source for
> >gd2.0.1 which i believe is the latest one
> 
> According to CVS log for ext/gd/libgd/gdft.c:
> [ snip ]
> It was added and then removed..

It was removed because it appeared to be already fixed by one of the
other patches. This patch broke it again. Please try a snapshot to see
if it works for you.

Sander

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] bundled gd

[Gareth Ardron]

At 09:14 11/10/2002 +0200, BUSTARRET, Jean-Francois wrote:

>We are currently building apps for French iMode, and have to use a 
>closed-source non-free Windows DLL to generate our images (can't use GD 
>and imageMagick's dithering algorithm is shitty).

have a look at imlib2 and the various command line stuff revolving around 
that - far far better than imagemagick and much quicker as well


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main config.w32.h.in

[Edin Kadribasic]

Why? Nobody seems to be willing to fix it for good and having a
broken build in the cvs causes problems such as snapshots not being
generatad, etc.

Edin
- Original Message -
From: "Sebastian Bergmann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 10, 2002 9:08 PM
Subject: [PHP-CVS] cvs: php4 /main config.w32.h.in


> sebastian Thu Oct 10 15:08:13 2002 EDT
>
>   Modified files:
> /php4/main config.w32.h.in
>   Log:
>   Break it again (after 4.3.0-pre1 :-)
>
>
> Index: php4/main/config.w32.h.in
> diff -u php4/main/config.w32.h.in:1.15
php4/main/config.w32.h.in:1.16
> --- php4/main/config.w32.h.in:1.15 Thu Oct 10 13:45:36 2002
> +++ php4/main/config.w32.h.in Thu Oct 10 15:08:13 2002
> @@ -2,22 +2,24 @@
>   Build Configuration for Win32.
>   This has only been tested with MS VisualC++ 6 (and later).
>
> - $Id: config.w32.h.in,v 1.15 2002/10/10 17:45:36 sebastian Exp $
> + $Id: config.w32.h.in,v 1.16 2002/10/10 19:08:13 sebastian Exp $
>  */
>
>  /* Default PHP / PEAR directories */
> +#define CONDENV(ev,def) (getenv(ev)!=NULL?getenv(ev):def)
> +
>  #define CONFIGURATION_FILE_PATH "php.ini"
> -#define PEAR_INSTALLDIR "c:\\php4\\pear"
> -#define PHP_BINDIR "c:\\php4"
> -#define PHP_CONFIG_FILE_PATH
(getenv("SystemRoot"))?getenv("SystemRoot"):""
> -#define PHP_CONFIG_FILE_SCAN_DIR ""
> -#define PHP_DATADIR "c:\\php4"
> -#define PHP_EXTENSION_DIR "c:\\php4"
> -#define PHP_INCLUDE_PATH ".;c:\\php4\\pear"
> -#define PHP_LIBDIR "c:\\php4"
> -#define PHP_LOCALSTATEDIR "c:\\php4"
> -#define PHP_PREFIX "c:\\php4"
> -#define PHP_SYSCONFDIR "c:\\php4"
> +#define PEAR_INSTALLDIR  CONDENV("PEAR_INSTALLDIR",
"c:\\php4\\pear")
> +#define PHP_BINDIR   CONDENV("PHP_BINDIR",
"c:\\php4")
> +#define PHP_CONFIG_FILE_PATH CONDENV("SystemRoot", "")
> +#define PHP_CONFIG_FILE_SCAN_DIR
CONDENV("PHP_CONFIG_FILE_SCAN_DIR", "")
> +#define PHP_DATADIR  CONDENV("PHP_DATADIR",
"c:\\php4")
> +#define PHP_EXTENSION_DIRCONDENV("PHP_EXTENSION_DIR",
"c:\\php4")
> +#define PHP_INCLUDE_PATH CONDENV("PHP_INCLUDE_PATH",
".;c:\\php4\\pear")
> +#define PHP_LIBDIR   CONDENV("PHP_LIBDIR",
"c:\\php4")
> +#define PHP_LOCALSTATEDIRCONDENV("PHP_LOCALSTATEDIR",
"c:\\php4")
> +#define PHP_PREFIX   CONDENV("PHP_PREFIX",
"c:\\php4")
> +#define PHP_SYSCONFDIR   CONDENV("PHP_SYSCONFDIR",
"c:\\php4")
>
>  /* Enable / Disable BCMATH extension (default: enabled) */
>  #define WITH_BCMATH 1
>
>
>
> --
> PHP CVS Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main config.w32.h.in

[Edin Kadribasic]

Why? Nobody seems to be willing to fix it for good and having a
broken build in the cvs causes problems such as snapshots not being
generatad, etc.

Edin
- Original Message -
From: "Sebastian Bergmann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 10, 2002 9:08 PM
Subject: [PHP-CVS] cvs: php4 /main config.w32.h.in


> sebastian Thu Oct 10 15:08:13 2002 EDT
>
>   Modified files:
> /php4/main config.w32.h.in
>   Log:
>   Break it again (after 4.3.0-pre1 :-)
>
>
> Index: php4/main/config.w32.h.in
> diff -u php4/main/config.w32.h.in:1.15
php4/main/config.w32.h.in:1.16
> --- php4/main/config.w32.h.in:1.15 Thu Oct 10 13:45:36 2002
> +++ php4/main/config.w32.h.in Thu Oct 10 15:08:13 2002
> @@ -2,22 +2,24 @@
>   Build Configuration for Win32.
>   This has only been tested with MS VisualC++ 6 (and later).
>
> - $Id: config.w32.h.in,v 1.15 2002/10/10 17:45:36 sebastian Exp $
> + $Id: config.w32.h.in,v 1.16 2002/10/10 19:08:13 sebastian Exp $
>  */
>
>  /* Default PHP / PEAR directories */
> +#define CONDENV(ev,def) (getenv(ev)!=NULL?getenv(ev):def)
> +
>  #define CONFIGURATION_FILE_PATH "php.ini"
> -#define PEAR_INSTALLDIR "c:\\php4\\pear"
> -#define PHP_BINDIR "c:\\php4"
> -#define PHP_CONFIG_FILE_PATH
(getenv("SystemRoot"))?getenv("SystemRoot"):""
> -#define PHP_CONFIG_FILE_SCAN_DIR ""
> -#define PHP_DATADIR "c:\\php4"
> -#define PHP_EXTENSION_DIR "c:\\php4"
> -#define PHP_INCLUDE_PATH ".;c:\\php4\\pear"
> -#define PHP_LIBDIR "c:\\php4"
> -#define PHP_LOCALSTATEDIR "c:\\php4"
> -#define PHP_PREFIX "c:\\php4"
> -#define PHP_SYSCONFDIR "c:\\php4"
> +#define PEAR_INSTALLDIR  CONDENV("PEAR_INSTALLDIR",
"c:\\php4\\pear")
> +#define PHP_BINDIR   CONDENV("PHP_BINDIR",
"c:\\php4")
> +#define PHP_CONFIG_FILE_PATH CONDENV("SystemRoot", "")
> +#define PHP_CONFIG_FILE_SCAN_DIR
CONDENV("PHP_CONFIG_FILE_SCAN_DIR", "")
> +#define PHP_DATADIR  CONDENV("PHP_DATADIR",
"c:\\php4")
> +#define PHP_EXTENSION_DIRCONDENV("PHP_EXTENSION_DIR",
"c:\\php4")
> +#define PHP_INCLUDE_PATH CONDENV("PHP_INCLUDE_PATH",
".;c:\\php4\\pear")
> +#define PHP_LIBDIR   CONDENV("PHP_LIBDIR",
"c:\\php4")
> +#define PHP_LOCALSTATEDIRCONDENV("PHP_LOCALSTATEDIR",
"c:\\php4")
> +#define PHP_PREFIX   CONDENV("PHP_PREFIX",
"c:\\php4")
> +#define PHP_SYSCONFDIR   CONDENV("PHP_SYSCONFDIR",
"c:\\php4")
>
>  /* Enable / Disable BCMATH extension (default: enabled) */
>  #define WITH_BCMATH 1
>
>
>
> --
> PHP CVS Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: session_register warnings

[Rasmus Lerdorf]

Sascha, would you mind explaining the reasoning for changing this
behaviour?  Whether it is documented or not, I'd like to hear a technical
reason for not allowing session_register() to act on global variables when
register_globals is off.  I still don't see it.  All I see is
inconsistency here.

-Rasmus

On Wed, 9 Oct 2002, Sascha Schumann wrote:

> > I'd like to do a collective rethink of this.  The simple description of
> > the session_register() function in the manual is:
>
> This description was correct initially (I wrote it), but has
> not been updated as the session module was extended.  I've
> noticed this documentation issue in the earlier thread, but
> have not come around to fix it yet.
>
> If I may refer you to the session index page again, that one
> clearly stated since the beginning that the behaviour
> changes, depending on register_globals.
>
> Now, if your application(s) rely on this feature and you
> don't want to change them, you can always disable the
> warning.
>
> > make the function behave exactly as described in the short description.
>
> I suggest we fix the documentation.
>
> >  2. changing this breaks BC
>
> I'm not aware of any BC issues.  If you have a test case,
> I'll be happy to look at it.
>
> - Sascha
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] How to debug?

[David Reid]

Can I run the tests under gdb to try and see if I can get a better
backtrace? I'm still seeing the segafluts in the session tests...

david


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: session_register warnings

[Sascha Schumann]

On Fri, 11 Oct 2002, Rasmus Lerdorf wrote:

> Sascha, would you mind explaining the reasoning for changing this
> behaviour?  Whether it is documented or not, I'd like to hear a technical
> reason for not allowing session_register() to act on global variables when
> register_globals is off.  I still don't see it.  All I see is
> inconsistency here.

PHP 4.2 and earlier versions behave inconsistenly with regard
to treating global variables as source of session variables.
They work exactly like this:

1st request

session_register('c');
$c = 3; # Updates session variable

2nd request

session_start();
$c = 5; # Does NOT update session variable

That is clearly broken under the assumption that
session_register() should act on global variables.  It
clearly does not (always).  A user should be able to access a
session var using globals either all the time or never.  If
it is 'sometimes', valid code will cause unexpected results
(imagine in the above example that $c is a global,
non-session variable and that $_SESSION["c"] is not set
during the first request).

From my point of view, it is a fallacy to ask for prolonging
this misfeature of earlier PHP 4.2 releases.  It absolutely
had to be addressed.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: session_register warnings

[Rasmus Lerdorf]

> PHP 4.2 and earlier versions behave inconsistenly with regard
> to treating global variables as source of session variables.
> They work exactly like this:
>
> 1st request
>
> session_register('c');
> $c = 3; # Updates session variable
>
> 2nd request
>
> session_start();
> $c = 5; # Does NOT update session variable
>
> That is clearly broken under the assumption that
> session_register() should act on global variables.  It
> clearly does not (always).

Ok, disregard everything else and let's just focus on this one statement
since it is the core of the disagreement.  The way session_register() has
always worked and has been documented is this:

   session_register() registers the global variable with that name in the
   current session.

Very simple.  It says that the named global variable will become part of
the session.  Nothing else.  It does not imply that this variable we have
injected into the session will always be available as a global or anything
else, it is simply a function that lets you take a global variable and put
it into the session.

If register_globals affects this, then you have completely changed the
meaning behind the register_globals switch.  register_globals should have
absolutely no side-effects.  It should be a simple and consistent switch
which only affects whether PHP's global symbol table is auto-populated or
not.

If register_globals is off, it is starting to sink in for people that they
will need to access variables through one of the autoglobal arrays and
that no variables will automatically enter the global symbol table.
Therefore it is quite consistent that they will have to get and modify
$_SESSION['c'] on the 2nd request.

I see absolutely no inconsistency here and completely disagree with
breaking BC for so many people on this point.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: session_register warnings

[Sascha Schumann]

Rasmus, if you were arguing for adding a second class of session
variables which are always available through and looked up in
the global symbol table, you actually had a point.  I
completely disagree though with your interpretation of the
outdated, unmaintained session_register() documentation.

> Ok, disregard everything else and let's just focus on this one statement
> since it is the core of the disagreement.  The way session_register() has
> always worked and has been documented is this:
>
>session_register() registers the global variable with that name in the
>current session.

The accompanying commit message for this documentation change
says everything:

"Expanded docs on session_register(). If anyone wants to
rewrite it to bemore clear, feel free."

Especially note that the sentence you quoted _predates_ the
existence of $HTTP_STATE_VARS.  The documentation of
session_register has unfortunately never been modified after
these were added.

Nevertheless, the implementation of the session module has
advanced and changed somewhat.

> Very simple.  It says that the named global variable will become part of
> the session. [snip]

It is saying that, because at the time of writing,
session_register could not take it from somewhere else.  Is
that so hard to accept?

> If register_globals affects this, then you have completely changed the
> meaning behind the register_globals switch.  [snip]

Sorry, your complaint comes a few years too late.

> I see absolutely no inconsistency here and completely disagree with
> breaking BC for so many people on this point.

4.3 maintains BC by default.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: session_register warnings

[Rasmus Lerdorf]

> > Very simple.  It says that the named global variable will become part of
> > the session. [snip]
>
> It is saying that, because at the time of writing,
> session_register could not take it from somewhere else.  Is
> that so hard to accept?

It is hard to accept because the function has always done exactly this and
it has always been documented to do exactly this.  And I still have yet to
hear a good argument for changing this behaviour.

> > I see absolutely no inconsistency here and completely disagree with
> > breaking BC for so many people on this point.
>
> 4.3 maintains BC by default.

No it doesn't, it spews a warning.  Which means BC is about to break.  If
there is no intention to break BC, then remove the warning.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] How to debug?

[Markus Fischer]

On Fri, Oct 11, 2002 at 03:22:21PM +0100, David Reid wrote : 
> Can I run the tests under gdb to try and see if I can get a better
> backtrace? I'm still seeing the segafluts in the session tests...

Does http://bugs.php.net/bugs-generating-backtrace.php help you?

-- 
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
 Derick, while ($xml) $ass->get_new_ideas();
<[James]> Markus: IE on_user_fart()
-- People doesn't seem to like the new XHTML2 specs :) --

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: session_register warnings

[Sascha Schumann]

With PHP 4.3, it finally becomes possible to completely
manage session variables without any dedicated functions.
Just set or unset variables in $_SESSION and you are done
with it.  It could not be any easier.

The streamlining of the serialization process also has
another advantage -- the extension will notify developers
that their script might be indeterministic.

How? you ask.  Imagine a section of code which intents to
change a session variable.  At the first execution, setting
the global works.  But when the section of code is run again,
the exact same code will silently fail.[1]

You have observed correctly that application developers have
noticed that disabling register_globals has an effect on
their session usage.  Those developers have appropiately
changed their applications to read from and write to
$_SESSION.

Now I ask you: Why should the same set of developers be
afraid or incapable of making their scripts more reliable and
not complete this transition?

[1] I hope everyone sees how absurd it is to suggest that
these kind of semantics were actually intended by the
session authors.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: session_register warnings

[Rasmus Lerdorf]

> With PHP 4.3, it finally becomes possible to completely
> manage session variables without any dedicated functions.
> Just set or unset variables in $_SESSION and you are done
> with it.  It could not be any easier.

And that's very nice.  I have no argument with that.

> The streamlining of the serialization process also has
> another advantage -- the extension will notify developers
> that their script might be indeterministic.
>
> How? you ask.  Imagine a section of code which intents to
> change a session variable.  At the first execution, setting
> the global works.  But when the section of code is run again,
> the exact same code will silently fail.[1]

request #1:

  session_register('c');
  $c = 3;

request #2:

  session_register('c');
  $c = 4;

This is the exact same code run twice.  It works exactly the same both
times.  Where is the silent failure?

> You have observed correctly that application developers have
> noticed that disabling register_globals has an effect on
> their session usage.  Those developers have appropiately
> changed their applications to read from and write to
> $_SESSION.

Not necessarily.  Many have changed their applications to read from
$_SESSION but have not changed how they create their session vars
initially.  Nor should they have to in my opinion.

> Now I ask you: Why should the same set of developers be
> afraid or incapable of making their scripts more reliable and
> not complete this transition?

They probably should, but I see no reason to break their existing code
without a really good reason.  You have yet to give a really good reason.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: session_register warnings

[Mike Hall]

Now I'm not really anyone special - just another user, as it were, but I do
use the session module on a daily basis as part of my job. FWIW, I agree
with Sascha on this one. A user should be able to work with a session
variable in global scope all the time, or not at all. Not some mish-mash of
both.

As it stands at the moment (with register_globals off), variables can be
pulled into a session from global scope, but they cannot be pulled out again
from global scope - you have to use the $_SESSION array. I find this counter
intuative... if I can put them into a session that way, why can't I pull
them out again that way?

Mike


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: session_register warnings

[Sascha Schumann]

> This is the exact same code run twice.  It works exactly the same both
> times.  Where is the silent failure?

The second change will not have any effect.  It will be lost.
The session module does not see it.  The module looks at
$_SESSION first, and if it does not find anything, falls back
to the global sym table.

You can try it yourself by firing up PHP 4.2 and running the
script from this test case.

http://lxr.php.net/source/php4/ext/session/tests/008.phpt

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php