Bug #16043 Updated: $_SESSION can't use in PHP 4.1.2

2002-03-21 Thread pettersen 

 ID:   16043
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Session related
 Operating System: Windows XP
 PHP Version:  4.1.2
 New Comment:

FYI:

I've tried 4.2 RC1 and (at least for me) It is not solving this
problem.  Has anyone else gotten sessions to work properly on win2000
platform, apache module, and 4.2RC1 ?

Erik


Previous Comments:


[2002-03-20 04:37:08] [EMAIL PROTECTED]

This bug is closed, because it's fixed in the development branch. You
can't expect us to make patches for every bug for every release.
4.2.0RC1 is coming out today, windows binaries will follow shortly.
With this RC you can if the bug is fixed without having to play with
building PHP yourself.

Derick



[2002-03-20 04:31:20] [EMAIL PROTECTED]

Why isn't this bug re-opened ?!?!?!
CVS HEAD branches?? whuh? The released 4.1.2 has a serious bug, that
isn't solved for de developers in the world. So, it should be open.

As a newbie I spent hours and hours on my scripts trying to figure out
why my session scripts went dead (after all, the chance that it's PHP
bug instead of a script fault is in my case quite small).

Yep: I use Win2000 SP2, Apache 1.3.23, MySQL 3.23.49 and PHP 4.1.2 as
an Apache module (upgrade since this weekend).

Now I read here a CLOSED bug report about exactly my problem. Bug 16102
is stil being analyzed, OK, but to close 16043 seems too hasty to say
the least.

Why isn't this mentioned in an extra 4.1.2 news flash?

When I read 16102 and 16043, all Windows based servers that run
sessions are STILL troubled by this (apache and IIS, PHP CGI and
module).



[2002-03-15 21:02:20] [EMAIL PROTECTED]

Bugs will be closed when it is fixed in CVS HEAD branch :)




[2002-03-15 16:03:17] [EMAIL PROTECTED]

Do the developers read closed bugreports or are we just suggesting 
nul?
I also know that this bugboard isn't a place suggestions
yaddayaddayadda... It is maybe better to post this to one of the
usenetgroups.



[2002-03-15 13:04:07] [EMAIL PROTECTED]

Dumb question:  What is the general policy of the PHP development team
on closing out bug reports?

This problem has been closed, yet the bug has not yet been resolved. 
The latest release of PHP available to the public is still v4.1.2, and
that version still contains this bug.  And do you really expect
everyone to understand CVS and to have the necessary compiler tools,
etc., to build their own executables and modules?  Whereas Linux and
most forms of Unix come with cc/gcc /etc., Windows does not.

By closing the bug report, anyone who downloads v4.1.2 and finds the
same problem, and who then does what the PHP Bug site asks (searching
for open problems that match your own), they will NOT find a match (the
default setting on the search page is to look for 'Open' problems
only).  This leads to new bug reports about the same problem, more
redundancy and repetition on the developers' part in replying, etc.
etc.  Do I understand this correctly?

Would it not make more sense to leave this bug report 'Open' until the
issue has, in fact, been resolved in the latest released version of
PHP?  Just a suggestion.

At this point, the PHP site's recommendation that All PHP - Windows
users are encouraged to upgrade to the latest version is, for anyone
doing session management, counterproductive.  Yes, the security
implications are there, but session management is a key feature for
many PHP-based sites, and v4.1.2 COMPLETELY breaks session support.

This is not a minor bug.  This is a MAJOR bug.  And new users may end
up having an unnecessarily negative view of PHP, which would be
unfortunate for everyone.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/16043

-- 
Edit this bug report at http://bugs.php.net/?id=16043edit=1

Bug #16047: include_path does NOT default to .

2002-03-13 Thread pettersen 

From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.1.2
PHP Bug Type: *Configuration Issues
Bug description:  include_path does NOT default to .

Hi,

Just drove my self crazy upgrading to the latest build for win32 4.1.2, as
an apache module

Granted I'm not very confident as to how this *should* work, I think I
found a minor bug/inconsistency.

If you do not set include_path it defaults to C:\php4\pear (or was it
c:\php4\includes\pear ) I believe based upon reading this, 
include_path string
Specifies a list of directories where the require(), include() and
fopen_with_path() functions look for files. The format is like the
system's PATH environment variable: a list of directories separated with a
colon in UNIX or semicolon in Windows. Example 3-3. UNIX include_path

include_path=.:/home/httpd/php-lib
 
 
Example 3-4. Windows include_path

include_path=.;c:\www\phplib
 
 
bThe default value for this directive is . (only the current
directory)/b.


So... I'm guessing it should default to . instead of C:\php4\pear (or
whatever) ... 

All of the includes on my site went bunk right after I upgraded... setting
include_path = . rectified this for me.

If this is obvious, and the intended effect, I apoligize in advance for my
erroroneous bug report.  

Erik
-- 
Edit bug report at http://bugs.php.net/?id=16047edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16047r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16047r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16047r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16047r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16047r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16047r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16047r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16047r=submittedtwice

Bug #16047 Updated: include_path does NOT default to .

2002-03-13 Thread pettersen 

 ID:   16047
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *Configuration Issues
 Operating System: Windows 2000
 PHP Version:  4.1.2
 New Comment:

I think someone else got the core of this issue and described it in
more technical terms in Bug #15865

Sorry about the duplication, I did search before submitting, however I
didn't find Bug #15865 until I browsed all the bugs for version 4.1.2

Thanks (so I guess you could close this, if the other one will get
fixed)   !

Erik


Previous Comments:


[2002-03-13 16:28:05] [EMAIL PROTECTED]

Hi,

Just drove my self crazy upgrading to the latest build for win32 4.1.2,
as an apache module

Granted I'm not very confident as to how this *should* work, I think I
found a minor bug/inconsistency.

If you do not set include_path it defaults to C:\php4\pear (or was it
c:\php4\includes\pear ) I believe based upon reading this, 
include_path string
Specifies a list of directories where the require(), include() and
fopen_with_path() functions look for files. The format is like the
system's PATH environment variable: a list of directories separated
with a colon in UNIX or semicolon in Windows. Example 3-3. UNIX
include_path

include_path=.:/home/httpd/php-lib
 
 
Example 3-4. Windows include_path

include_path=.;c:\www\phplib
 
 
bThe default value for this directive is . (only the current
directory)/b.


So... I'm guessing it should default to . instead of C:\php4\pear (or
whatever) ... 

All of the includes on my site went bunk right after I upgraded...
setting include_path = . rectified this for me.

If this is obvious, and the intended effect, I apoligize in advance for
my erroroneous bug report.  

Erik




-- 
Edit this bug report at http://bugs.php.net/?id=16047edit=1