[PHP-DOC] #31067 [Opn->Bgs]: know about php
ID: 31067 Updated by: [EMAIL PROTECTED] Reported By: klceproject at yahoo dot co dot in -Status: Open +Status: Bogus -Bug Type: *General Issues +Bug Type: Documentation problem Operating System: RED HAT LINUX PHP Version: 4.3.9 New Comment: This is wrong place for this.. Previous Comments: [2004-12-13 05:10:05] klceproject at yahoo dot co dot in Description: what are the applications of PHP? why is it so useful than java? -- Edit this bug report at http://bugs.php.net/?id=31067&edit=1
[PHP-DOC] #31542 [Opn]: eval() terminates PHP on fatal error instead of returning false
ID: 31542
Updated by: [EMAIL PROTECTED]
Reported By: jcmailtrap-php at yahoo dot ca
Status: Open
-Bug Type: Unknown/Other Function
+Bug Type: Documentation problem
Operating System: RHEL3
PHP Version: 5.0.3
New Comment:
So the one who wrote the manual page made a mistake since
eval() isn't some magic thing that can override fatal errors..
Previous Comments:
[2005-01-14 05:31:46] jcmailtrap-php at yahoo dot ca
Well, in eval()'s manual page, it is stated:
In case of a fatal error in the evaluated code, eval() returns FALSE.
Obviously eval() did not return FALSE in this case because the script
exited.
[2005-01-14 05:26:58] [EMAIL PROTECTED]
Fatal errors are...tadaa..FATAL! As such -> exit.
No bug here.
[2005-01-14 05:19:51] [EMAIL PROTECTED]
Don't all E_ERRORs do this?
[2005-01-13 18:14:34] jcmailtrap-php at yahoo dot ca
Description:
When a fatal error is caused by attempting to call a method on an
non-object or non-existing variable, eval() throws a fatal error which
terminates the script instead of returning false as stated in the doc.
Reproduce code:
---
$result = eval('$nosuchobject->method();');
echo "done eval\n";
if ($result===false) {
echo "error correctly returned\n";
}
Expected result:
Notice: Undefined variable: nosuchobject
Fatal error: Call to a member function method() on a non-object
done eval
error correctly returned
Actual result:
--
Notice: Undefined variable: nosuchobject
Fatal error: Call to a member function method() on a non-object
--
Edit this bug report at http://bugs.php.net/?id=31542&edit=1
[PHP-DOC] #31591 [Opn->Ver]: apache_getenv() is an 'undefined function'
ID: 31591
Updated by: [EMAIL PROTECTED]
Reported By: aronnax_98 at yahoo dot com
-Status: Open
+Status: Verified
-Bug Type: Apache related
+Bug Type: Documentation problem
Operating System: Mac OS X 10.3.7
PHP Version: 4.3.9
New Comment:
Yes, it is available, but only with Apache2.
Documentation should have a note about it.
Previous Comments:
[2005-01-18 04:01:58] aronnax_98 at yahoo dot com
Description:
When I try to call apache_getenv(...), PHP claims that
the function doesn't exist. The function is present in
the online PHP manual.
Reproduce code:
---
echo apache_getenv('SOME_ENV_VARIABLE');
Expected result:
VALUE_OF_SOME_ENV_VARIABLE
Actual result:
--
Fatal error: Call to undefined function: apache_getenv()
in /www/php/dryerase/config.php on line 21
--
Edit this bug report at http://bugs.php.net/?id=31591&edit=1
[PHP-DOC] #31418 [Fbk->NoF]: MySQL connection functions do Not Work With Double Quotes on Argument
ID: 31418
Updated by: [EMAIL PROTECTED]
Reported By: sam dot boles at acfb dot org
-Status: Feedback
+Status: No Feedback
Bug Type: Documentation problem
Operating System: Windows 2000
PHP Version: 5.0.3
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2005-01-07 09:13:21] [EMAIL PROTECTED]
> I saw several web posts mentioning trouble with this very
> issue.
Can you please give us links to these posts? There can be some clue to
understand this problem.
[2005-01-06 19:23:45] sam dot boles at acfb dot org
The code listed is simple because I was taking this one step at a time.
I wanted to be sure I could attach to the DB before writing more
complex code to actually do anything. I did not want to put in the
work at a full application until I knew that the motor would turn over,
so to speak.
Here is the course of the issue, as it evolved:
I installed MySQl several months ago (upgraded to 4.1.7 when that was
released) and have been using it via ASP using ODBC and also through
the native MySQL clients successfully. However, for portability
reasons, want to migrate to the PHP scripting language and use the
built in mySQL (or mySQLi) functions rather than ODBC. So I installed
Apache 2.0 and PHP 5.0.3 to gain this advantage.
However, what I found was that every attempt to do even the simplest
things with mySQL via PHP were stymied by the fact that the function
would not connect to the server--threw the 1045 error.
I tried several solutions--including updating the mysqllib.dll and
modifying php.ini, my.ini and Apache configurations. I tried setting
the MySQL server to use only Old Passwords. None of this had any
affect on the ability of the script to even connect with the server.
Essentially, I tried every solution mentioned in various forums and
help documents found on the PHP, MySQL and other sites.
I finally found one example online that used single quotes rather than
double quotes on the function arguments. When I tried using this
syntax, PHP connected and continues to function correctly. All queries
issued using this connection format work perfectly. Double quotes throw
the error.
I'm sure that it must be something odd about my setup here, but since I
saw several web posts mentioning trouble with this very issue, wanted to
put it out as a tip for something others could try if they are having
similar issues.
And I do use variables and escape sequences in strings. What I meant
(sorry I wasn't clear) is that there is nothing in the strings that
comprise the actual username "root" or password "hoo25boy" (not the
real password) that were formatted like escape sequences or variables
and that could have been misinterpreted somehow by the PHP or MySQL
engines.
I agree this is very very odd. A simple change like going from
$mysqli = new mysqli("host_name","user_name",
"password", "database");
to
$mysqli = new mysqli('host_name','user_name',
'password', 'database');
shouldn't have affected this--but in test after test here it does.
Thanks.
[2005-01-06 09:36:39] [EMAIL PROTECTED]
I can't believe that this is caused by any difference between ' and ".
Is your code really so simple? Don't you use any variables or escape
sequences inside strings?
Are you using new passwords or old in MySQL? You can check this by
"SELECT Password FROM mysql.user WHERE Host = 'localhost' AND User =
'root'". If the password begin with * it's new otherwise it's old.
MySQL extension doesn't work with new passwords (but with different
error message), MySQLi does.
[2005-01-05 21:07:07] sam dot boles at acfb dot org
Host is localhost
username is root
password does not contain '\' or '"'--strictly alphanumeric
don't know if this makes any difference, but in the versions that don't
work, when the error message prints, it puts both the username and
hostname in single quotes
such as:
Error 1045:Access denied for user 'root'@'localhost' (using
password:YES)
[2005-01-05 20:59:35] [EMAIL PROTECTED]
This is very very strange.
What username/password are you using?? (or if you don't want to give
the password, just say if you are using '\' or '"' chars in it.
Nuno
The remainder of the comments for this report are too long. To view
the rest of
[PHP-DOC] #31798 [Opn]: set_error_handler() object argument passed by value,not reference
ID: 31798
Updated by: [EMAIL PROTECTED]
Reported By: vl409 at yandex dot ru
Status: Open
-Bug Type: *General Issues
+Bug Type: Documentation problem
Operating System: linux-2.4.25,freebsd 4.10
PHP Version: 4.3.10
New Comment:
reclassified
Previous Comments:
[2005-02-01 21:55:05] vl409 at yandex dot ru
Description:
Possibly,it`s a duplicate bug of
Bug #25128 set_error_handler not sending reference
http://bugs.php.net/bug.php?id=25128&edit=2
I tried to write my own class for handling errors in php and
found that if i call set_error_handler with argument, being
object(&$this), it is passed by value, not by reference.
This is strange, because function set_error_handler is
declared same as call_user_func, but behaves differently.
as defined in manual:
mixed call_user_func ( callback function...)
mixed set_error_handler ( callback error_handler...)
I tested example on FreeBSD 4.1/PHP 4.3.10 and Linux 2.4.25/PHP 4.3.5
Code,demonstrating this, provided below.
P.S. If it`s a duplication, then you can mean this report as BUG IN
DOCUMENTATION! I found that i wanted to do almost the same as man in
Bug #25128, but due to lack of documentation, spent a lot of time for
nothing...
Reproduce code:
---
error_count=0;
set_error_handler(array(&$this,'handler'));
echo "New error handler registered!";
}
function handler()
{
echo "Cought an error! increasing counter!";
$this->error_count++;}
function show(){
echo "This object handled ".$this->error_count." errors";
}
}
$x=new error_handler;
$x->show();
trigger_error("Ooops!",E_USER_ERROR);
$x->show();
trigger_error("Ooops!",E_USER_ERROR);
$x->show();
echo "called by call_user_func:";
call_user_func(array(&$x, "handler"));
$x->show();
echo "called manually";
$x->handler();
$x->show();
?>
Expected result:
New error handler registered!
This object handled 0 errors
Cought an error! increasing counter!
This object handled 1 errors
Cought an error! increasing counter!
This object handled 2 errors
called by call_user_func:
Cought an error! increasing counter!
This object handled 3 errors
called manually
Cought an error! increasing counter!
This object handled 4 errors
Actual result:
--
New error handler registered!
This object handled 0 errors
Cought an error! increasing counter!
This object handled 0 errors
Cought an error! increasing counter!
This object handled 0 errors
called by call_user_func:
Cought an error! increasing counter!
This object handled 1 errors
called manually
Cought an error! increasing counter!
This object handled 2 errors
--
Edit this bug report at http://bugs.php.net/?id=31798&edit=1
[PHP-DOC] #28371 [Opn]: Different behaviour of fopen depending on r+,w+,a+
ID: 28371 Updated by: [EMAIL PROTECTED] Reported By: rc at opelgt dot org Status: Open -Bug Type: Filesystem function related +Bug Type: Documentation problem Operating System: MacOSX 10.3 PHP Version: 4.3.4 New Comment: reclassified Previous Comments: [2004-05-13 15:19:46] rc at opelgt dot org Yes, my sent script runs identically for all modes under Linux and MacOSX. Its different among the modes. The mode options in fopen() for my understanding should have only effect for the start: position of pointer, content of file, file creation if nessessary or not. Sure, read or write or both ways of access should remain until fclose(). ;-) 'r' and 'w' need clearstatcache() but 'a' doesnt. That is the unexpected and in the manual not mentioned difference. [2004-05-13 14:28:21] rc at opelgt dot org I think it could be mention in the manual: In PHP 4.2.3 the read pointer for fopen with 'a' is at the end of file. Instead in 4.3.4 the pointer is at '0'! So rewind for reading in 4.3.4 with 'a+' is no longer nessessary. Rüdiger [2004-05-12 19:12:34] rc at opelgt dot org Do you really think when such strange differences occur and the fopen description says nothing about it, its a question for support? Do you know why this differences occurs? Output with w+ is: Inhalt alt: neu: and with r+: Inhalt alt: 1234567890 neu: Rüdiger [2004-05-12 18:52:46] [EMAIL PROTECTED] The output under both linux and OSX is: Inhalt alt: 1234567890 neu: 13579 Your bug report doesn't sound so much like a bug report, but a support request; this isn't a support forum, so if you don't understand these results even after careful scrutiny of the fopen() manual page, please visit http://www.php.net/support.php to find someone who might be able to help you. [2004-05-12 17:20:59] rc at opelgt dot org Description: Hello, for my skill its a bit too much to understand whats going on here. Reproduce code: --- \nalt: ".fread($dh, filesize($datei))."\n"; ftruncate($dh, '0'); fwrite($dh, $neu); rewind($dh); echo 'neu: '.fread($dh, filesize($datei)); fclose($dh); ?> Expected result: I wrote the code above and exspected same behaviour for r+, w+ and a+. Before pos1 The content of 'test.txt' is written to '1234567890'. After pos1 the file is opened anothertime with r+,w+ or a+. Rewind sets the pointer to '0'. So that fread can read the file from the beginning. Ftruncate makes the size of the file to '0' and sets the pointer to the beginning of the file. Fwrite writes the new content and the size of the file will be as big as nessessary for the content. Rewind takes the pointer back from end to beginning of the file. Actual result: -- Echo should tell the new content. This only works with a+, but with r+ and w+ nothing is displayed. The first echo command tells the 'old' content in a+ and r+ mode, but not with w+. Seems to me there are undocumented differences between the modes that makes it difficult to choose and use one of them. Rüdiger -- Edit this bug report at http://bugs.php.net/?id=28371&edit=1
[PHP-DOC] #28141 [Opn]: socket_read return type: false vs "", when PHP_NORMAL_READ
ID: 28141
Updated by: [EMAIL PROTECTED]
Reported By: php at richardneill dot org
Status: Open
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4CVS, 5CVS (2005-02-14)
Assigned To: andrey
New Comment:
Forgot this part from that: recv() function is what socket_read() uses
internally.
Previous Comments:
[2005-02-14 22:20:51] [EMAIL PROTECTED]
>From recv() manpage:
"Upon successful completion, recv() shall return the length of the
message in bytes. If no messages are available to be received and the
peer has performed an orderly shutdown, recv() shall return 0.
Otherwise, -1 shall be returned and errno set to indicate the error."
[2005-02-14 17:30:00] php at richardneill dot org
Thanks. That makes sense. However, it still leaves a few problems,
essentially with wrong documentation.
---
1)The documentation for socket_read
http://uk.php.net/manual/en/function.socket-read.php
claims:
"Note: socket_read() may return a zero length string ("") indicating
the end of communication (i.e. the remote end point has closed the
connection)."
which is obviously not true.
-
2)Example 1 on the sockets page
http://uk.php.net/manual/en/ref.sockets.php
also supports the interpretation that
False => error; null => connection closed
if (false === ($buf = socket_read($msgsock, 2048,
PHP_NORMAL_READ))) {
echo "socket_read() failed: reason: " .
socket_strerror($ret) . "\n";
break 2;
}
if (!$buf = trim($buf)) {
continue;
}
--
3)How is one to determine the difference between
i)the other side closing the connection normally
and
ii)something going very wrong with the function?
According to the documentation,
"" => (i)
false => (ii)
In fact, it seems that
false => (i) or (ii), with no way to tell
"" => never actually happens
Thanks for your help,
Richard
[2005-02-14 09:10:12] [EMAIL PROTECTED]
There is no bug to fix here. You're actually getting "Connection reset
by peer" (ECONNRESET) and that makes recv() to return -1 -> PHP
socket_read() returns an error and FALSE.
Here's simplified WORKING script:
#!/usr/local/bin/php
[2004-04-25 06:56:24] php at richardneill dot org
Description:
According to the documentation, socket_read() can return:
1)A string - normal data
2)An empty string "" - the other end closed the connection
3)false - something went wrong.
But it seems to be returning false on connection close.
Reproduce code:
---
$buffer=socket_read($socket,2048,PHP_NORMAL_READ);
if ($buffer===false){
echo "Error: socket_read() failed: reason:
".socket_strerror(socket_last_error())." \n";
exit (1);
}elseif ($buffer==''){
echo "Socket $socket returned an empty string. Closing
connection\n";
socket_close($socket);
}else{
echo "Received data".trim($buffer)."\n";
}
Expected result:
I'm using netcat as a client, and then killing the netcat process with
Ctrl-C to simulate remote host disconnecting.
I expect to see the socket close.
Actual result:
--
Actually, the php script exits, because socket_read returns
false instead of "".
This may be a bug in the documentation for socket_read, rather than in
its behaviour.
Thanks for your help - Richard
--
Edit this bug report at http://bugs.php.net/?id=28141&edit=1
[PHP-DOC] #28141 [Bgs->Opn]: socket_read return type: false vs "", when PHP_NORMAL_READ
ID: 28141
Updated by: [EMAIL PROTECTED]
Reported By: php at richardneill dot org
-Status: Bogus
+Status: Open
-Bug Type: Sockets related
+Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4CVS, 5CVS (2005-02-14)
Assigned To: andrey
New Comment:
>From recv() manpage:
"Upon successful completion, recv() shall return the length of the
message in bytes. If no messages are available to be received and the
peer has performed an orderly shutdown, recv() shall return 0.
Otherwise, -1 shall be returned and errno set to indicate the error."
Previous Comments:
[2005-02-14 17:30:00] php at richardneill dot org
Thanks. That makes sense. However, it still leaves a few problems,
essentially with wrong documentation.
---
1)The documentation for socket_read
http://uk.php.net/manual/en/function.socket-read.php
claims:
"Note: socket_read() may return a zero length string ("") indicating
the end of communication (i.e. the remote end point has closed the
connection)."
which is obviously not true.
-
2)Example 1 on the sockets page
http://uk.php.net/manual/en/ref.sockets.php
also supports the interpretation that
False => error; null => connection closed
if (false === ($buf = socket_read($msgsock, 2048,
PHP_NORMAL_READ))) {
echo "socket_read() failed: reason: " .
socket_strerror($ret) . "\n";
break 2;
}
if (!$buf = trim($buf)) {
continue;
}
--
3)How is one to determine the difference between
i)the other side closing the connection normally
and
ii)something going very wrong with the function?
According to the documentation,
"" => (i)
false => (ii)
In fact, it seems that
false => (i) or (ii), with no way to tell
"" => never actually happens
Thanks for your help,
Richard
[2005-02-14 09:10:12] [EMAIL PROTECTED]
There is no bug to fix here. You're actually getting "Connection reset
by peer" (ECONNRESET) and that makes recv() to return -1 -> PHP
socket_read() returns an error and FALSE.
Here's simplified WORKING script:
#!/usr/local/bin/php
[2004-07-28 21:04:13] [EMAIL PROTECTED]
Assigning to myself (to get notification if i forget), changing the
version.
[2004-07-26 10:37:34] php at hristov dot com
I will take a look later today or these days. But for now, the code in
the function is :
if (type == PHP_NORMAL_READ) {
retval = php_read(php_sock->bsd_socket, tmpbuf, length, 0);
} else {
retval = recv(php_sock->bsd_socket, tmpbuf, length, 0);
}
if (retval == -1) {
PHP_SOCKET_ERROR(php_sock, "unable to read from socket", errno);
efree(tmpbuf);
RETURN_FALSE;
}
[2004-07-18 17:13:56] php2 at richardneill dot org
I've still got the same thing happening in PHP5.0.0(final)
I'm having some trouble with your example, so I'm using the attached
instead. It's basically copied from the php-sockets manual, but
slightly modified.
The key point: according to the documentation, when
(socket_read()===false), it means something has gone very wrong, i.e.
a fatal error. However, in practice, all this means is that the other
side has closed the connection.
I'm running this code as ./testsock.php
and the client is simply: netcat localhost
The problem is that, if netcat is killed with Ctrl-C, then the server
suffers a fatal error. I don't think that it should.
I've tried it under both version php-cli-4.3.7-4mdk (the current devel
version from Mandrake cooker) and php-5.0.0-cli which I just compiled.
In both cases, the same thing happens.
Regards
Richard
-
#!/usr/local/bin/php
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/28141
--
Edit this bug report at http://bugs.php.net/?id=28141&edit=1
[PHP-DOC] #32201 [Opn->Ver]: gettext: Unexpected output from textdomain()
ID: 32201 Updated by: [EMAIL PROTECTED] -Summary: Unexpected output from textdomain() Reported By: php at fimbul dot net -Status: Open +Status: Verified -Bug Type: Gettext related +Bug Type: Documentation problem Operating System: Linux (Debian unstable) PHP Version: 4.3.10 New Comment: >From the GNU gettext manpage: "If successful, the textdomain function returns the current message domain, after possibly changing it." As the PHP function is merely a wrapper to this gettext function, this is a documentation problem. Reclassified as such. Previous Comments: [2005-03-06 02:58:50] php at fimbul dot net Description: >From the documentation: string textdomain ( string text_domain ) This function sets the domain to search within when calls are made to gettext(), usually the named after an application. The previous default domain is returned. Call it with NULL as parameter to get the current setting without changing it. What actually happens: This function sets the domain to search within when calls are made to gettext(), usually the named after an application. The current default domain is returned, i.e. the domain just set. Call it with NULL as parameter to get the current setting without changing it. Reproduce code: --- Expected result: AABBCCA Actual result: -- ABBCCBB -- Edit this bug report at http://bugs.php.net/?id=32201&edit=1
[PHP-DOC] #32218 [Opn]: HTTP status 200 returned on HTTP CONNECT
ID: 32218
Updated by: [EMAIL PROTECTED]
Reported By: mcihar at suse dot cz
Status: Open
-Bug Type:Apache2 related
+Bug Type:Documentation problem
PHP Version: 5.0.3
New Comment:
Let's document it.
Previous Comments:
[2005-03-07 13:53:42] mcihar at suse dot cz
Description:
This is basically same as bug #19113, but I didn't find way to add
comment there and I do no thing it is bogus.
Problem is that mod_php (and mod_perl as well) don't care about request
type at all, and handle all same way. If this is really intended
behaviour, it should be documented.
I feel it is a bug, solution migth be to add method check to
php_handler. It might look like:
if (r->method_number != M_GET && r->method_number != M_POST) {
return DECLINED;
}
--
Edit this bug report at http://bugs.php.net/?id=32218&edit=1
[PHP-DOC] #29977 [Opn]: bool cast of "0000000000000"
ID: 29977 Updated by: [EMAIL PROTECTED] Reported By: hd dot php at aimail dot de Status: Open -Bug Type: Variables related +Bug Type: Documentation problem Operating System: linux PHP Version: 4.3.10 / 5+ New Comment: Document it. Previous Comments: [2004-09-05 10:04:55] [EMAIL PROTECTED] "00" is a string, like any other string. The only other string that will evaluate to false is "0". This may, however, be something we should fix, and at the very least document - what do others think? TRUE: $ php -r 'var_dump((bool)"00");' FALSE: $ php -r 'var_dump((bool)"0");' [2004-09-04 01:22:36] hd dot php at aimail dot de Description: * PHP Version 4.3.4 * bool cast of "0" should be false, not true. A "0" is returned from mysql timestamp fields. (bool)"0" should be consistent with (bool)(int)"0" At this point it is not. Reproduce code: --- Expected result: false Actual result: -- true -- Edit this bug report at http://bugs.php.net/?id=29977&edit=1
[PHP-DOC] #32337 [Opn]: Per Directory Values registry not working
ID: 32337 Updated by: [EMAIL PROTECTED] Reported By: jsonger at maintree dot com Status: Open -Bug Type: PHP options/info functions +Bug Type: Documentation problem Operating System: Windows 2000 PHP Version: 5.0.3 New Comment: This registry thing does NOT work for any option. It's just before script execution so it techinally can't work with e.g. register_globals. Previous Comments: [2005-03-17 10:38:53] baricak at post dot cz And Last But not Least: When I try to echo ini_get(); ,the value is correct as set in the registry, but the system does not work like it says- phpinfo() returns the old php.ini value and the system reacts as only the old php.ini was set. [2005-03-17 10:30:23] baricak at post dot cz Hello, I have the same problems. I just installed php5.0-win32-200503170130.zip on IIS5 with Windows 2000 as ISAPI module and Per Directory Values does not work with some of the settings. For instance, display_errors directive works fine, but register_globals DOES NOT. The another problem is, phpinfo() output is not correct. When I set display_errors in the registry to a different value as in php.ini, in the output of phpinfo() the value of "local" column stays untouched, even though the system reactions are like the new value was set. The Version 5.0.3 has the same problems. [2005-03-16 14:30:14] jsonger at maintree dot com Description: In both 5.0.3 and 5.0.4RC1 built on Mar 16 2005 10:19:30, the ISAPI module is not using the Per Directory Values registry settings. I have not tried this with the CGI version. -- Edit this bug report at http://bugs.php.net/?id=32337&edit=1
[PHP-DOC] #32387 [Opn]: Problem with upload_tmp_dir when set as "Per Directory Value"
ID: 32387 Updated by: [EMAIL PROTECTED] Reported By: ricike at aporisk dot hu Status: Open -Bug Type: *Configuration Issues +Bug Type: Documentation problem Operating System: Windows Server 2003 / IIS 6.0 PHP Version: 4.3.10 New Comment: Ah yes, this is the inherent problem of using the registry. The values from it are used AFTER upload has already happened (and just before script is executed) Moving to documentation problem, there was also other one.. Previous Comments: [2005-03-21 01:40:26] ricike at aporisk dot hu I tried the snapshot. The situation is the same, phpinfo() shows the correct configuration, but $_FILES["file"]["tmp_name"] always points to the path defined in php.ini, regardless of the Per Directory Values. [2005-03-20 22:59:20] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-03-20 22:32:37] ricike at aporisk dot hu Description: I have changed in php.ini the upload_tmp_dir to a directory which i want to use for most of the websites. And i used the "Per Directory Values" thing in the registry for a specific website's wwwroot to use an other temp dir for file uploads. When phpinfo() is called, it says the correct local and master values, but when i upload a file, it is uploaded into the the temp directory specified in php.ini, not to the directory specified for that website. -- Edit this bug report at http://bugs.php.net/?id=32387&edit=1
[PHP-DOC] #32414 [Opn]: session_start(): Cannot send session cache limiter
ID: 32414
Updated by: [EMAIL PROTECTED]
Reported By: d dot geels at grape dot ru
Status: Open
-Bug Type: Session related
+Bug Type: Documentation problem
Operating System: any
PHP Version: 4.3.10, also 5
New Comment:
This is actually just documentation problem:
You can't send any headers from a register_shutdown_function() call.
Or use any functions in such function that might send headers..such as
almost any session function.
Previous Comments:
[2005-03-22 18:46:42] d dot geels at grape dot ru
Tiny example, that always reproduces the bug.
text
If just call a() at the end -- no warnings, if a() called at shutdown
-- warning issued.
[2005-03-22 18:43:53] d dot geels at grape dot ru
No, we don't use this at all, this option is always set to 0.
Just checked, ini option is set to 0, .htaccess doesn't change this
option.
[2005-03-22 18:34:23] [EMAIL PROTECTED]
Do you have 'session.auto_start' set on somewhere?
(httpd.conf, .htaccess file, php.ini..)
[2005-03-22 18:25:12] d dot geels at grape dot ru
There is one more detail, I forgot to mention:
I couldn't kill warning message by calling @start_session() in line 45.
Is this because of warning message issued somewhere in calls from
session_start()?
[2005-03-22 18:16:04] d dot geels at grape dot ru
Just viewd latest session.c from CVS repository. There are not much
changes between versions 4 and 5, so bug still remains in PHP 5.
Somewhere here:
static int php_session_cache_limiter(TSRMLS_D)
{
php_session_cache_limiter_t *lim;
// for some reason, this string fails
if (PS(cache_limiter)[0] == '\0') return 0;
// I cant understand all this file, but I think, problem is
// that value 'none' is not properly recognized or processed
if (SG(headers_sent)) {
char *output_start_filename =
php_get_output_start_filename(TSRMLS_C);
int output_start_lineno = php_get_output_start_lineno(TSRMLS_C);
if (output_start_filename) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Cannot
send session
cache limiter - headers already sent (output started at %s:%d)",
output_start_filename, output_start_lineno);
} else {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Cannot
send session
cache limiter - headers already sent");
}
return -2;
}
for (lim = php_session_cache_limiters; lim->name; lim++) {
if (!strcasecmp(lim->name, PS(cache_limiter))) {
lim->func(TSRMLS_C);
return 0;
}
}
return -1;
}
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/32414
--
Edit this bug report at http://bugs.php.net/?id=32414&edit=1
[PHP-DOC] #32535 [Opn]: Are stream names URLs?
ID: 32535 Updated by: [EMAIL PROTECTED] Reported By: a at b dot c dot de Status: Open -Bug Type: Unknown/Other Function +Bug Type: Documentation problem Operating System: * PHP Version: 5.0.3 New Comment: reclassified Previous Comments: [2005-04-01 17:01:59] a at b dot c dot de Description: As indicated several times in the manual, the "filenames" that result from using stream wrappers are to be regarded as URLs, just as http, ftp and file schemes already are. However, ALL such wrappers separate the scheme (what the manual refers to as the "protocol" from the rest of the URL with "://" - an example being the "var://myvar" in the example of the stream_wrapper_register() page. This conflicts with RFC3986, the official specification for URIs (of which URLs are a subclass). The separator is just ":"; the double slash should only appear if what follows is a hierarchical structure in the sense given in section 3 of that document. This is explicitly stated as improper in RFC2718, section 2.1.2 (which refers to the previous URI standard, RFC2396). If these streams are supposed to be URLs, then the above example from the manual should read "var:myvar". -- Edit this bug report at http://bugs.php.net/?id=32535&edit=1
[PHP-DOC] #32554 [Opn]: member variable initialization with heredoc
ID: 32554 Updated by: [EMAIL PROTECTED] Reported By: 05 at gmail dot com Status: Open -Bug Type: Scripting Engine problem +Bug Type: Documentation problem Operating System: Linux 2.6/Gentoo PHP Version: 4CVS,5CVS (2005-04-03) New Comment: This is not really PHP bug but just missing documentation. (or I just couldn't find the place where it's documented :) You can only put static scalars as the default value. Previous Comments: [2005-04-03 07:12:40] 05 at gmail dot com Description: Trying to initialize a member variable using heredoc notation produces a compiler error: Parse error: parse error, unexpected T_START_HEREDOC in /.../foo.php on line 6 Reproduce code: --- Expected result: The member variable $bar to be assigned "blah blah blah". Actual result: -- Parse error: parse error, unexpected T_START_HEREDOC in /.../foo.php on line 6 -- Edit this bug report at http://bugs.php.net/?id=32554&edit=1
[PHP-DOC] #32671 [Opn]: Array keys converted from float to integer
ID: 32671 Updated by: [EMAIL PROTECTED] Reported By: marek at lewczuk dot com Status: Open -Bug Type: Arrays related +Bug Type: Documentation problem Operating System: Linux PHP Version: 5.0.3 New Comment: This is nothing new for PHP 5, same happens with PHP 4. Previous Comments: [2005-04-11 16:24:44] marek at lewczuk dot com One more example, what problem this "bug/behavior" may cause: $value1 = 345.654; $value2 = 345.655; $array = array(); $array[$value1] = $value1; $array[$value2] = $value2; Result: array ( 345 => 345.655, ) If this is a normal behavior you should put a note about this in the manual. [2005-04-11 16:19:04] marek at lewczuk dot com Description: Suppose we have a float value: $value = 345.332 and we want to use this value as an array key: $array[$value] = $value. This will cause that key will be truncated to integer 345 not to string "345.332". It is written in the manual that: "...A key may be either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. "8" will be interpreted as 8, while "08" will be interpreted as "08")..." >From this point of view floats should be converted to strings. I'm not saying that this is a bug, rather I would like to be sure if this is a proper behavior. Simple solution is to type cast float value to string (string), but we have to know that given value is a float (and sometimes, we don't know that). IMHO any other type than integer should be treat as string. Reproduce code: --- $value = 345.654; $array = array(); $array[$value] = "Float"; Expected result: array ( "345.654" => "Float" ) Actual result: -- array ( "345" => "Float" ) -- Edit this bug report at http://bugs.php.net/?id=32671&edit=1
[PHP-DOC] #32665 [Opn]: Premature flushing of output buffer when register_shutdown function called
ID: 32665
Updated by: [EMAIL PROTECTED]
Reported By: prathap at ee dot pdn dot ac dot lk
Status: Open
-Bug Type: Output Control
+Bug Type: Documentation problem
Operating System: Gentoo Linux
PHP Version: 5.0.3
New Comment:
It should be said in manual that you can't use ob_* functions in the
shutdown funcs since the ob-stuff is already ended before we run
these.
Previous Comments:
[2005-04-11 08:24:05] prathap at ee dot pdn dot ac dot lk
Description:
Hello,
I've posted a miniature version of my code here to explain my doubt.
This simply does not work the way it should. i.e ob_get_contents doen't
return
any string and the buffer just gets flushed by itself at termination.
Though the PHP manual says it is not possible to retrieve the contents
of any
output buffers using ob_get_contents() with PHP < 4.0.6. But I am using
PHP 5.
x.x
I posted this problem in the mailing list and I got this response from
skrol29:
I've tested your code on PHP 4.3.3 and I have the same behavior has
yours.
"Hello" is output at the end of the PhpInfo data, followed by a PHP
notice :
Notice: ob_end_clean(): failed to delete buffer. No buffer to delete.
in
...
And there is an empty "logfile" file created in the Apache directory
insteaf
of the script's directory.
If you change in your script:
***
register_shutdown_function("hello");
echo ("HELLO ");
die();
***
by
***
// register_shutdown_function("hello");
echo ("HELLO ");
hello()
die();
***
then it runs as expected and the "logfile" file is created in the
script's
directory.
It seems that when calling the shutdown function, all the buffered
output is
immedialty sent to the client and the buffer mode is closed.
You maybe have PHP bug here, or the manual is wrong about the
possibility to
retrieve the contents.
But we can notice that this also happens at the end of a script when
there
is no shutdown function.
I am still not sure if this is a bug. But I would be very grateful if
someone generously volunteers to see to this.
Thank you and congrats on for the good work you have been carrying on
all throughout.
Prathap
--
Edit this bug report at http://bugs.php.net/?id=32665&edit=1
[PHP-DOC] #32648 [Opn]: register_shutdown_function output corrupted if zlib.output_compression is On
ID: 32648
Updated by: [EMAIL PROTECTED]
Reported By: interghost at crovortex dot com
Status: Open
-Bug Type: Output Control
+Bug Type: Documentation problem
Operating System: Windows XP/Linux
PHP Version: 5.0.4
New Comment:
Manual is wrong here.
Previous Comments:
[2005-04-09 21:17:08] interghost at crovortex dot com
Description:
When using an echo/print inside a function called by
register_shutdown_function, AND while zlib.output_compression is set to
On, the last part of the output (whatever was echoed/printed in the
shutdown function) isn't compressed.
PS:
I've found that this bug was already reported before but was classified
as "Bogus" with the explanation:
"The registered shutdown functions are called after the request has
been completed (including sending any output buffers), so it is not
possible to send output to the browser using echo() or print(), or
retrieve the contents of any output buffers using ob_get_contents()."
However it clearly states in the manual that:
"...Since PHP 4.1, the shutdown functions are called as the part of the
request so that it's possible to send the output from them..."
Reproduce code:
---
function blah()
{
echo "Shut down";
}
register_shutdown_function('blah');
echo "testing bug";
Expected result:
testing bugShut down
Actual result:
--
With zlib.output_compression set to On in php.ini
In Mozilla based browsers:
testing bug
In IE:
an empty document
The difference above is because of different error handling in the
browsers (I think) where Mozilla simply truncates the corrupted part
while IE displays nothing
Note: Set zlib.output_compression to Off and both browsers will
display:
testing bugShut down
--
Edit this bug report at http://bugs.php.net/?id=32648&edit=1
[PHP-DOC] #32695 [Opn]: CURLPROXY_SOCKS5 Notices
ID: 32695 Updated by: [EMAIL PROTECTED] Reported By: just-anonimus-no-spam at no-such-host dot com Status: Open -Bug Type: cURL related +Bug Type: Documentation problem Operating System: Linux fc3 2.6.11.6 #1 Tue Apr PHP Version: 4.3.11 New Comment: Reclassified as documentation problem, the list of the constants should more clearly say in what PHP version's the options are available. (at least on curl_setopt() page) Just update to PHP 5.0.4 and this'll work. Previous Comments: [2005-04-13 16:00:41] just-anonimus-no-spam at no-such-host dot com Description: I can't solve some problem while trying to get a site content via socks5 proxy (CURL Information: libcurl/7.13.1 OpenSSL/0.9.7d zlib/1.1.4) While trying to do like this: Reproduce code: --- http://www.yahoo.com";); curl_setopt ($ch, CURLOPT_TIMEOUT, 30); curl_setopt ($ch, CURLOPT_PROXY, "192.168.1.12:1080"); curl_setopt ($ch, CURLOPT_PROXYTYPE, CURLPROXY_SOCKS5); curl_setopt ($ch, CURLOPT_RETURNTRANSFER, TRUE); curl_setopt ($ch, CURLOPT_FAILONERROR, true); curl_setopt ($ch, CURLOPT_FOLLOWLOCATION, 1); $result = curl_exec($ch); print curl_errno ($ch); print $result; curl_close ($ch); ?> Expected result: I get: print $result is Ok; Notice: Use of undefined constant CURLOPT_PROXYTYPE - assumed 'CURLOPT_PROXYTYPE' in /home/jim/php/curl_socks.php on line 7 Notice: Use of undefined constant CURLPROXY_SOCKS5 - assumed 'CURLPROXY_SOCKS5' in /home/jim/php/curl_socks.php on line 7 Actual result: -- But: The socks proxy is ok => $result also Ok! PS: PLEASE CHECK ERROR (Near Notices) THANKS::FOR_YOUR_WORK -- Edit this bug report at http://bugs.php.net/?id=32695&edit=1
[PHP-DOC] #31929 [Opn->Csd]: Output Buffering Bug
ID: 31929 Updated by: [EMAIL PROTECTED] Reported By: clover at fromru dot com -Status: Open +Status: Closed -Bug Type: Output Control +Bug Type: Documentation problem Operating System: WinXP, SuSe 9.2 (PHP:4.3...) PHP Version: 5.0.3 New Comment: Yes, it really is docu problem. Derick, get your facts right before you touch bugs. Previous Comments: [2005-04-13 11:36:00] [EMAIL PROTECTED] This is not a documentation bug, please revert your patch Jakub - this also works fine in PHP 4.3 and should work fine in PHP 5.x. [2005-04-05 15:00:49] [EMAIL PROTECTED] This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. You can't even call functions using the output buffering functions like print_r($expression, true) or highlight_file($filename, true) from a callback function. [2005-02-18 16:56:38] [EMAIL PROTECTED] That's docu problem. var_export cannot be used in output buffering handlers and that should clarified in the docs. [2005-02-11 07:56:34] clover at fromru dot com Description: i'm using ob_start() with a callback function; internally in it i use $res=var_export($var, TRUE) function but got an error: [11-Feb-2005 08:28:15] PHP Fatal error: var_export() [ref.outcontrol]: Cannot use output buffering in output buffering display handlers in E:\htdocs\index.php on line XXX Reproduce code: --- Expected result: the "dump" of all sent headers instead of string "something..." Actual result: -- "PHP Fatal error..." Comment: this error actually must be when i call var_dump() or var_export($var, FALSE) in output buffering handler. -- Edit this bug report at http://bugs.php.net/?id=31929&edit=1
[PHP-DOC] #32733 [Bgs->Opn]: libmysqli.dll not included w/5.0.4 & PHP_MySQL.DLL & PHP_MySQL.DLL won't load
ID: 32733 Updated by: [EMAIL PROTECTED] Reported By: jason at thinkingman dot org -Status: Bogus +Status: Open -Bug Type: Dynamic loading +Bug Type: Documentation problem Operating System: XP (SP2) PHP Version: 5.0.4 New Comment: Reopening and relclassifyin as documentation probelm since the release package (and snapshots) seem to have all the dlls now in the 'root' of the package. The install.txt needs a bit of tuning.. Jason, FYI: The libmysql.dll is NOT the extension. The extensions are found in ext/ directory. Previous Comments: [2005-04-17 14:46:42] [EMAIL PROTECTED] There's something wrong with either your installation method or the mirror you're downloading the package from. There definately IS php_mysqli.dll in the zip package.. [2005-04-17 06:51:56] jason at thinkingman dot org Typo -- It looks like libmysqli.dll was NOT included in the .ZIP distro -- looks like this was a problem with the 5.0.3 distro as well. [2005-04-17 06:50:28] jason at thinkingman dot org Description: Just upgraded to 5.0.4 (from 5.0.2) -- MySqli & MySql DLL's (Extensions won't load when IIS starts. Get error message saying Unable to Load. PHP.INI is conf'd correctly -- paths are good, OS paths are good -- no dup DLL's on system. Reinstalled 5.0.2 everything works fine again. It looks like libmysqli.dll was included in the .ZIP distro -- looks like this was a problem with the 5.0.3 distro as well. -- Edit this bug report at http://bugs.php.net/?id=32733&edit=1
[PHP-DOC] #32785 [Opn->Asn]: negative limit doesn't work in explode()
ID: 32785 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: Debian GNU/Linux PHP Version: 4.3.10 -Assigned To: +Assigned To: nlopess New Comment: Assigned to Nuno: Thanks for wasting our time. Previous Comments: [2005-04-21 00:45:31] [EMAIL PROTECTED] Also: Why the hell do you doc people put something like this in the manual WHEN THERE IS NO SUCH RELEASE ever made with such feature(s)???!!! [2005-04-21 00:43:54] [EMAIL PROTECTED] Reclassified as documentation problem: The examples should have BIG note about the being like that only with PHP 5.1 [2005-04-21 00:03:55] [EMAIL PROTECTED] It does the same on current PHP-version also. nandus% uname -a FreeBSD nandus.mikrolahti.fi 5.4-STABLE FreeBSD 5.4-STABLE #0: Tue Apr 19 23:27:27 EEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NANDUS i386 nandus% cat explode.php nandus% php explode.php Content-type: text/html X-Powered-By: PHP/5.0.4 Array ( [0] => one [1] => two|three|four ) Array ( [0] => one [1] => two [2] => three [3] => four ) [2005-04-20 23:45:39] [EMAIL PROTECTED] Description: http://www.php.net/explode Manual gives an example of limit-parameter used in explode(). Example 2 shows negative limit-value example and it seems not working like expected. Test-code at web: http://mikrolahti.fi/explode.php Reproduce code: --- Expected result: Array ( [0] => one [1] => two|three|four ) Array ( [0] => one [1] => two [2] => three ) Actual result: -- Array ( [0] => one [1] => two|three|four ) Array ( [0] => one [1] => two [2] => three [3] => four ) -- Edit this bug report at http://bugs.php.net/?id=32785&edit=1
[PHP-DOC] #32785 [Opn]: negative limit doesn't work in explode()
ID: 32785 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Debian GNU/Linux PHP Version: 4.3.10 New Comment: Also: Why the hell do you doc people put something like this in the manual WHEN THERE IS NO SUCH RELEASE ever made with such feature(s)???!!! Previous Comments: [2005-04-21 00:43:54] [EMAIL PROTECTED] Reclassified as documentation problem: The examples should have BIG note about the being like that only with PHP 5.1 [2005-04-21 00:03:55] [EMAIL PROTECTED] It does the same on current PHP-version also. nandus% uname -a FreeBSD nandus.mikrolahti.fi 5.4-STABLE FreeBSD 5.4-STABLE #0: Tue Apr 19 23:27:27 EEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NANDUS i386 nandus% cat explode.php nandus% php explode.php Content-type: text/html X-Powered-By: PHP/5.0.4 Array ( [0] => one [1] => two|three|four ) Array ( [0] => one [1] => two [2] => three [3] => four ) [2005-04-20 23:45:39] [EMAIL PROTECTED] Description: http://www.php.net/explode Manual gives an example of limit-parameter used in explode(). Example 2 shows negative limit-value example and it seems not working like expected. Test-code at web: http://mikrolahti.fi/explode.php Reproduce code: --- Expected result: Array ( [0] => one [1] => two|three|four ) Array ( [0] => one [1] => two [2] => three ) Actual result: -- Array ( [0] => one [1] => two|three|four ) Array ( [0] => one [1] => two [2] => three [3] => four ) -- Edit this bug report at http://bugs.php.net/?id=32785&edit=1
[PHP-DOC] #32785 [Bgs->Opn]: negative limit doesn't work in explode()
ID: 32785 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open -Bug Type: Arrays related +Bug Type: Documentation problem Operating System: Debian GNU/Linux PHP Version: 4.3.10 New Comment: Reclassified as documentation problem: The examples should have BIG note about the being like that only with PHP 5.1 Previous Comments: [2005-04-21 00:42:22] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Negative limits are only supported in PHP 5.1 [2005-04-21 00:03:55] [EMAIL PROTECTED] It does the same on current PHP-version also. nandus% uname -a FreeBSD nandus.mikrolahti.fi 5.4-STABLE FreeBSD 5.4-STABLE #0: Tue Apr 19 23:27:27 EEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NANDUS i386 nandus% cat explode.php nandus% php explode.php Content-type: text/html X-Powered-By: PHP/5.0.4 Array ( [0] => one [1] => two|three|four ) Array ( [0] => one [1] => two [2] => three [3] => four ) [2005-04-20 23:45:39] [EMAIL PROTECTED] Description: http://www.php.net/explode Manual gives an example of limit-parameter used in explode(). Example 2 shows negative limit-value example and it seems not working like expected. Test-code at web: http://mikrolahti.fi/explode.php Reproduce code: --- Expected result: Array ( [0] => one [1] => two|three|four ) Array ( [0] => one [1] => two [2] => three ) Actual result: -- Array ( [0] => one [1] => two|three|four ) Array ( [0] => one [1] => two [2] => three [3] => four ) -- Edit this bug report at http://bugs.php.net/?id=32785&edit=1
[PHP-DOC] #32870 [Opn]: Setting "output_handler" does not work with custom functions
ID: 32870 Updated by: [EMAIL PROTECTED] Reported By: ng4rrjanbiah at rediffmail dot com Status: Open -Bug Type: Output Control +Bug Type: Documentation problem Operating System: Windows XP PHP Version: 5.0.4 New Comment: It won't work because the script is compiled and executed AFTER the automatic output buffering using the php.ini output_handler is started. Docteam: It should be noted here http://www.php.net/manual/en/ref.outcontrol.php in the configuration directives paragraph, section "output_handler", that you can only use the buildin output handler functions and not any user defined ones. Previous Comments: [2005-04-28 17:56:01] ng4rrjanbiah at rediffmail dot com Description: Setting output_handler (either through php.ini our .htaccess) does not work with custom functions. It works for "ob_gzhandler" but *not* on any custom functions--say "foo". There was a detail discussion on c.l.php about this http://groups.google.com/[EMAIL PROTECTED] Though we could set custom callback functions through ob_start(), we couldn't set output_handler (for custom functions) via php.ini. The manual also hints that it could be set PHP_INI_PERDIR basis http://in2.php.net/ref.outcontrol#AEN111555 Peace to you all PHP saints... -R. Rajesh Jeba Anbiah Reproduce code: --- in php.ini set: output_handler "foo_callback" in test.php: Expected result: "foo_callback" to be listed Actual result: -- nothing. (Callback not registered.) -- Edit this bug report at http://bugs.php.net/?id=32870&edit=1
[PHP-DOC] #32948 [Opn]: $HTTP_RAW_POST_DATA is empty if form's enctype="multipart/form-data"
ID: 32948 Updated by: [EMAIL PROTECTED] Reported By: chaz_meister_rock at yahoo dot com Status: Open -Bug Type: HTTP related +Bug Type: Documentation problem -Operating System: OSX 10.3.9 +Operating System: * -PHP Version: 5.0.4 +PHP Version: Irrelevant New Comment: HTTP_RAW_POST_DATA is NOT set for multipart forms. Would be nice if this was said in the manual too. Previous Comments: [2005-05-05 03:10:34] chaz_meister_rock at yahoo dot com Description: $HTTP_RAW_POST_DATA is empty when using a form with enctype="multipart/form-data" set. php.ini contains always_populate_raw_post_data = On this issue looks similar to: http://bugs.php.net/bug.php?id=23765 Reproduce code: --- Expected result: it=groovy&upFile= Actual result: -- Notice: Undefined index: HTTP_RAW_POST_DATA -- Edit this bug report at http://bugs.php.net/?id=32948&edit=1
[PHP-DOC] #33240 [Opn]: XML_OPTION_SKIP_WHITE skips important spaces
ID: 33240 Updated by: [EMAIL PROTECTED] Reported By: jacob at jacobweber dot com Status: Open -Bug Type: XML related +Bug Type: Documentation problem Operating System: Fedora Core 3 PHP Version: 5.0.4 New Comment: Yes, it skips whitespace when you set it to 1. Otherwise it will not skip it, it's left as is. I could not find the documentation for these options (on the page for xml_parser_set_option()): XML_OPTION_SKIP_WHITE XML_OPTION_SKIP_TAGSTART even as they seem to have existed since PHP 3? :) Previous Comments: [2005-06-03 22:50:41] jacob at jacobweber dot com Description: Turning on XML_OPTION_SKIP_WHITE causes the space in the following XML to be skipped: ' & I believe this is incorrect. It doesn't skip the space in: & ' Jacob Reproduce code: --- $xmlStr = "' &"; $xmlParser = xml_parser_create(); xml_parser_set_option($xmlParser, XML_OPTION_SKIP_WHITE, 1); xml_parse_into_struct($xmlParser, $xmlStr, $xmlArr); xml_parser_free($xmlParser); print_r($xmlArr); Expected result: Array ( [0] => Array ( [tag] => A [type] => complete [level] => 1 [value] => ' & ) ) Actual result: -- Array ( [0] => Array ( [tag] => A [type] => complete [level] => 1 [value] => '& ) ) (note the missing space after the apostrophe -- Edit this bug report at http://bugs.php.net/?id=33240&edit=1
[PHP-DOC] #33225 [Opn]: PHP sends multiple Status headers
ID: 33225
Updated by: [EMAIL PROTECTED]
Reported By: phpbugs at thequod dot de
Status: Open
-Bug Type: CGI related
+Bug Type: Documentation problem
Operating System: *
PHP Version: 5.0.4
New Comment:
Here's what I get with Apache2 and your script:
HTTP/1.1 302 Found
Date: Fri, 03 Jun 2005 21:15:54 GMT
Server: Apache/2.0.52 (Fedora)
X-Powered-By: PHP/5.1.0-dev
Status: 301
Location: http://www.example.org
Connection: close
Content-Type: text/html; charset=ISO-8859-1
IMO, this is not a bug in either SAPI. Just documentation issue.
Previous Comments:
[2005-06-03 01:56:26] phpbugs at thequod dot de
Description:
Multiple "Status" lines get send when
using "header('Location: url')", which produces an
additional 302 (REDIRECT) status code.
This causes FastCGI (at least) to produce a 500 Internal
Server Error:
FastCGI: comm with server "/path/to/fcgi-starter" aborted:
error parsing headers: duplicate header 'status'
Documentation
(http://us2.php.net/manual/en/function.header.php) says:
Note: The HTTP status header line will always be the
first sent to the client [[NOT TRUE! - reproduce: echo
"" | php5/bin/php-fcgi]],
regardless of the
actual header() call being the first or not. The status
may be overridden by calling header() with a new status
line at any time unless the HTTP headers have already been
sent [[NOT TRUE! - this bug]].
---
configure (both PHP5 and PHP4):
./configure --enable-memory-limit
--enable-force-cgi-redirect \
--enable-track-vars --with-pcre-regex --with-mysql
--without-sqlite \
--with-zlib --with-bz2 --enable-mbstring --with-openssl
--enable-exif \
--with-dom=shared --with-ttf=shared --with-gd=shared
--enable-calendar \
--with-iconv --enable-inline-optimization
--enable-gd-native-ttf \
--with-ldap --with-ldap-sasl \
--with-gettext \
--without-mm --enable-fastcgi --prefix=/home/daniel/php5
Reproduce code:
---
$ cat << "?>" | php5/bin/php-fcgi
http://www.example.org' );
?>
Expected result:
Status: 301
Content-type: text/html
X-Powered-By: PHP/5.0.4
Location: http://www.example.org
Actual result:
--
Status: 302
Content-type: text/html
X-Powered-By: PHP/5.0.4
Status: 301
Location: http://www.example.org
--
Edit this bug report at http://bugs.php.net/?id=33225&edit=1
[PHP-DOC] #33225 [Opn]: PHP sends multiple Status headers
ID: 33225
Updated by: [EMAIL PROTECTED]
Reported By: phpbugs at thequod dot de
Status: Open
-Bug Type: CGI related
+Bug Type: Documentation problem
Operating System: *
PHP Version: 5.0.4
New Comment:
If Apache behaves like that (and CGI), it's not a bug.
Do NOT send multiple status headers if you wish it to work as you
expect.
Previous Comments:
[2005-06-05 16:59:14] [EMAIL PROTECTED]
Could you please check the last comment please?
And then return the bug to us if needed.
Thanks,
Nuno
[2005-06-05 13:45:31] phpbugs at thequod dot de
Sniper, please use a FastCGI-compiled PHP-CGI binary and
don't inspect the Apache output.
If you would have been running php-fastcgi on your Apache2
server you would've gotten a "Internal server error",
because fastcgi dies on multiple Status headers.
It's not only a documentation problem, but causes Internal
Server errors with Apache and fastcgi, because fastcgi is
very strict about the "There has to be exact one status
code in the cgi response".
[2005-06-03 23:18:04] [EMAIL PROTECTED]
Here's what I get with Apache2 and your script:
HTTP/1.1 302 Found
Date: Fri, 03 Jun 2005 21:15:54 GMT
Server: Apache/2.0.52 (Fedora)
X-Powered-By: PHP/5.1.0-dev
Status: 301
Location: http://www.example.org
Connection: close
Content-Type: text/html; charset=ISO-8859-1
IMO, this is not a bug in either SAPI. Just documentation issue.
[2005-06-03 01:56:26] phpbugs at thequod dot de
Description:
Multiple "Status" lines get send when
using "header('Location: url')", which produces an
additional 302 (REDIRECT) status code.
This causes FastCGI (at least) to produce a 500 Internal
Server Error:
FastCGI: comm with server "/path/to/fcgi-starter" aborted:
error parsing headers: duplicate header 'status'
Documentation
(http://us2.php.net/manual/en/function.header.php) says:
Note: The HTTP status header line will always be the
first sent to the client [[NOT TRUE! - reproduce: echo
"" | php5/bin/php-fcgi]],
regardless of the
actual header() call being the first or not. The status
may be overridden by calling header() with a new status
line at any time unless the HTTP headers have already been
sent [[NOT TRUE! - this bug]].
---
configure (both PHP5 and PHP4):
./configure --enable-memory-limit
--enable-force-cgi-redirect \
--enable-track-vars --with-pcre-regex --with-mysql
--without-sqlite \
--with-zlib --with-bz2 --enable-mbstring --with-openssl
--enable-exif \
--with-dom=shared --with-ttf=shared --with-gd=shared
--enable-calendar \
--with-iconv --enable-inline-optimization
--enable-gd-native-ttf \
--with-ldap --with-ldap-sasl \
--with-gettext \
--without-mm --enable-fastcgi --prefix=/home/daniel/php5
Reproduce code:
---
$ cat << "?>" | php5/bin/php-fcgi
http://www.example.org' );
?>
Expected result:
Status: 301
Content-type: text/html
X-Powered-By: PHP/5.0.4
Location: http://www.example.org
Actual result:
--
Status: 302
Content-type: text/html
X-Powered-By: PHP/5.0.4
Status: 301
Location: http://www.example.org
--
Edit this bug report at http://bugs.php.net/?id=33225&edit=1
[PHP-DOC] #33549 [Opn->Ver]: Wrong result with bcmul()
ID: 33549
Updated by: [EMAIL PROTECTED]
Reported By: a dot schilder at gmx dot de
-Status: Open
+Status: Verified
-Bug Type: BC math related
+Bug Type: Documentation problem
Operating System: Win XP SP2
PHP Version: 5.0.4
New Comment:
If you pass the numbers as strings (as expected, although the manual
has it wrong in the example), this works fine:
bcmul("1", "0.1", 5);
Reclassified as documentation issue. (the bad examples in bcmath
section)
Previous Comments:
[2005-07-02 18:03:12] a dot schilder at gmx dot de
Description:
The result returned by bcmul() with the factor X (greater than 0) and
0.1 is 0 - it's not the expected result.
Reproduce code:
---
// Does not work - result is 0:
bcmul(1, 0.1, 5);
// This workaround does it - result 0.1:
bcdiv(bcmul(1, 0.00010, 5), 10, 5);
Expected result:
The correct result 0.1
Actual result:
--
0
--
Edit this bug report at http://bugs.php.net/?id=33549&edit=1
[PHP-DOC] #33574 [Opn->Ver]: parse_ini_file fails to parse values containing "{"
ID: 33574
Updated by: [EMAIL PROTECTED]
Reported By: m at tacker dot org
-Status: Open
+Status: Verified
-Bug Type: Filesystem function related
+Bug Type: Documentation problem
Operating System: Gentoo Linux
PHP Version: 5.1.0b2
New Comment:
This is not a bug but new feature added in PHP 5.1 by Andrei:
"
Adding ability to refer to existing .ini variables from within .ini
files. Example:
open_basedir = ${open_basedir} ":/new/dir"
"
Quoting the values is very good idea anyway..
This isn't documented anywhere -> reclassified.
Previous Comments:
[2005-07-05 13:42:42] m at tacker dot org
Using quotations fixes that problem.
[2005-07-05 13:38:41] m at tacker dot org
Description:
PHP 5.1's parse_ini_file cannot parse this line where 5.0's can:
from_email = [EMAIL PROTECTED]
Expected result:
An array with
$config = array(
'from_email' => '[EMAIL PROTECTED]'
);
Actual result:
--
Warning: Error parsing ../include/config/config.ini
--
Edit this bug report at http://bugs.php.net/?id=33574&edit=1
[PHP-DOC] #33643 [Opn]: Fatal error: Only variables can be passed by reference
ID: 33643 Updated by: [EMAIL PROTECTED] Reported By: Jason at hybd dot net Status: Open -Bug Type:Scripting Engine problem +Bug Type:Documentation problem PHP Version: 5.1.0b2 New Comment: Yes, it is undocumented. But same goes for PHP 4.4.0 too. Reclassified. (this break was intentional and fixed a lot of references related bugs) Previous Comments: [2005-07-11 20:28:07] Jason at hybd dot net Sorry, it's all fair and well making this bogus, but this change breaks LOADS of existing code, so it is not a bug and it's behavior is NOT documented. The least you could have done is justify why this is not a bug and why this change was introduced into the language! This is really a PHP bug because thi has worked in all versions of PHP prior to this. There has been nothing in the way of warning or anything in recent releases to phase in this change in behaviour like there was with the call by reference thing. Do you expect many thousands of programmers to change their code because if this stupid querk. [2005-07-11 17:32:30] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . [2005-07-11 13:06:46] Jason at hybd dot net Description: This bug is a rehash of 33516, but I can't reopen as I'm not the original author. It seems like you can not pass tempories to function / method parameters. '1234567890'); } } $tmp = Foo::bar(); $var = array_pop($tmp); ?> Seems to work, but it shouldn't be down to the PHP user (imho) to implement this as this change in PHP 5.1 breaks a lot of existing code. Reproduce code: --- '1234567890'); } } $var = array_pop(Foo::bar()); ?> Expected result: $var = '1234567890'; Foo::bar() gets placed in temporary variable Actual result: -- Fatal error: Only variables can be passed by reference -- Edit this bug report at http://bugs.php.net/?id=33643&edit=1
[PHP-DOC] #33643 [Opn]: Fatal error: Only variables can be passed by reference
ID: 33643 Updated by: [EMAIL PROTECTED] Reported By: Jason at hybd dot net Status: Open Bug Type:Documentation problem PHP Version: 5.1.0b2 New Comment: This is not gonna change, it's now how it's supposed to be. Previous Comments: [2005-07-11 22:04:22] Jason at hybd dot net May I be a pain and just ask will there be any chance that this bug will be resolved at some point in the future, or will you push others to work round this bug. May i suggest, seeing as this does break a lot of things, would it be possible to make this something like a ze1_compatiblity_mode to help people phase this change in? I assume this fixes blugs like 32685. I assume is a similar issue as I had relating to in 32963, and I assume many other people have reported similar bugs. [2005-07-11 20:34:34] [EMAIL PROTECTED] Yes, it is undocumented. But same goes for PHP 4.4.0 too. Reclassified. (this break was intentional and fixed a lot of references related bugs) [2005-07-11 20:28:07] Jason at hybd dot net Sorry, it's all fair and well making this bogus, but this change breaks LOADS of existing code, so it is not a bug and it's behavior is NOT documented. The least you could have done is justify why this is not a bug and why this change was introduced into the language! This is really a PHP bug because thi has worked in all versions of PHP prior to this. There has been nothing in the way of warning or anything in recent releases to phase in this change in behaviour like there was with the call by reference thing. Do you expect many thousands of programmers to change their code because if this stupid querk. [2005-07-11 13:06:46] Jason at hybd dot net Description: This bug is a rehash of 33516, but I can't reopen as I'm not the original author. It seems like you can not pass tempories to function / method parameters. '1234567890'); } } $tmp = Foo::bar(); $var = array_pop($tmp); ?> Seems to work, but it shouldn't be down to the PHP user (imho) to implement this as this change in PHP 5.1 breaks a lot of existing code. Reproduce code: --- '1234567890'); } } $var = array_pop(Foo::bar()); ?> Expected result: $var = '1234567890'; Foo::bar() gets placed in temporary variable Actual result: -- Fatal error: Only variables can be passed by reference -- Edit this bug report at http://bugs.php.net/?id=33643&edit=1
[PHP-DOC] #27688 [Bgs->Opn]: Session names consisting of only numbers cause session id generation
ID: 27688
Updated by: [EMAIL PROTECTED]
Reported By: ryan at daelibs dot com dot au
-Status: Bogus
+Status: Open
-Bug Type: Session related
+Bug Type: Documentation problem
Operating System: *
PHP Version: 5CVS, 4CVS (2005-01-10)
Assigned To: amt
New Comment:
There should be a big fat warning about this in the manual.
Previous Comments:
[2005-07-29 18:29:48] [EMAIL PROTECTED]
Session name can NOT be a plain number.
No checks will be added since that'd make the code slower for no real
gain.
[2004-03-29 09:39:15] [EMAIL PROTECTED]
This happens because PHP turns a numeric session name
into an array index inside $_COOKIE and we're doing an
zend_hash_find() instead of a zend_hash_index_find().
(ext/session/session.c, line 1098).
We can probably fix the bug by doing a
zend_hash_index_find() instead if the session name
successfully converts to a integer.
[2004-03-29 04:53:03] unknown at simplemachines dot org
Here's a simple workaround:
Session ID: ', session_id(), '
Cookie: ', $_COOKIE[session_name()];
?>
Removing the session_id() line though, shows that the cookie is still
being properly set.
-[Unknown]
[2004-03-25 00:00:26] ryan at daelibs dot com dot au
Description:
When you use a session name that has only numbers, each call to
session_start seems to regenerate a new session id, so the session does
not persist.
The code below can be loaded and refreshed to reproduce the behaviour
Reproduce code:
---
';
echo 'Session Id: '.session_id().'';
?>
Expected result:
Session Name: 99
Session Id: {{a sid that remains the same between each refresh }}
Actual result:
--
Session Name: 99
Session Id: {{a different sid each refresh}}
--
Edit this bug report at http://bugs.php.net/?id=27688&edit=1
[PHP-DOC] #33790 [Ver->Opn]: Exec command trims spaces from output
ID: 33790
Updated by: [EMAIL PROTECTED]
Reported By: marcus at names dot co dot uk
-Status: Verified
+Status: Open
-Bug Type: Program Execution
+Bug Type: Documentation problem
Operating System: *
PHP Version: 5CVS, 4CVS (2005-07-20)
New Comment:
The manual should state this fact. There is no bug to fix as these
functions have worked like this since PHP 3.
You can use ob_start()..passthru()..ob_get_contents() as workaround. Or
you can use glob() or scandir() if you only need to get the filenames..
Previous Comments:
[2005-07-20 17:13:36] marcus at names dot co dot uk
Description should read, "all white space
is removed FROM THE END OF EACH LINE, rather than just
new line characters".
[2005-07-20 17:11:10] marcus at names dot co dot uk
Description:
Each line in the output array returned as the second
parameter of exec() is trimmed so that all white space
is removed, rather than just new line characters.
I found this issue while trying to use the following
command to find all files in the current directory whose
name ends in a space:
exec("find . -name '* '",$output_array,$status);
However, in $output_array the filenames have been
trimmed so that they no longer end in a space.
Reproduce code:
---
exec("find . -name '* '",$output_array,$status);
Expected result:
array(
"file1 "
"file2 "
);
Actual result:
--
array(
"file1"
"file2"
);
--
Edit this bug report at http://bugs.php.net/?id=33790&edit=1
[PHP-DOC] #30257 [Ver->Opn]: Unexpected result of xml_get_current_byte_index and xml_get_current_column_numb
ID: 30257
Updated by: [EMAIL PROTECTED]
Reported By: christoffer at natlikan dot se
-Status: Verified
+Status: Open
-Bug Type: XML related
+Bug Type: Documentation problem
Operating System: *
PHP Version: 5CVS-2005-02-02
New Comment:
This difference is caused by the fact that in PHP5 we use libxml
instead of expat by default.
To get the expat behaviour, you can always compile PHP with
--with-expat-dir=/path/to/expat
This change in behaviour needs to be documented though.
Previous Comments:
[2004-09-30 01:27:16] olivier at samalyse dot com
I'm experiencing similar troubles with xml_get_current_byte_index().
But I don't agree with the expected result christoffer proposes.
Actually, in php4 xml_get_current_byte_index() behaves perfectly to me.
Using the test code below with php version 4.3.4 produces :
ElementOpen - Row: 2 Col: 0 BIndex: 44
ElementOpen - Row: 4 Col: 1 BIndex: 61
ElementOpen - Row: 5 Col: 2 BIndex: 67
ElementClose - Row: 5 Col: 8 BIndex: 73
ElementClose - Row: 6 Col: 1 BIndex: 79
ElementClose - Row: 7 Col: 0 BIndex: 84
Byte Index 44 points at the beginning of the tag :
^
That is fine.
Now, if you omit the xml declaration '', using php5, you will obtain :
ElementOpen - Row: 1 Col: 5 BIndex: 8
ElementOpen - Row: 3 Col: 8 BIndex: 19
ElementOpen - Row: 4 Col: 11 BIndex: 25
ElementClose - Row: 4 Col: 15 BIndex: 33
ElementClose - Row: 5 Col: 18 BIndex: 39
ElementClose - Row: 6 Col: 21 BIndex: 44
Byte index 8 does not point at the beginning of the tag anymore, but at
its end :
^
In my particular case (XML indexing/marshalling) that's far less
usable. Some may consider that's no bug, but it breaks backward
compatibility with php4.
Now, if you let the xml declaration in place, this function does not
produce anything relevant anymore. As Christoffer reports, parsing this
xml document when it includes '' will produce :
ElementOpen - Row: 2 Col: 5 BIndex: 11
ElementOpen - Row: 4 Col: 8 BIndex: 22
ElementOpen - Row: 5 Col: 11 BIndex: 28
ElementClose - Row: 5 Col: 15 BIndex: 36
ElementClose - Row: 6 Col: 18 BIndex: 42
ElementClose - Row: 7 Col: 21 BIndex: 47
In this later case, what seems to happen is that the xml declaration
byte length is badly evaluated. If you add to this the fact that the
returned byte index points at the end of the tag (php5) instead of the
beginning of the tag (php4), it really starts to look like random
output...
[2004-09-27 20:36:13] christoffer at natlikan dot se
Description:
xml_get_current_byte_index and xml_get_current_column_number returns
unexpected values when the XML contains a XML declaration. Using
php5.0-win32-200409270830 and Apache/1.3.31.
Reproduce code:
---
");
}
function elementClose($parser, $elementName) {
echo("ElementClose - Row: " .
xml_get_current_line_number($parser) .
" Col: " . xml_get_current_column_number($parser) .
" BIndex: " . xml_get_current_byte_index($parser) .
"");
}
$parser = xml_parser_create();
xml_parser_set_option($parser, XML_OPTION_CASE_FOLDING, false);
xml_set_element_handler($parser, "elementOpen", "elementClose");
$xml =
"\n" .
"\n" .
"\ttest\n" .
"\t\n" .
"\t\tfoo\n" .
"\t\n" .
"";
xml_parse($parser, $xml);
xml_parser_free($parser);
?>
Expected result:
ElementOpen - Row: 2 Col: 10 BIndex: 52
ElementOpen - Row: 4 Col: 8 BIndex: 63
ElementOpen - Row: 5 Col: 11 BIndex: 69
ElementClose - Row: 5 Col: 9 BIndex: 73
ElementClose - Row: 6 Col: 2 BIndex: 79
ElementClose - Row: 7 Col: 1 BIndex: 85
Actual result:
--
ElementOpen - Row: 2 Col: 5 BIndex: 11
ElementOpen - Row: 4 Col: 8 BIndex: 22
ElementOpen - Row: 5 Col: 11 BIndex: 28
ElementClose - Row: 5 Col: 15 BIndex: 36
ElementClose - Row: 6 Col: 18 BIndex: 42
ElementClose - Row: 7 Col: 21 BIndex: 47
--
Edit this bug report at http://bugs.php.net/?id=30257&edit=1
[PHP-DOC] #33973 [Ver->Opn]: using ob_start(create_function(...)): will not show up in ob_list_handlers()
ID: 33973
Updated by: [EMAIL PROTECTED]
Reported By: php at koterov dot ru
-Status: Verified
+Status: Open
-Bug Type: Output Control
+Bug Type: Documentation problem
Operating System: *
PHP Version: 5CVS, 4CVS (2005-08-03)
New Comment:
Anonymous is anonymous. Need to document this though.
Previous Comments:
[2005-08-03 12:30:04] php at koterov dot ru
Description:
Seems ob_list_handlers() cannot work with functions created dynamically
using create_function(). "default output handler" is returned.
Reproduce code:
---
Expected result:
array(1) { [0]=> string(...) "name of dynamically created function" }
Actual result:
--
array(1) { [0]=> string(22) "default output handler" }
--
Edit this bug report at http://bugs.php.net/?id=33973&edit=1
[PHP-DOC] #33968 [Opn]: Little error in echo's manual page
ID: 33968
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Irrelevant
PHP Version: Irrelevant
New Comment:
Stupid example, why would you do that when you can do this:
echo ($some_var) ? 'true' : 'false';
:)
Previous Comments:
[2005-08-02 16:19:34] [EMAIL PROTECTED]
Description:
There is a little error in "Example 1. echo() examples" block.
###
// Because echo is not a function, following code is invalid.
($some_var) ? echo 'true' : echo 'false';
// However, the following examples will work:
($some_var) ? print('true'): print('false'); // print is a function
###
The problem is that print is not a function. Its not really a matter of
"It doesn't work because its a language construct".
Here are the patches en+fr:
Index: en/reference/strings/functions/echo.xml
===
RCS file: /repository/phpdoc/en/reference/strings/functions/echo.xml,v
retrieving revision 1.15
diff -u -r1.15 echo.xml
--- en/reference/strings/functions/echo.xml 23 Nov 2004 09:38:18
- 1.15
+++ en/reference/strings/functions/echo.xml 2 Aug 2005 14:10:41 -
@@ -67,11 +67,11 @@
line with just a semicolon. no extra whitespace!
END;
-// Because echo is not a function, following code is invalid.
+// Because echo does not behave like a function, following code is
invalid.
($some_var) ? echo 'true' : echo 'false';
// However, the following examples will work:
-($some_var) ? print('true'): print('false'); // print is a function
+($some_var) ? print 'true': print 'false'; // print behaves like a
function
echo $some_var ? 'true': 'false'; // changing the statement around
?>
]]>
Index: fr/reference/strings/functions/echo.xml
===
RCS file: /repository/phpdoc-fr/reference/strings/functions/echo.xml,v
retrieving revision 1.22
diff -u -r1.22 echo.xml
--- fr/reference/strings/functions/echo.xml 5 Jul 2005 21:05:27
- 1.22
+++ fr/reference/strings/functions/echo.xml 2 Aug 2005 14:13:03 -
@@ -73,11 +73,11 @@
de plus !
END;
-// comme echo() n'est pas une fonction, le code suivant n'est pas
valide
-($some_var) ? echo('Oui') : echo('Non');
+// comme echo() ne se comporte pas comme une fonction, le code suivant
n'est pas valide
+($some_var) ? echo 'Oui' : echo 'Non';
// Cependant, les lignes suivantes sont valides :
-($some_var) ? print('Oui') : print('Non'); // print est une fonction
+($some_var) ? print 'Oui' : print 'Non'; // print se comporte comme
une fonction.
echo $some_var ? 'Oui' : 'Non';
?>
]]>
--
Edit this bug report at http://bugs.php.net/?id=33968&edit=1
[PHP-DOC] #33968 [Opn]: Little error in echo's manual page
ID: 33968
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Irrelevant
PHP Version: Irrelevant
New Comment:
..and it was already mentioned in the docs too.. ISC..
Previous Comments:
[2005-08-04 09:17:04] [EMAIL PROTECTED]
Stupid example, why would you do that when you can do this:
echo ($some_var) ? 'true' : 'false';
:)
[2005-08-02 16:19:34] [EMAIL PROTECTED]
Description:
There is a little error in "Example 1. echo() examples" block.
###
// Because echo is not a function, following code is invalid.
($some_var) ? echo 'true' : echo 'false';
// However, the following examples will work:
($some_var) ? print('true'): print('false'); // print is a function
###
The problem is that print is not a function. Its not really a matter of
"It doesn't work because its a language construct".
Here are the patches en+fr:
Index: en/reference/strings/functions/echo.xml
===
RCS file: /repository/phpdoc/en/reference/strings/functions/echo.xml,v
retrieving revision 1.15
diff -u -r1.15 echo.xml
--- en/reference/strings/functions/echo.xml 23 Nov 2004 09:38:18
- 1.15
+++ en/reference/strings/functions/echo.xml 2 Aug 2005 14:10:41 -
@@ -67,11 +67,11 @@
line with just a semicolon. no extra whitespace!
END;
-// Because echo is not a function, following code is invalid.
+// Because echo does not behave like a function, following code is
invalid.
($some_var) ? echo 'true' : echo 'false';
// However, the following examples will work:
-($some_var) ? print('true'): print('false'); // print is a function
+($some_var) ? print 'true': print 'false'; // print behaves like a
function
echo $some_var ? 'true': 'false'; // changing the statement around
?>
]]>
Index: fr/reference/strings/functions/echo.xml
===
RCS file: /repository/phpdoc-fr/reference/strings/functions/echo.xml,v
retrieving revision 1.22
diff -u -r1.22 echo.xml
--- fr/reference/strings/functions/echo.xml 5 Jul 2005 21:05:27
- 1.22
+++ fr/reference/strings/functions/echo.xml 2 Aug 2005 14:13:03 -
@@ -73,11 +73,11 @@
de plus !
END;
-// comme echo() n'est pas une fonction, le code suivant n'est pas
valide
-($some_var) ? echo('Oui') : echo('Non');
+// comme echo() ne se comporte pas comme une fonction, le code suivant
n'est pas valide
+($some_var) ? echo 'Oui' : echo 'Non';
// Cependant, les lignes suivantes sont valides :
-($some_var) ? print('Oui') : print('Non'); // print est une fonction
+($some_var) ? print 'Oui' : print 'Non'; // print se comporte comme
une fonction.
echo $some_var ? 'Oui' : 'Non';
?>
]]>
--
Edit this bug report at http://bugs.php.net/?id=33968&edit=1
[PHP-DOC] #33947 [Opn]: session.cookie_domain default behavior undocumented
ID: 33947 Updated by: [EMAIL PROTECTED] Reported By: gabe at mudbugmedia dot com Status: Open Bug Type: Documentation problem Operating System: Linux/Debian PHP Version: Irrelevant New Comment: Hint: If that ini option is empty, the parameter will not be set at all. (after that, it's up to the browser to behave correctly..) Previous Comments: [2005-08-01 17:35:59] gabe at mudbugmedia dot com Description: For the php.ini setting session.cookie_domain, the default value of '' (empty string) is documented in the php.ini and on the website. However, the meaning of the empty string value, and its expected default behavior, is not documented. The documentation needs updating to state what cookie domain will be sent to the browser. As of now I am getting conflicting reports of whether this empty value should set the cookie to '.blah.com' (to go across all sub-domains) or just 'www.blah.com' -- Edit this bug report at http://bugs.php.net/?id=33947&edit=1
[PHP-DOC] #33598 [Ver->Opn]: Throwing exception from __destruct causes fatal error
ID: 33598
Updated by: [EMAIL PROTECTED]
Reported By: carlo dot razzeto at mtginfo dot com
-Status: Verified
+Status: Open
-Bug Type: Class/Object related
+Bug Type: Documentation problem
Operating System: *
PHP Version: 5CVS-2005-08-03
New Comment:
Throwing exceptions in __desctruct() is not allowed.
Should be documented..
Previous Comments:
[2005-07-07 01:46:59] carlo dot razzeto at mtginfo dot com
Description:
When performing an operation which throws an exception in the
__destruct method of a class, the following Error is generated
Fatal error: Exception thrown without a stack frame in Unknown on line
0
I have only observed this happening when an object goes out of scope
because the script has ended. Rather than generating a scripting engine
error, PHP should allow for the script to deal with the error, for
instance when an exception handler has been specified by the script.
Reproduce code:
---
class test {
function __construct() {
echo "Construct\n";
}
function greet() {
echo "Hello World\n";
}
function __destruct() {
echo "Destruct\n";
throw new Exception( 'test' );
}
}
$test = new test();
$test->greet();
Expected result:
Construct
Hello World
Destruct
Fatal error: Uncaught exception 'Exception' with message 'test' in
/home/crazzeto/test.php:13
Stack trace:
#0 /home/crazzeto/test.php(13): test::__destruct()
#1 /home/crazzeto/test.php(20): test::__destruct()
#2 /home/crazzeto/test.php(20): unknown()
#3 {main}
thrown in /home/crazzeto/test.php on line 13
Actual result:
--
[EMAIL PROTECTED] crazzeto]$ php test.php
Construct
Hello World
Destruct
Fatal error: Exception thrown without a stack frame in Unknown on line
0
--
Edit this bug report at http://bugs.php.net/?id=33598&edit=1
[PHP-DOC] #33772 [Ctl->Opn]: __destruct is run too early (session_save_handler)
ID: 33772
Updated by: [EMAIL PROTECTED]
Reported By: msipria at suomi24 dot fi
-Status: Critical
+Status: Open
-Bug Type: Class/Object related
+Bug Type: Documentation problem
Operating System: *
PHP Version: 5CVS-2005-07-19
New Comment:
Reclassified as documentation issue.
Previous Comments:
[2005-08-09 14:55:03] [EMAIL PROTECTED]
This patch fixes this problem by doing php_session_flush() before any
__destruct()'s are called:
http://www.php.net/~jani/patches/bug33772.patch
Note: It won't work if you have compiled ext/session as shared. We need
a better solution, I'm submitting this just as as temporary one.
[2005-08-09 14:01:49] [EMAIL PROTECTED]
This is chicken/egg problem and it cannot be solved. One expect that
destructors are called before session close the other uses object for
save handlers.
[2005-07-21 16:38:11] msipria at suomi24 dot fi
my class isn't extension of mysqli class, it just use it as object, and
with real class i have tryed session_write_close() function but mysql
connection is deat, i don't wanna restor it, i just wanna that it will
be alive at the end like now.
[2005-07-21 00:10:05] toma at smartsemantics dot com
Adding session_write_close() to the __destruct() function will restore
the write, close, and destroy functions to their proper order.
I use a custom session handler that extends my custom mysqli class. It
automatically checks for lost database connections and attempts
reconnects, etc.
This is still a bug, but the following makes your custom session
handler viable.
public function __destruct(){
@session_write_close();
}
Without session_write_close:
starting session
connecting to database
destroying session
writing session
can't write, database connection does not exist
connecting to database
writing session
closing session
With session_write_close:
starting session
connecting to database
writing session
closing session
destroying session
[2005-07-19 21:20:45] [EMAIL PROTECTED]
I need this fixed too, it's not possible to use e.g. mysqli as save
handler otherwise..
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/33772
--
Edit this bug report at http://bugs.php.net/?id=33772&edit=1
[PHP-DOC] #34206 [Bgs->Opn]: cwd set to server root (?) in __destruct
ID: 34206 Updated by: [EMAIL PROTECTED] Reported By: maniac_warlord at web dot de -Status: Bogus +Status: Open -Bug Type: Class/Object related +Bug Type: Documentation problem Operating System: Windows XP / Linux PHP Version: 5.0.4 New Comment: This really should be documented. Apache(1&2) does the weird cwd change for some reason. Previous Comments: [2005-08-22 01:02:16] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2005-08-21 19:11:26] maniac_warlord at web dot de Description: cwd is set to server root (i guess) instead of called php file's directory in __destruct() it probably isn't server root (see results), because that would be /www on linux - on windows it is Reproduce code: --- bar(); } } $f = new Foo(); $f->bar(); ?> Expected result: Windows XP: F:\htdocs F:\htdocs My webhoster's linux: /www/htdocs/[some number] /www/htdocs/[some number] (or whatever directory the file is in) Actual result: -- Windows XP: F:\htdocs D:\Apache\Apache 2 My webhoster's linux: /www/htdocs/[some number] / -- Edit this bug report at http://bugs.php.net/?id=34206&edit=1
[PHP-DOC] #34315 [Asn->Opn]: Installer disables php in httpd.conf
ID: 34315 Updated by: [EMAIL PROTECTED] Reported By: marcus at synchromedia dot co dot uk -Status: Assigned +Status: Open -Bug Type: Apache2 related +Bug Type: Documentation problem Operating System: MacOS X 10.4.2 PHP Version: 5.1.0RC1 Assigned To: sniper New Comment: It's done because most distributions with apache2 use the 'conf.d' style modularized configurations and the apxs tool can't handle anything but httpd.conf and that results in having the line in question in 2 places. Documentation should state this. Previous Comments: [2005-08-31 14:53:22] [EMAIL PROTECTED] It's stupid to do this - it will stop running installs from working properly when people upgrade. [2005-08-31 14:48:14] marcus at synchromedia dot co dot uk Any particular reason? I can see it being not unreasonable for new installs, but for upgrades (i.e. where the LoadModule line is already active) it seems really unnecessary. It means that every install of 5.1 will default to not working, even if it was working before. Is this change in behaviour documented? [2005-08-31 14:16:06] [EMAIL PROTECTED] That change was intentional, no bug here. [2005-08-31 14:12:03] [EMAIL PROTECTED] Jani, I think this is broken by you when you changed the apxs switch from "install" to "not install" or something, please have a look at it. [2005-08-31 14:05:51] marcus at synchromedia dot co dot uk Description: Everything compiles and installs ok (as an apache2filter), but apache2 just doesn't load it. I tracked it down to a simple problem in httpd.conf - the 5.1 installer comments out this line: LoadModule php5_module/sw/lib/apache2/modules/ libphp5.so Even though make install said: [preparing module `php5' in /sw/etc/apache2/httpd.conf] An identical configuration of PHP 5.0.5RC2 works perfectly and does not comment out that line, The CLI compile of 5.1 works ok too. Reproduce code: --- Starting with a working install of 5.0.5RC2, % cd php-5.1.0RC1 % grep php5_module /sw/etc/apache2/httpd.conf LoadModule php5_module/sw/lib/apache2/modules/libphp5.so % make install ... % grep php5_module /sw/etc/apache2/httpd.conf #LoadModule php5_module/sw/lib/apache2/modules/libphp5.so So it's definitely the installer that's disabling it. -- Edit this bug report at http://bugs.php.net/?id=34315&edit=1
[PHP-DOC] #34315 [Opn->Csd]: Installer disables php in httpd.conf
ID: 34315 Updated by: [EMAIL PROTECTED] Reported By: marcus at synchromedia dot co dot uk -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: MacOS X 10.4.2 PHP Version: 5.1.0RC1 New Comment: Reverted: I didn't realize it touched existing lines too and not only when it has to ADD it.. Previous Comments: [2005-08-31 16:46:48] marcus at synchromedia dot co dot uk OK, I can understand that reasoning, However, the choice is really between getting a (non-fatal) warning on startup for a duplicate LoadModule statement vs not working at all. I'd say the former is the more tolerable choice. While the complications with conf.d stuf may be true, if you find an uncommented LoadModule in httpd.conf, it doesn't seem likely that it is already duplicated elsewhere. I'm not familiar with how you tweak httpd.conf programatically, so I guess there may be more to it than that. [2005-08-31 16:36:46] [EMAIL PROTECTED] It's done because most distributions with apache2 use the 'conf.d' style modularized configurations and the apxs tool can't handle anything but httpd.conf and that results in having the line in question in 2 places. Documentation should state this. [2005-08-31 14:53:22] [EMAIL PROTECTED] It's stupid to do this - it will stop running installs from working properly when people upgrade. [2005-08-31 14:48:14] marcus at synchromedia dot co dot uk Any particular reason? I can see it being not unreasonable for new installs, but for upgrades (i.e. where the LoadModule line is already active) it seems really unnecessary. It means that every install of 5.1 will default to not working, even if it was working before. Is this change in behaviour documented? [2005-08-31 14:16:06] [EMAIL PROTECTED] That change was intentional, no bug here. 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/34315 -- Edit this bug report at http://bugs.php.net/?id=34315&edit=1
[PHP-DOC] #12324 [Ver->Opn]: arg_separator.output broken
ID: 12324
Updated by: [EMAIL PROTECTED]
Reported By: voudras at phpking dot org
-Status: Verified
+Status: Open
Bug Type: Documentation problem
Operating System: linux
-PHP Version: any
+PHP Version: Irrelevant
Previous Comments:
[2001-07-31 20:03:45] [EMAIL PROTECTED]
arg_separator.output - defines which separator character
is used in the PHP written URLs (ie. transparent sessids)
arg_separator.input - defines which separator characrters
(yes, there can be many) are used to separate the variables
in query string. This can NOT changed in script since
the time the script is run, the query string has already
been processed. You can only change this in php.ini / httpd.conf /
.htaccess files.
Reclassified as documentation problem. The ini-directives
documentation lacks (not only) these. Also, the documentation should be
restructured to show which directives can be change and where. Some kind
of table maybe?
--Jani
[2001-07-31 18:10:23] voudras at phpking dot org
This is a tricky lil bug, real easy to overlook. At the following url i
have a script with your example code - and it does not function
properly:
http://wart.phpking.org/test3.php
you can see some other examples of how this doesnt work at
http://wart.phpking.org/test.php
http://wart.phpking.org/test2.php
again, this seems to execute fine on windows based php/apache systems
(which is probably a good clue as to where the problem exists).
- ini_get("arg_separator.input") does not return the 'local' value, but
instead the default or php.ini value (this is different than with
ini_get(
"arg_separator.output"). Perhpas this is intensional?
- the above problem probably contributes to the fact that where the
query_string is parsed for variables - it always gets the default
arg_separator.*
[2001-07-31 11:00:07] [EMAIL PROTECTED]
ok... the problem exists in your script at
http://wart.phpking.org/test.php
but using the EXACT script that I created, it works fine...
Please use this one... (EXACTLY)
status -> closed
[2001-07-31 10:55:35] [EMAIL PROTECTED]
i have gotten emails from people saying that they have reproduced
this error. Can anybody from PHP verify this? I have not been
able to reproduce this error (using the script in my last post.)
[2001-07-24 09:20:39] [EMAIL PROTECTED]
you have your params mixed up. replace arg_separator.output
with arg_separator.input and things will work. I modified
your script below. This one works as you wanted it to.
Key: '$key' Value '$val'";
}
}
echo "";
echo "Click to
activate test";
echo "";
?>
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/12324
--
Edit this bug report at http://bugs.php.net/?id=12324&edit=1
[PHP-DOC] #21970 [Ver->Asn]: Creating a new Tutorial section
ID: 21970 Updated by: [EMAIL PROTECTED] Reported By: philip at cornado dot com -Status: Verified +Status: Assigned Bug Type: Documentation problem Operating System: all PHP Version: Irrelevant Assigned To: aidan Previous Comments: [2005-01-25 07:44:08] [EMAIL PROTECTED] Somewhere down the line this bug report got renamed so be sure it's not closed until include_path is properly (extensively) documented. Not everything belongs in a tutorial...I agree with Goba on all points. [2005-01-24 16:44:24] [EMAIL PROTECTED] I agree with both Anatoly & Goba, here. - Getting started needs to be easily found by new developers. - And ~"Techniques" is a good name for the section we envisioned as "Tutorials" they're programming (usually php-specific or web-specific) techniques. - Perhaps a note should be dropped into the intro to "features/techniques" section that links to Getting Started. S [2005-01-23 15:09:06] [EMAIL PROTECTED] I think 'getting started' should be left alone, it is quite good for a beginner to start. If you look a bit closely at 'features' though, it is the exact place where tutorials are located already. We agreed on it before AFAIR that extension specific tutorials should go into their reference part, while broader scope tutorials or core tutorials should go into 'features'. Now we can rename it to 'PHP Programming Techniques' or something more flashy, but I think it is the right place to push tutorials into (except the getting started tutorial). Derek: 'reference' should be very far from being confused with 'tutorial' IMHO! [2005-01-23 14:50:02] [EMAIL PROTECTED] No, getting started is for beginners and they should be able to get to this page as fast as possible by just clicking "next" link or by looking at Table of Contents. Being good attractor for newbies "Getting Started" should be located at the top of ToC and visible by default. "Language Reference" is too dull to reflect how clear and easy PHP is. [2005-01-23 08:23:39] [EMAIL PROTECTED] I believe we should rename Getting Started to Tutorials (or something similar and relevant), and move it below Language Reference. The introduction section of Getting Started should be moved to the beginning of the Language Reference section. This seems to fit best. Right now 'Getting Started' is an oddball. 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/21970 -- Edit this bug report at http://bugs.php.net/?id=21970&edit=1
[PHP-DOC] #21964 [Ana]: Uploads of a file with size 0 bytes succeed.
ID: 21964
Updated by: [EMAIL PROTECTED]
Reported By: johnson at nicusa dot com
Status: Analyzed
Bug Type: Documentation problem
Operating System: ANY
PHP Version: Irrelevant
New Comment:
And iirc, nowadays you don't get any error (if your PHP is not compiled
with --enable-debug :)
Previous Comments:
[2003-02-03 01:01:28] [EMAIL PROTECTED]
[EMAIL PROTECTED]: don't try analyzing any bugs as you obviously don't have
a clue.
For doc people:
With PHP 4.3.0 -> you can upload 0 byte files and you don't
get any error. There is no error code '5'.
You get error 4 (UPLOAD_ERR_NO_FILE) if you don't put any file in the
field.
[2003-02-01 05:06:07] [EMAIL PROTECTED]
Actually it looks more than a documentation problem:
For now there is not any define(name) for the new error code. Plus it
looks it's under a #ifdef that can't happen because of : #undef
DEBUG_FILE_UPLOAD in line 39 of main/rfc1867.c.
There is the code:
#ifdef DEBUG_FILE_UPLOAD
if(strlen(filename) > 0 && total_bytes == 0) {
sapi_module.sapi_error(E_WARNING, "Uploaded
file size 0 - file
[%s=%s] not saved", param, filename);
cancel_upload = 5;
}
#endif
You can note that usually #ifdef DEBUG_FILE_UPLOAD is used only to hide
the sapi_module.sapi_error() function not the whole code.
eg:
if(strlen(filename) == 0) {
#ifdef DEBUG_FILE_UPLOAD
sapi_module.sapi_error(E_NOTICE, "No file
uploaded");
#endif
cancel_upload = UPLOAD_ERROR_D;
}
There is also an another point, why a file with 0 byte has to be
cancelled? Has it been discussed?
According to melvyn:
why would php stop me to upload a file of 0 bytes?
Take a 'web-ftp' for like a sitebuilder kinda app
it would just upload these and create a 0 byte file, which is what I
expect it to do for instance: config.php in phpBB2 is 0 bytes outof the
box.
it needs that to be, for install to work.
So now there are some questions, does the code 5 ever happen? If yes
is it expected that it stops the upload and why do not give it a real
name so we can finally document it.
[2003-01-30 11:43:59] [EMAIL PROTECTED]
I believe this was fixed in 4.2.3 and later.
[2003-01-30 10:47:31] johnson at nicusa dot com
I have seen in various places, postings that an uploaded file with size
of 0 bytes should now fail. In version 4.2.2 on Solaris 8 it succeeds.
Please make clear in the documentation exactly when/in which version of
PHP this was changed to throw an error code 5.
--
Edit this bug report at http://bugs.php.net/?id=21964&edit=1
[PHP-DOC] #34354 [Opn]: parse_ini_file interprets "null" as empty string
ID: 34354
Updated by: [EMAIL PROTECTED]
Reported By: php dot net at sharpdreams dot com
Status: Open
-Bug Type: Filesystem function related
+Bug Type: Documentation problem
Operating System: Win32
PHP Version: 5CVS-2005-09-03 (snap)
New Comment:
reclassified
Previous Comments:
[2005-09-03 03:53:56] php dot net at sharpdreams dot com
Description:
The documentation is unclear on this aspect so I am presuming this is a
bug:
Keys in INI files set to null (no quotes) are parsed as empty string ""
instead of a true null.
If this is intended behavior then it should be documented as such.
Reproduce code:
---
-- test.ini --
[foo]
bar = null
-- test.php --
var_dump( parse_ini_file( "test.ini" ) );
Expected result:
array(1) {
["foo"]=>
NULL
}
Actual result:
--
array(1) {
["foo"]=>
string(0) ""
}
--
Edit this bug report at http://bugs.php.net/?id=34354&edit=1
[PHP-DOC] #34370 [Opn]: intval fails on negative hex numbers
ID: 34370
Updated by: [EMAIL PROTECTED]
Reported By: andreybl at matrix dot co dot il
Status: Open
-Bug Type: *General Issues
+Bug Type: Documentation problem
Operating System: RH EL 3.0
PHP Version: 5CVS-2005-09-05 (snap)
New Comment:
Documentation should state this more clearly.
Previous Comments:
[2005-09-05 00:32:29] andreybl at matrix dot co dot il
Description:
inval() for negative hex number returns the max integer value.
Reproduce code:
---
$hex1 = intval("0x", 16);
$hex2 = intval("0x7fff", 16);
var_dump($hex1, $hex2);
Expected result:
int(-1)
int(2147483647)
Actual result:
--
int(2147483647)
int(2147483647)
--
Edit this bug report at http://bugs.php.net/?id=34370&edit=1
[PHP-DOC] #34390 [Asn->Opn]: Redefinition of static methods in subclasses
ID: 34390
Updated by: [EMAIL PROTECTED]
Reported By: cbelin at free dot fr
-Status: Assigned
+Status: Open
-Bug Type: Class/Object related
+Bug Type: Documentation problem
Operating System: Windows XP SP2
PHP Version: 5.0.4
Assigned To: sniper
New Comment:
Reclassified as docu bug.
Previous Comments:
[2005-09-12 11:37:54] [EMAIL PROTECTED]
This is documentation bug.
[2005-09-07 11:54:31] [EMAIL PROTECTED]
Dmitry, shouldn't this procude an error..?
[2005-09-06 13:49:50] cbelin at free dot fr
Description:
Manual says that static members and methods cannot be redefined in
subclasses.
It seems that it's not completely true (at least with PHP 5.0.4 under
Windows XP), as redefining static methods in subclasses is allowed, and
works fine (i.e. without triggering errors even if error level includes
E_STRICT).
Reproduce code:
---
class Base
{
public static function foo()
{
return 'Foo...';
}
}
class Extended extends Base
{
public static function foo()
{
return 'Bar !!!';
}
}
echo Extended::foo();
Expected result:
An error, or the output of Base::foo()
Actual result:
--
It works, and prints 'Bar !!!'
--
Edit this bug report at http://bugs.php.net/?id=34390&edit=1
[PHP-DOC] #33772 [Asn->Opn]: __destruct is run too early (session_save_handler)
ID: 33772
Updated by: [EMAIL PROTECTED]
Reported By: msipria at suomi24 dot fi
-Status: Assigned
+Status: Open
Bug Type: Documentation problem
Operating System: *
PHP Version: 5CVS-2005-07-19
Previous Comments:
[2005-09-10 12:34:54] zulan at zulan dot net
If this is the egg, the chicken is:
http://bugs.php.net/bug.php?id=27555
Is there a way to make it ini_set-able if objects->__destruct or
sess_write_close first?
[2005-09-09 22:01:22] earnest dot berry at gmail dot com
I also am having the issue. I'm using 5.1.0b3 with mysql 4.1.13a-nt.
Will this be fixed in the next relase of PHP?
[2005-09-09 21:56:34] tss24 at cornell dot edu
Experiencing the same exact problem with PHP 5.0.5 and MySQL 4.1.11
Was this a new bug with PHP 5.0.5 / 5.1.x?
[2005-08-24 23:58:03] webmaster at vintagegaming dot org
I want to enter this as a new bug report but I expect it would be
kicked out as a duplicate of 33635, which links to this bug. This
seems related in that something has changed so that my mysqli link is
closed before the shutdown_function is executed.
The following code works in all php5 versions before 5.1beta3.
';
register_shutdown_function('shutdown');
?>
Expected Result:
foo
foo
Actual Result:
foo
Warning: Couldn't fetch mysqli in c:\program files\apache
group\Apache\htdocs\foo.php on line 7
and to further this annoying issue, why is it that the equivalent mysql
function still works in 5.1b3?
';
register_shutdown_function('shutdown');
?>
Expected Result:
foo
foo
Actual Result:
foo
foo
[2005-08-23 03:03:36] [EMAIL PROTECTED]
Reclassified as documentation issue.
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/33772
--
Edit this bug report at http://bugs.php.net/?id=33772&edit=1
[PHP-DOC] #34533 [Opn]: LDAP cannot connect when linked against Oracle LDAP libraries
ID: 34533
Updated by: [EMAIL PROTECTED]
Reported By: liamr at umich dot edu
Status: Open
-Bug Type: LDAP related
+Bug Type: Documentation problem
Operating System: linux 2.4.31
PHP Version: 5CVS-2005-09-16 (snap)
New Comment:
I'm reclassifying this as documentation problem.
The solution is quite simple actually. If you'd use
the oracle database functions, they wouldn't work any better either.
You have to ALWAYS set the environment correctly when dealing with
Oracle.
For me, setting ORACLE_HOME was enough.
More information about these environment variables can be found at
http://www.php.net/oci8
There should be a note about this in the LDAP section of the manual..
Previous Comments:
[2005-09-16 21:56:23] liamr at umich dot edu
It's not much more complicated, but here..
LDAP query test" );
echo( "Connecting ..." );
$ds=ldap_connect('ldap.itd.umich.edu', 389);
print_r( $ds );
echo( "connect result is ".$ds."" );
if ($ds) {
echo( "Binding ..." );
$r=ldap_bind($ds);
echo( "Bind result is ".$r."" );
echo( "Closing connection" );
ldap_close( $ds );
} else {
echo( "Unable to connect to LDAP server" );
}
?>
[2005-09-16 21:25:49] [EMAIL PROTECTED]
Obviously the script you provided in your report is not the one you
used to generate that (useless) strace. Can you please show the code
you tried?
[2005-09-16 20:37:35] liamr at umich dot edu
Description:
ldap_connect() returns "Unable to connect to LDAP server" when linked
against Oracle LDAP libraries. I've tried this with PHP 4.3.11, 5.0.5,
5.1.0RC1, and a snapshot I downloaded today (php5-200509161630), all
against Oracle 8.1.7 (full install), 10.1.0.3 (full install), and
10.1.0.4 (instantclient w/ the LDAP headers copied from a full
install). Apache 1.3.33 on an LFS based distro running the 2.4.31
kernel.
Reproduce code:
---
$ds=ldap_connect('ldap.example.com', 389);
Expected result:
When the ldap extension is linked against openldap, the ldap_connect()
results in an LDAP connection.
Actual result:
--
When linked against Oracle's LDAP, the server is unable to establish a
connection. Looking at strace, it doesn't even query the network:
open("/usr/lib/php/extensions/no-debug-non-zts-20050617/ldap.so",
O_RDONLY) = 8
read(8,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300+\0\0004\0\0\00085\1\0\0\0\0\0004\0
\0\4\0(\0\"\0\37\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0xw\0\0xw\0\0\5\0\0\0\0\20\0\0\1\0\0\0\200w\0\0\200\207\0\0\200\207\0\0\240\5\0\0\274\5\0\0\6\0\0\0\0\20\0\0\2\0\0\0\f|\0\0\f\214\0\0\f\214\0\0\340\0\0\0\340\0\0\0\6\0\0\0\4\0\0\0P\345td\\w\0\0\\w\0\0\\w\0\0\34\0\0\0\34\0\0\0\4\0\0\0\4\0\0\0\203\0\0\0\233\0\0\0\0\0\0\0002\0\0\0A\0\0\0\0\0\0\0\226\0\0\0\0\0\0\0006\0\0\0\0\0\0\0q\0\0\0009\0\0\0|\0\0\0U\0\0\0%\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\214\0\0\0\210\0\0\0\0\0\0\0\215\0\0\0\0\0\0\0\0\0\0\0~\0\0\0\0\0\0\0\0\0\0\0v\0\0\0\231\0\0\0]\0\0\0\0\0\0\0\225\0\0\0\0\0\0\0[\0\0\0O\0\0\0\0\0\0\0\201\0\0\0008\0\0\0C\0\0\0\0\0\0\0S\0\0\0m\0\0\0\0\0\0\0\217\0\0\0\0\0\0\0z\0\0\0J\0\0\0Q\0\0\0\211\0\0\0/\0\0\0)\0\0\0\0\0\0\0K\0\0\0\232\0\0\0\0\0\0\0h\0\0\0\0\0\0\0\0\0\0\0H\0\0\0\0\0\0\0\227\0\0\0\220\0\0\0\223\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0_\0\0\0\0\0\0\0\222\0\0\0\0\0\0\0&\0\0\0\"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=\0\0\0\177\0\0\0\0\0\0\0e\0\0\0\0\0\0\0b\0\0\0w\0\0\0003\0\0\0I\0\0\0005\0\0\!
0n\0\0\0\216\0\0\0\0\0\0\0\230\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0#\0\0\0k\0\0\0([EMAIL
PROTECTED]:\0\0\0\0\0\0\0\0\0\0\0>\0\0\0.\0\0\!
0\0\0\0\0",
1024) = 1024
fstat64(8, {st_dev=makedev(8, 1), st_ino=1947378, st_mode=S_IFREG|0755,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=184,
st_size=86383, st_atime=2005/09/16-12:58:21,
st_mtime=2005/09/16-12:56:19, st_ctime=2005/09/16-12:56:28}) = 0
old_mmap(NULL, 36156, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) =
0x42b59000
mprotect(0x42b61000, 3388, PROT_NONE) = 0
old_mmap(0x42b61000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
8, 0x7000) = 0x42b61000
close(8)= 0
open("/usr/local/oracle/lib/mmx/cmov/libclntsh.so.10.1", O_RDONLY) = -1
ENOENT (No such file or directory)
stat64("/usr/local/oracle/lib/mmx/cmov", 0xbfffa1d0) = -1 ENOENT (No
such file or directory)
open("/usr/local/oracle/lib/mmx/libclntsh.so.10.1", O_RDONLY) = -1
ENOENT (No such file or directory)
stat64("/usr/local/oracle/lib/mmx", 0xbfffa1d0) = -1 ENOENT (No such
file or directory)
open("/usr/local/oracle/lib/cmov/libclntsh.so.10.1", O_RDONLY) = -1
ENOENT (No such file or directory)
stat64("/usr/local/oracle/lib/cmov", 0xbfffa1d0) = -1 ENOENT (No such
file or directory)
open("/usr/local/oracle/lib/libclntsh.so.10.1", O_RDONLY) = 8
read(8,
"\177ELF\
[PHP-DOC] #34533 [Fbk->Opn]: LDAP cannot connect when linked against Oracle LDAP libraries
ID: 34533
Updated by: [EMAIL PROTECTED]
Reported By: liamr at umich dot edu
-Status: Feedback
+Status: Open
Bug Type: Documentation problem
Operating System: linux 2.4.31
PHP Version: 5CVS-2005-09-16 (snap)
New Comment:
You're just doing it wrong. Works fine for me using this configure
line:
# export ORACLE_HOME=/home/oracle/OraHome_1
# ./configure --disable-all \
'--with-ldap=/home/oracle/OraHome_1
And using the PHP CLI binary on command line, run your script..
Note: I have Oracle 10.1.0.3 libs.
Previous Comments:
[2005-09-16 22:49:43] [EMAIL PROTECTED]
How exactly do you set it and what it's value when you're using full
installs?
Do you get any error messages or something?
[2005-09-16 22:43:11] liamr at umich dot edu
I am setting ORACLE_HOME in my apache startup script. Doesn't help.
[2005-09-16 22:36:09] [EMAIL PROTECTED]
I'm reclassifying this as documentation problem.
The solution is quite simple actually. If you'd use
the oracle database functions, they wouldn't work any better either.
You have to ALWAYS set the environment correctly when dealing with
Oracle.
For me, setting ORACLE_HOME was enough.
More information about these environment variables can be found at
http://www.php.net/oci8
There should be a note about this in the LDAP section of the manual..
[2005-09-16 21:56:23] liamr at umich dot edu
It's not much more complicated, but here..
LDAP query test" );
echo( "Connecting ..." );
$ds=ldap_connect('ldap.itd.umich.edu', 389);
print_r( $ds );
echo( "connect result is ".$ds."" );
if ($ds) {
echo( "Binding ..." );
$r=ldap_bind($ds);
echo( "Bind result is ".$r."" );
echo( "Closing connection" );
ldap_close( $ds );
} else {
echo( "Unable to connect to LDAP server" );
}
?>
[2005-09-16 21:25:49] [EMAIL PROTECTED]
Obviously the script you provided in your report is not the one you
used to generate that (useless) strace. Can you please show the code
you tried?
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/34533
--
Edit this bug report at http://bugs.php.net/?id=34533&edit=1
[PHP-DOC] #33890 [Opn->Fbk]: Code blocks through documentation look bad in Firefox
ID: 33890 Updated by: [EMAIL PROTECTED] Reported By: nic dot linley at gmail dot com -Status: Open +Status: Feedback -Bug Type: Website problem +Bug Type: Documentation problem Operating System: Windows XP Pro SP2 PHP Version: Irrelevant New Comment: Any example URLs/code blocks that don't look "nice" ? I haven't seen any yet.. Previous Comments: [2005-07-27 21:40:09] nic dot linley at gmail dot com Description: Most of the "code blocks" throughout the documentation php.net have funny widths when viewed in Firefox (1.0.6), causing irritating word wrapping that is difficult if not impossible to read. Looks fine in Internet Explorer. -- Edit this bug report at http://bugs.php.net/?id=33890&edit=1
[PHP-DOC] #33678 [Opn->Bgs]: Install.txt needs modification
ID: 33678 Updated by: [EMAIL PROTECTED] Reported By: jurgen at telebusiness dot net -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: ALL PHP Version: Irrelevant New Comment: Definately not correct way to add the types. Previous Comments: [2005-07-13 14:12:49] jurgen at telebusiness dot net Description: Currently I disagree with this section in INSTALL.TXT: (Recurring in seceral sections !!!) # Add this line inside the conditional brace AddType application/x-httpd-php .php # For syntax highlighted .phps files, also add AddType application/x-httpd-php-source .phps Because: AddType OVERWRITES mimes.types definitions. So don't use Addtype in httpd.conf but change mimes.types with: (append after line application/pgp-signature) application/x-httpd-php php application/x-httpd-php-source phps This works both for windows and unix. -- Edit this bug report at http://bugs.php.net/?id=33678&edit=1
[PHP-DOC] #33628 [Opn->Fbk]: There is a problem in the documentation in non english versions
ID: 33628 Updated by: [EMAIL PROTECTED] Reported By: koby_m at hotmail dot com -Status: Open +Status: Feedback -Bug Type: Website problem +Bug Type: Documentation problem Operating System: windows xp/2000 PHP Version: Irrelevant New Comment: I didn't quite get it..what context..? (picture tells more than thousand words, so provide one? :) Previous Comments: [2005-07-10 08:45:47] koby_m at hotmail dot com Description: When you enter the (Hebrew documentation or any other non english documentation) in the online documentation when you want to click on any page in the context (for example you want to enter the preface ) the text on the link is written in hebrew but when you click on the link it takes you to the english preface page (http://www.php.net/manual/en/preface.php)instead of the hebrew one, and when i go manually to http://www.php.net/manual/he/preface.php the page is there and it's in hebrew as you would expect. Hope you will understand me , if not i will just a screen shot of what happens and what should happen. thanks koby meir. -- Edit this bug report at http://bugs.php.net/?id=33628&edit=1
[PHP-DOC] #33575 [Opn->Asn]: OOP5 "Patterns": Example not a Factory Method
ID: 33575 Updated by: [EMAIL PROTECTED] Reported By: nick dot telford at ntlworld dot com -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant Assigned To: aidan New Comment: Feel free to fix it. FFTFI. :) Previous Comments: [2005-07-05 17:55:32] nick dot telford at ntlworld dot com Description: http://www.php.net/manual/en/language.oop5.patterns.php The first description and example identify the example to be a Factory Method, this is not strictly true, it's a Parameterized Factory Method (sometimes referred to simply as "Factory"), and is a slight derivation of the Factory Method pattern. A pure Factory Method doesn't use parameters to select the class(es) to instanciate, it uses multiple methods and acts slightly differently. Ultra low priority bug report, I know i'm being pedantic, but I felt it was worth reporting anyway. Nicholas Telford -- Edit this bug report at http://bugs.php.net/?id=33575&edit=1
[PHP-DOC] #30185 [Opn->Asn]: Documentation for native interfaces
ID: 30185 Updated by: [EMAIL PROTECTED] Reported By: sigsby at mopo3 dot com -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: NA PHP Version: 5.0.1 -Assigned To: +Assigned To: helly New Comment: Assigned to the SPL maintainer.. :) Previous Comments: [2005-04-05 17:08:37] [EMAIL PROTECTED] Documentation is available at http://www.php.net/~helly/php/ext/spl/ , it should be probably incorporated to the manual. [2004-09-21 20:21:35] sigsby at mopo3 dot com Description: I contacted support about where to find documentation for the PHP 5 native interfaces. Gabor Hojtsy [EMAIL PROTECTED] replied saying that this is supposed to be covered in an appendix in the documentation, but it is apparently not complete. I was asked to open a bug report so the progress of this documentation can be tracked. Here ya go! -- Edit this bug report at http://bugs.php.net/?id=30185&edit=1
[PHP-DOC] #34102 [Opn->Fbk]: Omission in Documentation
ID: 34102 Updated by: [EMAIL PROTECTED] Reported By: mikerob818 at cs dot com -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: Windows 98 PHP Version: Irrelevant New Comment: So what is missing in the docs about this? Providing a clear patch to fix them would be nice.. (URL to the manual page would help too) Previous Comments: [2005-08-12 16:56:13] mikerob818 at cs dot com Description: In reference to your response to Bug Report #34083 PHP Manual: Errors, Inconsistencies, and Omissions I think I have gone through the PHP manual thoroughly but still can't get PHP5 to work with Personal Web Server 4. This is Part 3 of my bug report and I would appreciate a response. Thanks, Robin * Omissions in Documentation Once PHP is installed with Personal Web Server 4 (under Windows 98), when the folder c:\PHP is right clicked to get PHP properties, there is a Web Sharing tab that states "Microsoft Personal Web Server is started". The Share this Folder Option is selected and /Php appears under Aliases. However, trying to execute a simple script like hello.php results in an HTTP 404 File not found condition. In addition, the equivalent in hello.asp will also result in this error. You can only run an asp program under Personal Web Server by selecting Do Not Share this Folder. However, an Error dialogue box will appear that asks: "Disable web sharing of this folder? This action will delete all the aliases for this item." which then results in this error message when trying to run hello.php under Personal Web Server: HTTP Error 403 403.1 Forbidden: Execute Access Forbidden This error can be caused if you are trying to execute a CGI, ISAPI, or other executable program from a directory that does not allow programs to be executed. The PHP documentation does not address these problems with Personal Web Server. You need to discuss whether it is possible to run both PHP and ASP under Personal Web Server and how this can be done without getting a file not found condition. -- Edit this bug report at http://bugs.php.net/?id=34102&edit=1
[PHP-DOC] #34098 [Opn->Fbk]: windows's PWS install instructions may need update
ID: 34098 Updated by: [EMAIL PROTECTED] Reported By: mikerob818 at cs dot com -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: Windows 98 PHP Version: Irrelevant New Comment: What manual page is this? URL? Previous Comments: [2005-08-12 16:16:00] mikerob818 at cs dot com Description: In reference to your response to Bug Report #34083 PHP Manual: Errors, Inconsistencies, and Omissions I think I have gone through the PHP manual thoroughly but still can't get PHP5 to work with Personal Web Server 4. This is Part I of my bug report and I would appreciate a response. Thanks, Robin Documentation Error Microsoft IIS / PWS Windows and PWS 4 PWS 4 does not support ISAPI, only PHP CGI should be used. · In the PWS Manager, right click on a given directory you want to add PHP support to, and select Properties. Check the 'Execute' checkbox, and confirm. The instruction should be: In Personal Web Manager: Click View> Advanced Click Edit Properties Check Execute checkbox Click OK -- Edit this bug report at http://bugs.php.net/?id=34098&edit=1
[PHP-DOC] #34026 [Ver]: Polish CHM is corrupted
ID: 34026 Updated by: [EMAIL PROTECTED] Reported By: kamil dot figiela at gmail dot com Status: Verified Bug Type: Documentation problem Operating System: WinXP PHP Version: Irrelevant New Comment: Still broken. Previous Comments: [2005-08-07 16:11:02] kamil dot figiela at gmail dot com Description: Polish CHM is corrupted, file length is only 440 KB, while other CHM's are 6 MB -- Edit this bug report at http://bugs.php.net/?id=34026&edit=1
[PHP-DOC] #33075 [Opn->Asn]: [NL] Typo in Dutch Documentary
ID: 33075 Updated by: [EMAIL PROTECTED] Reported By: william at wjbakker dot com -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: Win2000 Prof PHP Version: Irrelevant -Assigned To: +Assigned To: derick New Comment: Derick, you're the only dutchie I know. :) Previous Comments: [2005-05-20 11:10:17] william at wjbakker dot com Description: Type error on: http://nl2.php.net/manual/nl/function.chunk-split.php Latest lines says: "Ziek ook" should be "Zie ook" Error only appears on this specific page. Reproduce code: --- Ziek ook http://nl2.php.net/manual/nl/function.chunk-split.php Expected result: "Ziek ook" Actual result: -- "Ziek ook" -- Edit this bug report at http://bugs.php.net/?id=33075&edit=1
[PHP-DOC] #33213 [Opn->Ver]: Documentation redirection
ID: 33213 Updated by: [EMAIL PROTECTED] Reported By: mvl22 at mailinator dot com -Status: Open +Status: Verified Bug Type:Documentation problem PHP Version: Irrelevant New Comment: It doesn't take me to any hyperwave funcs page, but it sure does not go to the right page either. Previous Comments: [2005-06-01 17:16:52] mvl22 at mailinator dot com Description: http://php.net/:: takes the user (inexplicably) to the Hyperwave functions page rather than the Scope Resolution Operator (::) [Paamayim Nekudotayim] page language.oop5.paamayim-nekudotayim.html -- Edit this bug report at http://bugs.php.net/?id=33213&edit=1
[PHP-DOC] #32548 [Csd->Opn]: rsync.php.net connection is refused
ID: 32548 Updated by: [EMAIL PROTECTED] Reported By: david at mytton dot net -Status: Closed +Status: Open -Bug Type: DocWeb problem +Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: This section in the HOWTO for documenting PHP is totally out-of-date. I'd guess the whole thing needs a rewrite.. Previous Comments: [2005-09-20 20:38:10] [EMAIL PROTECTED] Fixed in the howto. [2005-09-20 16:18:24] [EMAIL PROTECTED] The doc howto is simply wrong, there is no such thing. [2005-09-20 15:55:21] [EMAIL PROTECTED] James, fix this. [2005-04-02 22:21:35] david at mytton dot net Description: When trying to access http://rsync.php.net/ I get an error: Connection was refused This is linked from the PHP Doc documentation at http://doc.php.net/php/dochowto/chapter-online-generation.php Expected result: It should load the website Actual result: -- Error: Connection was refused -- Edit this bug report at http://bugs.php.net/?id=32548&edit=1
[PHP-DOC] #32548 [Opn->Csd]: rsync.php.net connection is refused
ID: 32548 Updated by: [EMAIL PROTECTED] Reported By: david at mytton dot net -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: The specific section is fixed in CVS. Previous Comments: [2005-09-20 21:19:42] [EMAIL PROTECTED] This section in the HOWTO for documenting PHP is totally out-of-date. I'd guess the whole thing needs a rewrite.. [2005-09-20 20:38:10] [EMAIL PROTECTED] Fixed in the howto. [2005-09-20 16:18:24] [EMAIL PROTECTED] The doc howto is simply wrong, there is no such thing. [2005-09-20 15:55:21] [EMAIL PROTECTED] James, fix this. [2005-04-02 22:21:35] david at mytton dot net Description: When trying to access http://rsync.php.net/ I get an error: Connection was refused This is linked from the PHP Doc documentation at http://doc.php.net/php/dochowto/chapter-online-generation.php Expected result: It should load the website Actual result: -- Error: Connection was refused -- Edit this bug report at http://bugs.php.net/?id=32548&edit=1
[PHP-DOC] #26902 [Opn->Asn]: [chm] Right to left in hebrew at CHM file.
ID: 26902 Updated by: [EMAIL PROTECTED] Reported By: webmaster at bubbles dot co dot il -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: win32 PHP Version: Irrelevant -Assigned To: +Assigned To: derick Previous Comments: [2004-01-14 09:17:43] [EMAIL PROTECTED] It is for me... [2004-01-14 07:32:39] webmaster at bubbles dot co dot il Description: I downloaded you refrence of the php in herbrew (chm file). The direction of the text need to be right-to-left and not left-to-right. -- Edit this bug report at http://bugs.php.net/?id=26902&edit=1
[PHP-DOC] #27334 [Opn]: clone keyword vs __clone
ID: 27334 Updated by: [EMAIL PROTECTED] Reported By: trancer at trancer dot nl Status: Open -Bug Type:Website problem +Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Reclassified as documentation problem, that information SHOULD be in the manual! Previous Comments: [2004-02-23 03:09:44] [EMAIL PROTECTED] Reclassifying as a php.net website problem as the zend-engine-2.php file is under phpweb/. [2004-02-20 14:56:12] trancer at trancer dot nl Description: Had the following: fatal error: Cannot call __clone() method on objects - use 'clone $obj' instead. Dig some digging, stumbled upon http://www.php.net/ChangeLog-5.php mentioning the following: "Redesigned clone by adding a clone keyword (clone $obj) and copying all properties before __clone() is called. Also allows calling parent __clone function by using parent::__clone(). (Zeev, Andi)" However the document http://www.php.net/zend-engine-2.php is in conflict with this mentioning a lot about __clone() "An object copy is created by calling the object's __clone() method:" Please fix the zend-engine-2 documentation. -- Edit this bug report at http://bugs.php.net/?id=27334&edit=1
[PHP-DOC] #34612 [Opn]: LC_MESSAGES is not documented on the setlocale Documentation Page
ID: 34612 Updated by: [EMAIL PROTECTED] Reported By: timo dot hummel at 4fb dot de Status: Open Bug Type: Documentation problem Operating System: irrelevant PHP Version: Irrelevant New Comment: Also note: LC_MESSAGES is _not_ available on all platforms! Previous Comments: [2005-09-23 13:30:25] timo dot hummel at 4fb dot de Description: The Documentation for setlocale misses a description for the LC_MESSAGES constant. http://www.php.net/setlocale -- Edit this bug report at http://bugs.php.net/?id=34612&edit=1
[PHP-DOC] #34612 [Opn->Ver]: LC_MESSAGES is not documented on the setlocale Documentation Page
ID: 34612 Updated by: [EMAIL PROTECTED] Reported By: timo dot hummel at 4fb dot de -Status: Open +Status: Verified Bug Type: Documentation problem Operating System: irrelevant PHP Version: Irrelevant Previous Comments: [2005-09-23 15:03:37] [EMAIL PROTECTED] Also note: LC_MESSAGES is _not_ available on all platforms! [2005-09-23 13:30:25] timo dot hummel at 4fb dot de Description: The Documentation for setlocale misses a description for the LC_MESSAGES constant. http://www.php.net/setlocale -- Edit this bug report at http://bugs.php.net/?id=34612&edit=1
[PHP-DOC] #34653 [Asn]: No documentation for OCI-Lob->savefile and OCI-Lob->writetofile
ID: 34653 Updated by: [EMAIL PROTECTED] Reported By: cjbj at hotmail dot com Status: Assigned -Bug Type: +Bug Type: Documentation problem Operating System: n/a PHP Version: 6CVS-2005-09-27 (CVS) Assigned To: tony2001 New Comment: Classified. Interesting. How did you manage to submit a bug without a category? Or did tony somehow remove it? :) Previous Comments: [2005-09-27 08:36:00] cjbj at hotmail dot com Description: Documentation for OCI-Lob->savefile and OCI-Lob->writetofile is not in http://www.php.net/manual/en/ These methods are visible in the oci8.c file in CVS, http://www.php.net/manual/en/function.oci-new-descriptor.php OCI-Lob->savefile is also used in Example 1 of http://www.php.net/manual/en/function.oci-new-descriptor.php -- Edit this bug report at http://bugs.php.net/?id=34653&edit=1
[PHP-DOC] #30915 [Opn->Asn]: User Contributed Notes on docs.php.net
ID: 30915 Updated by: [EMAIL PROTECTED] Reported By: sean at caedmon dot net -Status: Open +Status: Assigned Bug Type: Livedocs problem Operating System: n/a PHP Version: Irrelevant Assigned To: derick Previous Comments: [2005-01-24 19:30:54] [EMAIL PROTECTED] I haven't looked at the orphaned notes script, I will. I was just planning on grabbing the livedocs DB daily, from docs.php.net. If this is easily solved in other ways, then sure, I'll use them. That's another discussion, though. I'd still like to see user-notes on docs.php.net. S [2005-01-24 19:23:33] [EMAIL PROTECTED] But why do you need a DB with the notes? Anyway, you have all the notes in the docweb server, because of the orphan notes' script. I've also implemented in livedocs a method to retrieve the notes without the "misterious key". (configure --with-notes-mirror=us3). [2005-01-24 16:48:38] [EMAIL PROTECTED] I said "would be nice", but once this is working, I'll be able to port my (currently broken) notes manager over to docweb (ie, I have a stronger "want" for this). Yes, I could use someone else's notes database (ie, mine), now, but I'd like to grab an "official" one. S [2004-11-26 16:29:18] sean at caedmon dot net Description: Would be nice to get user notes working on http://docs.php.net/ (Spoke to Derick, already. He didn't seem to think it was a problem, but requested a reminder.) S -- Edit this bug report at http://bugs.php.net/?id=30915&edit=1
[PHP-DOC] #34683 [Opn->Ver]: get_browser ignores $_SERVER['HTTP_USER_AGENT'] setting
ID: 34683 Updated by: [EMAIL PROTECTED] Reported By: skissane at gmail dot com -Status: Open +Status: Verified -Bug Type: Unknown/Other Function +Bug Type: Documentation problem -Operating System: Linux (FC4) +Operating System: Irrelevant -PHP Version: 5.0.5 +PHP Version: Irrelevant New Comment: It does use the HTTP_USER_AGENT. But it does not use it from $_SERVER['HTTP_USER_AGENT'], this is a documentation error. (you can't just change any pre-set $_SERVER values!) You need to pass the function the different browser agent string if you think the one found in $_SERVER['HTTP_USER_AGENT'] isn't correct. Previous Comments: [2005-09-30 10:12:22] skissane at gmail dot com Sniper, what renders this "bogus"? The docs imply it behaves a certain way... and it doesn't. Either the docs are wrong or the code is wrong -- either way there is a bug. [2005-09-30 10:07:30] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. [2005-09-30 07:52:01] skissane at gmail dot com Description: According to the docs "By default, the value of $_SERVER['HTTP_USER_AGENT'] is used". However, setting this to a different value does not change the output of get_browser with no arguments. Indeed, under CLI SAPI, HTTP_USER_AGENT is not set initially, and even if you set it by hand before calling get_browser() it still gives an error that it is not set. Reproduce code: --- Run from CLI SAPI: http://bugs.php.net/?id=34683&edit=1
[PHP-DOC] #20557 [Fbk->NoF]: pg_lo_export will not take 3 parameters
ID: 20557 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Documentation problem Operating System: freebsd 4.7-RELEASE PHP Version: 4.2.3 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2002-11-22 05:00:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-21 20:33:47] [EMAIL PROTECTED] the documentation lists a resource connection as a third optional parameter to pg_lo_export. when this is supplied, a "wrong parameter count" error is displayed. './configure' '--with-apxs=/home/httpd/apache/bin/apxs' '--enable-versioning' '--with-pgsql=/usr/local' '--enable-shmop' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-mbstring' '--with-gd' '--with-mbstr-enc-trans' '--enable-inline-optimization' -- Edit this bug report at http://bugs.php.net/?id=20557&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20836 [Opn]: sybase_fetch_assoc & mssql_fetch_assoc missing
ID: 20836 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Sybase (dblib) related +Bug Type: Documentation problem Operating System: Linux PHP Version: 4.3.0RC2 New Comment: The sybase_fetch_assoc() exists in sybase-ct extension only. The documentation is a bit confusing though. Previous Comments: [2002-12-05 14:12:30] [EMAIL PROTECTED] mssql_fetch_assoc has been added to PHP with version 4.2.1 according to www.php.net However, when porting code to linux this function seems to be missing, most probably there is no function sybase_fetch_assoc. -- Edit this bug report at http://bugs.php.net/?id=20836&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20695 [Opn]: substr does not always return a string
ID: 20695
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Feature/Change Request
+Bug Type: Documentation problem
Operating System: Windows 98
PHP Version: 4.2.3
New Comment:
This script shows clearly what happens:
Output:
string(1) "A"
string(0) ""
bool(false)
bool(false)
And this is quite correct and expected behaviour.
Documentation though should mention that invalid start position and
length will make it return FALSE.
Previous Comments:
[2002-12-09 05:18:24] [EMAIL PROTECTED]
Hi Jan,
thanks for you reply! I have tried the snapshot
(for Windows) that you pointed me to. The program
works as you say - which IMHO is a bug.
The output is - as you mention:
1
substr("A",0,1):1
substr("A",0,0):1
substr("A",1,1):
substr("A",1,0):
This means that substr("A",1,1) and substr("A",1,0) are both
not strings. Therefore substr does _not_ always return a string.
If this is considered correct, then it should be mentioned in
the documentation.
Personally, I would prefer this to be considered
incorrect: I would prefer substr($s,$n,$m) to always return a string,
at least if $s is a string and $n and $m are integers.
Please either improve the documentation or make substr($s,$n,$m)
always return a string (at least if $s is a string and $n and $m are
integers).
Thanks for putting this PHP together. It is a great means to produce
results quickly!
Cheers,
Raimund
[2002-12-08 10:20:23] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2002-11-28 04:49:32] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
jan@dahlia ~> php bug_20695.php
1
substr("A",0,1):1
substr("A",0,0):1
substr("A",1,1):
substr("A",1,0):
jan@dahlia ~> php -v
PHP 4.4.0-dev (cli)
works fine here
[2002-11-28 04:45:55] [EMAIL PROTECTED]
substr($s,$n,$m) is supposed to always return a string (at least if $s
is a string and $n and $m are integers).
However:
is_string(substr($s,strlen($s),$m))
returns false, so substr did not return a string.
Example:
echo is_string("")."\n";
echo "substr(\"A\",0,1):".is_string(substr("A",0,1))."\n";
echo "substr(\"A\",0,0):".is_string(substr("A",0,0))."\n";
echo "substr(\"A\",1,1):".is_string(substr("A",1,1))."\n";
echo "substr(\"A\",1,0):".is_string(substr("A",1,0))."\n";
[2002-11-28 04:40:53] [EMAIL PROTECTED]
substr($s,$n,$m) is supposed to always return a string (at least if $s
is a string and $n and $m are integers).
However:
is_string(substr($s,strlen($s),$m))
returns false, so substr did not return a string.
Example:
$s="";
echo is_string("")."\n";
echo "substr(\"A\",0,1):".is_string(substr("A",0,1))."\n";
echo "substr(\"A\",0,0):".is_string(substr("A",0,0))."\n";
echo "substr(\"A\",1,1):".is_string(substr("A",1,1))."\n";
echo "substr(\"A\",1,0):".is_string(substr("A",1,0))."\n";
--
Edit this bug report at http://bugs.php.net/?id=20695&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20695 [Opn->Bgs]: substr does not always return a string
ID: 20695
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Documentation problem
Operating System: Windows 98
PHP Version: 4.2.3
New Comment:
..and that's what the docs say too.. :)
Previous Comments:
[2002-12-09 05:43:38] [EMAIL PROTECTED]
This script shows clearly what happens:
Output:
string(1) "A"
string(0) ""
bool(false)
bool(false)
And this is quite correct and expected behaviour.
Documentation though should mention that invalid start position and
length will make it return FALSE.
[2002-12-09 05:18:24] [EMAIL PROTECTED]
Hi Jan,
thanks for you reply! I have tried the snapshot
(for Windows) that you pointed me to. The program
works as you say - which IMHO is a bug.
The output is - as you mention:
1
substr("A",0,1):1
substr("A",0,0):1
substr("A",1,1):
substr("A",1,0):
This means that substr("A",1,1) and substr("A",1,0) are both
not strings. Therefore substr does _not_ always return a string.
If this is considered correct, then it should be mentioned in
the documentation.
Personally, I would prefer this to be considered
incorrect: I would prefer substr($s,$n,$m) to always return a string,
at least if $s is a string and $n and $m are integers.
Please either improve the documentation or make substr($s,$n,$m)
always return a string (at least if $s is a string and $n and $m are
integers).
Thanks for putting this PHP together. It is a great means to produce
results quickly!
Cheers,
Raimund
[2002-12-08 10:20:23] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2002-11-28 04:49:32] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
jan@dahlia ~> php bug_20695.php
1
substr("A",0,1):1
substr("A",0,0):1
substr("A",1,1):
substr("A",1,0):
jan@dahlia ~> php -v
PHP 4.4.0-dev (cli)
works fine here
[2002-11-28 04:45:55] [EMAIL PROTECTED]
substr($s,$n,$m) is supposed to always return a string (at least if $s
is a string and $n and $m are integers).
However:
is_string(substr($s,strlen($s),$m))
returns false, so substr did not return a string.
Example:
echo is_string("")."\n";
echo "substr(\"A\",0,1):".is_string(substr("A",0,1))."\n";
echo "substr(\"A\",0,0):".is_string(substr("A",0,0))."\n";
echo "substr(\"A\",1,1):".is_string(substr("A",1,1))."\n";
echo "substr(\"A\",1,0):".is_string(substr("A",1,0))."\n";
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/20695
--
Edit this bug report at http://bugs.php.net/?id=20695&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20739 [WFx->Ana]: parentheses surrounding return()'s arguments do seem to matter
ID: 20739
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Won't fix
+Status: Analyzed
-Bug Type: Scripting Engine problem
+Bug Type: Documentation problem
Operating System: All
PHP Version: 4.3.0-dev/4.4.0-dev
New Comment:
The docs say different thing:
"Note: Note that since return() is a language construct and not a
function, the parentheses surrounding its arguments are not
required--in fact, it is more common to leave them out than to use
them, although it doesn't matter one way or the other. "
This is not true, according to Andi..
Previous Comments:
[2002-12-09 06:41:21] [EMAIL PROTECTED]
You are right they do matter. When you're putting paratheses you're
telling the engine that this is an expression with a possible value
(e.g. (3+2) ) and not a variable.
[2002-11-30 16:00:59] [EMAIL PROTECTED]
In addition to returning the wrong value the code produces a number of
memory leaks that are listed below.
/home/rei/PHP_CVS/php4/Zend/zend_execute.c(468) : Freeing 0x084F7E24
(12 bytes), script=r.php
/home/rei/PHP_CVS/php4/Zend/zend_hash.c(262) : Freeing 0x084F7DCC (40
bytes), script=r.php
Last leak repeated 1 time
/home/rei/PHP_CVS/php4/Zend/zend_hash.c(178) : Freeing 0x084FCBF4 (32
bytes), script=r.php
Last leak repeated 1 time
/home/rei/PHP_CVS/php4/Zend/zend_execute.c(1692) : Freeing 0x084FCB94
(44 bytes), script=r.php
/home/rei/PHP_CVS/php4/Zend/zend_variables.c(135) : Actual location
(location was relayed)
Last leak repeated 1 time
/home/rei/PHP_CVS/php4/Zend/zend_execute.c(471) : Freeing 0x084F96FC
(4 bytes), script=r.php
/home/rei/PHP_CVS/php4/Zend/zend_variables.c(111) : Actual location
(location was relayed)
/home/rei/PHP_CVS/php4/Zend/zend_execute.c(479) : Freeing 0x084F96BC
(12 bytes), script=r.php
/home/rei/PHP_CVS/php4/Zend/zend_execute.c(1986) : Freeing 0x084F960C
(44 bytes), script=r.php
/home/rei/PHP_CVS/php4/Zend/zend_API.c(565) : Actual location (location
was relayed)
[2002-11-30 15:37:53] [EMAIL PROTECTED]
I'm using PHP 4.2.3 on Windows NT 5.0 build 2195 (win2k)
along with Apache and stumbled across a strange behaviour
regarding return() arguments in parentheses.
Consider the following code:
class Node {
var $children;
var $name;
function Node($name) {
$this->children = array();
$this->name = $name;
}
function &add($n) {
$this->children[0] = $n;
return($this->children[0]); # these () make a difference
}
}
$t = new Node("top");
$node = new Node("foo");
$n = &$t->add($node);
$n->name = "bar";
print $n->name; # output: "bar"
print $t->children[0]->name; # output: "foo"
The code is working as expected (i.e., both times
"bar" is printed) when you remove the
parentheses from the return call in the add method.
According to the manual, parentheses in a return
call shouldn't make a difference.
--
Edit this bug report at http://bugs.php.net/?id=20739&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20905 [Opn->Ana]: exec() vs file() with newlines
ID: 20905
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
-Bug Type: Filesystem function related
+Bug Type: Documentation problem
Operating System: linux
PHP Version: 4.2.2
New Comment:
Reclassified.
The manual page for 'file()' does mention this.
But it should be mentionaed for 'exec()' too..(the optional array
output parameter..)
Previous Comments:
[2002-12-09 07:25:48] [EMAIL PROTECTED]
This is just basically an inconsistency between file() and exec()
file() will return the newline on the end of each element in the array,
ie:
$data = file("somefile.txt");
$data[0][ strlen($data[0])-1 ] == "\n"
but exec() doesn't put newlines on it's output:
exec("soemthing", $data);
$data[0][ strlen($data[0])-1 ] != "\n"
At the least, the manual page for file() and/or exec() should state
this behaviour.
--
Edit this bug report at http://bugs.php.net/?id=20905&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21630 [Opn]: imageCreateFromGIF doesn't work
ID: 21630 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Linux 2.4.20 PHP Version: 4.3.0 New Comment: http://www.boutell.com/gd/manual2.0.10.html "Pixel values are only interpolated if the destination image is a truecolor image. Otherwise, gdImageCopyResized is automatically invoked. " (doesn't this mean that it's a bug in GD library itself?) Previous Comments: [2003-01-14 14:00:08] [EMAIL PROTECTED] Hello, I confirm (if necessary) the Derick's comment. This a problem due to palette images limitations (255+1 colors). Resampling or filtering an image needs commonly more colors than 255, a kind of approximation is used to calc the new resampled pixel and its color, with a palette image we try to allocate a new color, if that failed, we choose the closest (in theory), the closest computed color is not always the closest visual color. That produces weird result, like blank (or visually blank) images. You can reproduce this problem with imagerotate used with a palette image (imagecreate), allocate 3 colors, draw 2 differents boxes, and rotate the image with a custom angle (not a quarter angle), you will get a blank image or near blank. Hope that helps, pierre [2003-01-14 13:32:25] [EMAIL PROTECTED] Should be documented (better) then. Derick [2003-01-14 13:20:41] [EMAIL PROTECTED] I've managed to resolve this, it's not a bug with the ImageCreateFromGIF function, but the ImageCopyResampled, the blank image needs to be created with ImageCreateTrueColor or the resultant image is blank. Not sure whether this becomes a bogus bug or whether the real issue is with ImageCopyResampled? In fact, I've just looked at the user notes for ImageCopyResampled and people are saying there to use Truecolor. [2003-01-14 05:33:10] [EMAIL PROTECTED] Just to confirm, I just checked in phpinfo, and I am using the bundled GD (you made me wonder whether I had built php correctly). [2003-01-14 05:19:12] [EMAIL PROTECTED] tar located at http://support.brendata.co.uk/phpbug21630.tgz can be run from the command line. 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/21630 -- Edit this bug report at http://bugs.php.net/?id=21630&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21388 [Fbk->Opn]: [chm] bug on streams.php-stream-open-wrapper-ex.html
ID: 21388 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Documentation problem Operating System: windows PHP Version: 4.3.0 New Comment: I guess the streams docs are still on Wez's TODO? :) Previous Comments: [2003-01-03 07:24:58] [EMAIL PROTECTED] ignore my last message... it's a mistake! [2003-01-03 07:23:38] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2003-01-03 07:15:28] [EMAIL PROTECTED] Manual description: "php_stream_open_wrapper_ex() is exactly like php_stream_open_wrapper(), but allows you to specify a php_stream_context object using context. To find out more about stream contexts, see XXX" Ok, now I see that "XXX" is a number in manual's Function Reference. It looks pretty wired for me for a first time. Any other Roman number is ok, but XXX looks like "thing that should be filled in later" . Thing for discussion : Shouldn't it be a link to the XXX part of manual ? Or instead of "see XXX" -> "see XXX part of Function Reference" ? BTW. PHP manual is a great job :) [2003-01-03 06:57:30] [EMAIL PROTECTED] I am afraid I cannot see the point. What is the bug? [2003-01-03 06:15:22] [EMAIL PROTECTED] I have found a bug on page streams.php-stream-open-wrapper-ex.html which is : To find out more about stream contexts, see XXX [chm date: 2002-12-27]... -- Edit this bug report at http://bugs.php.net/?id=21388&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #16111 [Opn]: IIS/CGI only gives "Security Alert! PHP CGI cannot be accessed directly."
ID: 16111
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: PWS related
+Bug Type: Documentation problem
Operating System: Windows
PHP Version: 4.2.1
New Comment:
This is still a documentation problem, document that people should
check their php.ini is actually read by PHP.
Previous Comments:
[2003-01-18 15:17:01] [EMAIL PROTECTED]
This still looks like a problem to me, am marking as a PWS problem
until resolved.
Also it's important to know the correct php.ini is being edited as this
seems to be the cause of many peoples problems. So before reporting
information to this bug report, please be sure to state where phpinfo()
says it is.
If a PWS expert knows this is still a documentation problem, please
reclassify with an explanation.
[2003-01-16 20:56:50] [EMAIL PROTECTED]
win 98SE, PWS, PHP4.3.0 installbinary. ME TOO! read everything I can
find - no solution
1. PWS installed and working
2. run install shield for PHP4.3.0 normal install
(also did manual install forcing PWS etc.)
3. build simple hello.php put in root of PWS directories
4. 'Execute' is checked for that folder
5. useing browser - link/get/select hello.php
6. get same BUG. error "Security Alert... (seems PHP is trying!)
7. Changed cgi.force_redirect = 0 in PHP.ini (in c:/windows)
8. bug changed. Now the hello.php script just shows up as html text
i.e. the is not executed. (seems PHP is not being accessed
or pulled into the game)
9. because symptoms changed PHP IS reading the php.ini file - it is not
in the wrong directory. so all fixes listed so far will not work.
This is definitly a showstopper for many.
I think that setting cgi.force_redirect = 0 is somehow resulting in the
PWS not knowing where to look for the PHP.exe or something like that
but what do I know. A documentation FIX that works would be nice.
Also there seems to be different fixes for IIS and PWS and the docs are
not clear which fix for which.
[2002-12-07 06:53:50] [EMAIL PROTECTED]
Hello shelley
win2000 + iis + php
I had the same problem with header("Location) redirects.
And I don't have a solution only have one ugly code to do the same...
echo "
document.location.href=$url";
I hope change this code on the future, when somebody will have a
solution.
DJF
[2002-11-10 04:07:00] [EMAIL PROTECTED]
I too had the same problem. I read that I had to set
cgi.force_redirect=0 I did this and nothing happened. I tried
everything, only to find out that my php.ini file was not in c:\winnt
like the docs said they it would be. No the binary distro put it in
c:\documents and settings\administrator\windows I copied that file to
c:\winnt and the php part is working.
[2002-08-26 17:32:53] [EMAIL PROTECTED]
I read bug this bug and have changed my security setting on IIS and it
makes
no difference. I'm also using Zend, Smarty & ADODB. In addition I'm
running on a pentium 4. I am
having major problems in our login program and took the code out into
a
seperate test problem, and am still having the same redirect problems.
I have been checking the Forums in the PHP community for the last week
and
find this seems to be a problem. I've tested the following code and it
only will re-direct 1 time out of 5 or 6 times, of executing the
code(with
no code changes). It gives an error message the other times.
Here is my test program:
http://bugs.php.net/16111
--
Edit this bug report at http://bugs.php.net/?id=16111&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20814 [Ver->Ana]: reproducable, freaky parse error in 'here document' structure
ID: 20814 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Analyzed -Bug Type: Scripting Engine problem +Bug Type: Documentation problem Operating System: all PHP Version: 4.4.0-dev New Comment: This has been documented but it could also mention, that if the end tag of heredoc is not 'clean', ie. it's not exactly 'heredoc;' like in the example above, then it is NOT considered the end tag. ZE will ignore it and continued looking for the end tag.. and as it is not found, there will be a parse error, with line number being the last line of the script. Previous Comments: [2002-12-04 14:58:11] [EMAIL PROTECTED] To clarify the line mismatch: AFAIK it's the same as a missing '}' in if/else. It will report on the __last__ expected '}', while the error will intuitively start on the __first__ unclosed '}'. The '$' is 'end' as in regexps. [2002-12-04 11:24:55] [EMAIL PROTECTED] To clarify a few points: a) This is known and is both documented and is a current feature request: http://bugs.php.net/bug.php?id=8685 http://www.php.net/language.types.string#language.types.string.syntax.heredoc b) The error that's reported is odd, and looks something like this: Parse error: parse error, unexpected $ in test.php on line 42 Where 42 is, for example, on the last line of test.php even when the error is elsewhere. This error sorta makes sense in most cases (like a missing quote or closing brace) but IMHO not here. Maybe someone can briefly explain what PHP is thinking. c) Many have attempted to fix this and many more have reported it (a) but it appears to be almost impossible to fix and remains a feature request. Again, it is documented with a big fat warning. Am leaving as open as this mentions the strange error too (b), not just the known feature request. [2002-12-04 11:23:05] [EMAIL PROTECTED] [quick on the trigger]... scratch that last sentence ... I was going to point out that the closing tag has to be flush left but I think that is not a bug. [2002-12-04 11:04:39] [EMAIL PROTECTED] I've tested this on PHP 4.2.3 for OSX, Open BSD, Linux... If you leave any whitespace after the closing tag of a here document structure (not sure if that's what it is called, like in Perl) a parse error will occur but never for the correct line. This seems like a bug to me because a semi- colon should terminate the code allowing the programmer to put comments or whatever after the semi-colon. Here is an example: $variable = "variable"; $someVariable = << text text $variable testing here document hereDocument; // closing comment or just whitespace echo $someVariable; After the closing "hereDocument;" if you leave any whitespace (other than a carriage return) or text, a parse error is generated but the line number never leads you to the right place. This can be very confusing if you are working on a large class (like I was) and you left a tab or space after a closing tag. I'm not sure how consciously supported the here document structure is but this is worth addressing since here documents can be very useful for storing large variables containing HTML code with double and single quotes, for example. While I'm submitting this bug, I might as well point -- Edit this bug report at http://bugs.php.net/?id=20814&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21813 [Opn]: OCIFetchInto() requires array result passed by reference
ID: 21813 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: OCI8 related +Bug Type: Documentation problem Operating System: Windows 2000 SP3 PHP Version: 4.2.3 New Comment: Explained Philip on IRC why this really is a documentation problem.. :) Previous Comments: [2003-01-21 22:18:42] [EMAIL PROTECTED] Considering this function relies on a deprecated feature, this a bug in OCIFetchInto() itself. Reclassified->Oci8 related. >From the docs for allow_call_time_pass_reference: "This method is deprecated and is likely to be unsupported in future versions of PHP/Zend." Also does @ suppress these type of warnings? [2003-01-21 20:34:54] [EMAIL PROTECTED] Currently, as of 1/21/03, the documentation states that the result array used with OCIFetchInto() must be passed by reference. Since this has changed after 4.2.0(?) and is not required (generating warnings), the documentation should be updated to explain which particular version(s) will see this phenomenon, especially for those who are upgrading or testing against multiple versions. I understand that a note has been included by a user about this problem, but the note is not clear on the versions affected or when the change was made. I am using PHP Version 4.2.3 on System Windows NT 5.0 build 2195 in CGI mode only loading the php_oci8.dll module. -- Edit this bug report at http://bugs.php.net/?id=21813&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21885 [Opn]: move_uploaded_file error with open_basedir
ID: 21885 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Filesystem function related +Bug Type: Documentation problem Operating System: Windows XP - IIS PHP Version: 4.3.0 New Comment: This was changed because of this bug: http://bugs.php.net/bug.php?id=16128&edit=1 And it will stay. Reclassified as documentation prob. Previous Comments: [2003-01-27 17:11:21] [EMAIL PROTECTED] yes - i have the same problem with php running as cgi in windows 2000 pro with IIS. it used to work just fine, but now with 4.3.0 i get the same error. it seems like this is a bug, because the documentation specifically says: move_uploaded_file() is not affected by the normal safe-mode UID-restrictions. This is not unsafe because move_uploaded_file() only operates on files uploaded via PHP. even though open_basedir is not safe_mode i think the same logic should apply! meanwhile i'll just add the temp dir to open_basedir is a quickfix. [2003-01-27 15:35:20] [EMAIL PROTECTED] Yeah this behavior has changed, it didn't do this in 4.2.3. It seems like it *used to* bypass the open_basedir check when using move_uploaded_file on a file in upload_tmp_dir. Or rather, it added one's upload_tmp_dir to open_basedir automatically (bug 17488). Could someone comment as to whether or not this is a permanent change, and if so, perhaps document it somewhere on php.net? (FreeBSD 4.6-STABLE Apache/1.3.27 PHP/4.3.0 apxs, safe_mode=Off) [2003-01-27 06:36:28] [EMAIL PROTECTED] no that is my writing fault on this submission :) [2003-01-27 05:25:48] [EMAIL PROTECTED] missing _ in open_basedir ? [2003-01-26 05:01:33] [EMAIL PROTECTED] i've a script that worked well with 4.2.2, this scripts makes an upload my ini is set to: open basedir=. ; File Uploads ; ; Whether to allow HTTP file uploads. file_uploads = On ; Temporary directory for HTTP uploaded files (will use system default if not ; specified). upload_tmp_dir ="c:\temp\php-uploads" ; Maximum allowed size for uploaded files. upload_max_filesize = 6M my script does simply: move_uploaded_file($_FILES['new_file_file']['tmp_name'], $this->path.$this->filename); in my class... it gives me: Warning: move_uploaded_file() [function.move-uploaded-file.html]: open_basedir restriction in effect. File(c:\temp\php-uploads\phpD.tmp) is not within the allowed path(s): (.) in C:\neoportal\modules\mediaalbum\mediafile_class.php on line 95 it seems that a open_basedir check is made on the source file and not only on the destination file. the file is correctly uploaded to c:\temp\php-uploads\phpD.tmp but not moved to dest folder (that is a subfolder of current dir so it's in the allowed path) The same error is in PHPMYADMIN 2.3.3pl1 when i try to upload a file .sql Adding the c:\temp\ path to open basedir as ".;c:\temp\" doesn't help -- Edit this bug report at http://bugs.php.net/?id=21885&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21927 [Opn->Ana]: PHP crashes upon trying to access .php page.
ID: 21927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed -Bug Type: Reproducible crash +Bug Type: Documentation problem Operating System: Windows 95 PHP Version: 4.3.0 New Comment: Since PHP 4.3.0 were not supporting win95 anymore. phpdoc-team: the documentation should be fixed by removing any links to win95 and also there should be some note somewhere about this too..installation page maybe? (I wasn't aware of this before I asked Edin..) Previous Comments: [2003-01-28 16:31:50] [EMAIL PROTECTED] Every .php page that I try to run crashes with this pop up dialog error message: "The PHP.EXE file is linked to missing export KERNEL32.DLL:Cancello." The above dialog box has the title "Error Starting Program" showing and requires three clicks on OK to close. I'm running Apache 1.3.27 on Windows 95 and have no problem with PHP 4.0.3pl1 which works fine. I've tried scripts as simple as "" to no avail. -- Edit this bug report at http://bugs.php.net/?id=21927&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21981 [Csd]: MYSQL_CLIENT_SSL constant is undefined
ID: 21981 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Documentation problem Operating System: Windows NT 5.1 PHP Version: 4CVS-2003-01-31 (stable) New Comment: It's only available if PHP's mysql extension is build against mysql 4 client libs..which is not the case for win32 binaries, AFAIK. (the bundled mysql libs are 3.23.49) Previous Comments: [2003-01-31 11:12:46] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Thx for the hint. MySQL-SSL Support will be available in PHP 5.0 [2003-01-31 10:43:22] [EMAIL PROTECTED] Of course I meant SSL :o) Changed category to "Documentation problem" [2003-01-31 10:40:44] [EMAIL PROTECTED] No, it's still in. Please follow the link mentioned above. There you'll find this passage: The client_flags parameter can be a combination of the constants MYSQL_CLIENT_SSL, MYSQL_CLIENT_COMPRESS, MYSQL_CLIENT_IGNORE_SPACE or MYSQL_CLIENT_INTERACTIVE. Thanks for the information, could you tell when SLL support will be enabled? [2003-01-31 10:07:19] [EMAIL PROTECTED] s/SSH/SSL [2003-01-31 09:55:53] [EMAIL PROTECTED] SSH-Client constant was removed from the documentation (en) ~5 months ago. PHP's current mysql extension doesn't support SSH connects. 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/21981 -- Edit this bug report at http://bugs.php.net/?id=21981&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21997 [Opn]: mktime typo
ID: 21997 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: *General Issues +Bug Type: Documentation problem Operating System: not important PHP Version: 4.3.0 New Comment: reclassified Previous Comments: [2003-02-01 10:31:10] [EMAIL PROTECTED] D A textual representation of a week, three letters Mon through Sun A textual of a DAY I guess. :) Mark -- Edit this bug report at http://bugs.php.net/?id=21997&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21964 [Opn->Ana]: Uploads of a file with size 0 bytes succeed.
ID: 21964
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
-Bug Type: Filesystem function related
+Bug Type: Documentation problem
Operating System: ANY
PHP Version: ANY
New Comment:
[EMAIL PROTECTED]: don't try analyzing any bugs as you obviously don't have
a clue.
For doc people:
With PHP 4.3.0 -> you can upload 0 byte files and you don't
get any error. There is no error code '5'.
You get error 4 (UPLOAD_ERR_NO_FILE) if you don't put any file in the
field.
Previous Comments:
[2003-02-01 05:06:07] [EMAIL PROTECTED]
Actually it looks more than a documentation problem:
For now there is not any define(name) for the new error code. Plus it
looks it's under a #ifdef that can't happen because of : #undef
DEBUG_FILE_UPLOAD in line 39 of main/rfc1867.c.
There is the code:
#ifdef DEBUG_FILE_UPLOAD
if(strlen(filename) > 0 && total_bytes == 0) {
sapi_module.sapi_error(E_WARNING, "Uploaded file size
0 - file
[%s=%s] not saved", param, filename);
cancel_upload = 5;
}
#endif
You can note that usually #ifdef DEBUG_FILE_UPLOAD is used only to hide
the sapi_module.sapi_error() function not the whole code.
eg:
if(strlen(filename) == 0) {
#ifdef DEBUG_FILE_UPLOAD
sapi_module.sapi_error(E_NOTICE, "No file uploaded");
#endif
cancel_upload = UPLOAD_ERROR_D;
}
There is also an another point, why a file with 0 byte has to be
cancelled? Has it been discussed?
According to melvyn:
why would php stop me to upload a file of 0 bytes?
Take a 'web-ftp' for like a sitebuilder kinda app
it would just upload these and create a 0 byte file, which is what I
expect it to do for instance: config.php in phpBB2 is 0 bytes outof the
box.
it needs that to be, for install to work.
So now there are some questions, does the code 5 ever happen? If yes
is it expected that it stops the upload and why do not give it a real
name so we can finally document it.
[2003-01-30 11:43:59] [EMAIL PROTECTED]
I believe this was fixed in 4.2.3 and later.
[2003-01-30 10:47:31] [EMAIL PROTECTED]
I have seen in various places, postings that an uploaded file with size
of 0 bytes should now fail. In version 4.2.2 on Solaris 8 it succeeds.
Please make clear in the documentation exactly when/in which version of
PHP this was changed to throw an error code 5.
--
Edit this bug report at http://bugs.php.net/?id=21964&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21998 [Ver->Ana]: array_pop() moves current element pointer since 4.3.0
ID: 21998 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Analyzed -Bug Type: Arrays related +Bug Type: Documentation problem Operating System: all PHP Version: 4.3.0 New Comment: I have fixed this now in CVS. But the docs should mention that the pointer is reset by array_pop/array_shift. Previous Comments: [2003-02-03 10:51:39] [EMAIL PROTECTED] Clarification: In PHP 4.2.3, the current array position was reset after array_pop() and array_shift(). [2003-02-03 00:39:14] [EMAIL PROTECTED] [EMAIL PROTECTED]: I reverted my changes, not my fault. :-p But there is indeed some bug in this, since array_pop() should not affect the current key. [2003-02-01 15:08:57] [EMAIL PROTECTED] Array related. One of these commits broke it. revision 1.180 date: 2002/08/01 17:34:31; author: rodif_bl; state: Exp; lines: +12 -15 array_pop wasnt setting next index revision 1.179 date: 2002/08/01 16:44:47; author: sniper; state: Exp; lines: +1 -4 That was not correct.. revision 1.178 date: 2002/08/01 16:39:52; author: sniper; state: Exp; lines: +5 -2 Reset index when doing array_pop() [2003-02-01 13:42:12] [EMAIL PROTECTED] This prints "bool(false)" in 4.3.0 (current element pointer points somewhere out of the array) and var_dump($a[0]) in 4.2.3 (array is reset after array_pop). I had to add many additional reset()'s after installing 4.3.0. How array_pop() (and may be others) affects current element pointer is not documented, so this behavior is not a bug. The only purpose of writing all this is that I want to know how array_pop() will work in future PHP releases. -- Edit this bug report at http://bugs.php.net/?id=21998&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18403 [Fbk]: changable directive information (ini_set)
ID: 18403
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type:Documentation problem
PHP Version: 4.5.0
New Comment:
what's the status with this?
Previous Comments:
[2003-01-19 21:01:30] [EMAIL PROTECTED]
I have just commited the script:
phpdoc/scripts/genPHP_INI_ENTRY.php
which should replace my aging phpdoc/scripts/mk_ini_set_table.sh
Test that script. By default it will generate files named
'test_ini.xml' in the appropriate dirs.
If all looks OK, we can go ahead and remove the ini_set table, make the
new script generate all the ini.xml files and change the manual files
where appropriate (makefile, etc.)
Also, look at the approach there. It might be useful for making
replacements for the funcsummary and funclist scripts.
[2003-01-18 05:00:51] [EMAIL PROTECTED]
First, there should not be two places to change, so all ini information
should be in reference/.../ini.xml files. For those ini settings that
are global (not extension related), they should be at some common place
(not ini_set). Much like the configure options.
Second if you would like to make it automatically update all
translations, the simlest thing is to put it out into its own file, and
link it using an entity. The entity will be automatically created for
the .xml file, so you only need to replace / with . in the path... Then
if translators won't translate the file, it will automatically be up to
date in all languages.
[2003-01-16 20:21:01] [EMAIL PROTECTED]
This important topic needs more analysis.
The generated table found at php.net/ini_set (which is created by
phpdoc/scripts/mk_ini_set_table.sh) should not be listed at
php.net/ini_set but rather it should be listed somewhere near
config.xml as this table is certainly not ini_set specific.
Also, this table needs a third description column which somehow should
not be affected by mk_ini_set_table.sh. This would be, for example, a
place to explain why register_globals is PHP_INI_ALL.
And lastly, this information should be related to {extension}/ini.xml
somehow as currently the information is kept track of in two places.
This deserves some thought too.
Regarding the original purpose of this bug report, when
mk_ini_set_table.sh is run it should be run on all translations, not
just /en/. This would mean translations of this wouldn't get
out-of-date.
[2002-07-23 14:58:43] [EMAIL PROTECTED]
Because it is sometimes really nice to have comments on settings (not
much like the indexes), they may be better to be kept as normal XML
files updated by hand.
A new idea is that maybe we can autogenerate it from the source, and
keep it language independent, and make all names links to their
corresponding parts (now in configure.xml and in the future in several
ini.xml files in ext docs)
[2002-07-23 14:05:17] [EMAIL PROTECTED]
The list of ini_set() configuration options is manually autogenerated.
Sometimes changes are made, though, to reflect real world (imho)
behavior. And, sometimes php4 is modified through discussion of this
list.
Here are some options:
(a) Have this list autogenerated with every manual build.
(b) Have a centralized copy of this table, have all languages use it.
Doing (a) assumes no changes will be made (as they won't be kept),
currently we do make changes so this may not be viable. (b) is good as
this table is only in english anyways although it'd make it more
difficult to add a third "description" column for these settings. A
description column would be good to describe why the PHP4 source is the
way it is, and why one might not have expected behavior.
Feel free to discuss. A related documentation feature request is bug
#18372
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/18403
--
Edit this bug report at http://bugs.php.net/?id=18403&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18403 [Fbk->Opn]: changable directive information (ini_set)
ID: 18403
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type:Documentation problem
PHP Version: 4.5.0
New Comment:
keep this open then..
Previous Comments:
[2003-02-04 17:10:44] [EMAIL PROTECTED]
The script is there. Had made some limited tests in my local copy of
the phpdoc, and seems to be working. I would like someone involved in
the manual build to test it and give some feedback.
IIRC something along the lines of the script's output was in the PHPDOC
todo list.
[2003-02-04 16:45:51] [EMAIL PROTECTED]
what's the status with this?
[2003-01-19 21:01:30] [EMAIL PROTECTED]
I have just commited the script:
phpdoc/scripts/genPHP_INI_ENTRY.php
which should replace my aging phpdoc/scripts/mk_ini_set_table.sh
Test that script. By default it will generate files named
'test_ini.xml' in the appropriate dirs.
If all looks OK, we can go ahead and remove the ini_set table, make the
new script generate all the ini.xml files and change the manual files
where appropriate (makefile, etc.)
Also, look at the approach there. It might be useful for making
replacements for the funcsummary and funclist scripts.
[2003-01-18 05:00:51] [EMAIL PROTECTED]
First, there should not be two places to change, so all ini information
should be in reference/.../ini.xml files. For those ini settings that
are global (not extension related), they should be at some common place
(not ini_set). Much like the configure options.
Second if you would like to make it automatically update all
translations, the simlest thing is to put it out into its own file, and
link it using an entity. The entity will be automatically created for
the .xml file, so you only need to replace / with . in the path... Then
if translators won't translate the file, it will automatically be up to
date in all languages.
[2003-01-16 20:21:01] [EMAIL PROTECTED]
This important topic needs more analysis.
The generated table found at php.net/ini_set (which is created by
phpdoc/scripts/mk_ini_set_table.sh) should not be listed at
php.net/ini_set but rather it should be listed somewhere near
config.xml as this table is certainly not ini_set specific.
Also, this table needs a third description column which somehow should
not be affected by mk_ini_set_table.sh. This would be, for example, a
place to explain why register_globals is PHP_INI_ALL.
And lastly, this information should be related to {extension}/ini.xml
somehow as currently the information is kept track of in two places.
This deserves some thought too.
Regarding the original purpose of this bug report, when
mk_ini_set_table.sh is run it should be run on all translations, not
just /en/. This would mean translations of this wouldn't get
out-of-date.
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/18403
--
Edit this bug report at http://bugs.php.net/?id=18403&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19466 [Fbk->NoF]: Improve dll explication
ID: 19466 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Documentation problem Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-01-23 16:03:43] [EMAIL PROTECTED] How do you feel this should be written? Please submit a rewrite for these two paragraphs. [2002-09-18 03:53:23] [EMAIL PROTECTED] Hi, For Windows installations, the install.txt features an explication on which dll's should be copied where, depending on your installation. This paragraph from install.txt is highly confusing as it talks about 'dlls' but there are 4 groups. There is the php4ts.dll, the SAPI dll's the /dll/* dll's and the extension dll's. Don't use "the dll's" in one text which mixes them all. I would be nice if this text would be rephrased. There's also a contradiction in the same text warning/avoiding and later recommending using SAPI dll's. "You need to ensure that the dlls which php uses can be found. The precise dlls involved depend on which web server you use and whether you want to run php as a cgi or as a server module. php4ts.dll is always used. If you are using a server module (e.g. isapi or apache) then you will need the relevent dll from the sapi folder. If you are using any php extension dlls then you will need those as well. To make sure that the dlls can be found, you can either copy them to the system directory (e.g. winnnt/system32 or windows/system) or you can make sure that they live in the same directory as the main php executable or dll your web server will use (e.g. php.exe, php4apache.dll)." Geert -- Edit this bug report at http://bugs.php.net/?id=19466&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20851 [Fbk->NoF]: windows and upload_tmp_dir
ID: 20851 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Documentation problem Operating System: Windows Millenium PHP Version: 4.2.3 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-01-26 11:21:12] [EMAIL PROTECTED] So your default tmp directory couldn't be written to or it didn't exist at all? [2003-01-26 11:06:16] [EMAIL PROTECTED] I read the changelog and for me appear that this is something like the bug 20725, that was fixed in PHP 4.3.0, since I try do it again in 4.3.0 and the PHP put the files on C:/windows/temp, but this don´t work on 4.2.3. Thanks. [2003-01-21 12:17:55] [EMAIL PROTECTED] According to the source there are defaults. Here are some comments found within hp_open_temporary_file.c: /* We can't count on the environment variables TEMP or TMP, * and so must make the Win32 API call to get the default * directory for temporary files. Note this call checks * the environment values TMP and TEMP (in order) first. */ That call is made to GetTempPath. Run msconfig.exe and tell us what the above environment variables are set to on your system. [2002-12-05 21:34:26] [EMAIL PROTECTED] In a mailing list the people tell they can´t make the example of file upload work, only who uses windows. So a begin work on this and discover why. If you don´t define upload_tmp_dir in php.ini, appears that php don´t know where to put, or it puts the file but don´t know where so $_FILES['userfile']['name'] return the correct value, but $_FILES['userfile']['tmp_name'] comes empty and you can´t move the file. Note that I don´t have anything in TMPDIR too. The people on windows "must" set the upload_tmp_dir in php.ini, without this can´t upload a file. -- Edit this bug report at http://bugs.php.net/?id=20851&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #15637 [Opn->Ana]: if using URI, ldap_connect() returns resource ID when server does not exist
ID: 15637
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
-Bug Type: LDAP related
+Bug Type: Documentation problem
Operating System: Linux - RedHat 7.2
PHP Version: 4.4.0-dev
New Comment:
When openldap 2.x is used, the ldap_connect() does not actually
connect, it just initializes the connecting parameters. The actual
connect happens with next calls
to ldap_* funcs, usually it is 'ldap_bind()'.
This is just documentation problem. Not any bug in code.
Previous Comments:
[2003-01-24 19:51:01] [EMAIL PROTECTED]
Yes, I still get ldap resources everytime except when passing in "/" or
a wrong parameter count.
[2003-01-20 16:12:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
With latest CVS it returns FALSE when appropriate, cannot replicate the
problem.
[2003-01-17 22:26:57] [EMAIL PROTECTED]
I cannot get ldap_connect() to return false under ANY conditions,
including with the examples provided in this bug report. I find this
behavior impossible to document, please have another look at this.
Reclassifying -> ldap related.
Shouldn't these return false? They are not URI's:
var_dump(ldap_connect('foo'));
var_dump(ldap_connect('does.not.exist'));
I get resources with both. apache1.3.26/php4.4/openldap2.0.23
[2003-01-06 11:28:38] [EMAIL PROTECTED]
when using an ip address ldap_connect doesn't work as described.
$server = "10.1.1.100";
$port = "389";
$ds = ldap_connect($server, $port);
the result is true even if the server does not exist or the service is
not running.
[2002-12-27 16:27:34] [EMAIL PROTECTED]
I have observed something like this (in php-4.30rc3):
The whole script:
regards.
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/15637
--
Edit this bug report at http://bugs.php.net/?id=15637&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22158 [Opn->Ana]: "8M" isn't and integer is it ?
ID: 22158 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed -Bug Type: *Configuration Issues +Bug Type: Documentation problem Operating System: Red Hat 8.0 PHP Version: 4.2.2 New Comment: This needs a bit clarifying in the docs.. M (or K) can only be used in php.ini file. In .htaccess / httpd.conf you have to use plain integer for the bytes. Previous Comments: [2003-02-10 18:52:52] [EMAIL PROTECTED] First off, I think you guys are great and I would be at a loss without you so many-many thanks But. while troubleshooting a file upload issue with imp (standard thing reported many times in a number of different varieties upload_max_filesize ignored and the likewise post_max_size ignored and even memory_limit doesn't matter) I first looked to my php.ini and started adjusting these settings to no avail. My actual problem was a gem of a file httpd/conf.d/php.conf which contained -- SetOutputFilter PHP SetInputFilter PHP LimitRequestBody 524288 the cause of my httpd/errorlog file noting... "Requested content-length of 2172475 is larger than the configured limit of 524288" --> that's what I get for Red Hat RPMs instead of real files Anyway the possible "bug" is that the documentation specifically states that all three of these configuration directives are of type integer and the default is "8M"... it seems to me that should be 800 if the unit is bytes. And, even the units of the directive is a bit unclear and should be clearly stated, I think. Thanks for your patience and good work and if this isn't in line... well I fixed my problem so I'm still thrilled with you folks. -- Edit this bug report at http://bugs.php.net/?id=22158&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22198 [Opn->Ana]: date() returning incorrect date
ID: 22198 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed -Bug Type: Date/time related +Bug Type: Documentation problem Operating System: Solaris 8 (sparc) PHP Version: 4.3.0 New Comment: Yes, it was what I suspected. On Linux, the same script gives 30/03/2003 from the 00:00:00 time til the end. We need to document this behaviour a bit better.. (never use 00:00:00 as time!) Previous Comments: [2003-02-12 21:47:17] [EMAIL PROTECTED] script: $frm2\n"; } } } ?> relevant part of output: ... (0 h, 59 m, 55 s) 1048982395 --> 29/03/2003 (0 h, 59 m, 56 s) 1048982396 --> 29/03/2003 (0 h, 59 m, 57 s) 1048982397 --> 29/03/2003 (0 h, 59 m, 58 s) 1048982398 --> 29/03/2003 (0 h, 59 m, 59 s) 1048982399 --> 29/03/2003 (1 h, 0 m, 0 s) 1048982400 --> 30/03/2003 (1 h, 0 m, 1 s) 1048982401 --> 30/03/2003 (1 h, 0 m, 2 s) 1048982402 --> 30/03/2003 (1 h, 0 m, 3 s) 1048982403 --> 30/03/2003 (1 h, 0 m, 4 s) 1048982404 --> 30/03/2003 ... [2003-02-12 21:30:23] [EMAIL PROTECTED] Try using some other time that midnight. Some systems tend to behave a bit differently during the dst change and in those systems, the hour between 00:00 - 01:00 doesn't exist..(e.g. Macosx does the same) [2003-02-12 21:07:03] [EMAIL PROTECTED] = TIME END 2003-02-13 03:02:41 = TEST RESULT SUMMARY - Exts skipped: 76 Exts tested : 14 - Number of tests : 443 Tests skipped : 221 (49.9%) Tests failed:3 ( 0.7%) Tests passed: 219 (49.4%) - Time taken : 111 seconds = = FAILED TEST SUMMARY - Error message handling [tests/run-test/test005.phpt] Bug #21131: fopen($filename, "a+") has broken position [ext/standard/tests/file/bug21131.phpt] strtotime() function [ext/standard/tests/time/002.phpt] = [2003-02-12 20:41:07] [EMAIL PROTECTED] We are waiting for your feedback about the result of the test. Thank you. [2003-02-12 20:38:52] [EMAIL PROTECTED] on freebsd x86: $ php -v 4.2.1 $ uname -sr FreeBSD 4.6-STABLE $ php -q data.php 1048896000 29/03/2003 1048982400 30/03/2003 on sparc: $ php -v PHP 4.3.0 (cli) (built: Feb 10 2003 18:07:11) Copyright (c) 1997-2002 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies with Zend Optimizer v2.1.0, Copyright (c) 1998-2003, by Zend Technologies $ uname -sr SunOS 5.8 $ php -q data.php 1048896000 29/03/2003 1048978800 29/03/2003 Timestamps are different 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/22198 -- Edit this bug report at http://bugs.php.net/?id=22198&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22198 [Ana]: date() returning incorrect date
ID: 22198 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Documentation problem Operating System: Solaris 8 (sparc) PHP Version: 4.3.0 New Comment: btw. mktime() has 7th optional parameter 'is_dst'. When I use your example script, and set that to 1, I get same results as you. >From manual page for mktime: "is_dst can be set to 1 if the time is during daylight savings time, 0 if it is not, or -1 (the default) if it is unknown whether the time is within daylight savings time or not. If it's unknown, PHP tries to figure it out itself. This can cause unexpected (but not incorrect) results. " Try setting that to 0. Previous Comments: [2003-02-12 21:51:14] [EMAIL PROTECTED] Yes, it was what I suspected. On Linux, the same script gives 30/03/2003 from the 00:00:00 time til the end. We need to document this behaviour a bit better.. (never use 00:00:00 as time!) [2003-02-12 21:47:17] [EMAIL PROTECTED] script: $frm2\n"; } } } ?> relevant part of output: ... (0 h, 59 m, 55 s) 1048982395 --> 29/03/2003 (0 h, 59 m, 56 s) 1048982396 --> 29/03/2003 (0 h, 59 m, 57 s) 1048982397 --> 29/03/2003 (0 h, 59 m, 58 s) 1048982398 --> 29/03/2003 (0 h, 59 m, 59 s) 1048982399 --> 29/03/2003 (1 h, 0 m, 0 s) 1048982400 --> 30/03/2003 (1 h, 0 m, 1 s) 1048982401 --> 30/03/2003 (1 h, 0 m, 2 s) 1048982402 --> 30/03/2003 (1 h, 0 m, 3 s) 1048982403 --> 30/03/2003 (1 h, 0 m, 4 s) 1048982404 --> 30/03/2003 ... [2003-02-12 21:30:23] [EMAIL PROTECTED] Try using some other time that midnight. Some systems tend to behave a bit differently during the dst change and in those systems, the hour between 00:00 - 01:00 doesn't exist..(e.g. Macosx does the same) [2003-02-12 21:07:03] [EMAIL PROTECTED] = TIME END 2003-02-13 03:02:41 = TEST RESULT SUMMARY - Exts skipped: 76 Exts tested : 14 - Number of tests : 443 Tests skipped : 221 (49.9%) Tests failed:3 ( 0.7%) Tests passed: 219 (49.4%) - Time taken : 111 seconds = = FAILED TEST SUMMARY - Error message handling [tests/run-test/test005.phpt] Bug #21131: fopen($filename, "a+") has broken position [ext/standard/tests/file/bug21131.phpt] strtotime() function [ext/standard/tests/time/002.phpt] = [2003-02-12 20:41:07] [EMAIL PROTECTED] We are waiting for your feedback about the result of the test. Thank you. 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/22198 -- Edit this bug report at http://bugs.php.net/?id=22198&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21883 [Opn]: jpc and jp2
ID: 21883 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: all PHP Version: 4.3.0 New Comment: Only thing to document is that since 4.3.1 PHP supports JPEG 2000 and WBMP imagetypes too.. Previous Comments: [2003-01-27 12:50:10] [EMAIL PROTECTED] This remains open until jpc and jp2 are documented properly. This may need to be faq that's referred to in various places? Or maybe a language-snippet? Because I doubt getimagesize() is the only appropriate place for this information. [2003-01-27 12:42:37] [EMAIL PROTECTED] Thank you, i think the "bug" is closed. I am waiting for PHP 4.3.x where x > 1. [2003-01-26 15:34:34] [EMAIL PROTECTED] Sadly, JPEG 2000 support didn't make it for 4.3. JPEG 2000 raw codestream support should be in 4.3.1. JP2 support will probably feature in 5.0. A current stable snapshot should work for JPC, and JP2 will work if you compile from HEAD. adamw [2003-01-26 04:43:04] [EMAIL PROTECTED] It's only working correctly in PHP > 4.3 -> doc problem. [2003-01-26 01:55:46] [EMAIL PROTECTED] -Short script : -List of modules : I dowloaded PHP4.3 binary for Windows (ZIP file), from your site. -Any other information : I tried the same script with a JPG image, it works. I saw every where that JPEG2000 is managed in PHP 4.3. : http://www.zend.com/manual/function.getimagesize.php for exemple. Is there a "Zend" PHP or is it for the future ? -- Edit this bug report at http://bugs.php.net/?id=21883&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
