[PHP-DOC] #39356 [Opn-Ana]: in_array() causes Nesting level too deep fatal error
ID: 39356
Updated by: [EMAIL PROTECTED]
Reported By: 7am dot online at gmail dot com
-Status: Open
+Status: Analyzed
-Bug Type: Arrays related
+Bug Type: Documentation problem
Operating System: Windows XP
PHP Version: 5.2.0
Previous Comments:
[2006-11-04 14:47:26] [EMAIL PROTECTED]
http://php.net/in_array is completely quiet about references
this is a change from 5.1 so it should at least be a documentation
problem.
[2006-11-03 14:01:24] [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
In php 5 objects are passed by reference, so your code does in
fact create a circular dependency.
[2006-11-03 03:04:24] 7am dot online at gmail dot com
Description:
Doing a in_array() check against an array containing objects with
recursive dependency causes a Nesting level too deep - recursive
dependency? fatal error.
Reproduce code:
---
?php
class A
{
public $b;
}
class B
{
public $a;
}
$a = new A;
$b = new B;
$b-a = $a;
$a-b = $b;
$test = array($a, $b);
var_dump(in_array($a, $test));
Expected result:
bool(true), as in PHP5.1.6
Actual result:
--
Fatal error: Nesting level too deep - recursive dependency? in
[FILENAME] on line 19
--
Edit this bug report at http://bugs.php.net/?id=39356edit=1
[PHP-DOC] #39296 [Asn-Ana]: is_readable is raising a warning when the file or dir is outside open_basedir
ID: 39296
Updated by: [EMAIL PROTECTED]
Reported By: judas dot iscariote at gmail dot com
-Status: Assigned
+Status: Analyzed
-Bug Type: Safe Mode/open_basedir
+Bug Type: Documentation problem
Operating System: Linux
PHP Version: 5CVS-2006-10-29 (CVS)
Assigned To: iliaa
New Comment:
This should be documented.
Previous Comments:
[2006-10-29 23:51:06] judas dot iscariote at gmail dot com
it is silent in 4_4 , 4.3.9 this annoyance affects the whole stat()
family.
if this is considered a bug in the code here is my fix :
--- ext/standard/filestat.c 2 Jul 2006 13:51:40 -
1.136.2.8.2.3
+++ ext/standard/filestat.c 29 Oct 2006 23:45:54 -
@@ -660,7 +660,7 @@
}
if ((wrapper = php_stream_locate_url_wrapper(filename, local,
0 TSRMLS_CC)) == php_plain_files_wrapper) {
- if (php_check_open_basedir(local TSRMLS_CC) ||
(PG(safe_mode) !php_checkuid_ex(filename, NULL,
CHECKUID_ALLOW_FILE_NOT_EXISTS, CHECKUID_NO_ERRORS))) {
+ if (php_check_open_basedir_ex(local, 0 TSRMLS_CC) ||
(PG(safe_mode) !php_checkuid_ex(filename, NULL,
CHECKUID_ALLOW_FILE_NOT_EXISTS, CHECKUID_NO_ERRORS))) {
RETURN_FALSE;
}
}
this change was introduced in php 5.1.5 by Ilia.
http://cvs.php.net/viewvc.cgi/php-src/ext/standard/filestat.c?r1=1.136.2.8r2=1.136.2.9
it this is considered not to be a bug, please update the documentation
;)
[2006-10-29 18:00:29] phpbugs at thequod dot de
Has this changed since 5.1 or 4.x?
[2006-10-29 09:52:52] judas dot iscariote at gmail dot com
Description:
is_readable is raising and open_basedir warrning when the file/dir is
not in open_basedir.
this is not expected or at least is not mentioned in the
documentation.
Reproduce code:
---
php -d display_errors=1 -dopen_basedir=`pwd` -r
'var_dump(is_readable(/tmp));'
Expected result:
a silent
bool(false)
as stated on the documentation.
Actual result:
--
Warning: is_readable(): open_basedir restriction in effect. File(/tmp)
is not within the allowed path(s):
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=39296edit=1
[PHP-DOC] #37431 [Opn-Ana]: pg_send_query doc and operation don't match
ID: 37431
Updated by: [EMAIL PROTECTED]
Reported By: cstdenis at ctgameinfo dot com
-Status: Open
+Status: Analyzed
-Bug Type: PostgreSQL related
+Bug Type: Documentation problem
Operating System: FreeBSD 5.4
PHP Version: 5.1.4
New Comment:
The function requires 2 parameters, connection string and then
the query. The docs needs to be adjusted to reflect this fact.
Previous Comments:
[2006-05-13 23:36:05] cstdenis at ctgameinfo dot com
Mistyped the query. Should be
pg_send_query (insert into test (test1, test2) values ('a', 1));
not that it matters, its just an example.
[2006-05-13 23:33:22] cstdenis at ctgameinfo dot com
Description:
Warning: pg_send_query() expects exactly 2 parameters, 1 given
According to the docs
bool pg_send_query ( resource connection, string query )
bool pg_send_query ( string query )
One of those is wrong, and I'm betting on the code since all the other
functions in the group accept 1 OR 2 prameters.
Reproduce code:
---
pg_send_query (insert into test (test1, test2) ('a', 1));
Expected result:
Query executed.
Actual result:
--
Warning: pg_send_query() expects exactly 2 parameters, 1 given
Query not executed.
--
Edit this bug report at http://bugs.php.net/?id=37431edit=1
[PHP-DOC] #36281 [Asn-Ana]: bindParam not working with LIKE '%:foo%'
ID: 36281 Updated by: [EMAIL PROTECTED] Reported By: vendor at visv dot net -Status: Assigned +Status: Analyzed -Bug Type: PDO related +Bug Type: Documentation problem Operating System: Linux PHP Version: 5.1.2 Assigned To: wez Previous Comments: [2006-02-04 18:54:21] vendor at visv dot net Possibly. How can we determine that definitively? At the least, I would like to add a user-note to the online documentation, if someone cannot add it to the core docs for pdo-mysql. The db in question is mysql 4.1 [2006-02-04 18:49:21] [EMAIL PROTECTED] I doubt this is a bug... many DB APIs simply don't support bind variables like this. A bind variable is not just any substitution for a string. [2006-02-04 18:49:15] [EMAIL PROTECTED] That is not a valid parameter definition. [2006-02-04 18:21:16] vendor at visv dot net No change nor improvement with http://snaps.php.net/php5.1-latest.tar.gz on Feb 4. 12:20PM [2006-02-04 12:48:08] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip 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/36281 -- Edit this bug report at http://bugs.php.net/?id=36281edit=1
[PHP-DOC] #35527 [Opn-Bgs]: brace escape problem ( continues? )
ID: 35527
Updated by: [EMAIL PROTECTED]
Reported By: judas dot iscariote at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 5CVS-2005-12-02 (CVS)
Assigned To: iliaa
New Comment:
This fixes a consistency bug found in older releases.
Previous Comments:
[2005-12-03 02:49:07] judas dot iscariote at gmail dot com
php t.php
... abc ...
... {abc} ...
PHP 4.3.10 (cli) (built: Nov 18 2005 00:58:42)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
So.. another Backward incompatible change ??
it 's not mentioned in the upgrade Guide...
http://www.php.net/README_UPGRADE_51.php
[2005-12-03 02:03:31] [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
This is expected behaviour, {} is no longer special, they are being
treated like any other character.
[2005-12-03 01:57:59] [EMAIL PROTECTED]
# php t.php
... abc ...
... \{abc} ...
# php -v
PHP 5.1.2-dev (cli) (built: Dec 3 2005 01:35:55) (DEBUG)
Copyright (c) 1997-2005 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2005 Zend Technologies
[2005-12-02 22:58:40] judas dot iscariote at gmail dot com
Description:
seems to be related to Bug #35411
but now the \ char is displayed.
'../configure' '--prefix=/usr' '--datadir=/usr/share/php5'
'--mandir=/usr/share/man' '--bindir=/usr/bin' '--libdir=/usr/lib64'
'--includedir=/usr/include' '--with-libdir=lib64'
'--sysconfdir=/etc/php5/apache2'
'--with-config-file-path=/etc/php5/apache2'
'--with-config-file-scan-dir=/etc/php5/conf.d'
'--with-exec-dir=/usr/lib64/php5/bin' '--enable-magic-quotes'
'--enable-libxml' '--enable-session' '--with-mm' '--with-pcre-regex'
'--enable-xml' '--enable-simplexml' '--enable-spl' '--enable-safe-mode'
'--enable-sigchild' '--disable-debug' '--enable-memory-limit'
'--enable-inline-optimization' '--enable-zend-multibyte'
'--with-apxs2=/usr/sbin/apxs2' '--disable-all'
Reproduce code:
---
Same as Bug #35411
Expected result:
php 5.0.5:
... abc ...
... {abc} ...
Actual result:
--
... abc ...
... \{abc} ...
--
Edit this bug report at http://bugs.php.net/?id=35527edit=1
[PHP-DOC] #35169 [Asn]: proc_get_status lost exitcode after second call
ID: 35169
Updated by: [EMAIL PROTECTED]
Reported By: c dot affolter at stepping-stone dot ch
Status: Assigned
-Bug Type: Program Execution
+Bug Type: Documentation problem
Operating System: Linux version 2.4.21
PHP Version: 5.1.0RC4
Assigned To: wez
New Comment:
This is a not a bug, but an undocumented behaviour.
Previous Comments:
[2005-11-09 12:53:39] [EMAIL PROTECTED]
Wez, how is it? Bug or undocumented behaviour?
[2005-11-09 11:18:51] c dot affolter at stepping-stone dot ch
Description:
After a process (via proc_open()) has exited, proc_get_status() returns
the actual exit code (within array['exitcode']) of that process.
If proc_get_status() gets called a second time, the previous exit code
will be lost (-1), because the internal waitpid() function won't return
the pid a second time.
So, either this is a bug and proc_get_status() has to keep track of the
exitcode value (as it does for 'command', 'pid' and 'running') or this
behaviour should be mentioned in the documentation.
Reproduce code:
---
#!/usr/bin/env php
?php
$descriptors = array(
0 = array('pipe', 'r'),
1 = array('pipe', 'w'),
2 = array('pipe', 'w'));
$pipes = array();
$ressource = proc_open('/bin/true', $descriptors, $pipes);
echo stream_get_contents($pipes[1]);
// first call exitcode == 0
var_dump(proc_get_status($ressource));
// second call exitcode == -1
var_dump(proc_get_status($ressource));
fclose($pipes[1]);
proc_close($ressource);
?
Expected result:
array(8) {
[command]=
string(9) /bin/true
[pid]=
int(31590)
[running]=
bool(false)
[signaled]=
bool(false)
[stopped]=
bool(false)
[exitcode]=
int(0)
[termsig]=
int(0)
[stopsig]=
int(0)
}
array(8) {
[command]=
string(9) /bin/true
[pid]=
int(31590)
[running]=
bool(false)
[signaled]=
bool(false)
[stopped]=
bool(false)
[exitcode]=
int(0)
[termsig]=
int(0)
[stopsig]=
int(0)
}
Actual result:
--
array(8) {
[command]=
string(9) /bin/true
[pid]=
int(31590)
[running]=
bool(false)
[signaled]=
bool(false)
[stopped]=
bool(false)
[exitcode]=
int(0)
[termsig]=
int(0)
[stopsig]=
int(0)
}
array(8) {
[command]=
string(9) /bin/true
[pid]=
int(31590)
[running]=
bool(false)
[signaled]=
bool(false)
[stopped]=
bool(false)
[exitcode]=
int(-1)
[termsig]=
int(0)
[stopsig]=
int(0)
}
--
Edit this bug report at http://bugs.php.net/?id=35169edit=1
[PHP-DOC] #33834 [Opn-Bgs]: docs.php.net, search feature is not working fine.
ID: 33834 Updated by: [EMAIL PROTECTED] Reported By: sanjeev at adari dot net -Status: Open +Status: Bogus Bug Type: Livedocs problem Operating System: Linux PHP Version: Irrelevant New Comment: Not livedocs sw problem, closing. Previous Comments: [2005-07-23 11:08:39] [EMAIL PROTECTED] docs.php.net is not intended to be viewed by end users, it is just a test machine for a new rendering engine. This is a livedocs (deployment) problem. [2005-07-23 08:13:58] sanjeev at adari dot net Description: After I enter some words in the search box and press enter.. I was directed to http://docs.php.net/search.php and this has just a white page with a search box, strict check box abd search button. when i again use this search box and click on search, i get these messages: Warning: sqlite_exec() [function.sqlite-exec]: cannot attach empty database: sc in /local/Web/sites/livedocs/search.php on line 34 Warning: sqlite_array_query() [function.sqlite-array-query]: no such table: search_cache in /local/Web/sites/livedocs/search.php on line 36 Warning: sqlite_exec() [function.sqlite-exec]: no such table: search_cache in /local/Web/sites/livedocs/search.php on line 40 Warning: sqlite_exec() [function.sqlite-exec]: no such table: cache_data in /local/Web/sites/livedocs/search.php on line 44 Warning: sqlite_single_query() [function.sqlite-single-query]: no such table: cache_data in /local/Web/sites/livedocs/search.php on line 46 Strict: No Results Found -- Edit this bug report at http://bugs.php.net/?id=33834edit=1
[PHP-DOC] #33515 [Opn-Csd]: parameter inside literallayout causes empty pre
ID: 33515 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Livedocs problem PHP Version: Irrelevant New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-06-30 12:02:00] [EMAIL PROTECTED] Description: Example: http://docs.php.net/en/function.imap-headerinfo.html -- Edit this bug report at http://bugs.php.net/?id=33515edit=1
[PHP-DOC] #32780 [Opn-Csd]: refpurpose isn't displayed if it contains a function or entity
ID: 32780 Updated by: [EMAIL PROTECTED] Reported By: jsgoupil at lookstrike dot com -Status: Open +Status: Closed Bug Type: Livedocs problem Operating System: Linux PHP Version: Irrelevant New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-06-20 18:22:47] [EMAIL PROTECTED] Also happens in titleliteralfoo/literal/title. [2005-06-16 02:35:07] [EMAIL PROTECTED] Analysis: If the refpurpose has children, livedocs breaks (tries to pring $node-content, but really wants $node-children[n]-content (and it needs to transform the children)). S [2005-04-21 01:18:54] [EMAIL PROTECTED] same if entity (null;) See pg_field_is_null [2005-04-20 20:24:48] jsgoupil at lookstrike dot com Description: The content of refpurpose is not displayed if it contains a function tag : function. As you can see on pg_set_error_verbosity Jean-Sébastien Goupil -- Edit this bug report at http://bugs.php.net/?id=32780edit=1
[PHP-DOC] #33269 [Opn-Csd]: link tag displays wrong output when using with type tag
ID: 33269 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Livedocs problem PHP Version: Irrelevant New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. I think this is fixed, but if it's not please provide a URL to page that demonstrates the problem. Previous Comments: [2005-06-16 02:37:51] [EMAIL PROTECTED] I'm pretty sure this is the same behavior as #32780. The link formatter doesn't expect the node to have children, and is trying to output $node-content (where $node-child[n]-content needs to be output after a transform). S [2005-06-08 01:36:02] [EMAIL PROTECTED] Description: When you write something like link linkend=language.types.ressourceDoc on typeresource/types/link It will output directly the Resource title. So with link linkend=language.types.integerDoc on typeresource/types/link will output Integer (with the link of course) Supposed to output Doc on typeresource/types with the link. -- Edit this bug report at http://bugs.php.net/?id=33269edit=1
[PHP-DOC] #30440 [Opn-Bgs]: Nested entities cause invalid XML
ID: 30440 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Livedocs problem Operating System: n/a PHP Version: Irrelevant Assigned To: iliaa New Comment: The parser expects charset of the XML files to be UTF-8, for the French translation it is ISO-8859-1. To solve many of the errors in parsing, modify mkindex.php and change xml_parser_create(UTF-8); to xml_parser_create(ISO-8859-1); This is not a livedocs bug, as the input should technically be UTF-8. Previous Comments: [2005-06-20 17:19:06] [EMAIL PROTECTED] I have still the same errors... Do I have to apply the patch again ? [2005-06-18 04:03:40] [EMAIL PROTECTED] This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. [2005-04-20 20:37:16] [EMAIL PROTECTED] I applied the patch and with French doc there are a lot of accents... (é à ...) I got only a Warning (the page is displayed but crash only at the special character) : XML: 1:33 Invalid character Line: 1 is divdiv class=function_linkfunctionpg_affected_rows/function - Retourne le nombre de lignes affectées/div divdiv class=function_linkfunctionpg_affected_rows/function - Retourne le nombre de lignes affectées/div div class=function_linkfunctionpg_cancel_query/function - Annule une requête asynchrone/div ... It seems that it is only for displaying functions at the end of a reference.xml file Example : fr/ref.pgsql.html [2004-10-15 17:54:58] [EMAIL PROTECTED] Confirmed that this patch fixes this problem. Could someone with the necessary karma please patch commit? Thanks, S [2004-10-15 17:44:09] [EMAIL PROTECTED] That should be fixed with one of my patches: http://livedocs.aborla.net/patch.php?id=entities 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/30440 -- Edit this bug report at http://bugs.php.net/?id=30440edit=1
[PHP-DOC] #33390 [Opn-Csd]: user notes need to be escaped
ID: 33390 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Livedocs problem PHP Version: Irrelevant New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-06-18 05:41:55] [EMAIL PROTECTED] Still broken, see the first note here: http://didou.keliglia.com/manuals/php/index.php?l=enq=function.domxml-xslt-stylesheet The problem is that the regexp doesn't match anything after the ? sequence in the XSL header. A fix would be to remove the preg_replace_callback() call and directly call highlight_php_code() if ? is detetcted by strpos(). [2005-06-18 04:16:14] [EMAIL PROTECTED] This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. [2005-06-18 03:15:46] [EMAIL PROTECTED] Description: Notes are not escaped : http://livedocs.phpdoc.info/index.php?l=enq=function.domxml-xslt-stylesheet -- Edit this bug report at http://bugs.php.net/?id=33390edit=1
[PHP-DOC] #33387 [Opn-Csd]: Livedocs dies silently with no sqlite
ID: 33387 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Livedocs problem PHP Version: Irrelevant New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-06-17 18:26:45] [EMAIL PROTECTED] Description: Livedocs dies silently when no SQLite extension is available. This happens in common.php, line 72: $fb_idx = @sqlite_open(FALLBACK_INDEX); (sqlite_open() is undefined) Here's a patch.. might be a better way to handle this. Dying silently is annoying, and difficult to debug, though. http://www.phpdoc.info/patches/livedocs_sqlite.patch -- Edit this bug report at http://bugs.php.net/?id=33387edit=1
[PHP-DOC] #33358 [Opn-Csd]: Should use TITLEABBREV in TOC
ID: 33358 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Livedocs problem Operating System: N/A PHP Version: Irrelevant New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-06-16 01:46:43] [EMAIL PROTECTED] 19:32 @ilia sean, can you clarify your livedocs bug report 19:32 @sean yeah.. sorry it was unclear.. take a look here: http://livedocs.phpdoc.info/apd 19:33 @sean you'll see that the TOC on the left shows Advanced PHP debugger (this is the title.../title tag) 19:33 @sean but on php.net/apd it's APD (the titleabbrev) 19:33 @sean make sense? 19:33 @sean I took a stab at fixing it -- I don't think it'll be fun. [2005-06-16 00:43:15] [EMAIL PROTECTED] Description: Livedocs uses the TITLE in the TOC (idents table), but it should use the TITLEABBREV if available (like the DSSSL does -- and it makes the TOC much nicer). -- Edit this bug report at http://bugs.php.net/?id=33358edit=1
[PHP-DOC] #33037 [Opn-Csd]: English : Example Bad output
ID: 33037
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type:Livedocs problem
PHP Version: Irrelevant
Previous Comments:
[2005-05-26 19:25:32] [EMAIL PROTECTED]
leave it open for further investigation.
[2005-05-24 01:00:05] phpdoc at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-05-17 00:56:40] [EMAIL PROTECTED]
I'm already running the patch mentionned in #30440
http://livedocs.aborla.net/patch.php?id=entities
Moreover, i wrote a comment into this bug.
I applied it a long time ago and, if I remember, one of the pattern
didn't match, so Ive corrected all files by hand.
These lines were removed :
-$GLOBALS['special'] = array('gt' = 1,'lt' = 1,'quot' = 1,'amp' =
1);
-
function handle_include($node)
{
global $current_page;
$ref = $node-attributes['ref'];
- /* Special HTML entities */
- if (isset($GLOBALS['special'][$ref])) {
- return '' . $ref . ';';
- }
-
[2005-05-16 16:28:46] [EMAIL PROTECTED]
Its a livedocs problem.
Could you please try my ancient patch mentioned in #30440 ?
[2005-05-16 03:52:27] [EMAIL PROTECTED]
Description:
reference/strings/functions/htmlspecialchars-decode.html
Ok, look at the example in livedocs what it outputs..., the output is
the same... (check example too).
I don't really know if it is a doc bug or a livedocs bug.
Feel free to redirect this bug to Livedocs...
Perhaps the output will be great on php.net, i don't know ?!
Expected result:
?php
$str = 'pthis -gt; quot;/p';
echo htmlspecialchars_decode($str);
// notez ici que les guillemets ne sont pas convertis
echo htmlspecialchars_decode($str, ENT_NOQUOTES);
?
pthis - /p
pthis - quot;/p
Actual result:
--
?php
$str = 'pthis -gt; /p';
echo htmlspecialchars_decode($str);
// notez ici que les guillemets ne sont pas convertis
echo htmlspecialchars_decode($str, ENT_NOQUOTES);
?
pthis - /p
pthis - /p
--
Edit this bug report at http://bugs.php.net/?id=33037edit=1
[PHP-DOC] #30440 [Ana-Csd]: Nested entities cause invalid XML
ID: 30440 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type: Livedocs problem Operating System: n/a PHP Version: Irrelevant Assigned To: iliaa New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-04-20 20:37:16] [EMAIL PROTECTED] I applied the patch and with French doc there are a lot of accents... ( ...) I got only a Warning (the page is displayed but crash only at the special character) : XML: 1:33 Invalid character Line: 1 is divdiv class=function_linkfunctionpg_affected_rows/function - Retourne le nombre de lignes affectes/div divdiv class=function_linkfunctionpg_affected_rows/function - Retourne le nombre de lignes affectes/div div class=function_linkfunctionpg_cancel_query/function - Annule une requte asynchrone/div ... It seems that it is only for displaying functions at the end of a reference.xml file Example : fr/ref.pgsql.html [2004-10-15 17:54:58] [EMAIL PROTECTED] Confirmed that this patch fixes this problem. Could someone with the necessary karma please patch commit? Thanks, S [2004-10-15 17:44:09] [EMAIL PROTECTED] That should be fixed with one of my patches: http://livedocs.aborla.net/patch.php?id=entities [2004-10-15 06:56:20] [EMAIL PROTECTED] Description: When an entity contains a nested (special character) entity, the handler is not called properly, and this can result in malformed XML. I worked on this for about 30 mins, tonight, and didn't get very far, so no patch, yet. Reproduce code: --- http://livedocs.phpdoc.info/ref.regex Expected result: ulink url=http://www.tin.org/bin/man.cgi?section=7topic=regex; Actual result: -- ulink url=http://www.tin.org/bin/man.cgi?section=7phpdoc_include ref=amp/topic=regex -- Edit this bug report at http://bugs.php.net/?id=30440edit=1
[PHP-DOC] #33390 [Opn-Csd]: user notes need to be escaped
ID: 33390 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Livedocs problem PHP Version: Irrelevant New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-06-18 03:15:46] [EMAIL PROTECTED] Description: Notes are not escaped : http://livedocs.phpdoc.info/index.php?l=enq=function.domxml-xslt-stylesheet -- Edit this bug report at http://bugs.php.net/?id=33390edit=1
[PHP-DOC] #33157 [Opn-Ana]: Missing htmlspecialchars_decode
ID: 33157 Updated by: [EMAIL PROTECTED] Reported By: mjs15451 at hotmail dot com -Status: Open +Status: Analyzed -Bug Type: *General Issues +Bug Type: Livedocs problem Operating System: Linux 2.6.10 PHP Version: 5.0.4 New Comment: Documentation is wrong, this function is found in PHP 5.1 only Previous Comments: [2005-05-27 01:57:06] mjs15451 at hotmail dot com Description: htmlspecialchars_decode() is missing. Reproduce code: --- echo htmlspecialchars_decode(asdflt;gt;); Expected result: Should output: asdf Actual result: -- Fatal error: Call to undefined function htmlspecialchars_decode() I double checked my php version and I am definitely running php 5.0.4 and according to the docs this function should be available in PHP 5. http://us2.php.net/manual/en/function.htmlspecialchars-decode.php I did the usual configure, make, make install. ./configure --prefix=/usr/lib/php --with-apxs2=/usr/sbin/apxs2 --with-openssl --with-zlib --enable-dio --with-bz2 --enable-calendar --enable-bcmath --with-curl=/usr/include/curl --enable-exif --enable-filepro --enable-ftp --with-ttf --enable-mbstring --enable-zend-multibyte --without-mysql --with-mysqli=/usr/lib/mysql/bin/mysql_config --with-mysql-sock=/var/run/mysqld/mysql.sock --enable-sockets --enable-sqllite-utf8 --enable-wddx --with-gettext=/usr/lib/gettext --with-imagick=/usr --with-mcrypt --with-mhash --with-gd --with-jpeg-dir --with-png-dir --with-freetype-dir --with-zlib-dir --with-libxml-dir make make install -- Edit this bug report at http://bugs.php.net/?id=33157edit=1
[PHP-DOC] #31826 [Opn-Csd]: property should be a span, not a div
ID: 31826 Updated by: [EMAIL PROTECTED] Reported By: didou at keliglia dot com -Status: Open +Status: Closed Bug Type:Livedocs problem PHP Version: Irrelevant Assigned To: ilia New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-02-03 10:41:39] didou at keliglia dot com Description: Here's the patch : http://www.powertrip.co.za/livedocs/viewpatch.php?patch=20 -- Edit this bug report at http://bugs.php.net/?id=31826edit=1
[PHP-DOC] #30320 [Opn-Csd]: Properly format note titles
ID: 30320
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type:Livedocs problem
PHP Version: Irrelevant
Assigned To: ilia
New Comment:
This bug has been fixed in CVS.
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2004-10-04 14:00:12] [EMAIL PROTECTED]
Here's the patch formatted correctly:
http://www.powertrip.co.za/livedocs/viewpatch.php?patch=11
[2004-10-04 13:51:11] [EMAIL PROTECTED]
Description:
This patch properly formats note titles
Actual result:
--
--- repository\livedocs\themes\default\livedoc.1.6.css Sun Aug 08
18:50:24 2004
+++ repository\livedocs\themes\default\livedoc.css Sun Sep 12 16:46:28
2004
@@ -76,6 +76,12 @@
margin: 0.6em;
}
+div.note div.title {
+ text-decoration: underline;
+ padding: 0.4em 0 0 0.4em;
+}
+
+
div.warning {
background-color: #ff;
border: solid 2px #ff;
--
Edit this bug report at http://bugs.php.net/?id=30320edit=1
[PHP-DOC] #30319 [Opn-Csd]: Display the Note ID for user notes
ID: 30319 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Livedocs problem PHP Version: Irrelevant Assigned To: ilia New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-10-04 13:59:38] [EMAIL PROTECTED] Here's the patch formatted correctly: http://www.powertrip.co.za/livedocs/viewpatch.php?patch=8 [2004-10-04 13:49:09] [EMAIL PROTECTED] Description: This patch adds the Note ID to the user notes. This allows users to properly reference a note in other notes, emails, irc conversations etc. Expected result: --- C:\Documents and Settings\Aidan Lister\Local Settings\Temp\TCV80.tmp\livedoc_funcs.1.10.php Sun Aug 15 07:41:37 2004 +++ E:\cvs\livedocs\livedoc_funcs.php Wed Sep 08 09:43:51 2004 @@ -258,7 +258,7 @@ $the_note = format_listing($node); $inner .= ' '.$note['who']. - ' '.$date.' '.$the_note.' '; + ' (#'.$note['id'].') '.$date.''.$the_note.''; } return $inner . ; -- Edit this bug report at http://bugs.php.net/?id=30319edit=1
[PHP-DOC] #30456 [Opn-Csd]: Livedocs malforms example code
ID: 30456 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Livedocs problem PHP Version: Irrelevant Assigned To: ilia New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-10-19 06:03:03] [EMAIL PROTECTED] Nuno, You might be seing my changes I made for the patch. The problem is that hightlight_string() doesn't put nbsp; in all places where a space occurs, causing in some places a ' ' to get compressed thus loosing indententation. Here is an example of the white space compression (example Extending the Exception class): http://livedocs.homelinux.com/en/language.oop5.exceptions.html Note: 1) indentation in actual code is four spaces. this only produces 3. 2) the comments withing /* */ get malformed. CSS might be able to fix this problem, I'll look into instead of translating all spaces to nbsp; I'm not sure exactly why the original translations of '\n ' to 'brnbsp;' was there but I'm assuming its due to the behaviour of highlight_string(). [2004-10-19 05:08:37] [EMAIL PROTECTED] Whitespce in any element which hasn't set preserve to true will be ignored in most circumstances. Using nbsp; won't be ignored, or setting preserve-whitespace in the CSS. Then you can not use nbsp; at all. [2004-10-17 12:48:12] [EMAIL PROTECTED] Sorry for my stupidity, but I couldn't find where the problem is... and nor how the patch would fix the problem. The patch will also create a bigger page (by replacing ' nbsp;' with two nbsp;) [2004-10-17 06:25:38] [EMAIL PROTECTED] here is a patch to fix the white space issue: http://www.powertrip.co.za/livedocs/viewpatch.php?patch=17 [2004-10-17 04:48:02] [EMAIL PROTECTED] http://livedocs.zirzow.dyndns.org/index.php?l=enq=language.oop5.exceptions Look at the docblock, the first space is truncated. All the programlistings have 3 spaces for the first indent, though 4 are in the code. 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/30456 -- Edit this bug report at http://bugs.php.net/?id=30456edit=1
[PHP-DOC] #30204 [Opn-Csd]: hardcoded html in navigation needs to be removed.
ID: 30204 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Livedocs problem Operating System: * PHP Version: Irrelevant Assigned To: ilia New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-09-23 04:05:02] [EMAIL PROTECTED] Description: In order to generate a menu similar to php's, the generation of the menu needs to by flexible, Here is a patch that will allow this: http://www.powertrip.co.za/livedocs/viewpatch.php?patch=12 Summary of Changes: * create new constansts, that are defined in the html_format.php: NAV_TRUNCATE - 0 for no truncation, otherwise truncates at number specified. (defaults to 25) NAV_SPACE - the character to use for spaces between navigation words. (default nbsp;) NAV_START - html to be used before navigation should be started. NAV_END - html used after navigation NAV_CHILDREN_EMBEDED - where to place children navigation items. if true, under the currently selected item, otherwise at the end of the list. (defaults to false) * new optionional nav_item() function. used to wrap special html around a navigation element. * special css classes on navigation items that get folded. (header up home) * special css class on the last child,if CHILDREN_EMBEDED is true. -- Edit this bug report at http://bugs.php.net/?id=30204edit=1
[PHP-DOC] #30455 [Opn-Csd]: Livedocs strips HTML comments from source
ID: 30455
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type:Livedocs problem
PHP Version: Irrelevant
Assigned To: ilia
New Comment:
This bug has been fixed in CVS.
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2004-11-13 19:05:25] smileaf at ryalth dot com
stripping comments can be a problem if your wanting to use the w3c
recommendation to comment script data out for older browsers.
I'm experiencing this with php 5.0.2 using xsltprocessor
[2004-10-16 09:11:01] [EMAIL PROTECTED]
Yes, those lines can be removed safely.
[2004-10-16 07:02:34] [EMAIL PROTECTED]
Description:
Livedocs strips comments from files, which is a problem if you want to
add comments to HTML blocks in CDATA.
This is the offending line:
livedocs_funcs.php/213
/* strip comments */
$data = preg_replace('@!--\s+.*\s--@Usm', '', $data);
I'm not sure why this needs to be done, but perhaps it can be removed
or improved.
--
Edit this bug report at http://bugs.php.net/?id=30455edit=1
[PHP-DOC] #31616 [Opn-Csd]: Indexing system doesn't work on windows
ID: 31616 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Livedocs problem Operating System: n/a PHP Version: Irrelevant Assigned To: ilia New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-01-19 21:12:45] [EMAIL PROTECTED] Description: The current index system doesn't work corrently on windows/cygwin. Patch: http://livedocs.aborla.net/patch.php?id=windows.build Anyways, the indexing system should be rewriten, because the current is phpdoc specific. -- Edit this bug report at http://bugs.php.net/?id=31616edit=1
[PHP-DOC] #31238 [Ana]: pg_field_is_null fails for column with upper case name
ID: 31238 Updated by: [EMAIL PROTECTED] Reported By: phpdevel-no-spam at pv2c dot sk Status: Analyzed -Bug Type: PostgreSQL related +Bug Type: Documentation problem Operating System: * PHP Version: 4CVS, 5CVS (2004-12-22) Assigned To: sniper New Comment: This should be documented. Previous Comments: [2004-12-22 09:06:10] [EMAIL PROTECTED] I can verify this. It happens because the underlying PQfnumber() function tolower()'s the passed field name. You can avoid that by passing the name double-quoted: - if(pg_field_is_null($res, 0, $field)) + if(pg_field_is_null($res, 0, \$field\)) I have prepared a patch for this but it's up to the committee whether we will fix this in sources or in documentation. [2004-12-22 01:00:11] phpdevel-no-spam at pv2c dot sk Description: When calling pg_field_is_null() with 3. parameter the column name and it has upper case letters in it, an error is the result: PHP Warning: pg_field_is_null(): Bad column offset specified in bugtest.php on line 15 This bug was reproduced using PostgreSQL 7.4.6, PHP 4.3.10 PostgreSQL 7.4.6, PHP 4.3.9 PostgreSQL 7.4.6, PHP 4.3.10 using two different servers. This bug doesn't occur when the 3. parameter is column offset, or the column name contains only lover case letters. Reproduce code: --- http://www.pv2c.sk/php/bugtest.zip (1KB) Included is also a sample db creation script. Expected result: Just want to know if the column is NULL. Actual result: -- Just an warning. -- Edit this bug report at http://bugs.php.net/?id=31238edit=1
[PHP-DOC] #29712 [Opn-Ana]: ereg() does not return TRUE
ID: 29712 Updated by: [EMAIL PROTECTED] Reported By: liit at geeksbynature dot dk -Status: Open +Status: Analyzed -Bug Type: *Regular Expressions +Bug Type: Documentation problem Operating System: Gentoo Linux PHP Version: 4.3.8 New Comment: ereg() returns the length of the matched string on success, the documentation is wrong. Previous Comments: [2004-08-16 20:57:24] liit at geeksbynature dot dk Description: The function ereg() either returns (boolean)FALSE or (int)1, and not (boolean)FALSE or (boolean)TRUE Reproduce code: --- echo gettype(ereg(foo,foo)); echo gettype(ereg(foo,bar)); Expected result: boolean boolean Actual result: -- integer boolean -- Edit this bug report at http://bugs.php.net/?id=29712edit=1
[PHP-DOC] #29601 [Opn]: sqlite_query() return resource handles for non-row returning sql
ID: 29601
Updated by: [EMAIL PROTECTED]
Reported By: Jared dot Williams1 at ntlworld dot com
Status: Open
-Bug Type: SQLite related
+Bug Type: Documentation problem
Operating System: Windows 2000/IIS
PHP Version: 5CVS-2004-08-10 (dev)
New Comment:
Documentation problem.
Previous Comments:
[2004-08-10 16:06:50] Jared dot Williams1 at ntlworld dot com
Description:
It appears sqlite_query() and sqlite_unbuffered_query() differ from the
documentation
From http://uk.php.net/manual/en/function.sqlite-query.php
quote
For queries that return rows, this function will return a result handle
which can then be used with functions such as sqlite_fetch_array() and
sqlite_seek().
For other kinds of queries, this function will return a boolean result;
TRUE for success or FALSE for failure.
/quote
Seems a handle is returned irrespective of the type of query.
Reproduce code:
---
?php
$cnn = sqlite_open('Northwind.db');
if (is_resource($cnn))
{
var_dump(sqlite_unbuffered_query($cnn, 'DELETE FROM Categories WHERE
CategoryID 10'));
@sqlite_close($cnn);
}
?
Expected result:
bool(true)
Actual result:
--
resource(2) of type (sqlite result)
--
Edit this bug report at http://bugs.php.net/?id=29601edit=1
[PHP-DOC] #27361 [Opn]: strip_tags() doesn't fail on incomplete tag if there is non-html output before.
ID: 27361 Updated by: [EMAIL PROTECTED] Reported By: stu-php at better dot domain dot name Status: Open -Bug Type: Strings related +Bug Type: Documentation problem Operating System: Windows Server 2003 PHP Version: 5.0.0b4 (beta4) New Comment: The fact that strip_tags() does not validate HTML and can strip excess data when encountering incomplete tags should be documented. Previous Comments: [2004-02-23 16:57:12] stu-php at better dot domain dot name In one line, ok. strip_tags() doesn't error in the way it says it should on the function documentation page. That should be clear and concise enough. Take a look at http://better.domain.name/php/ and tell me if the files there represent expected outcomes of strip_tags() usage. [2004-02-23 16:55:25] stu-php at better dot domain dot name The function returns an error if there is text in one place, but NOT if there is text in another set of places, or nowhere at all. How is that NOT a bug? If I were relying on this function to give me accurate error information in an if statement or something then I wouldn't want it erroring if and when it felt like it. If it's supposed to strip html and error on invalid tags and then it goes ahead and fails to error because there is no text before the broken tag then there's a problem. Consider: http://better.domain.name/php/strips.phps The output has to be seen by viewing the source of http://better.domain.name/php/strips.php as it's completely erroneous output at the moment. Is that the expected behaviour? [2004-02-23 16:39:53] [EMAIL PROTECTED] Explain in one line what the bug is then...I don't see it either. [2004-02-23 16:36:36] stu-php at better dot domain dot name This is NOT a bogus bug. Just because the MAIN functionality of the function is there does not mean that there is not a bug here. The function behaves in an unexpected manner. That is a bug. If the documentation contradicts the actual function then something needs to be fixed. Either the documentation or the function code. [2004-02-23 13:54:24] [EMAIL PROTECTED] Try outputting the actual result of the strip_tags() and you'll see that it works perfectly. (strip_tags() is not any validator...whatever the docs say) 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/27361 -- Edit this bug report at http://bugs.php.net/?id=27361edit=1
[PHP-DOC] #23220 [Asn-Ana]: fgets() causes warning while reading data via SSL channel (HTTPS)
ID: 23220
Updated by: [EMAIL PROTECTED]
Reported By: storozhilov at mail dot ru
-Status: Assigned
+Status: Analyzed
-Bug Type: Filesystem function related
+Bug Type: Documentation problem
Operating System: *
PHP Version: 4CVS
Assigned To: wez
New Comment:
Marking as documentation problem. Some (IIS) non-standard
compliant servers send data in a way that causes PHP to
raise warnings. When working with such servers you should
lower your error_reporting level not to include warnings.
Previous Comments:
[2004-02-16 20:16:59] scottmacvicar at ntlworld dot com
Since this indeed an error but it will happen anytime you make an HTTPS
request to IIS i think the error should be changed to E_NOTICE and the
error message updated to what it actually does.
Patch
---
diff -u network.c network.c.patched
--- network.c 2004-02-17 01:20:49.0 +
+++ network.c.patched 2004-02-17 01:22:23.0 +
@@ -870,8 +870,8 @@
case SSL_ERROR_SYSCALL:
if (ERR_peek_error() == 0) {
if (nr_bytes == 0) {
- php_error_docref(NULL
TSRMLS_CC, E_WARNING,
- SSL: fatal
protocol error);
+ php_error_docref(NULL
TSRMLS_CC, E_NOTICE,
+ SSL: EOF
occurred in violation of protocol);
stream-eof = 1;
retry = 0;
} else {
[2004-02-16 19:58:27] scottmacvicar at ntlworld dot com
Found the cause of this now.
Its Microsoft's we can do what we want attituide in regards to IIS.
An EOF occured but the SSL close_notify message hasn't been sent.
I'll write a patch and post it tomorrow hopefully.
[2004-02-16 17:00:49] aaron_hawryluk at shaw dot ca
This also seems to cause a problem with file_get_contents which I am
using to retrieve transaction data. Test case is:
code?php
file_get_contents(https://any.secure.server;);
?/code
returns:
codeWarning: file_get_contents(): SSL: fatal protocol error in
/usr/local/www/data-dist/navdev/test.php on line 2/code
...plus whatever data the secure server provides.
[2004-02-04 18:48:37] douga at accessdata dot com
I am seeing the same error. It appears to be generated after the
following loop has completed. More specifically, the Warning message is
emitted just after the loop terminates.
while( !feof($handle) )
{
echo Looping to read in all of the reply.br;
$reply .= fgets($handle);
}
PHP 4.3.4 compiled with --with-openssl
What other information would be helpful?
[2004-01-27 12:58:26] admin at jazzfanz dot com
I'm sorry but I can't really tell based on this thread if there was
ever a version of PHP where this problem was corrected. Is there a
version?
I'm on 4.3.3 currently under IPlanet.
Is there a workaround without using cURL?
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/23220
--
Edit this bug report at http://bugs.php.net/?id=23220edit=1
[PHP-DOC] #26381 [Opn]: rand() without srand() doesn't work
ID: 26381 Updated by: [EMAIL PROTECTED] Reported By: spam at vrana dot cz Status: Open -Bug Type: Math related +Bug Type: Documentation problem Operating System: Windows XP PHP Version: 4.3.3 New Comment: Manual is wrong. Previous Comments: [2003-11-25 08:46:41] spam at vrana dot cz iliaa, please read the manual yourself before stating bugs as bogus. As I already wrote here, the manual says: As of PHP 4.2.0, there is no need to seed the random number generator with srand() or mt_srand() as this is now done automatically. [2003-11-25 08:41:49] [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 For random numbers you MUST call srand() before rand(). [2003-11-25 04:53:44] spam at vrana dot cz Unfortunately it behaves the same with Windows snapshots. For case it's not obvious from my fist comment - if I call srand() before rand() it works well. [2003-11-25 04:24:32] [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 Works fine for me within Windows XP, within Apache and CLI. [2003-11-24 08:21:33] spam at vrana dot cz Description: Function rand() without setting random seed by srand() returns always the same value. It doesn't work only on Windows PHP-CLI. As Windows Apache module and also on Linux PHP-CLI it works as it should. Reproduce code: --- echo rand(); Expected result: (random value) Actual result: -- 24849 -- Edit this bug report at http://bugs.php.net/?id=26381edit=1
[PHP-DOC] #26309 [Opn-Csd]: imageftbbox() requires the optional parameter
ID: 26309 Updated by: [EMAIL PROTECTED] Reported By: kputnam at putnamcabinets dot com -Status: Open +Status: Closed -Bug Type: GD related +Bug Type: Documentation problem Operating System: Debian GNU/Linux (Sid) PHP Version: 5.0.0b2 (beta2) New Comment: 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. This is a documentation problem. The imagettfbbox() allows the Previous Comments: [2003-11-19 01:02:06] kputnam at putnamcabinets dot com Description: The documentation shows that the last parameter is optional (extrainfo) but an error is generated when it is left out. Calling with an empty array as the last parameter resolves the issue. Reproduce code: --- $box = imageftbbox($size,$angle,$this-fonts[$font],$text); Actual result: -- PHP Warning: Wrong parameter count for imageftbbox() -- Edit this bug report at http://bugs.php.net/?id=26309edit=1
[PHP-DOC] #25997 [Opn-Ana]: Embedded null characters in strings breaks documented behavior of functions.
ID: 25997 Updated by: [EMAIL PROTECTED] Reported By: xodfull at starmen dot net -Status: Open +Status: Analyzed -Bug Type: *General Issues +Bug Type: Documentation problem Operating System: Linux, Apache. PHP Version: 4.3.3 New Comment: ip2long() works as advertised. However, if brought a very good point and this should be documented. For security, if ip2long() is used only for validation the IP should be escaped or should be used like this: $ip = long2ip(ip2long($ip)); Previous Comments: [2003-10-27 10:32:49] xodfull at starmen dot net Magic quotes needs to be disabled for this particular example to work. Anyway, I'm using RedHat's build of Linux 2.4.20, with Apache 1.3.28. [2003-10-27 02:03:03] [EMAIL PROTECTED] I've tested your code with 4.3.3, 4.3.4-CVS, 5-CVS and can't reproduce reasult you get (ip2long returns -1, as expected). Please, give more info about your OS Apache. [2003-10-26 22:32:27] xodfull at starmen dot net Description: ip2long() is supposed to return -1 on an invalid ip address. Because of PHP's method of storing strings, and a careless calling of standard C library functions that use null-terminated strings, it will not return -1 on invalid ip addresses that contain embedded null characters in appropriate places. The function ip2long() generates an IPv4 Internet network address from its Internet standard format (dotted string) representation. If ip_address is invalid than -1 is returned. Note that -1 does not evaluate as FALSE in PHP. Reproduce code: --- if(ip2long($_GET[ip]) != -1) echo($_GET[ip]); http://something.net/somescript.php?ip=127.0.0.1%00bfoo/b Expected result: Arbitrary HTML insertion. Worse effects may be possible depending on the application. -- Edit this bug report at http://bugs.php.net/?id=25997edit=1
[PHP-DOC] #25961 [Opn]: sem_get with fixed IDC_CREAT flag
ID: 25961 Updated by: [EMAIL PROTECTED] Reported By: daredevil at rozmova dot if dot ua Status: Open -Bug Type: Semaphore related +Bug Type: Documentation problem Operating System: FreeBSD, cygwin PHP Version: 4.3.3 New Comment: It seems strange that IPC_CREATE flag is always set, but it's removal will break backwards compatibility. The only way I see that this problem could be resolved is by adding another optional argument to the function, which would disable IPC_CREATE flag. Previous Comments: [2003-10-23 02:51:32] daredevil at rozmova dot if dot ua Description: in the sem_get function, according to the source code, semaphore *always* getting with IPC_CREATE flag. That is unnecessary in situations, when I wanna get an existing semaphore, not to create a new one. Also in the Documentation You should mention, that a PHP semaphore is really THREE of them! Because when writing an client-server app (php as a client platform ang C/C++ as a server platform), and a semaphore is created in C++ as semget(key, 1(!), IPC_CREATE | 0666) - I need onle one! When trying to reach it in php sem_get(key) php handles an ivalid argument exception because php wanna re-create the semaphore set from 1 to 3. -- Edit this bug report at http://bugs.php.net/?id=25961edit=1
[PHP-DOC] #20447 [Ver-Ana]: Register_shutdown_function - connection still open while registered shutdown...
ID: 20447
Updated by: [EMAIL PROTECTED]
Reported By: richardz at omniture dot com
-Status: Verified
+Status: Analyzed
-Bug Type: Scripting Engine problem
+Bug Type: Documentation problem
Operating System: RedHat 7.2
PHP Version: 4.2.3
New Comment:
This is a documtation problem.
Under certain condition you may infact be able to output data to the
browser from inside the register_shutdown_function handler.
Previous Comments:
[2003-05-04 03:08:25] [EMAIL PROTECTED]
Verified, its supposed to:
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().
The documentation is correct.
[2003-05-04 02:31:26] [EMAIL PROTECTED]
Is this a documentation problem or a php-bug?
According to some users the documented behaviour worked under PHP
4.1.0, but now the function behaves differently.
Could someone please check this?
[2003-01-16 12:14:43] firewire at itsyourdomain dot com
I to have run across this problem. I was hoping to use a registered
shutdown function to do some final fairly slow socket processing that
the client didn't need to see. My test case is as follows:
register_shutdown_function('sd');
function sd()
{
echo I shouldn't be seen;
sleep(5);
}
Causes the browser to echo text then sleep for 5 seconds before
completing the page. I also agree that the manual is incorrect. Is
there another way to force php to close the output stream so slower non
user related functions can be executed?
[2002-11-15 10:32:35] richardz at omniture dot com
My problem is that the connection to the browser is still open while
the registered shutdown functions are executing. The documentation
says that from the registered shutdown functions you WON'T be able to
echo or print or modify the contents of the buffer. I can...
Example:
using apache 1.3.27
php version 4.2.3
//
?
function doThing(){
for($i=0;$i10;$i++){
//just looping to demonstrate that the page hangs while
executing this function
}
echo PHP documentation says I shouldn't see this in my browser;
}
register_shutdown_function('doThing');
?
html
Test Page.
brbr
/html
I was hoping to register shutdown functions to do some cleanup -
without affecting the load time of the site. Apparently these
functions don't work that way?
--
Edit this bug report at http://bugs.php.net/?id=20447edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #24159 [Ver]: Php starts indexing from zero if lowest index is negative
ID: 24159 Updated by: [EMAIL PROTECTED] Reported By: rsen010 at ec dot auckland dot ac dot nz Status: Verified -Bug Type: Scripting Engine problem +Bug Type: Documentation problem Operating System: Any PHP Version: 4.3.2, 5.0.0b2-dev New Comment: This is a documentation issue. The change was made to avoid possible crashes. Previous Comments: [2003-08-03 19:40:43] [EMAIL PROTECTED] This behaviour was introduced in 4.3.0 - reclassifying as an array problem. I don't know if the behaviour or the documentation should be changed. [2003-06-12 15:38:20] rsen010 at ec dot auckland dot ac dot nz Description: Hi, When I was going through Chapter 7.types in PHP manual I found something confusing regarding the following statement Having e.g. the highest index being -6 will result in -5 being the new key (under Syntax specifying with array()).What actually happens is it Php starts indexing from zero if lowest index is negative value unless there is no index of zero. But amazing thing is sometimes it omit some values unless. Just consider the following examples. Ex:1 $a = array(-3='February', 'March'); print_r($a); This will prints out the folloiwng Array ( [-3] = February [0] = March ) Ex:2 $a = array( 'January', '0'='a','b', 'c',-3='February', 'March'); print_r($a); This will prints out the folloiwng Array ( [0] = a [1] = b [2] = c [-3] = February [3] = March ) Please be kind to check this out if Im correct and reply me. Thanks Naleen Reproduce code: --- $a = array(-3='February', 'March'); print_r($a); $a = array( 'January', '0'='a','b', 'c',-3='February', 'March'); print_r($a); Expected result: Array (-3=February, [-2] = March ); Array ( [1]=January [0] = a [2] = b [3] = c [-3] = February [4] = March ) Actual result: -- Array ([-3] = February [0] = March ) Array ( [0] = a [1] = b [2] = c [-3] = February [3] = March ) -- Edit this bug report at http://bugs.php.net/?id=24159edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #24220 [Opn-Csd]: String conversion to numbers in range()
ID: 24220 Updated by: [EMAIL PROTECTED] Reported By: minakov at bas-net dot by -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: WinXP PHP Version: 4.3.1 New Comment: 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. Previous Comments: [2003-06-17 05:39:05] [EMAIL PROTECTED] This is a doc problem. From PHP 4.1.0 and higher you can also use characters as a range... and the function effectively does range(2, 2) now (it takes the first character). [2003-06-17 05:32:25] minakov at bas-net dot by Description: I've found a bug with range in PHP 4.3.1; eg. print_r(range(2003, 2004)) != print_r(range(2003, 2004)); print_r(range(2003, 2004)) == print_r(range(2, 2)); Reproduce code: --- print_r(range(2003, 2004)); Expected result: Array ( [0] = 2003 [1] = 2004 ) Actual result: -- Array ( [0] = 2 ) -- Edit this bug report at http://bugs.php.net/?id=24220edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22908 [Opn-Bgs]: fatal error cannot open zlib.lib
ID: 22908 Updated by: [EMAIL PROTECTED] Reported By: kieran dot kennedy at esbi dot ie -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: windows 98 PHP Version: 4.3.1 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. dupe Previous Comments: [2003-03-26 09:40:03] kieran dot kennedy at esbi dot ie php.exe is not compilable using the instructions at /manual/en/install.windows.php#install.windows.build and the MS VC++ project file under /win32 for all 3 source versions: - latest version complete source (php-4.3.1) - PHP snapshots latest CVS (4.5.x-dev) - PHP snapshots latest CVS (5.0.x-dev) Symptom (on MS Windows 98 using MS VC++ 6): ... Configuration: php4dllts - Win32 Release_TS ... Linking... LINK : fatal error LNK1181: cannot open input file zlib.lib Error executing link.exe. php.exe - 1 error(s), 21 warning(s) -- Edit this bug report at http://bugs.php.net/?id=22908edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22907 [Opn-Bgs]: fatal error cannot open zlib.lib
ID: 22907 Updated by: [EMAIL PROTECTED] Reported By: kieran dot kennedy at esbi dot ie -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: windows 98 PHP Version: 4.3.1 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. dupe Previous Comments: [2003-03-26 09:40:00] kieran dot kennedy at esbi dot ie php.exe is not compilable using the instructions at /manual/en/install.windows.php#install.windows.build and the MS VC++ project file under /win32 for all 3 source versions: - latest version complete source (php-4.3.1) - PHP snapshots latest CVS (4.5.x-dev) - PHP snapshots latest CVS (5.0.x-dev) Symptom (on MS Windows 98 using MS VC++ 6): ... Configuration: php4dllts - Win32 Release_TS ... Linking... LINK : fatal error LNK1181: cannot open input file zlib.lib Error executing link.exe. php.exe - 1 error(s), 21 warning(s) -- Edit this bug report at http://bugs.php.net/?id=22907edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22906 [Opn-Bgs]: fatal error cannot open zlib.lib
ID: 22906 Updated by: [EMAIL PROTECTED] Reported By: kieran dot kennedy at esbi dot ie -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: windows 98 PHP Version: 4.3.1 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. dupe Previous Comments: [2003-03-26 09:39:54] kieran dot kennedy at esbi dot ie php.exe is not compilable using the instructions at /manual/en/install.windows.php#install.windows.build and the MS VC++ project file under /win32 for all 3 source versions: - latest version complete source (php-4.3.1) - PHP snapshots latest CVS (4.5.x-dev) - PHP snapshots latest CVS (5.0.x-dev) Symptom (on MS Windows 98 using MS VC++ 6): ... Configuration: php4dllts - Win32 Release_TS ... Linking... LINK : fatal error LNK1181: cannot open input file zlib.lib Error executing link.exe. php.exe - 1 error(s), 21 warning(s) -- Edit this bug report at http://bugs.php.net/?id=22906edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22405 [Opn-Bgs]: srthwrbg
ID: 22405 Updated by: [EMAIL PROTECTED] Reported By: dgilkison at lanter dot com -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: wun PHP Version: 4.2.3 New Comment: 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. Thank you for your interest in PHP. not a bug. Previous Comments: [2003-02-24 16:42:14] dgilkison at lanter dot com remove me from mailing -- Edit this bug report at http://bugs.php.net/?id=22405edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22008 [Opn]: fgetss : 0 vs false, html on multiple lines
ID: 22008
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: all
PHP Version: 4.3.0
New Comment:
I've tried the latest CVS and tried to fetch the page you've specified.
As far as I can tell the function had worked correctly, only non-html
output was displayed.
P.S. Philip the fgetss() function is supposed to handle tags that span
multiple lines, so that should not be a problem.
Previous Comments:
[2003-02-02 22:06:07] [EMAIL PROTECTED]
This is something to do with !DOCTYPE
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0//EN
http://www.w3.org/TR/REC-html40/strict.dtd;
seems to be causing problem.
Again PHP4.2.3 or earlier treats this without problem.
[2003-02-02 21:08:46] [EMAIL PROTECTED]
Thank you for your comments.
I found this problem only occurs when parsing specific html.
Please try the following URL to see my problem.
Thank you.
?php
$fp =
fopen(http://adds.aviationweather.gov/projects/adds/metars/index.php?metarIds=ksfo;,
r);
while (($line=fgetss($fp, 4096))!==FALSE) {
echo $line;
}
fclose($fp);
?
?php
$fp =
fopen(http://adds.aviationweather.gov/projects/adds/metars/index.php?metarIds=ksfo;,
r);
while (($line = strip_tags(fgets($fp, 4096)))!==FALSE) {
echo $line;
}
fclose($fp);
?
[2003-02-02 15:46:14] [EMAIL PROTECTED]
c) Add a note regarding the 'blank lines' comment from Ilia.
I don't think strip_tags() needs this note but maybe it does
(doubtful).
[2003-02-02 15:41:51] [EMAIL PROTECTED]
That or maybe a problem existed because it only gets/strips one line at
a time which makes dealing with html tags spanning multiple lines
not-so-good. So using this fgetss() example script vs
strip_tags(file_get_contents($url)) will yield different results.
Reclassifying as a doc problem for fgetss():
a) Add the 0 vs false entity
b) Add a warning regarding spanning html tags; offer an alternative
[2003-02-02 14:44:04] [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.
Thank you for your interest in PHP.
I think the problem you are seeing may stem from incorrect usage of the
fgetss() function. For that reason I am including a sample of a working
code for this function below
?php
$fp = fopen(http://bugs.php.net/bug.php?id=22008;, r);
while (($line = fgetss($fp, 4096)) !== FALSE) {
echo $line;
}
fclose($fp);
?
Note that the output of fgetss gets compared to false, this is very
important because it is quite likely that fgetss() will return 'blanks'
if the line only contains HTML data.
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/22008
--
Edit this bug report at http://bugs.php.net/?id=22008edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21964 [Opn]: Uploads of a file with size 0 bytes succeed.
ID: 21964 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Filesystem function related +Bug Type: Documentation problem Operating System: Solaris 8 PHP Version: 4.2.2 New Comment: I believe this was fixed in 4.2.3 and later. Previous Comments: [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=21964edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21774 [Opn]: Chokes on php_version.h during configure
ID: 21774 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: *Compile Issues +Bug Type: Documentation problem Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: It is a known issue that using non-gnu utilities may cause PHP install not to work. This should be documented. Previous Comments: [2003-01-20 10:25:30] [EMAIL PROTECTED] I've had problems with compiling php 4.3 on 4 different solaris 8 machines. Last thing you can see on the screen is 'Updated php_version.h'. At this point it just hangs, System load goes up to 1.00. A list of processes show a high cpu usage on 'tr'. ps looks like admin 26932 77.3 0.1 928 528 pts/2R 11:13:46 0:31 tr x- x_ top looks like 26932 admin1 00 928K 528K run 1:02 93.78% tr Solution. I was to install the GNU Textutils http://www.gnu.org/directory/textutils.html Works perfect. Figured this may help other users if the same problem occures -- Edit this bug report at http://bugs.php.net/?id=21774edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21116 [Opn-Ana]: where do I find optional dlls?
ID: 21116 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed -Bug Type: PHP options/info functions +Bug Type: Documentation problem Operating System: Windows PHP Version: 4.3.0RC3 New Comment: printer extension had proved to be unstable and therefor was dropped from PHP core and moved to PECL. PECL extensions are NOT bundled by default. The documentation for the extension should be either moved to the PECL documentation repository or have a clear inidicator regarding the fact that it was moved to PECL. Previous Comments: [2002-12-20 12:15:18] [EMAIL PROTECTED] I understand. I just wanted to point out the fact that it isn't there. The dll needs to be packaged in the binary rather than having to go look for it. Thanks for the info. [2002-12-20 12:04:09] [EMAIL PROTECTED] I'm not sure the policy of php.ini and extensions that aren't included in the windows distro (dlls) but regardless this is a php-dev question so am marking it as such. I don't think the php.ini entry should be removed though, I'm sure there are others and they are commented out. Also, this may have to do with PECL extensions being included or not. Btw, you can find this (and many other dlls) here: http://kromann.info/php4.php Changing summary to: Where do I find optional dlls? :) [2002-12-20 11:38:17] [EMAIL PROTECTED] In the ini file there is a php_printer.dll option under extensions. No such dll file exists in the extensions directory. This option just needs to be deleted out of the ini file. -- Edit this bug report at http://bugs.php.net/?id=21116edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20822 [Asn]: getimagesize() returning null instead of false
ID: 20822 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Documentation problem Operating System: linux PHP Version: 4.2.3 Assigned To: john New Comment: getimagesize() returns NULL only in one case and that being if invalid parameters are passed to the functions. For example calling getimagesize() without any parameters. Invalid files and so on, result in the documentated FALSE return value. Previous Comments: [2002-12-04 20:54:17] [EMAIL PROTECTED] maybe its also worth mentioning that getimagesize() spews out an error if the filesize() of the file is 0 bytes :/ - this isnt so nice :/ [2002-12-04 20:47:55] [EMAIL PROTECTED] cutting out from the php manual: If accessing the filename image is impossible, or if it isn't a valid picture, getimagesize() will return FALSE and generate a warning. ... when getimagesize() in fact returns NULL (atleast in 4.2.3 (debian unstable tree)) -- Edit this bug report at http://bugs.php.net/?id=20822edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19158 [Fbk-Csd]: [chm] bug on streams.basics.html
ID: 19158
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Closed
Bug Type: Documentation problem
Operating System: windows
PHP Version: 4.2.2
New Comment:
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.
User reports (via email) that the problem has been fixed.
Previous Comments:
[2002-10-31 13:58:19] [EMAIL PROTECTED]
Does the problem still exist in the latest version (10th edition) of
the chm manual?
[2002-08-28 17:31:32] [EMAIL PROTECTED]
I have found a bug on page streams.basics.html
[chm date: 2002-08-14]...
The following code is displayed so that certain lines overlap each
other.
php_stream * stream = php_stream_open_wrapper(http://www.php.net;,
rb, REPORT_ERRORS, NULL);
if (stream) {
while(!php_stream_eof(stream)) {
char buf[1024];
if (php_stream_gets(stream, buf, sizeof(buf))) {
printf(buf);
} else {
break;
}
}
php_stream_close(stream);
}
--
Edit this bug report at http://bugs.php.net/?id=19158edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20248 [Opn-Bgs]: q pt decis?
ID: 20248 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: win xp PHP Version: 4.2.3 New Comment: 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. Thank you for your interest in PHP. Previous Comments: [2002-11-04 11:52:53] [EMAIL PROTECTED] y vite' si tu hermana ta buena no s mi culpa q c la gargchen todos. Ademas, piter es un puto del ort!! y todos c garchan a la vieja y a la hemana. -- Edit this bug report at http://bugs.php.net/?id=20248edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #14260 [Opn-Bgs]: $HTTP_RAW_POST_DATA Manual Update
ID: 14260 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: ALL PHP Version: 4.0.6 New Comment: 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. Thank you for your interest in PHP. In most cases $HTTP_RAW_POST_DATA is not avaliable. It only becomes avaliable if the always_populate_raw_post_data ini option is enabled. Therefor it is not listed on the inidicated page. Previous Comments: [2001-11-27 21:12:03] [EMAIL PROTECTED] The bug ist that it appears to me that the Section in the PHP manual need some refreshment concerning built in PHP variables. For example if someone wants to use $HTTP_RAW_POST_DATA he wouldn't even know that he wants to use it since it is not in the manual section for this. perhaps someone updates this manual. Short script that reproduces the problem: #!/bin/bash lynx \ http://www.php.net/manual/de/language.variables.predefined.php ok, in this sense, cu :-) -- Edit this bug report at http://bugs.php.net/?id=14260edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18990 [Opn-Fbk]: [chm] general layout comment
ID: 18990 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4CVS-2002-08-20 New Comment: Is still still an issue in the 10th edition of the chm documentation avaliable from http://weblabor.hu/php-doc-chm/ ? Previous Comments: [2002-08-20 13:00:25] [EMAIL PROTECTED] [chm date: 2002-08-14]... Just a note about the layout of the high skin. I find having the function name and description together in the same part of the top bar quite confusing. I keep expecting the function definition to appear just under the bar. Perhaps at the top of the body, or in a separate bar below the description would be better. Either way, I find having it looking like just a second line of the description is misleading. -- Edit this bug report at http://bugs.php.net/?id=18990edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18756 [Asn-Fbk]: August Edition Format Poorly Designed
ID: 18756 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Feedback Bug Type: Documentation problem Operating System: Windows 2000 Server PHP Version: 4.2.2 Assigned To: derick New Comment: Is still still an issue in the 10th edition of the chm documentation avaliable from http://weblabor.hu/php-doc-chm/ ? Previous Comments: [2002-08-08 06:58:57] [EMAIL PROTECTED] will check when I'm back from vacation Derick [2002-08-07 08:49:57] [EMAIL PROTECTED] I had downloaded a fresh version at the time of my last comment ... 7 Aug 7:23am [2002-08-07 07:33:30] [EMAIL PROTECTED] So this is a bug in the CHM generation. Can you please download a newer version and check if the problem still exists? Derick, can you please look at this? [2002-08-07 07:27:12] [EMAIL PROTECTED] One other thing, when in an actual function document, if I click 'Locate' to locate the navigation location, it goes nowhere. There is no direct navigation to each function. I have to click through the function list to get to specific function documents. Documents cannot be reached by clicking in the navigation tree directly. [2002-08-07 07:23:14] [EMAIL PROTECTED] My TOC verbatim: Appendix K. Function Index Function Index My Function Index verbatim: PHP Manual Stig Sæther Bakken Alexander Aulbach Egon Schmid Jim Winstead Lars Torben Wilson Rasmus Lerdorf Andrei Zmievski Jouni Ahto Edited by Stig Sæther Bakken Egon Schmid This file was generated: Fri Aug 02 04:10:35 2002 Go to http://www.php.net/docs.php to get the actual version. Copyright © 1997, 1998, 1999, 2000, 2001, 2002 the PHP Documentation Group My Function List Function Index A abs() acos() acosh() addcslashes() addslashes() apache_child_terminate() apache_lookup_uri() apache_note() apache_request_headers() apache_response_headers() apache_setenv() array() array_change_key_case() array_chunk() array_count_values() array_diff() array_fill() array_filter() array_flip() array_intersect() array_key_exists() array_keys() array_map() array_merge() array_merge_recursive() array_multisort() array_pad() etc ... etc ... etc ... As shown above. Listed alphabetically. No grouping is shown. I'm not sure if the version I'm downloading is complete or not. 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/18756 -- Edit this bug report at http://bugs.php.net/?id=18756edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18935 [Opn-NoF]: I don't want the user notes.
ID: 18935
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: No Feedback
Bug Type: Documentation problem
Operating System: windows2k
PHP Version: 4.2.2
New Comment:
Is still still an issue in the 10th edition of the chm documentation
avaliable from http://weblabor.hu/php-doc-chm/ ?
Previous Comments:
[2002-08-26 08:44:32] [EMAIL PROTECTED]
Wez I tried that manual assignment and it does not work at all even in
IE5 it returns with an error if I try to put a nonexistent page in the
iframe. It works if the page exists. So it's even worse then the method
currently used... Doh...
[2002-08-17 06:01:24] [EMAIL PROTECTED]
Nothing has changed in user note loading, you probably upgraded your IE
from 5 to 6... BTW I'll try that manual assignment...
[2002-08-16 21:55:48] [EMAIL PROTECTED]
I dunno -- seems like something has changed in chm_sample_7 to cause
this problem. I went back to sample_6 and it's working perfectly
without any user notes.
[2002-08-16 16:38:12] [EMAIL PROTECTED]
You might find that manually assigning the src of the
iframe after the main page has loaded is a workable solution to this
problem.
[2002-08-16 14:21:40] [EMAIL PROTECTED]
We have reports about non-displaying manual pages because of missing
notes. Even if you have that notes file there,
pages without notes are not showed using some IE6 setups (not all!),
because IE6 puts the error message of an inline frame to the top
document for some reason. It's far not logical, and till now we were
unable to find a solution.
The quick fix if you would not like to see notes is to edit the
skins/greenlinks/style.css file. First delete the first few lines
causing the links to be green (so you get the lo skin ;), and then add
this:
#pageNotes { display: none; }
Then even when you have php_manual_notes.chm in place, the notes won't
appear.
This won't fix the problem with files which does not have notes (test
it with the CHM part for example). For that problem, I cannot provide
any solution.
The logical thing would be from IE6, is if a page is not found in an
iframe, the error is displayed in that iframe and not in the parent
document... Next week I'll take a summer break, and then I'll look into
this with at least releasing a test suite for IE6 users out there to
test for possible solutions...
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/18935
--
Edit this bug report at http://bugs.php.net/?id=18935edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18935 [NoF-Fbk]: I don't want the user notes.
ID: 18935 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Feedback Bug Type: Documentation problem Operating System: windows2k PHP Version: 4.2.2 Previous Comments: [2002-10-31 11:43:23] [EMAIL PROTECTED] Is still still an issue in the 10th edition of the chm documentation avaliable from http://weblabor.hu/php-doc-chm/ ? [2002-08-26 08:44:32] [EMAIL PROTECTED] Wez I tried that manual assignment and it does not work at all even in IE5 it returns with an error if I try to put a nonexistent page in the iframe. It works if the page exists. So it's even worse then the method currently used... Doh... [2002-08-17 06:01:24] [EMAIL PROTECTED] Nothing has changed in user note loading, you probably upgraded your IE from 5 to 6... BTW I'll try that manual assignment... [2002-08-16 21:55:48] [EMAIL PROTECTED] I dunno -- seems like something has changed in chm_sample_7 to cause this problem. I went back to sample_6 and it's working perfectly without any user notes. [2002-08-16 16:38:12] [EMAIL PROTECTED] You might find that manually assigning the src of the iframe after the main page has loaded is a workable solution to this problem. 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/18935 -- Edit this bug report at http://bugs.php.net/?id=18935edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19453 [Asn-Fbk]: [chm] bug on function.error-reporting.html
ID: 19453 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4.2.3 Assigned To: goba New Comment: Is still still an issue in the 10th edition of the chm documentation avaliable from http://weblabor.hu/php-doc-chm/ ? Previous Comments: [2002-09-17 09:54:41] [EMAIL PROTECTED] We are working on a solution for it. [2002-09-17 08:44:33] [EMAIL PROTECTED] I have found a bug on page function.error-reporting.html [chm date: 2002-08-28]... new manual wont copy .. copy to clipboard is not working -- Edit this bug report at http://bugs.php.net/?id=19453edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18411 [Opn-Bgs]: print_r(FALSE) not consistant with print_r(TRUE)
ID: 18411 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: W2K Professional PHP Version: 4.2.1 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thank you for your interest in PHP. Dupe of #19575. Even though this is an earlier report I am making it the 'bogus' one, since the 19575 is assigned to Goba and hopefuly will be fixed soon. Previous Comments: [2002-10-05 10:27:51] [EMAIL PROTECTED] TRUE has always been 1 and FALSE . To me it would be inconsistent if you did strlen(FALSE) and got TRUE, for example. It just needs to be documented better. [2002-07-18 09:39:48] [EMAIL PROTECTED] As the boolean page holds information on converting to boolean, I have expected this info to be found on the strings page, but it's not there ;) Though the integer page has info on converting to integer... So this should be explained on the strings page IMHO. [2002-07-18 09:27:14] [EMAIL PROTECTED] This is expected behavior, but I can not find this in the manual either (atleast not on http://www.php.net/manual/en/language.types.boolean.php). Making it a documentation problem. Derick [2002-07-18 09:09:10] [EMAIL PROTECTED] No doubt there is a reason for: print_r(TRUE)displays 1 print_r(FALSE) displays nothing But too me, it just seems inconsistant, bad practise and very confusing. I can find nothing in the documentation I have on, why it is like this, as the text indicates 0 is to FALSE as 1 is to TRUE. It is also obvious from your bug list, that the area of TRUE/FALSE and 1/0 has its problems. -- Edit this bug report at http://bugs.php.net/?id=18411edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #17324 [Opn-Fbk]: charset in polish chm is wrong
ID: 17324 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: win98 PHP Version: 4.2.1 New Comment: Does the problem still exist in the latest version (10th edition) of the chm manual? Previous Comments: [2002-05-21 02:13:27] [EMAIL PROTECTED] It's true. Additionaly, users can't search the manual because of incompatible charsets. I've investigated this problem about month ago. There is no other way to solve it than converting the whole manual to cp-1250 and changing meta before compiling chm. I hope it would be possible with the new version of chm. [2002-05-20 19:50:39] [EMAIL PROTECTED] codepage in polish chm is wrong. In head of all html files included into chm documentation charset is set to iso8952-2 but letters are written like this: Rozdzia#179; instead of Rozdzia³ But also in list on the left, polish letters are shown wrong despite of that are written ok. best regards Andrzej Korcala -- Edit this bug report at http://bugs.php.net/?id=17324edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #16398 [Opn-Bgs]: Eng. chm: Predefined constants is missing
ID: 16398 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Win2k PHP Version: 4.1.2 New Comment: 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. Thank you for your interest in PHP. Previous Comments: [2002-08-27 05:00:18] [EMAIL PROTECTED] The predefined constants are moved to different extension reference sections (where they belong). Only some core and standard constants should be listed there... [2002-08-26 15:08:48] [EMAIL PROTECTED] php_manual_en.chm downloaded 26 Aug 2002 is still missing Predefined Constants in the List of Reserved Words appendix. [2002-06-27 07:45:50] [EMAIL PROTECTED] status - open, changed reporter [2002-06-27 07:39:59] [EMAIL PROTECTED] I downloaded the manual today and this is still the case, that is Appendix G - Predefined constants is empty. [2002-05-10 15:55:31] [EMAIL PROTECTED] Can you try with the latest CHM? Derick 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/16398 -- Edit this bug report at http://bugs.php.net/?id=16398edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19158 [Opn-Fbk]: [chm] bug on streams.basics.html
ID: 19158
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Documentation problem
Operating System: windows
PHP Version: 4.2.2
New Comment:
Does the problem still exist in the latest version (10th edition) of
the chm manual?
Previous Comments:
[2002-08-28 17:31:32] [EMAIL PROTECTED]
I have found a bug on page streams.basics.html
[chm date: 2002-08-14]...
The following code is displayed so that certain lines overlap each
other.
php_stream * stream = php_stream_open_wrapper(http://www.php.net;,
rb, REPORT_ERRORS, NULL);
if (stream) {
while(!php_stream_eof(stream)) {
char buf[1024];
if (php_stream_gets(stream, buf, sizeof(buf))) {
printf(buf);
} else {
break;
}
}
php_stream_close(stream);
}
--
Edit this bug report at http://bugs.php.net/?id=19158edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19742 [Opn-Fbk]: [chm] bug on ref.domxml.html
ID: 19742 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4.2.1 New Comment: Does the problem still exist in the latest version (10th edition) of the chm manual? Previous Comments: [2002-10-03 19:37:18] [EMAIL PROTECTED] reclassified [2002-10-03 15:37:02] [EMAIL PROTECTED] Well, I am reading bugs of how to get the different objects and components of an xml document, and I have got a simply and fine solution that is like follow, ?php $my_xml_file = file(books.xml) or die(Error...br); $dom_tree = domxml_xmltree( $my_xml_file[0] ); echo DOMTREE loadedbr; print(pre); print_r( $dom_tree ); print(/pre); echo br\n; ? The best of it, you do not need the whole path to read the file and you get the whole description of your DOM. This is my books.xml file, ?xml version='1.0' encoding='UTF-8'?booksbookTitleLa peste/TitleAuthorAlbert Camus/AuthorPrice30/Price/book/books where the tree is listed in one only line. And here is what I get with the above php code, DOMTREE loaded DomDocument Object ( [name] = #document [url] = [version] = 1.0 [encoding] = UTF-8 [standalone] = -1 [type] = 9 [compression] = -1 [charset] = 1 [0] = 1 [1] = 8040992 [children] = Array ( [0] = DomElement Object ( [type] = 1 [tagname] = books [0] = 2 [1] = 8040880 [children] = Array ( [0] = DomElement Object ( [type] = 1 [tagname] = book [0] = 3 [1] = 8040784 [children] = Array ( [0] = DomElement Object ( [type] = 1 [tagname] = Title [0] = 4 [1] = 8040688 [children] = Array ( [0] = DomText Object ( [type] = 3 [name] = #text [content] = La peste [0] = 5 [1] = 8040608 ) ) ) [1] = DomElement Object ( [type] = 1 [tagname] = Author [0] = 6 [1] = 8040512 [children] = Array ( [0] = DomText Object ( [type] = 3 [name] = #text [content] = Albert Camus [0] = 7 [1] = 8048576 ) ) ) [2] = DomElement Object ( [type] = 1
[PHP-DOC] #18934 [Opn-Csd]: HTML page too wide
ID: 18934 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: N/A PHP Version: 4.2.2 Assigned To: imajes New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Appears to have been fixed, I can read the page just fine in 800x600 without any horizontal scroll bars. Previous Comments: [2002-08-16 14:27:33] [EMAIL PROTECTED] i'm actually fixing this. please don't say it's fixed when it's not :) [2002-08-16 04:49:44] [EMAIL PROTECTED] Hrm.. we should fix the already-fixed quick fix too... [2002-08-15 23:05:07] [EMAIL PROTECTED] Please use the printer-friendly version of PHP-Manual on low resolutions. [2002-08-15 23:04:26] [EMAIL PROTECTED] Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php [2002-08-15 21:41:22] [EMAIL PROTECTED] The webpage for some of the documentation is too wide to easily read on 800 x 600 monitors. (Please don't tell me to upgrade monitors. That is so MS-like.) One has to scroll right to left to read each line. An example is at: http://www.php.net/manual/en/language.variables.predefined.php Here, it appears that somebody put a long URL in the comments, which HTML cannot break. One solution would be to make the comments in a *seperate* HTML table container than the top description part. That way a fat comment table won't ruin the description table also. -- Edit this bug report at http://bugs.php.net/?id=18934edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19959 [Opn-Csd]: fgets, fgetc
ID: 19959 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: win32/linux PHP Version: 4.2.3 New Comment: 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. fgets() is now binary safe in latest CVS. Previous Comments: [2002-10-18 12:22:24] [EMAIL PROTECTED] yes [2002-10-17 12:35:24] [EMAIL PROTECTED] I assume you have used 'rb' for mode in fopen..? [2002-10-17 12:07:02] [EMAIL PROTECTED] Hi, maybe only a doc problem. fgetc seems to be binary safe, while fgets not. assume: fopen a lokal file, read it with fgetc or fgets, you'll get bogus results with fgets if the opened file contains \0 Friedhelm Betz -- Edit this bug report at http://bugs.php.net/?id=19959edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19200 [Asn-Csd]: dl() fails with E_ERROR when php is compiled with ZTS
ID: 19200
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: Documentation problem
Operating System: Linux 2.4.19
PHP Version: 4CVS-2002-08-30
Assigned To: ilia
New Comment:
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.
Made absolete by the change in CVS. dl() now returns E_WARNING and
fails when operating in a ZTS enviroment.
Previous Comments:
[2002-08-30 13:04:56] [EMAIL PROTECTED]
so checkout the phpdoc and fix it :)
[2002-08-30 12:47:30] [EMAIL PROTECTED]
The documentation mentions that dl() will fail with E_ERROR if
safe_mode is enabled or enable_dl is turned off. However, it does not
mention that if PHP is compiled with ZTS, dl() would also fail with
E_ERROR.
This means that if the user wants to handle dl() failure gracefuly
within their own script they must do the following check in their code,
before calling dl() function:
if( ini_get('safe_mode') || !ini_get('enable_dl') || ZEND_THREAD_SAFE )
{
echo The dl() functionality is not avaliablebr /\n;
}
--
Edit this bug report at http://bugs.php.net/?id=19200edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #14460 [Opn-Ver]: no bookmarks in PDF version
ID: 14460 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified Bug Type:Documentation problem PHP Version: 4.1.0 Previous Comments: [2002-06-17 14:27:42] [EMAIL PROTECTED] i think that is related to the size problems, the last chapters do not get rendered, TOC has some ?? entries in it and no bookmark list is generated when TOC is broken? [2002-01-22 10:25:37] [EMAIL PROTECTED] Bug or feature? =) [2001-12-12 11:03:32] [EMAIL PROTECTED] there're no bookmarks (left hand side) in the pdf manual. - almost unuseable... -- Edit this bug report at http://bugs.php.net/?id=14460edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19575 [Opn-Dup]: Boolean prints 1 for TRUE but nothing for FALSE
ID: 19575 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: Documentation problem Operating System: Red Hat Linux 7.2 PHP Version: 4.2.3 New Comment: Dupe of bug #18411 Previous Comments: [2002-09-24 06:56:43] [EMAIL PROTECTED] A boolean of TRUE will print as 1 whereas FALSE prints as This has caused me a problem since I had assume that TRUE would print as TRUE and FALSE would print as FALSE. Could you add this to the documentation. I could understand 1/0, TRUE/FALSE, but 1/ is not evident at first. I'd even suggest a change request that booleans print out as TRUE/FALSE (since booleans really should not be 1/0 integers or empty/non-empty strings but BOOLEANS) but I'm sure that would ge shot down. :) -- Edit this bug report at http://bugs.php.net/?id=19575edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #17069 [Opn-Csd]: Session register_globals
ID: 17069
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Windows 2000
PHP Version: 4.1.2
New Comment:
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.
Previous Comments:
[2002-08-23 08:04:52] [EMAIL PROTECTED]
I'm wondering if this is actually still true. Can anyone confirm this?
[2002-05-30 06:46:21] [EMAIL PROTECTED]
It's a mis-assumption that session_register()ing a global variable
put's it into $_SESSION in the same request.
Sessions never behaved this way.
The documentation should be clearer on this, reclassifying.
[2002-05-07 05:57:46] [EMAIL PROTECTED]
This code don't work properly:
?php
session_start();
if (get_cfg_var('register_globals')) {
if (!session_is_registered('step')) {
session_register(step);
$step = 0;
}
} else {
if (!isset($_SESSION['step'])) {
$_SESSION['step'] = 0;
}
}
echo $_SESSION['step']++;
echo session_encode();
?
brA HREF=?php echo $_SERVER['PHP_SELF']?Reload/A
If register_globals is On, reload will increment counter.
If register_globals is Off, session will read_only like.
It create session file with zero length. Any write not occurs.
session_encode() returns a empty string;
--
Edit this bug report at http://bugs.php.net/?id=17069edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #16685 [Opn-Ana]: safe_mode_include_dir check is not correct
ID: 16685
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
-Bug Type: Scripting Engine problem
+Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.2.0
New Comment:
Unless you specify / at the end PHP will allow any path that will be
begin with a specified string. Meaning that if /a/b/c is specified then
/a/b/cde will be allowed. A note about this exists for nearly all
directory limiting function, however it is absent from the docs on the
safe_mode_include_dir option. Consquently, I am making this report a
documentation issue.
Previous Comments:
[2002-04-18 12:32:11] [EMAIL PROTECTED]
I found that safe_mode_include_dir check is not correct.
Here's why:
resolved_name (the path in question) and ptr (a next directory from the
safe_mode_include_dir list) are compared so:
if (strncmp(ptr, resolved_name, strlen(ptr) ==0 )
let ptr=/var/www/script and resolved_name=/var/www/scripts
obviously, they will match though it's wrong.
It is necessary to add an extra check for trailing char
(valid one is either a slash or \0)
In fact, checking lengthes of those may save a bit CPU time
(especially with the long list).
Here's suggested patch (it also is available at
http://www.cf1.ru/~byg/patch/php/safe_mode_include_dir.patch
ftp://ftp.cf1.ru/pub/patches/php/safe_mode_include_dir.patch
):
--- main/fopen_wrappers.c.orig Thu Apr 18 21:40:57 2002
+++ main/fopen_wrappers.c Thu Apr 18 23:02:55 2002
@@ -233,6 +233,7 @@
char *ptr;
char *end;
char resolved_name[MAXPATHLEN];
+ int len;
/* Resolve the real path into resolved_name */
if (expand_filepath(path, resolved_name TSRMLS_CC) ==
NULL)
@@ -250,15 +251,20 @@
}
/* Check the path */
+len = strlen(ptr);
+ if (strlen(resolved_name) = len) {
#ifdef PHP_WIN32
- if (strncasecmp(ptr, resolved_name,
strlen(ptr)) == 0)
+ if (strncasecmp(ptr, resolved_name, len) ==
0)
#else
- if (strncmp(ptr, resolved_name, strlen(ptr)) ==
0)
+ if (strncmp(ptr, resolved_name, len) == 0)
#endif
- {
- /* File is in the right directory */
- efree(pathbuf);
- return 0;
+ {
+ if ((*(resolved_name + len) ==
DEFAULT_SLASH) || (*(resolved_name + len) == '\0')) {
+ /* File is in the right directory
*/
+ efree(pathbuf);
+ return 0;
+ }
+ }
}
ptr = end;
--
Edit this bug report at http://bugs.php.net/?id=16685edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18332 [Opn]: is_readable/is_writable/is_executable support under safe mode
ID: 18332 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: any PHP Version: 4.2.1 New Comment: In the current release of the manual is_readable/is_writable now mention the fact that they will not check safe_mode limitation. The is_executable however, still needs to be documented. Previous Comments: [2002-07-15 21:52:19] [EMAIL PROTECTED] I think stat function can be used to know actual permissions. is_* function supposed to return if current process can do something or not. IMO. We may need to change doc a bit. - Documentation Problem [2002-07-13 18:31:32] [EMAIL PROTECTED] It would be very useful if is_readable/is_writable/is_executable series of functions would work with safe mode. Currently is_writable() will report a file that in reality cannot be accessed undersafe mode is writeable, which is clearly misleading. At least, could the manual be modified in such a way as to document that those functions will not work properly under safe_mode. -- Edit this bug report at http://bugs.php.net/?id=18332edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19371 [Asn-Csd]: Pages containing version information which shouldn't
ID: 19371 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type:Documentation problem PHP Version: 4CVS-2002-09-12 Assigned To: hholzgra New Comment: 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. Previous Comments: [2002-09-12 05:12:12] [EMAIL PROTECTED] problem here is that refentry is used for both functions and the PCRE specs ... have to make the dsssl code more clever about it ... [2002-09-12 04:11:48] [EMAIL PROTECTED] Take a look at http://www.php.net/manual/en/pcre.pattern.modifiers.php and http://www.php.net/manual/en/pcre.pattern.syntax.php Those pages show up (unknown) right below the title and if I got Hartmuts patch right will read no version information, might be only in CVS in the future. Can we exclude this for these kind of pages? -- Edit this bug report at http://bugs.php.net/?id=19371edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19210 [Opn-Csd]: read_exif_data truncates JPEG comments to 198 characters
ID: 19210
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: RedHat 7.2/Linux 2.4.9
PHP Version: 4.1.2
New Comment:
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.
Previous Comments:
[2002-09-03 15:47:21] [EMAIL PROTECTED]
reclassified..
[2002-09-03 14:24:06] [EMAIL PROTECTED]
This is apparently resolved in 4.2.2. However, the layout of the
return array from read_exif_data has significantly changed, so I'm
going to have to rewrite my code. In particular, there is no array
element named 'Comments' which was present in 4.1.2 (and I can find no
mention of this change in the ChangeLog or a footnote in the current
online documentation).
In fact, the additional parameters do not even work in PHP 4.2. So
you have to code
$exif = @read_exif_data ($image, 0, true);
if (!isset($exif) || empty($exif)) {
// Fall back to PHP 4.1 read_exif_data()
$exif = read_exif_data ($image);
...
}
Someplace, a footnote to this effect would be nice. Should I open a
documentation bug?
[2002-09-03 13:15:59] [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-09-03 12:12:42] [EMAIL PROTECTED]
I should have posted a small test sample. I'm putting one up on my web
site at http://www.astrofoto.org/people/roland/bug.php. The image
being probed can be loaded from the URL
http://www.astrofoto.org/people/roland/20020716-1.05.jpg
[2002-09-03 12:05:51] [EMAIL PROTECTED]
I have a JPEG (*not* from a digital camera) to which I have added a
comment block using wrjpegcom. rdjepgcom confirms that the comment is
correct in the file. The length of the comment is about 345
characters.
When I read the comment back from PHP using read_exif_data, the length
is truncated at 198 characters. Note that JPEG comment blocks can be
up to 64k(!). The comment in question is all text, no ASCII nulls, so
I'm assuming this truncation is happening inside PHP.
--
Edit this bug report at http://bugs.php.net/?id=19210edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #16217 [Opn]: syslog functions and exit functions are buggy
ID: 16217 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Reproducible crash +Bug Type: Documentation problem Operating System: windows NT 4/ win2000 pro/server PHP Version: 4.2.1 New Comment: I cannot replicate the crash. However, there is a definate problem with the docs for openlog() functions. On win32 LOCAL_LOG0 through LOCAL_LOG7 are not avaliable. In fact the openlog line in the example returns a warning about the 3rd parameter being invalid. The openlog facilities should be better documented, mentioning which are *nix specific, win32 specific and which are common. Previous Comments: [2002-06-10 04:33:37] [EMAIL PROTECTED] platform : apache 1.3.24 / php 4.2.1 / w2k SP2 I test on php 4.2.1 and there are some difference. The exit function seem to not cause bug, but the closelog crash apache (drwatson is started...). This appear when i reload one or two times the script. all works fine when i comment closelog. No problem on linux [2002-03-22 04:29:02] [EMAIL PROTECTED] Crash appear with the php module, not with cgi version. with module and without extensions, apache always crash... So this bugs is related to apache module. I don't test with php 4.1.2 and on linux, it seems to be ok. [2002-03-22 04:01:06] [EMAIL PROTECTED] Does this also happen if you only use the CGI version on command line and as less modules (i.e. no ldp/oci8/whatever) as possible? [2002-03-22 03:22:58] [EMAIL PROTECTED] Hello, Apache crash on windows platform when i use syslog functions ( openlog, syslog, closelog) and exit(). the script is: 1: ?php 2: define_syslog_variables(); 3: openlog(Test, LOG_PID | LOG_PERROR, LOG_LOCAL0); 4: syslog(LOG_WARNING,Essai de log); 5: closelog(); 6: exit(); 7: ? if i comment line 5 and 6, it's works fine. if i comment line 3, 4, 5 , apache crash after few reload or navigation between index page and this script. if i comment line 6, apache crash in the same case as above... config: w2k pro sp2 apache 1.3.22 ( start in commmand line or as service ) php 4.1.1 + ldap + oci8 (8.1.7) win nt 4 sp 6 apache 1.3.22 php 4.1.0 + ldap + oci8 (8.1.6) thanks for your comment. -- Edit this bug report at http://bugs.php.net/?id=16217edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #16217 [Opn]: syslog functions and exit functions are buggy
ID: 16217 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: windows NT 4/ win2000 pro/server PHP Version: 4.2.1 New Comment: Actually that's LOG_LOCAL0 through LOG_LOCAL7 that are not avaliable. I made a typo in my previous comment. Previous Comments: [2002-08-30 14:35:06] [EMAIL PROTECTED] I cannot replicate the crash. However, there is a definate problem with the docs for openlog() functions. On win32 LOCAL_LOG0 through LOCAL_LOG7 are not avaliable. In fact the openlog line in the example returns a warning about the 3rd parameter being invalid. The openlog facilities should be better documented, mentioning which are *nix specific, win32 specific and which are common. [2002-06-10 04:33:37] [EMAIL PROTECTED] platform : apache 1.3.24 / php 4.2.1 / w2k SP2 I test on php 4.2.1 and there are some difference. The exit function seem to not cause bug, but the closelog crash apache (drwatson is started...). This appear when i reload one or two times the script. all works fine when i comment closelog. No problem on linux [2002-03-22 04:29:02] [EMAIL PROTECTED] Crash appear with the php module, not with cgi version. with module and without extensions, apache always crash... So this bugs is related to apache module. I don't test with php 4.1.2 and on linux, it seems to be ok. [2002-03-22 04:01:06] [EMAIL PROTECTED] Does this also happen if you only use the CGI version on command line and as less modules (i.e. no ldp/oci8/whatever) as possible? [2002-03-22 03:22:58] [EMAIL PROTECTED] Hello, Apache crash on windows platform when i use syslog functions ( openlog, syslog, closelog) and exit(). the script is: 1: ?php 2: define_syslog_variables(); 3: openlog(Test, LOG_PID | LOG_PERROR, LOG_LOCAL0); 4: syslog(LOG_WARNING,Essai de log); 5: closelog(); 6: exit(); 7: ? if i comment line 5 and 6, it's works fine. if i comment line 3, 4, 5 , apache crash after few reload or navigation between index page and this script. if i comment line 6, apache crash in the same case as above... config: w2k pro sp2 apache 1.3.22 ( start in commmand line or as service ) php 4.1.1 + ldap + oci8 (8.1.7) win nt 4 sp 6 apache 1.3.22 php 4.1.0 + ldap + oci8 (8.1.6) thanks for your comment. -- Edit this bug report at http://bugs.php.net/?id=16217edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #14668 [Opn-Bgs]: wrong bit arithmetics
ID: 14668 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: SuSE Linux 7.1 PHP Version: 4.1.0 New Comment: 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 You are using ip2long, which in many cases will return a interger value greater then 2147483647 (on 32 bit machines). Since, PHP normally treats numbers as signed, numbers greater then 2147483647 become negative. The solution to your problem would be to use sprintf(%u, base_convert(ip2long(255.255.0.255 ) ^ 0x, 10, 2 )); This will tell php to treat the number as an unsigned integer, allowing it to go as high as 4294967295, which is largest value ip2long can possibly return. Previous Comments: [2002-05-04 00:13:42] [EMAIL PROTECTED] Don't use ip2long/long2ip. It just dosen't work. Do it by yourself with bcmath. Manual page should clearly note the limitation. Changed to doc problem to see if manual is ok. [2001-12-23 06:55:25] [EMAIL PROTECTED] Hi, using ip2long is strange enough itself (would you please do some better description on what I get out after calling this function or at least do some references to documents (RFCs) describing that IP address in full length notation format). Anyhow: I'm coding the following ?php $a = base_convert( 0x ^ 1, 10 2 ); var_dump( $a ); ? and get string(2) 10 (under 4.0.6 I got something different: 31 () 1's in string without that trailing 0) what about all the other leading bits that should be 1? And in relation with the ip2long-trouble I'm having: ?php $a = base_convert( ip2long( 255.255.0.255 ), 10, 2 ); $b = base_convert( ip2long( 255.255.0.255 ) ^ 0x, 10, 2 ); var_dump( $a, $b ); ? what gives me string(16) 0001 string(16) I beg to get some fast response! This behaviour of ip2long and/or xor-operator is too strange to be easily understood after reading that minimal function reference entry. But I need it a lot for some work that needs to be done urgently!! Thank you very much! Regards, Thomas Urban -- Edit this bug report at http://bugs.php.net/?id=14668edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #10374 [Opn-Bgs]: Depreciated features or not
ID: 10374 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: 4.0.4pl1 New Comment: Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. There are no set dates or release numbers for when legacy function will be removed. As far as I know PHP4 still supports many functions that were marked as legacy back in 3.X days. If/When a function will be removed be assured it will be noted in the release notes for that version. Previous Comments: [2001-04-18 03:39:37] [EMAIL PROTECTED] There are features/functions that are depreciated or going to be depreciated. It is nice to see what is depreciated and is going to be depreciated in the PHP Manual. (Although, there is Migrating from section. List of them would be nice and some of them is not docuemented. There aren't many as far as I know especially after 4.0.0.) I guess depreciated feature/function/etc are not on the manual, but it hard to tell w/o document if they are just not documented or depreciated and deleted. It would be also nice to encourage/discourage use of feature/function/etc for current/future release. Examples are: - accessing string as array and modify string as array - ?php_track_vars? (It's in NEWS and user could know it's depreciated, though) - set_nonblock() - Assoc array index without quote. For example, $str = This is $arr[element] and you will NOT see warning with E_ALL and this works; - track_vars always on for 4.0.3(It's in NEWS, though) - magic_quote = off in php.ini for 4.1? -- Edit this bug report at http://bugs.php.net/?id=10374edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #11618 [Ana-Csd]: session and form data
ID: 11618 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type: Documentation problem Operating System: linux 2.2.16-22 PHP Version: 4.0.4 New Comment: Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. The manual now contains clear exmaples of headers that should be sent to prevent caching of both HTTP/1.0 and HTTP/1.1 connections. Previous Comments: [2002-02-08 08:33:13] [EMAIL PROTECTED] Ok. Try telnetting to that page telnet yoursite.com 80 Type: HEAD /thepage.php HTTP/1.1 Host: yoursite.com Obviously replace thepage.php and yoursite.com with your actual site. See what the headers are (especially the Pragma: or Cache-Control headers) [2002-02-07 22:41:59] [EMAIL PROTECTED] To answer the most recent question from alindeman (I apologize, but I do not know your name): The mention of nocache isn't exactly just HTTP/1.0, however the Pragma header in fact is unique to HTTP/1.0 and was only included in HTTP/1.1 to maintain backwards compatibility. No directives exist for this header except nocache. HTTP/1.1 introduces the Cache-Control header, and with it comes many available directives. In fact, nocache is still one of these. I'm honestly not sure how the session_cache_limiter is implemented at the protocol level, but I can try to figure it out if it would be helpful to you. guo_feng: Though from your brief account I would say that you have now chosen the most appropriate value for session_cache_limiter (assuming it affects the value of the Cache-Control header), I would suggest learning more about it so that you feel more confident in your implementation. To briefly answer your question, however, public basically declares that the content may be cached by anything. Private has a bit more unclear definition to me (you might find more clarification in your research), but it basically allows caching but not in a shared cache. An example of a shared cache would be a proxy that many people are connected to, so the content might be considered a bit too sensitive to be accidentally returned to another user. Hope that helps. Thanks for all your help guo_feng. Chris [2002-02-07 19:33:35] [EMAIL PROTECTED] Wasn't nocache a HTTP/1.0 thing? Is must-revalidate the HTTP/1.1 equivilant? Can anybody verify this so that I can do something with the docs. [2001-06-23 06:35:20] [EMAIL PROTECTED] reclassified as documentation problem. This should be explained better in the manual. [2001-06-22 12:57:37] [EMAIL PROTECTED] I have solve the problem when I set session.cache_limiter =must-revalidate But I don't why!Can somebody tell me? 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/11618 -- Edit this bug report at http://bugs.php.net/?id=11618edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
