[PHP-DOC] #32679 [Opn-Bgs]: There is a version numbering problem within some of the documentation.
ID: 32679 Updated by: [EMAIL PROTECTED] Reported By: compnerd at gmail dot com -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: It's no typo, we can simply predict the future. :) Rather than update the tense on every version we simply document everything as is. This is documented: http://php.net/manual/en/about.phpversions.php Previous Comments: [2005-04-12 07:39:11] compnerd at gmail dot com Description: Well, I was browsing the documentation and I came across a line that says since PHP version 5.1.0 and it shocked me. I thought I had the newest being 5.0.3, which is still not the newest. But, there is no version 5.1.0. And, with doing a Google search of the Entire Documentation, it appears a lot. I think it is a simple typo, but thought someone should know. I'm sorry if I didn't see another bug listed with this problem. I did search and couldn't find one. http://www.google.com/search?q=5.1.0+site:www.php.netl=en -- Edit this bug report at http://bugs.php.net/?id=32679edit=1
[PHP-DOC] cvs: phpdoc /en/appendices about.xml
philip Tue Apr 12 03:19:49 2005 EDT Modified files: /phpdoc/en/appendices about.xml Log: Mention that features are added in major releases, not minor ones. And that the manual is written in present, not future tense. Although this won't eliminate bugs like #32679 it may help. http://cvs.php.net/diff.php/phpdoc/en/appendices/about.xml?r1=1.40r2=1.41ty=u Index: phpdoc/en/appendices/about.xml diff -u phpdoc/en/appendices/about.xml:1.40 phpdoc/en/appendices/about.xml:1.41 --- phpdoc/en/appendices/about.xml:1.40 Tue Mar 1 11:04:18 2005 +++ phpdoc/en/appendices/about.xml Tue Apr 12 03:19:49 2005 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.40 $ -- +!-- $Revision: 1.41 $ -- appendix id=about titleAbout the manual/title @@ -281,6 +281,12 @@ is 4.3.x). Most of the time, this is not an error in the documentation. Explanation is often added for features not available in the current PHP release, but which will be available in a known future PHP version. + Typically, PHP only adds new features in major releases otherwise only bugs + are fixed. Using the A.B.C versioning format, a major release increments A + or B whereas minor releases increment C. So for example it's not uncommon + for a feature to be documented as available in PHP x.1.x when the latest + release is PHP x.0.x. Also note that the manual is written in present + tense, not future tense. /para para Many times the PHP manual lists Default Values for PHP directives. These
[PHP-DOC] cvs: phpdoc /en/language types.xml
vrana Tue Apr 12 03:40:56 2005 EDT Modified files: /phpdoc/en/language types.xml Log: Floats in array key (bug #32671) http://cvs.php.net/diff.php/phpdoc/en/language/types.xml?r1=1.152r2=1.153ty=u Index: phpdoc/en/language/types.xml diff -u phpdoc/en/language/types.xml:1.152 phpdoc/en/language/types.xml:1.153 --- phpdoc/en/language/types.xml:1.152 Tue Apr 5 08:20:44 2005 +++ phpdoc/en/language/types.xmlTue Apr 12 03:40:55 2005 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.152 $ -- +!-- $Revision: 1.153 $ -- chapter id=language.types titleTypes/title @@ -1336,7 +1336,9 @@ be interpreted as such (i.e. literal8/literal will be interpreted as literal8/literal, while literal08/literal will be interpreted as - literal08/literal). There are no different indexed and + literal08/literal). + Floats in varnamekey/varname are truncated to typeinteger/type. + There are no different indexed and associative array types in PHP; there is only one array type, which can both contain integer and string indices. /para
[PHP-DOC] cvs: phpdoc /en/reference/funchand/functions register-shutdown-function.xml
vrana Tue Apr 12 03:58:43 2005 EDT Modified files: /phpdoc/en/reference/funchand/functions register-shutdown-function.xml Log: Clarify that OB functions can't be used in the shutdown function (bug #32665) http://cvs.php.net/diff.php/phpdoc/en/reference/funchand/functions/register-shutdown-function.xml?r1=1.10r2=1.11ty=u Index: phpdoc/en/reference/funchand/functions/register-shutdown-function.xml diff -u phpdoc/en/reference/funchand/functions/register-shutdown-function.xml:1.10 phpdoc/en/reference/funchand/functions/register-shutdown-function.xml:1.11 --- phpdoc/en/reference/funchand/functions/register-shutdown-function.xml:1.10 Wed Mar 23 05:38:20 2005 +++ phpdoc/en/reference/funchand/functions/register-shutdown-function.xml Tue Apr 12 03:58:41 2005 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.10 $ -- +!-- $Revision: 1.11 $ -- !-- splitted from ./en/functions/funchand.xml, last change in rev 1.1 -- refentry id=function.register-shutdown-function refnamediv @@ -36,8 +36,8 @@ buffers using functionob_get_contents/function. Since PHP 4.1, the shutdown functions are called as the part of the request so that it's possible to send the output from them. There is - currently no way to process the data after the request has been - completed. + currently no way to process the data with output buffering functions in + the shutdown function. /para para As of PHP 4, it is possible to pass parameters to the shutdown function by
[PHP-DOC] cvs: phpdoc /en/reference/funchand/functions register-shutdown-function.xml
vrana Tue Apr 12 04:07:47 2005 EDT Modified files: /phpdoc/en/reference/funchand/functions register-shutdown-function.xml Log: Shutdown function is called after closing OB (bug #32648) http://cvs.php.net/diff.php/phpdoc/en/reference/funchand/functions/register-shutdown-function.xml?r1=1.11r2=1.12ty=u Index: phpdoc/en/reference/funchand/functions/register-shutdown-function.xml diff -u phpdoc/en/reference/funchand/functions/register-shutdown-function.xml:1.11 phpdoc/en/reference/funchand/functions/register-shutdown-function.xml:1.12 --- phpdoc/en/reference/funchand/functions/register-shutdown-function.xml:1.11 Tue Apr 12 03:58:41 2005 +++ phpdoc/en/reference/funchand/functions/register-shutdown-function.xml Tue Apr 12 04:07:46 2005 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.11 $ -- +!-- $Revision: 1.12 $ -- !-- splitted from ./en/functions/funchand.xml, last change in rev 1.1 -- refentry id=function.register-shutdown-function refnamediv @@ -38,6 +38,10 @@ request so that it's possible to send the output from them. There is currently no way to process the data with output buffering functions in the shutdown function. + Shutdown function is called after closing all opened output buffers thus, + for example, its output will not be compressed if link + linkend=ini.zlib.output-compressionzlib.output_compression/link is + enabled. /para para As of PHP 4, it is possible to pass parameters to the shutdown function by
Re: [PHP-DOC] cvs: phpdoc /dsssl html-common.dsl
Gabor Hojtsy wrote: The substring match can be easily abstracted, so more checks can be made (and it can be done not only in HTML, but also in other outputs). Let me know what you think. Wow. Can you please remove version info also from streams.*? Jakub Vrana
[PHP-DOC] #32679 [Bgs]: There is a version numbering problem within some of the documentation.
ID: 32679 User updated by: compnerd at gmail dot com Reported By: compnerd at gmail dot com Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: I'm sorry to have placed this in. I should have found that, but of course, I didn't. Previous Comments: [2005-04-12 08:16:44] [EMAIL PROTECTED] It's no typo, we can simply predict the future. :) Rather than update the tense on every version we simply document everything as is. This is documented: http://php.net/manual/en/about.phpversions.php [2005-04-12 07:39:11] compnerd at gmail dot com Description: Well, I was browsing the documentation and I came across a line that says since PHP version 5.1.0 and it shocked me. I thought I had the newest being 5.0.3, which is still not the newest. But, there is no version 5.1.0. And, with doing a Google search of the Entire Documentation, it appears a lot. I think it is a simple typo, but thought someone should know. I'm sorry if I didn't see another bug listed with this problem. I did search and couldn't find one. http://www.google.com/search?q=5.1.0+site:www.php.netl=en -- Edit this bug report at http://bugs.php.net/?id=32679edit=1
[PHP-DOC] #32661 [Opn-Csd]: Wrong french translation of ENT_NOQUOTES in html_entity_decode
ID: 32661 Updated by: [EMAIL PROTECTED] Reported By: webmaster at colder dot ch -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. fixed by dams Previous Comments: [2005-04-10 23:26:25] webmaster at colder dot ch Description: The french translation of html_entity_decode() contains a mistake on the description of the constant ENT_NOQUOTES. Expected result: ENT_NOQUOTESIgnore les guillemets doubles et les guillemets simples Actual result: -- ENT_NOQUOTESConvertit les guillemets simples et ignore les guillemets doubles. -- Edit this bug report at http://bugs.php.net/?id=32661edit=1
[PHP-DOC] #32156 [NEW]: [DOC] French : Ocirc
From: jsgoupil at lookstrike dot com Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: [DOC] French : Ocirc Description: fr/reference/array/functions/array-merge.xml $Revision : 1.27 $ It displays on PHP.net : trapézoOcirc;de On livedocs : trapézophpdoc_include ref=Ocirc/de In the code and in the display of the example. Furthermore, I think it is icirc and not Ocirc ? Jean-Sébastien Goupil -- Edit bug report at http://bugs.php.net/?id=32156edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32156r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32156r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32156r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32156r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32156r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32156r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32156r=needscript Try newer version: http://bugs.php.net/fix.php?id=32156r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32156r=support Expected behavior: http://bugs.php.net/fix.php?id=32156r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32156r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32156r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32156r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32156r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32156r=dst IIS Stability: http://bugs.php.net/fix.php?id=32156r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32156r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32156r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32156r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32156r=mysqlcfg
[PHP-DOC] #32154 [NEW]: [DOC] French : PHP Tag
From: jsgoupil at lookstrike dot com Operating system: WinXP PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: [DOC] French : PHP Tag Description: fr/reference/strings/functions/ucfirst.xml $Revision : 1.11 $ Il manque les tags ?php et ? et la coloration syntaxique. -- Edit bug report at http://bugs.php.net/?id=32154edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32154r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32154r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32154r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32154r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32154r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32154r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32154r=needscript Try newer version: http://bugs.php.net/fix.php?id=32154r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32154r=support Expected behavior: http://bugs.php.net/fix.php?id=32154r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32154r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32154r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32154r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32154r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32154r=dst IIS Stability: http://bugs.php.net/fix.php?id=32154r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32154r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32154r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32154r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32154r=mysqlcfg
[PHP-DOC] #32277 [NEW]: Bogus example given for array_merge()
From: a at b dot c dot de Operating system: N/A PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: Bogus example given for array_merge() Description: Para 3 of the text reads: If only one [associative] array is given ... duplicate entries will be merged into the last one. See example three for details. And example 3 shows: $array_two = array(jay = bob, randal = dante, jay = jason); $result_two = array_merge($array_two); print_r($result_two); Since when has an associative array been able to contain duplicated keys (jay, in this case)? The array_merge() in the given example is a complete no-op, as a print_r($array_two) shows. Since duplicate entries never occur in associative arrays, there doesn't seem to be much point discussing what happens when array_merge() encounters them. -- Edit bug report at http://bugs.php.net/?id=32277edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32277r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32277r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32277r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32277r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32277r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32277r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32277r=needscript Try newer version: http://bugs.php.net/fix.php?id=32277r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32277r=support Expected behavior: http://bugs.php.net/fix.php?id=32277r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32277r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32277r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32277r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32277r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32277r=dst IIS Stability: http://bugs.php.net/fix.php?id=32277r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32277r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32277r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32277r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32277r=mysqlcfg
[PHP-DOC] #32025 [NEW]: ca.php.net redirect is borked
From: no-need at to dot email dot me Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: ca.php.net redirect is borked Description: When I visit a page such as http://php.net/unset I am redirected to http://ca.php.net/unset which is fine but for the fact that ca.php.net has been down for about 24 hours now. I am able to load ca2.php.net and ca3.php.net fine. The redirect system should be updated periodically with a list of currently active mirrors. /Chad -- Edit bug report at http://bugs.php.net/?id=32025edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32025r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32025r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32025r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32025r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32025r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32025r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32025r=needscript Try newer version: http://bugs.php.net/fix.php?id=32025r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32025r=support Expected behavior: http://bugs.php.net/fix.php?id=32025r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32025r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32025r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32025r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32025r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32025r=dst IIS Stability: http://bugs.php.net/fix.php?id=32025r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32025r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32025r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32025r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32025r=mysqlcfg
[PHP-DOC] #32294 [NEW]: Intval doc doesn't mention return value
From: mpr at er dot dtu dot dk Operating system: Irrelevant PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: Intval doc doesn't mention return value Description: Intval documentation doesn't mention what the return value of intval applied to a non-nummeric string will be. Ie. Doesn't mention that intval(this is not a number, and can never be interpreted as one); will return -1. Furthermore there's quite a few user contributed notes, that deal with intvals return value being undefined in case of integer overflow. This, IMHO, should be documented too. -- Edit bug report at http://bugs.php.net/?id=32294edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32294r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32294r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32294r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32294r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32294r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32294r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32294r=needscript Try newer version: http://bugs.php.net/fix.php?id=32294r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32294r=support Expected behavior: http://bugs.php.net/fix.php?id=32294r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32294r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32294r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32294r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32294r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32294r=dst IIS Stability: http://bugs.php.net/fix.php?id=32294r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32294r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32294r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32294r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32294r=mysqlcfg
[PHP-DOC] #32520 [NEW]: inet_ntop manual page has the wrong example
From: shimi at shimi dot net Operating system: PHP version: 5CVS-2005-03-31 (dev) PHP Bug Type: Documentation problem Bug description: inet_ntop manual page has the wrong example Description: In http://www.php.net/manual/en/function.inet-ntop.php : Example is for function inet_pton, while the page is about the function inet_ntop. P.S. Shame that Irrelevant is no longer an option for PHP Version. If you ask me, errors on the website shouldn't matter the PHP version I am using (if, at all, I'm using), so I just choosed one of them randomally. -- Edit bug report at http://bugs.php.net/?id=32520edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32520r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32520r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32520r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32520r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32520r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32520r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32520r=needscript Try newer version: http://bugs.php.net/fix.php?id=32520r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32520r=support Expected behavior: http://bugs.php.net/fix.php?id=32520r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32520r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32520r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32520r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32520r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32520r=dst IIS Stability: http://bugs.php.net/fix.php?id=32520r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32520r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32520r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32520r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32520r=mysqlcfg
[PHP-DOC] #32335 [NEW]: Class Details for Object Iterator is missing
From: andreas dot lange at haas-media dot de Operating system: PHP version: 5.0.3 PHP Bug Type: Documentation problem Bug description: Class Details for Object Iterator is missing Description: http://www.php.net/manual/en/language.oop5.iterations.php There should be a detailed description of the Iterator Interface. The following information is missing: methods, what return values are valid. Best Regards Andreas Lange -- Edit bug report at http://bugs.php.net/?id=32335edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32335r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32335r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32335r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32335r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32335r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32335r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32335r=needscript Try newer version: http://bugs.php.net/fix.php?id=32335r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32335r=support Expected behavior: http://bugs.php.net/fix.php?id=32335r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32335r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32335r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32335r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32335r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32335r=dst IIS Stability: http://bugs.php.net/fix.php?id=32335r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32335r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32335r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32335r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32335r=mysqlcfg
[PHP-DOC] #32044 [NEW]: Problem with String conversion to numbers example in polish doc
From: mrkwdk at vp dot pl Operating system: windows PHP version: 4.3.10 PHP Bug Type: Documentation problem Bug description: Problem with String conversion to numbers example in polish doc Description: The problem is with the type returning - it should be double or float. Reproduce code: --- $foo = 10.0 winek + 1;// $foo jest typu integer (11) -- Edit bug report at http://bugs.php.net/?id=32044edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32044r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32044r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32044r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32044r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32044r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32044r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32044r=needscript Try newer version: http://bugs.php.net/fix.php?id=32044r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32044r=support Expected behavior: http://bugs.php.net/fix.php?id=32044r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32044r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32044r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32044r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32044r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32044r=dst IIS Stability: http://bugs.php.net/fix.php?id=32044r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32044r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32044r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32044r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32044r=mysqlcfg
[PHP-DOC] #32336 [NEW]: French translation error in htmlspecialchars documentation
From: eric_php at fantasy-lands dot net Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: French translation error in htmlspecialchars documentation Description: Hi, In page some mirroring site/manual/fr/function.htmlspecialchars.php, there is a mismatch between lower than and greater than translations which has been swapped. Current content is: (supérieur à) devient lt; (inférieur à) devient gt; and should be: (inférieur à) devient lt; (supérieur à) devient gt; Regards, Eric -- Edit bug report at http://bugs.php.net/?id=32336edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32336r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32336r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32336r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32336r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32336r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32336r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32336r=needscript Try newer version: http://bugs.php.net/fix.php?id=32336r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32336r=support Expected behavior: http://bugs.php.net/fix.php?id=32336r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32336r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32336r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32336r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32336r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32336r=dst IIS Stability: http://bugs.php.net/fix.php?id=32336r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32336r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32336r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32336r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32336r=mysqlcfg
[PHP-DOC] #32227 [NEW]: array_slice() 'offset' argument description slightly inaccurate
From: php at jessemccarthy dot net Operating system: N/A PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: array_slice() 'offset' argument description slightly inaccurate Description: Very simple documentation issue. In the entry for array_slice(), the second argument, offset, is described as follows: If offset is positive, the sequence will start at that offset in the array. If offset is negative, the sequence will start that far from the end of the array. I believe this should read If offset is non-negative . . . -- Edit bug report at http://bugs.php.net/?id=32227edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32227r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32227r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32227r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32227r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32227r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32227r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32227r=needscript Try newer version: http://bugs.php.net/fix.php?id=32227r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32227r=support Expected behavior: http://bugs.php.net/fix.php?id=32227r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32227r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32227r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32227r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32227r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32227r=dst IIS Stability: http://bugs.php.net/fix.php?id=32227r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32227r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32227r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32227r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32227r=mysqlcfg
[PHP-DOC] #32357 [NEW]: Fix on Compiling PECL extensions statically into PHP
From: imacat at mail dot imacat dot idv dot tw Operating system: Linux PHP version: 5.0.3 PHP Bug Type: Documentation problem Bug description: Fix on Compiling PECL extensions statically into PHP Description: The procedure described in section Compiling PECL extensions statically into PHP in INSTALL and in PHP manual is incorrect. Instead of running: $ cd /your/phpsrcdir $ ./buildconf $ ./configure --help $ ./configure --with-extname --enable-someotherext --with-foobar $ make $ make install One should run with autoconf 2.13: $ cd /your/phpsrcdir $ rm -f ./configure $ ./buildconf --force $ ./configure --help $ ./configure --with-extname --enable-someotherext --with-foobar $ make $ make install The with autoconf 2.13 should be mentioned in the document, too. -- Edit bug report at http://bugs.php.net/?id=32357edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32357r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32357r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32357r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32357r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32357r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32357r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32357r=needscript Try newer version: http://bugs.php.net/fix.php?id=32357r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32357r=support Expected behavior: http://bugs.php.net/fix.php?id=32357r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32357r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32357r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32357r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32357r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32357r=dst IIS Stability: http://bugs.php.net/fix.php?id=32357r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32357r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32357r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32357r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32357r=mysqlcfg
[PHP-DOC] #32570 [NEW]: mysqli_data_seek documentation says that it can be used with unbuffered results
From: jmarbas at hotmail dot com Operating system: n/a PHP version: 5.0.3 PHP Bug Type: Documentation problem Bug description: mysqli_data_seek documentation says that it can be used with unbuffered results Description: http://ca3.php.net/manual/en/function.mysqli-data-seek.php Documentation for mysqli_data_seek function says: Note: This function can only be used with unbuffered results attained from the use of the mysqli_store_result() or mysqli_query() functions. Shouldnt that be 'buffered' and not 'unbuffered' because mysqli_store_result() returns a buffered result set object. -- Edit bug report at http://bugs.php.net/?id=32570edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32570r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32570r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32570r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32570r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32570r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32570r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32570r=needscript Try newer version: http://bugs.php.net/fix.php?id=32570r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32570r=support Expected behavior: http://bugs.php.net/fix.php?id=32570r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32570r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32570r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32570r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32570r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32570r=dst IIS Stability: http://bugs.php.net/fix.php?id=32570r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32570r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32570r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32570r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32570r=mysqlcfg
[PHP-DOC] #32625 [NEW]: Emphasis needed on restarting after changing Path variable
From: peter dot ordal at rochester dot edu Operating system: Windows Server 2003 PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: Emphasis needed on restarting after changing Path variable Description: The following note was rejected from comments to the PHP manual, so I am submitting it here. This attaches to the instructions on how to get php_mysql support under PHP 5 on Windows. http://www.php.net/manual/en/faq.databases.php#faq.databases.mysql.php5 --- Users of Windows who run IIS should be aware that it takes a system restart for IIS to re-read your Path environment variable. This is apparently by design, as IIS is started by the Windows services manager which inherits its environment once only, on system start. For me, running PHP on Windows Server 2003 IIS 6, any page request would hang as PHP searched for and did not find libmysql.dll. My workaround (until the load was low enough to safely restart the server) was to put libmysql.dll in /windows/system32. --- I don't think this exact text should be included in the manual, but it seems an issue worth making users aware of. There is a link to setting up the Windows systems PATH http://www.php.net/manual/en/faq.installation.php#faq.installation.addtopath in this answer, which, without comment includes the step Press OK and restart your computer. Since the user is not prompted to restart by Windows, it seems worthwhile to at least flag that step with something like This is required. I felt this would be better as a note to the manual because the manual is not technically in error, and thus I wouldn't personally call it a bug. It just seemed like a friendly piece of advice to give to other users. Reproduce code: --- Also, be sure libmysql.dll is available to the systems PATH. Expected result: With the instruction to restart the system buried and not explained, I felt it may be susuperfluous. I expeced PHP to be using the new Path without a restart. (This applies to IIS only, I believe.) Actual result: -- PHP used the old path until I restarted the entire system. -- Edit bug report at http://bugs.php.net/?id=32625edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32625r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32625r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32625r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32625r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32625r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32625r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32625r=needscript Try newer version: http://bugs.php.net/fix.php?id=32625r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32625r=support Expected behavior: http://bugs.php.net/fix.php?id=32625r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32625r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32625r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32625r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32625r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32625r=dst IIS Stability: http://bugs.php.net/fix.php?id=32625r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32625r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32625r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32625r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32625r=mysqlcfg
[PHP-DOC] #32499 [NEW]: resource context not documented in file_get_contents, file, readfile
From: csaba at alum dot mit dot edu Operating system: irrelevant PHP version: 5CVS-2005-03-30 (dev) PHP Bug Type: Documentation problem Bug description: resource context not documented in file_get_contents, file, readfile Description: There are a huge lot of file functions (e.g. file_put_contents, file_get_contents, file, readfile, etc.) that take a 'resource context' argument, but I don't find this documented under the manual entry for the individual functions, nor under the File system entry (http://at.php.net/manual/en/ref.filesystem.php), nor does google.com show an obvious location for it when I put in resource context and tell PHP to search within the online documentation. This might not be such an issue, but file_get_contents take additional arguments (offset, maxlen) AFTER the resource context and there isn't even an example for the default to use. Nor is there mention of the type (eg. string) that this argument should be. There is mention of Stream contexts at http://at2.php.net/stream but a reasonable person reading through would have to conclude that they are different animals since the function documentation so consistently sticks with 'resource context' whereas the streams section talks exclusively about 'stream context'. Furthermore, the example (number 2 at the link above) cited at http://bugs.php.net/bug.php?id=27628edit=2 does not directly address this either Csaba Gabor from Vienna Expected result: It would be nice to have a link to the centralized documentation for 'resource context' along with an example -- Edit bug report at http://bugs.php.net/?id=32499edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32499r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32499r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32499r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32499r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32499r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32499r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32499r=needscript Try newer version: http://bugs.php.net/fix.php?id=32499r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32499r=support Expected behavior: http://bugs.php.net/fix.php?id=32499r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32499r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32499r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32499r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32499r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32499r=dst IIS Stability: http://bugs.php.net/fix.php?id=32499r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32499r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32499r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32499r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32499r=mysqlcfg
[PHP-DOC] #32212 [Fbk-Csd]: vrana
ID: 32212
Updated by: [EMAIL PROTECTED]
Reported By: gardan at gmx dot net
-Status: Feedback
+Status: Closed
Bug Type: Documentation problem
Operating System: -
PHP Version: Irrelevant
Assigned To: vrana
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Previous Comments:
[2005-03-07 05:39:17] [EMAIL PROTECTED]
What bug from 2002 are you talking about?
[2005-03-07 02:56:02] gardan at gmx dot net
Description:
Using a form with input name like name=foo[] this is what is returned
for files:
$_FILES = array(1) {
[foo]=
array(5) {
[name]=
array(2) {
[0]=
string(0)
[1]=
string(0)
}
[type]=
array(2) {
[0]=
string(0)
[1]=
string(0)
}
[...snip...]
}
}
Expected:
$_FILES = array(1) {
[foo]=
array(2) {
[0]=
array(5) {
[name]=
string(0)
[type]=
string(0)
[...snip...]
}
[1]=
array(5) {
[0]=
string(0)
[1]=
string(0)
[...snip...]
}
}
}
This being highly unintuitive, though in a bug report from 2002 closed
as won't change, should be documented.
--
Edit this bug report at http://bugs.php.net/?id=32212edit=1
[PHP-DOC] #31567 [Opn]: ref.ftp: missing stuff
ID: 31567 Updated by: [EMAIL PROTECTED] Reported By: didou at keliglia dot com Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: PHP 5 is mentioned in configure now. Third point - do you mean just mention ftp_pasv() in ftp_connect()? Previous Comments: [2005-02-13 04:25:18] [EMAIL PROTECTED] Second is also fixed [2005-01-20 19:13:47] [EMAIL PROTECTED] The first was fixed by mazzanet [2005-01-16 07:00:24] didou at keliglia dot com Also, the configure section doesn't mention PHP5. [2005-01-16 06:53:08] didou at keliglia dot com Description: Not mentionned: - ftp_*get() will overwrite the local files. - one can pass options to ftp_site, ftp_nlist, etc. We need to document this. This is because no escaping is performed in the C sources. It can also introduce bugs (for filenames with spaces, etc - ftp_connect() doesn't support proxies. (or maybe it's okay now ?) There are notes dealing with the subject. have fun! -- Edit this bug report at http://bugs.php.net/?id=31567edit=1
[PHP-DOC] #32407 [Opn-Bgs]: Object Aggregation in PHP5
ID: 32407 Updated by: [EMAIL PROTECTED] Reported By: kozlik at kufr dot cz -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: all PHP Version: 5.0.3 New Comment: There's version information by each function. There's just PHP 4 = 4.2.0 by aggregate() and friends, there's no PHP 5. Previous Comments: [2005-03-22 09:45:13] kozlik at kufr dot cz Description: By this: http://bugs.php.net/bug.php?id=28052 it seems that Object Aggregation isn't supported in PHP5. It should be mentioned in documentation, shouldn't it? -- Edit this bug report at http://bugs.php.net/?id=32407edit=1
[PHP-DOC] #32181 [Opn-Sus]: russian desc problem
ID: 32181 Updated by: [EMAIL PROTECTED] Reported By: nods at nsfse dot com -Status: Open +Status: Suspended Bug Type:Documentation problem PHP Version: Irrelevant 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. Thank you for your interest in PHP. We had this bug before reported, and we checked it out. It seems to be a bug in the Microsoft thing as we handle chmod exactly the same way as all other functions, and it is contained in the CHM. Previous Comments: [2005-03-03 21:39:39] nods at nsfse dot com [2005-03-03 21:38:15] nods at nsfse dot com Description: there is a some litle problem in the russian manual version that goes in the chm format namely, in the file system function section link to chmod() function doesnt load the function page when hit on it from the main function list it seems that link to the function page is wrong could you please fix it? thank you -- Edit this bug report at http://bugs.php.net/?id=32181edit=1
[PHP-DOC] #32094 [Asn-Csd]: Problem with charset
ID: 32094 Updated by: [EMAIL PROTECTED] Reported By: qubol at polbox dot com -Status: Assigned +Status: Closed Bug Type: Documentation problem Operating System: Windows 98 PHP Version: 5.0.2 Assigned To: derick New Comment: Problem solved. The polish documentation rebuilt from xml sources with the new settings (show all languages with utf-8 encoding). Previous Comments: [2005-03-01 11:39:55] intro at pf dot pl The problem is caused by Apache config file. Here's, what i got from your server: HTTP/1.1 200 OK Date: Tue, 01 Mar 2005 10:18:11 GMT Server: Apache/1.3.26 (Unix) mod_gzip/1.3.26.1a PHP/4.3.3-dev X-Powered-By: PHP/4.3.3-dev Content-language: pl Set-Cookie: LAST_LANG=pl; expires=Wed, 01-Mar-06 10:18:11 GMT; path=/; domain=.php.net Last-Modified: Tue, 01 Mar 2005 10:13:05 GMT Vary: Cookie Connection: close Transfer-Encoding: chunked Content-Type: text/html;charset=utf-8 The last line sets encoding to utf-8, but website is encoded in iso-8859-2 in Apache config file the following line should be commented out: # AddDefaultCharset UTF-8 [2005-02-25 12:21:20] [EMAIL PROTECTED] This is a know problem and is reported on other bug reports. We are currently working on it. [2005-02-24 17:27:28] qubol at polbox dot com Description: Since a month the PHP documentation in Polish language (http://www.php.net/manual/pl) is displayed improperly - Polish characters are replaced by some other. I checked it out in my computer at Opera, Gecko and IE - all browsers do not show correct text. I also experienced that problem on other machine, running Windows 2000 with IE 6.0. -- Edit this bug report at http://bugs.php.net/?id=32094edit=1
[PHP-DOC] #32536 [Opn-Csd]: Unserialize() and booleans
ID: 32536 Updated by: [EMAIL PROTECTED] Reported By: AxelLuttgens at swing dot be -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: n/a PHP Version: 4.3.10 New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. FALSE is returned both in the case of an error and if unserializing the serialized FALSE value. This special case can be catched by comparing str parameter with serialize(false) or by catching the issued E_NOTICE. Previous Comments: [2005-04-01 17:30:45] [EMAIL PROTECTED] I think we really should add the last sentence of Axel before closing the bug. [2005-04-01 17:14:38] [EMAIL PROTECTED] This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. [2005-04-01 17:09:05] AxelLuttgens at swing dot be Description: The docs state that unserialize() may return an integer, float, string, array or object. But it may also return a boolean: $bool = TRUE; $serbool = serialize($bool); $unserbool = unserialize($serbool); echo $serbool, '/', gettype($unserbool), '/', $unserbool? 'TRUE': 'FALSE'; -- b:1;/boolean/TRUE Changing TRUE to FALSE in the above yields: -- b:0;/boolean/FALSE The problem is that a FALSE value is by itself undistinguishable from an unserialization error, not that unserialize() cant' return a boolean. HTH, Axel -- Edit this bug report at http://bugs.php.net/?id=32536edit=1
[PHP-DOC] #22253 [Opn-Csd]: method becomes constructor in subclass
ID: 22253
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: win2k
PHP Version: 4.3.2-dev
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Old stuff removed, PHP 4 description fixed.
Previous Comments:
[2003-02-24 07:59:38] [EMAIL PROTECTED]
Reopening as a doc problem, so doc guys will get this to fix...
[2003-02-24 02:53:24] [EMAIL PROTECTED]
This behavior will not be changed in the context of PHP 4.x, but will
be fixed in PHP 5.0 (Zend Engine 2)
[2003-02-23 17:14:47] [EMAIL PROTECTED]
Okay, now I got it. :)
The rule for PHP 4 should be:
If class extending a base class hasn't got a constructor of it's own,
then the constructor of the base class is called.
Your example lacked the constructor for class String itself..but the
last example in manual has that special case. And running that example
shows that this is bullshit:
This is fixed in PHP 4 by modifying the rule to: 'A
constructor is a function of the same name as the class
it is being defined in.'. Thus in PHP 4, the class B
would have no constructor function of its own and the
constructor of the base class would have been called,
printing 'I am the constructor of A.br'.
(as it actually calls the method B()!)
p.s. Someone should clear out those PHP 3 examples and changes out of
the docs altogether as they only cause confusion and only document how
it should behave in PHP 4.
[2003-02-23 05:56:14] [EMAIL PROTECTED]
No, no and no.
Excerpts:
|In PHP 4, a function becomes a constructor,
|when it has the same name as the class it
|is defined in
In my example, the function printStr is not defined in class printStr,
so it should not become a constructor according to this statament.
Another example at the bottom of the page you mentioned:
|class A
|{
|function A()
|{
|echo I am the constructor of A.br\n;
|}
|
|function B()
|{
|echo I am a regular function named B in class
|A.br\n;
|echo I am not a constructor in A.br\n;
|}
|}
|
|class B extends A
|{
|function C()
|{
|echo I am a regular function.br\n;
|}
|}
|
|// This will call B() as a constructor.
|$b = new B;
|
|In PHP 3, the function B() in class A will suddenly become
|a constructor in class B, although it was never intended to
|be. The rule in PHP 3 is: 'A constructor is a function of
|the same name as the class.'. PHP 3 does not care if the
|function is being defined in class B, or if it has been
|inherited.
|
|This is fixed in PHP 4 by modifying the rule to: 'A
|constructor is a function of the same name as the class
|it is being defined in.'. Thus in PHP 4, the class B
|would have no constructor function of its own and the
|constructor of the base class would have been called,
|printing 'I am the constructor of A.br'.
The above example says, that the B() method becomes a constructor in
PHP 3, but *not* in PHP 4, as there is no constructor defined for class
B itself. Therefore it inherits the base classes constructor, which
exists in the manual's example. In my case, there is no constructor in
the base class. Therefore it should not call any method, as the text
suggests.
So this is not a documented behaviour. In fact it is documented, that
it should not work this way in PHP 4, but only in PHP 3...
[2003-02-23 01:20:05] [EMAIL PROTECTED]
It's by design and even documented here:
http://www.php.net/manual/en/language.oop.constructor.php
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/22253
--
Edit this bug report at http://bugs.php.net/?id=22253edit=1
[PHP-DOC] #32607 [Opn-Bgs]: path changes in windows
ID: 32607 Updated by: [EMAIL PROTECTED] Reported By: mark at seriti dot com -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: windows 2000 PHP Version: Irrelevant New Comment: There's a FAQ: http://php.net/faq.installation#faq.installation.addtopath You have to know how to modify PATH and other basic facts if you read only install.txt. Previous Comments: [2005-04-06 15:28:59] mark at seriti dot com I was refering to install.txt which comes with the zip download file. Yes it is in the online manual but by the time I got there i was chasing my tail. Thanks for your help. [2005-04-06 15:06:47] [EMAIL PROTECTED] Where exactly are you referring to in the manual? At http://www.php.net/manual/en/faq.installation.php#faq.installation.phprc it says you must reboot your system as the last step. [2005-04-06 14:33:09] mark at seriti dot com Description: At last I have installed PHP with Apache 2 on windows 2000 This was after a two day wild goose chase involving php.ini not being read, dll's not loading, the include_path variable not being recognised for PEAR extensions. Anyhow I learnt two things that I hope will save someone else the pain i have been through. 1.) If PHP does not find PHP.INI it uses hard coded default values that work fine until you install PEAR extensions and need to change the Include_path varaiablethen your troubles begin unless you knew about 2.) below 2.) To keep PHP files in a separate directory you must add C:\PHP TO YOUR PATH STATEMENT (Control panel, system, advances, environmental variables, system variables, select path and edit) AND REBOOT THE MACHINE OTHERWISE THE PATH VARIABLE DOES NOT UPDATE. The install.txt urges a manual install but neglects to mention the REBOOT requirement for the PATH statement to take effect. A minor omission but what a lot of pain it caused me. -- Edit this bug report at http://bugs.php.net/?id=32607edit=1
[PHP-DOC] #29514 [Opn]: auto_globals_jit not in php.ini
ID: 29514
Updated by: [EMAIL PROTECTED]
Reported By: holliwell at gmx dot net
Status: Open
Bug Type: Documentation problem
Operating System: linux -2.4.20
PHP Version: 5.0.0
New Comment:
This is now documented in the PHP Manual but still needs to find its
way into php.ini-{dist|recommended)
Here's the diff:
http://cvs.php.net/diff.php/phpdoc/en/appendices/ini.xml?r1=1.11r2=1.12ty=h
Previous Comments:
[2004-08-17 18:06:18] [EMAIL PROTECTED]
Changed to docu problem, 'cos it's not documented too. Probably Zeev
can tell about Just-In-Time variables initialization, as he was the
person who implemented it.
[2004-08-03 23:59:30] holliwell at gmx dot net
Description:
Hi,
phpinfo() reports about auto_globals_jit, but this directive is neither
in php.ini-dist nor php.ini-recommended.
Regards
Friedhelm Betz
--
Edit this bug report at http://bugs.php.net/?id=29514edit=1
[PHP-DOC] #32277 [Opn-Csd]: Bogus example given for array_merge()
ID: 32277 Updated by: [EMAIL PROTECTED] Reported By: a at b dot c dot de -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: Example was removed at 2005/02/16 15:27:02. Previous Comments: [2005-03-11 13:35:55] a at b dot c dot de Description: Para 3 of the text reads: If only one [associative] array is given ... duplicate entries will be merged into the last one. See example three for details. And example 3 shows: $array_two = array(jay = bob, randal = dante, jay = jason); $result_two = array_merge($array_two); print_r($result_two); Since when has an associative array been able to contain duplicated keys (jay, in this case)? The array_merge() in the given example is a complete no-op, as a print_r($array_two) shows. Since duplicate entries never occur in associative arrays, there doesn't seem to be much point discussing what happens when array_merge() encounters them. -- Edit this bug report at http://bugs.php.net/?id=32277edit=1
[PHP-DOC] #32607 [Opn-Fbk]: path changes in windows
ID: 32607 Updated by: [EMAIL PROTECTED] Reported By: mark at seriti dot com -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: windows 2000 PHP Version: Irrelevant New Comment: Where exactly are you referring to in the manual? At http://www.php.net/manual/en/faq.installation.php#faq.installation.phprc it says you must reboot your system as the last step. Previous Comments: [2005-04-06 14:33:09] mark at seriti dot com Description: At last I have installed PHP with Apache 2 on windows 2000 This was after a two day wild goose chase involving php.ini not being read, dll's not loading, the include_path variable not being recognised for PEAR extensions. Anyhow I learnt two things that I hope will save someone else the pain i have been through. 1.) If PHP does not find PHP.INI it uses hard coded default values that work fine until you install PEAR extensions and need to change the Include_path varaiablethen your troubles begin unless you knew about 2.) below 2.) To keep PHP files in a separate directory you must add C:\PHP TO YOUR PATH STATEMENT (Control panel, system, advances, environmental variables, system variables, select path and edit) AND REBOOT THE MACHINE OTHERWISE THE PATH VARIABLE DOES NOT UPDATE. The install.txt urges a manual install but neglects to mention the REBOOT requirement for the PATH statement to take effect. A minor omission but what a lot of pain it caused me. -- Edit this bug report at http://bugs.php.net/?id=32607edit=1
[PHP-DOC] #32043 [Opn-Bgs]: incorrect display in web site
ID: 32043 Updated by: [EMAIL PROTECTED] Reported By: annonceurs at webiologie dot org -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: all PHP Version: Irrelevant 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. Thank you for your interest in PHP. . Previous Comments: [2005-02-21 14:11:57] annonceurs at webiologie dot org Description: Since you have updated the web site, the display of accentued letters in the french doc is incorrect. The letters é,à, à, ù and others appears as ? . Page is noted as UTF8 but the encoding is iso-8859-15. Best regards LD NB : I have attempted to send a mail to the Webmaster, but your mail acceptation system is incomprehensible. I receveid many times a confirmation request. -- Edit this bug report at http://bugs.php.net/?id=32043edit=1
[PHP-DOC] #32671 [Opn-Csd]: Array keys converted from float to integer
ID: 32671 Updated by: [EMAIL PROTECTED] Reported By: marek at lewczuk dot com -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Linux PHP Version: 5.0.3 New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Floats in key are truncated to integer. Previous Comments: [2005-04-11 20:46:17] marek at lewczuk dot com Maybe is same for PHP4 - I just never had a chance check how this works. So, I understand that this is a proper behavior, right ? [2005-04-11 17:45:20] [EMAIL PROTECTED] This is nothing new for PHP 5, same happens with PHP 4. [2005-04-11 16:24:44] marek at lewczuk dot com One more example, what problem this bug/behavior may cause: $value1 = 345.654; $value2 = 345.655; $array = array(); $array[$value1] = $value1; $array[$value2] = $value2; Result: array ( 345 = 345.655, ) If this is a normal behavior you should put a note about this in the manual. [2005-04-11 16:19:04] marek at lewczuk dot com Description: Suppose we have a float value: $value = 345.332 and we want to use this value as an array key: $array[$value] = $value. This will cause that key will be truncated to integer 345 not to string 345.332. It is written in the manual that: ...A key may be either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. 8 will be interpreted as 8, while 08 will be interpreted as 08)... From this point of view floats should be converted to strings. I'm not saying that this is a bug, rather I would like to be sure if this is a proper behavior. Simple solution is to type cast float value to string (string), but we have to know that given value is a float (and sometimes, we don't know that). IMHO any other type than integer should be treat as string. Reproduce code: --- $value = 345.654; $array = array(); $array[$value] = Float; Expected result: array ( 345.654 = Float ) Actual result: -- array ( 345 = Float ) -- Edit this bug report at http://bugs.php.net/?id=32671edit=1
[PHP-DOC] #32286 [Opn-Fbk]: safe-mode needs some better docs..
ID: 32286 Updated by: [EMAIL PROTECTED] Reported By: joe dot knall at gmx dot net -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: Linux PHP Version: 4.3.10 New Comment: Looks like some comments got deleted...what was the problem and what do you feel needs documented exactly? Previous Comments: [2005-03-15 23:53:18] joe dot knall at gmx dot net ownership doesn't matter; ownership does matter! if /php/lib/php/file.php is owned by webmaster:webmaster it works, otherwise the result is as stated; THANK YOU, I'm sorry; I mixed it up during all the testing somehow:( but still it's irritating and not logical from the user's point of view; in my special case (Smarty, in /php/lib/php/Smarty) the files are owned by root:root; ok, this could be handled with the safe_mode_gid option and setting those file's ownership to root:webmaster (as far as I understand by now) ... still I think, if a file can be included it should exist; for me this case is closed by now; if you think this behaviour with safe mode is as intended please set the status to closed and _add_a_sentence_to_the_docu_ thank you [2005-03-14 01:17:42] [EMAIL PROTECTED] As what user you run that script? And what does this output: # ls -l /php/lib/php/file.php [2005-03-12 04:41:09] joe dot knall at gmx dot net Description: file_exists() returns FALSE but file exists, is in include_path, open_basedir and safe_mode_include_dir; only happens when safe_mode=On (not so when safe_mode=Off); anyways file can be used with include/require; relative or absolute path and ownership doesn't matter; same problem with is_readable(); './configure' '--prefix=/php' '--infodir=/usr/share/info' '--mandir=/usr/local/man' '--disable-cgi' '--disable-cli' '--disable-ipv6' '--disable-pear' '--disable-short-tags' '--enable-safe-mode' '--with-apxs2=/apache/bin/apxs' '--with-config-file-path=/apache/conf' '--with-mysql=/mysql' '--with-zlib-dir' pear is installed manually; may be a feature, but smarty works that way and I don't know where else to report this (internals/core.assemble_plugin_filepath.php, line 33) Reproduce code: --- test script: (/www/htdocs/test.php) ?php $file = '/php/lib/php/file.php'; echo file_exists($file) ? 'ok' : 'nok'; // echo is_readable($file) ? 'ok' : 'nok'; echo br /\n; include $file; ? file.php: ?php echo here I am; ? Expected result: If file can be included it should exist, isn't it? So output should be: ok here I am Actual result: -- nok here I am -- Edit this bug report at http://bugs.php.net/?id=32286edit=1
[PHP-DOC] #32617 [Opn-Bgs]: Argument swapping example contains bogus slashes
ID: 32617 Updated by: [EMAIL PROTECTED] Reported By: tommy at apt dot no -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: This is not a bug. The slashes are required because you have the integer specifying the order in front of the $. Previous Comments: [2005-04-07 09:45:27] tommy at apt dot no Description: http://se.php.net/sprintf#AEN144043 The slashes infront of the $ shouldn't as far as I can see, be there: Example 3. Argument swapping ?php $format = The %2\$s contains %1\$d monkeys; printf($format, $num, $location); ? -- Edit this bug report at http://bugs.php.net/?id=32617edit=1
[PHP-DOC] #30669 [Opn-Csd]: readline_completion_function parameter count is odd
ID: 30669 Updated by: [EMAIL PROTECTED] Reported By: php at trancer dot nl -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Example will be added later (as for every function). Previous Comments: [2004-11-03 09:23:03] [EMAIL PROTECTED] Proto fixed in XML sources, other comments remain. [2004-11-03 03:36:55] php at trancer dot nl Description: readline_completion_function description is very very brief and needs fixing. Besides that the description doesnt match the function header at all. You need to fill in function it refers to but its argument is called line? Might be that the comment is also of use. Another nice fix there would be an example of the callback function. -- Edit this bug report at http://bugs.php.net/?id=30669edit=1
[PHP-DOC] #28371 [Fbk-NoF]: Different behaviour of fopen depending on r+,w+,a+
ID: 28371 Updated by: phpdoc@lists.php.net Reported By: rc at opelgt dot org -Status: Feedback +Status: No Feedback Bug Type: Documentation problem Operating System: MacOSX 10.3 PHP Version: 4.3.4 New Comment: 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. Previous Comments: [2005-03-15 14:24:05] [EMAIL PROTECTED] Please tell us what exactly is not documented. In my eyes, everything works exactly as described on fopen page, mainly in the table A list of possible modes for fopen() using mode. [2005-02-03 05:05:56] [EMAIL PROTECTED] reclassified [2004-05-13 15:19:46] rc at opelgt dot org Yes, my sent script runs identically for all modes under Linux and MacOSX. Its different among the modes. The mode options in fopen() for my understanding should have only effect for the start: position of pointer, content of file, file creation if nessessary or not. Sure, read or write or both ways of access should remain until fclose(). ;-) 'r' and 'w' need clearstatcache() but 'a' doesnt. That is the unexpected and in the manual not mentioned difference. [2004-05-13 14:28:21] rc at opelgt dot org I think it could be mention in the manual: In PHP 4.2.3 the read pointer for fopen with 'a' is at the end of file. Instead in 4.3.4 the pointer is at '0'! So rewind for reading in 4.3.4 with 'a+' is no longer nessessary. Rüdiger [2004-05-12 19:12:34] rc at opelgt dot org Do you really think when such strange differences occur and the fopen description says nothing about it, its a question for support? Do you know why this differences occurs? Output with w+ is: InhaltBR alt: BR neu: and with r+: InhaltBR alt: 1234567890BR neu: Rüdiger 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/28371 -- Edit this bug report at http://bugs.php.net/?id=28371edit=1
[PHP-DOC] #25983 [Ctl]: PECL Extensions lack PHP version information
ID: 25983 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant Assigned To: vrana New Comment: Here's the patch: http://www.vrana.cz/scite/functable_pecl.diff.txt Previous Comments: [2005-02-20 22:46:07] [EMAIL PROTECTED] Updating bug as all PECL extensions lack version information within the PHP Manual. Status-Critical. Vrana, could you add a link to the patch within this bug report? [2003-11-19 13:11:33] [EMAIL PROTECTED] Erm, since PECL extensions are currently documented in the PHP manual, this should be fixed somehow... [2003-11-19 07:41:29] [EMAIL PROTECTED] printer functions are going to be moved into PECL [2003-10-25 01:08:26] [EMAIL PROTECTED] Description: The reference for printer functions say it is available after 4.0.4, but in every function is no version information, might be only in CVS, I think the reference is right, so this need to be fixed. I know this is not on xml files, but generated from a script or something like this. -- Edit this bug report at http://bugs.php.net/?id=25983edit=1
[PHP-DOC] #31591 [Csd-Opn]: env information needs clarification
ID: 31591
Updated by: [EMAIL PROTECTED]
-Summary: apache_getenv() is an 'undefined function'
Reported By: aronnax_98 at yahoo dot com
-Status: Closed
+Status: Open
Bug Type: Documentation problem
Operating System: Mac OS X 10.3.7
PHP Version: 4.3.9
Previous Comments:
[2005-01-18 19:44:54] [EMAIL PROTECTED]
This requirement has been documented, but some questions:
1) Assuming putenv() or apache_setenv() aren't used, will
apache_getenv(), getenv(), and the Superglobals always have the same
value?
2) How do these functions differ? putenv() vs. apache_setenv(), etc.
[2005-01-18 12:12:13] [EMAIL PROTECTED]
Yes, it is available, but only with Apache2.
Documentation should have a note about it.
[2005-01-18 04:01:58] aronnax_98 at yahoo dot com
Description:
When I try to call apache_getenv(...), PHP claims that
the function doesn't exist. The function is present in
the online PHP manual.
Reproduce code:
---
echo apache_getenv('SOME_ENV_VARIABLE');
Expected result:
VALUE_OF_SOME_ENV_VARIABLE
Actual result:
--
Fatal error: Call to undefined function: apache_getenv()
in /www/php/dryerase/config.php on line 21
--
Edit this bug report at http://bugs.php.net/?id=31591edit=1
[PHP-DOC] #32454 [Opn-Csd]: ibase_affected_rows always returns 0
ID: 32454
Updated by: [EMAIL PROTECTED]
Reported By: m dot muncke at computer1020 dot at
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Suse 9
PHP Version: 5.0.3
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Previous Comments:
[2005-03-26 18:01:11] [EMAIL PROTECTED]
Marking as doc problem then.
[2005-03-25 18:10:54] m dot muncke at computer1020 dot at
ok, this was not documented.
Thank you for fast reply.
[2005-03-25 16:07:56] [EMAIL PROTECTED]
ibase_affected_rows() returns the number of rows that were modified by
the previous INSERT, UPDATE or DELETE. It does *not* return the number
of rows available for fetching from a SELECT query.
[2005-03-25 14:44:53] m dot muncke at computer1020 dot at
Description:
ibase_affected_rows() always returns 0 even if the select count(*) does
not.
I always recieve 0 rows
IBConsole : select count(*) from Table ;
- returns 12 rows
Reproduce code:
---
$db =
ibase_pconnect('localhost:/data/database/foo.fdb','SYSDBA','masterkey');
$query = select * from Table;
$ret = ibase_query ($query);
$zu = ibase_affected_rows ( $db) ;
if ($zu == 0 )
echo (query returns 0 rows);
else
echo (query returns at least 1 row );
Expected result:
Expected result :
ibase_affected_rows should return number 12 as a select in isql or
IBConsole does return 12 rows;
Actual result:
--
Actual result is always 0
--
Edit this bug report at http://bugs.php.net/?id=32454edit=1
[PHP-DOC] #32181 [Opn]: russian desc problem
ID: 32181 User updated by: nods at nsfse dot com Reported By: nods at nsfse dot com Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Previous Comments: [2005-03-03 21:38:15] nods at nsfse dot com Description: there is a some litle problem in the russian manual version that goes in the chm format namely, in the file system function section link to chmod() function doesnt load the function page when hit on it from the main function list it seems that link to the function page is wrong could you please fix it? thank you -- Edit this bug report at http://bugs.php.net/?id=32181edit=1
[PHP-DOC] #25983 [Asn-Csd]: PECL Extensions lack PHP version information
ID: 25983 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant Assigned To: hholzgra New Comment: So this is fixed in CVS. printer extension will show only as in PECL (without PHP 4), it's not a big deal IMHO. Previous Comments: [2005-04-03 01:58:59] [EMAIL PROTECTED] i've applied the path and i'm rebuilding the version information right now ... but the real problem here is that ext/printer was completely removed (physicly) from the php-src CVS repository instead of just doing a cvs delete, that is the real reason for the version information being lost :( so even with the functable patch applied it will just say that these functions are available in PECL but the information that it was available in some 4.x versions is lost well, actually the version information is still in the CVS files that were moved to the PECL repository so it might be possible to extract them from there ... but unless there are other extensions that have been moved this way, too, i'll refuse to add extra code to do this ... [2005-02-21 11:49:08] [EMAIL PROTECTED] Here's the patch: http://www.vrana.cz/scite/functable_pecl.diff.txt [2005-02-20 22:46:07] [EMAIL PROTECTED] Updating bug as all PECL extensions lack version information within the PHP Manual. Status-Critical. Vrana, could you add a link to the patch within this bug report? [2003-11-19 13:11:33] [EMAIL PROTECTED] Erm, since PECL extensions are currently documented in the PHP manual, this should be fixed somehow... [2003-11-19 07:41:29] [EMAIL PROTECTED] printer functions are going to be moved into PECL 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/25983 -- Edit this bug report at http://bugs.php.net/?id=25983edit=1
[PHP-DOC] #32222 [Bgs]: some ini setting default values need special attention
ID: 3 Updated by: [EMAIL PROTECTED] Reported By: philip at cornado dot com Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Nice, it's been fixed in CVS :) How about NULL, should we change that to ? Previous Comments: [2005-03-07 18:21:06] [EMAIL PROTECTED] The script already searches for C macros. The on-line manual isn't updated. If you take a look at http://php.net/manual/en/ini.php you can see that the default for include_path is .;/path/to/php/pear. If you find any strange value, just say ;) [2005-03-07 18:09:30] philip at cornado dot com Description: For example: http://php.net/manual/en/ini.core.php include_pathPHP_INCLUDE_PATHPHP_INI_ALL doc_rootPHP_INCLUDE_PATHPHP_INI_SYSTEM user_dirNULLPHP_INI_SYSTEM extension_dir PHP_EXTENSION_DIR PHP_INI_SYSTEM Notice the constants being used as default values, this is not good. A couple years ago I posted the following proposal: * http://marc.theaimsgroup.com/?l=phpdocm=105161194723229 In it contains various constants and their associated default values. We need something similar to that for the generated ini table. Perhaps check for default values if said value prefix is PHP_ (except safe_mode_allowed_env_vars) and have the generation script (phpdoc/scripts/iniupdate/) find and insert the appropriate value OR (but most likely not) simply hardcode them. -- Edit this bug report at http://bugs.php.net/?id=3edit=1
[PHP-DOC] #32335 [Opn-Bgs]: Class Details for Object Iterator is missing
ID: 32335 Updated by: [EMAIL PROTECTED] Reported By: andreas dot lange at haas-media dot de -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: 5.0.3 New Comment: There's a description of Iterator's methods at http://www.php.net/manual/en/ref.spl.php and there's a link from language.oop5.iterations. Previous Comments: [2005-03-16 13:47:47] andreas dot lange at haas-media dot de Description: http://www.php.net/manual/en/language.oop5.iterations.php There should be a detailed description of the Iterator Interface. The following information is missing: methods, what return values are valid. Best Regards Andreas Lange -- Edit this bug report at http://bugs.php.net/?id=32335edit=1
[PHP-DOC] #18403 [Opn-Csd]: changable directive information (ini_set)
ID: 18403 Updated by: [EMAIL PROTECTED] Reported By: huet dot olivier at free dot fr -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: Irrelevant New Comment: I've uploaded my script, which can do the following: * Parse php-src and pecl * Replace C macros * update the ini appendix and all reference/*/ini.xml files * create the changelog column Previous Comments: [2004-07-26 23:06:03] [EMAIL PROTECTED] Links from ini_set already present, ini_set table updated from sources by a script once a time. Left to do: Automatically update reference/*/ini.xml by the same script which updates ini_set; find a way how to automatically document changes of versions in permissions (changeable column). [2003-02-04 20:18:53] [EMAIL PROTECTED] Some thoughts: a) A third column called 'type' that dictates what type the directive takes on (string,int,float..) b) A regex tweak is needed to allow settings such as url_rewriter.tags to work (note the commas) c) Currently $map is used to decide which test_ini.xml a setting goes into. Should we use it with $excludeitems too? d) Also generate a master list Regarding a big change, currently the description of many directives exist in the manual but are separate from this generated table. This is a little confusing as this information might go better together. This could include reciprocal links OR a fourth column for the description. [2003-02-04 18:21:34] [EMAIL PROTECTED] keep this open then.. [2003-02-04 17:10:44] [EMAIL PROTECTED] The script is there. Had made some limited tests in my local copy of the phpdoc, and seems to be working. I would like someone involved in the manual build to test it and give some feedback. IIRC something along the lines of the script's output was in the PHPDOC todo list. [2003-02-04 16:45:51] [EMAIL PROTECTED] what's the status with this? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18403 -- Edit this bug report at http://bugs.php.net/?id=18403edit=1
[PHP-DOC] #28371 [Opn-Fbk]: Different behaviour of fopen depending on r+,w+,a+
ID: 28371 Updated by: [EMAIL PROTECTED] Reported By: rc at opelgt dot org -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: MacOSX 10.3 PHP Version: 4.3.4 New Comment: Please tell us what exactly is not documented. In my eyes, everything works exactly as described on fopen page, mainly in the table A list of possible modes for fopen() using mode. Previous Comments: [2005-02-03 05:05:56] [EMAIL PROTECTED] reclassified [2004-05-13 15:19:46] rc at opelgt dot org Yes, my sent script runs identically for all modes under Linux and MacOSX. Its different among the modes. The mode options in fopen() for my understanding should have only effect for the start: position of pointer, content of file, file creation if nessessary or not. Sure, read or write or both ways of access should remain until fclose(). ;-) 'r' and 'w' need clearstatcache() but 'a' doesnt. That is the unexpected and in the manual not mentioned difference. [2004-05-13 14:28:21] rc at opelgt dot org I think it could be mention in the manual: In PHP 4.2.3 the read pointer for fopen with 'a' is at the end of file. Instead in 4.3.4 the pointer is at '0'! So rewind for reading in 4.3.4 with 'a+' is no longer nessessary. Rüdiger [2004-05-12 19:12:34] rc at opelgt dot org Do you really think when such strange differences occur and the fopen description says nothing about it, its a question for support? Do you know why this differences occurs? Output with w+ is: InhaltBR alt: BR neu: and with r+: InhaltBR alt: 1234567890BR neu: Rüdiger [2004-05-12 18:52:46] [EMAIL PROTECTED] The output under both linux and OSX is: InhaltBR alt: 1234567890BR neu: 13579 Your bug report doesn't sound so much like a bug report, but a support request; this isn't a support forum, so if you don't understand these results even after careful scrutiny of the fopen() manual page, please visit http://www.php.net/support.php to find someone who might be able to help you. 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/28371 -- Edit this bug report at http://bugs.php.net/?id=28371edit=1
[PHP-DOC] #32222 [Opn-Bgs]: some ini setting default values need special attention
ID: 3 Updated by: [EMAIL PROTECTED] Reported By: philip at cornado dot com -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: The script already searches for C macros. The on-line manual isn't updated. If you take a look at http://php.net/manual/en/ini.php you can see that the default for include_path is .;/path/to/php/pear. If you find any strange value, just say ;) Previous Comments: [2005-03-07 18:09:30] philip at cornado dot com Description: For example: http://php.net/manual/en/ini.core.php include_pathPHP_INCLUDE_PATHPHP_INI_ALL doc_rootPHP_INCLUDE_PATHPHP_INI_SYSTEM user_dirNULLPHP_INI_SYSTEM extension_dir PHP_EXTENSION_DIR PHP_INI_SYSTEM Notice the constants being used as default values, this is not good. A couple years ago I posted the following proposal: * http://marc.theaimsgroup.com/?l=phpdocm=105161194723229 In it contains various constants and their associated default values. We need something similar to that for the generated ini table. Perhaps check for default values if said value prefix is PHP_ (except safe_mode_allowed_env_vars) and have the generation script (phpdoc/scripts/iniupdate/) find and insert the appropriate value OR (but most likely not) simply hardcode them. -- Edit this bug report at http://bugs.php.net/?id=3edit=1
[PHP-DOC] #32094 [Com]: Problem with charset
ID: 32094 Comment by: intro at pf dot pl Reported By: qubol at polbox dot com Status: Assigned Bug Type: Documentation problem Operating System: Windows 98 PHP Version: 5.0.2 Assigned To: derick New Comment: The problem is caused by Apache config file. Here's, what i got from your server: HTTP/1.1 200 OK Date: Tue, 01 Mar 2005 10:18:11 GMT Server: Apache/1.3.26 (Unix) mod_gzip/1.3.26.1a PHP/4.3.3-dev X-Powered-By: PHP/4.3.3-dev Content-language: pl Set-Cookie: LAST_LANG=pl; expires=Wed, 01-Mar-06 10:18:11 GMT; path=/; domain=.php.net Last-Modified: Tue, 01 Mar 2005 10:13:05 GMT Vary: Cookie Connection: close Transfer-Encoding: chunked Content-Type: text/html;charset=utf-8 The last line sets encoding to utf-8, but website is encoded in iso-8859-2 in Apache config file the following line should be commented out: # AddDefaultCharset UTF-8 Previous Comments: [2005-02-27 19:38:58] mp3 at inet dot ua xsltproc rules [2005-02-25 12:21:20] [EMAIL PROTECTED] This is a know problem and is reported on other bug reports. We are currently working on it. [2005-02-24 17:27:28] qubol at polbox dot com Description: Since a month the PHP documentation in Polish language (http://www.php.net/manual/pl) is displayed improperly - Polish characters are replaced by some other. I checked it out in my computer at Opera, Gecko and IE - all browsers do not show correct text. I also experienced that problem on other machine, running Windows 2000 with IE 6.0. -- Edit this bug report at http://bugs.php.net/?id=32094edit=1
[PHP-DOC] #29737 [Opn-Csd]: ip2long() works not as documented
ID: 29737 Updated by: [EMAIL PROTECTED] Reported By: belikoviv at is dot lg dot ua -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Windows 2000 SP4; Fedora Core 2 PHP Version: 5.0.0 New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. ip2long() will return FALSE for the IP 255.255.255.255 in PHP 5 = 5.0.2. It was fixed in PHP 5.0.3 where it returns -1 (same as PHP 4). Previous Comments: [2005-04-06 12:16:43] belikoviv at is dot lg dot ua Function ip2long() fixed long time ago, but now I see incorrect note in documentation (at bottom of the chapter): Note: ip2long() will return -1 (PHP 4) or FALSE (PHP 5) for the IP 255.255.255.255 This is incorrect. ip2long returns -1 in both PHP4 and PHP5 for IP 255.255.255.255. Value -1 is _correct_ value for 255.255.255.255, so that note must be deleted from documentation. Note about PHP4 is exist near the top of chapter. [2004-08-19 18:44:43] [EMAIL PROTECTED] Be patient, Win32 snaps are not ready yet. Latest PHP5 win32 snapshot was built on: Aug 19, 2004 08:30 GMT. [2004-08-19 18:18:25] belikoviv at is dot lg dot ua Sorry, but problem not fixed - I try php5-win32-latest.zip and php5.0-win32-200408190830.zip. Both snapshots return FALSE on address 255.255.255.255. [2004-08-19 16:04:35] [EMAIL PROTECTED] Fixed in CVS, thanks. [2004-08-19 16:04:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-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/29737 -- Edit this bug report at http://bugs.php.net/?id=29737edit=1
[PHP-DOC] #32414 [Csd]: session_start(): Cannot send session cache limiter
ID: 32414
Updated by: [EMAIL PROTECTED]
Reported By: d dot geels at grape dot ru
Status: Closed
-Bug Type: Session related
+Bug Type: Documentation problem
Operating System: any
PHP Version: 4.3.10, also 5
New Comment:
Nope.
Use ini_set('session.use_cookies', false); to turn off cookie sending
and session_cache_limiter(''); to not use ANY cache limiter, because
'none' is being sent too.
Please, do not reclassify existing and already closed bugs, fill a new
report if you feel that there is *really* a bug.
For further questions please use support forums and mailing lists.
Previous Comments:
[2005-03-23 12:08:27] d dot geels at grape dot ru
No, you misunderstood me: I want to say, that problem is that
session_start() ALWAYS tries to send headers. Even if all reasons for
sending are eliminated by ini_set('session.use_cookies', 0) and
session_cache_limiter('none'), it still tries to send empty headers,
which cause bug subject warning.
[2005-03-23 11:43:40] [EMAIL PROTECTED]
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Shutdown function is called during the script shutdown so headers are
always already sent.
[2005-03-23 01:10:03] d dot geels at grape dot ru
The problem is that session_start() tries to send headers, but it must
not.
Try 'curl -v url to above example' and just call function a() at the
end, without registering shutdown function, you'll see, that
session_start() doesn't send any headers if second call to
session_cache_limiter has parameter 'none'. So, why does it complain,
when called from shutdown function? That is the bug actually.
[2005-03-22 22:56:05] [EMAIL PROTECTED]
This is actually just documentation problem:
You can't send any headers from a register_shutdown_function() call.
Or use any functions in such function that might send headers..such as
almost any session function.
[2005-03-22 18:46:42] d dot geels at grape dot ru
Tiny example, that always reproduces the bug.
?
ini_set('session.use_cookies', 0);
session_id('1234');
session_cache_limiter('public');
session_start();
session_write_close();
?
text
?
function a(){
session_cache_limiter('none');
session_start();
session_write_close();
}
register_shutdown_function('a');
?
If just call a() at the end -- no warnings, if a() called at shutdown
-- warning issued.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/32414
--
Edit this bug report at http://bugs.php.net/?id=32414edit=1
[PHP-DOC] #32528 [Bgs]: If (comparison) {do} function not documented neither properly working
ID: 32528
Updated by: [EMAIL PROTECTED]
Reported By: grasso789 at versanet dot de
Status: Bogus
Bug Type: Documentation problem
Operating System: All
PHP Version: 4.3.10
New Comment:
I guess today is April 1st :-).
Previous Comments:
[2005-04-01 07:21:47] [EMAIL PROTECTED]
It's very much documented:
http://php.net/manual/en/language.control-structures.php#control-structures.if
The parse error is because of a missing ;
[2005-04-01 06:49:49] grasso789 at versanet dot de
Description:
PHP has the IF (boolean expression) {...} function which is not
documented at all. I am searching for a logical if function since I
want to compare numbers.
Reproduce code:
---
if (01) {echo(The world does still exist!)}
Expected result:
The world does still exist!
Actual result:
--
Parse error: parse error, expecting `','' or `';'' in ...
--
Edit this bug report at http://bugs.php.net/?id=32528edit=1
[PHP-DOC] #32211 [Opn]: Hexadecimal integer value above 32-bit doesn't convert to float
ID: 32211 Updated by: [EMAIL PROTECTED] Reported By: osp at tinet dot org Status: Open -Bug Type: Variables related +Bug Type: Documentation problem Operating System: Linux and Windows XP PHP Version: 4.3.10 New Comment: Documentation is wrong here... Previous Comments: [2005-03-07 02:24:35] osp at tinet dot org Description: Hexadecimal values that don't fit a 32-bit size are not converted to float as specified on documentation: Integer overflow If you specify a number beyond the bounds of the integer type, it will be interpreted as a float instead. This works for decimal numbers, but not hexadecimal. Reproduce code: --- ?php $myvalue = 0x1; // 33-bit value //$myvalue = 4294967296; echo $myvalue.br; var_dump( $myvalue ); ? Expected result: 4294967296 float(4294967296) (0x1) Actual result: -- 2147483647 int(2147483647) (0x7FFF) -- Edit this bug report at http://bugs.php.net/?id=32211edit=1
[PHP-DOC] #32269 [Fbk-Opn]: [chm] bug
ID: 32269 User updated by: webmaster at zapx dot net Reported By: webmaster at zapx dot net -Status: Feedback +Status: Open Bug Type: Documentation problem Operating System: windows PHP Version: Irrelevant New Comment: OK, now I get this error. Internet Explorer Script Error An error has occurred in the script on this page. Line: 7 Char: 19 Error: Permission denied Code: 0 URL: ms-its:c:\phpmanual\php_manual_notes.chm::/ref.array.html Do you want to continue running scripts on this page? Yes alt+y No alt+n I still get the following error when opening up the first topic Internet Explorer Script Error An error has occurred in the script on this page. Line: 461 Char: 5 Error: Object required Code: 0 URL: mk:@MSITStore:c:\phpmanual\php_manual_en.chm::/_index.html Do you want to continue running scripts on this page? Yes alt+y No alt+n Previous Comments: [2005-03-20 16:37:33] [EMAIL PROTECTED] Can you please try this new file: http://mega.ist.utl.pt/~ncpl/php_manual_chm.zip and then update the error message/line number if the problem persists. [2005-03-13 00:30:32] webmaster at zapx dot net IE version is 6.0 I dont' know which skin, I just used it as was default when I downloaded it. The error is: Internet Explorer Script Error An error has occurred in the script on this page. Line: 437 Char: 5 Error: Object required Code: 0 URL: mk:@MSITStore:c:\phpmanual\php_manual_en.chm::/_index.html Do you want to continue running scripts on this page? Yes No Even when clicking yes or no, it still redisplays this error the next time I attempt showing a topic. [2005-03-12 23:48:54] [EMAIL PROTECTED] and which skin are you using? And which Internet explorer version? And can you type here the errors you receive, please? [2005-03-12 17:00:54] webmaster at zapx dot net I'm using Windows XP. I wonder if it could be the HH version I'm using. [2005-03-12 13:23:42] [EMAIL PROTECTED] Which IE/windows version are you using? BTW, it works fine here. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32269 -- Edit this bug report at http://bugs.php.net/?id=32269edit=1
[PHP-DOC] #32227 [Opn-Csd]: array_slice() 'offset' argument description slightly inaccurate
ID: 32227 Updated by: [EMAIL PROTECTED] Reported By: php at jessemccarthy dot net -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: [2005-03-08 00:23:29] php at jessemccarthy dot net Description: Very simple documentation issue. In the entry for array_slice(), the second argument, offset, is described as follows: If offset is positive, the sequence will start at that offset in the array. If offset is negative, the sequence will start that far from the end of the array. I believe this should read If offset is non-negative . . . -- Edit this bug report at http://bugs.php.net/?id=32227edit=1
[PHP-DOC] #32122 [Opn-Bgs]: header(Status: 404 Not Found); does not work
ID: 32122 Updated by: [EMAIL PROTECTED] Reported By: OvdSpek at LIACS dot NL -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Linux, Windows XP, 2003 PHP Version: 5CVS-2005-03-01 New Comment: This is in the docs: header that starts with the string HTTP/ ... In PHP 3, this only works when PHP is compiled as an Apache module. You can achieve the same effect using the Status header. IMHO it's obvious that 1. this means header that starts with the string HTTP/ and 2. you can achieve the same effect with Status header only in PHP 3. Previous Comments: [2005-03-10 12:49:17] [EMAIL PROTECTED] I don't think that's expected to work for anything other than the CGI SAPI, so I think this is a docs bug if anything. Certainly sapi_header_op doesn't special-case Status:; so this isn't apache2-SAPI-specific. [2005-03-04 17:08:25] OvdSpek at LIACS dot NL But this bug report wasn't about that, it was about Status: 404 Not Found not working. If that's not supposed to work, please mention that in the documentation. [2005-03-04 16:51:25] [EMAIL PROTECTED] This works: ?php header(HTTP/1.0 404 Not Found); ? [2005-02-28 22:09:22] OvdSpek at LIACS dot NL :( GET /temp/404.php HTTP/1.1 HTTP/1.1 200 OK Date: Mon, 28 Feb 2005 21:04:06 GMT Server: Apache/2.0.53 (Win32) PHP/5.1.0-dev X-Powered-By: PHP/5.1.0-dev Status: 404 Not Found Content-Length: 0 Keep-Alive: timeout=15, max=96 Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1 [2005-02-28 22:01:55] OvdSpek at LIACS dot NL Will do. Just wondering, why did the summary change from header(Status: 404 Not Found); doesn't work to Multiple small packets send for HTTP request? 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/32122 -- Edit this bug report at http://bugs.php.net/?id=32122edit=1
[PHP-DOC] #32617 [Bgs]: Argument swapping example contains bogus slashes
ID: 32617 User updated by: tommy at apt dot no Reported By: tommy at apt dot no Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Sorry, my mistake. When using as string delimiter, they should obviously be there, as in the example. But, if using ' as string delimiter, they shouldn't be there, but this isn't really relevant for the example. Previous Comments: [2005-04-07 10:03:09] [EMAIL PROTECTED] This is not a bug. The slashes are required because you have the integer specifying the order in front of the $. [2005-04-07 09:45:27] tommy at apt dot no Description: http://se.php.net/sprintf#AEN144043 The slashes infront of the $ shouldn't as far as I can see, be there: Example 3. Argument swapping ?php $format = The %2\$s contains %1\$d monkeys; printf($format, $num, $location); ? -- Edit this bug report at http://bugs.php.net/?id=32617edit=1
[PHP-DOC] #32607 [Fbk-Opn]: path changes in windows
ID: 32607 User updated by: mark at seriti dot com Reported By: mark at seriti dot com -Status: Feedback +Status: Open Bug Type: Documentation problem Operating System: windows 2000 PHP Version: Irrelevant New Comment: I was refering to install.txt which comes with the zip download file. Yes it is in the online manual but by the time I got there i was chasing my tail. Thanks for your help. Previous Comments: [2005-04-06 15:06:47] [EMAIL PROTECTED] Where exactly are you referring to in the manual? At http://www.php.net/manual/en/faq.installation.php#faq.installation.phprc it says you must reboot your system as the last step. [2005-04-06 14:33:09] mark at seriti dot com Description: At last I have installed PHP with Apache 2 on windows 2000 This was after a two day wild goose chase involving php.ini not being read, dll's not loading, the include_path variable not being recognised for PEAR extensions. Anyhow I learnt two things that I hope will save someone else the pain i have been through. 1.) If PHP does not find PHP.INI it uses hard coded default values that work fine until you install PEAR extensions and need to change the Include_path varaiablethen your troubles begin unless you knew about 2.) below 2.) To keep PHP files in a separate directory you must add C:\PHP TO YOUR PATH STATEMENT (Control panel, system, advances, environmental variables, system variables, select path and edit) AND REBOOT THE MACHINE OTHERWISE THE PATH VARIABLE DOES NOT UPDATE. The install.txt urges a manual install but neglects to mention the REBOOT requirement for the PATH statement to take effect. A minor omission but what a lot of pain it caused me. -- Edit this bug report at http://bugs.php.net/?id=32607edit=1
[PHP-DOC] #31303 [Opn-Csd]: treating a string like a regular array leads to a fatal offset
ID: 31303
Updated by: [EMAIL PROTECTED]
Reported By: schmad at miller-group dot net
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Mac OS X 10.3.7
PHP Version: 5.0.3
New Comment:
This behavior isn't limited to [] either, {} is affected the same way.
But anyway, using unset() on strings like this has no use whatsoever.
An example has now been added to migration5.xml so this bug is closed.
Previous Comments:
[2004-12-30 09:48:41] [EMAIL PROTECTED]
Reverted, sorry. I'm not sure where to add this piece of information so
I'm leaving this bug open for someone else :-).
[2004-12-29 20:47:41] [EMAIL PROTECTED]
Yep, please revert the change at 'language.types.string'.
PHP 5 only causes a fatal error whith 'unset($string[a]);'
Nuno
[2004-12-29 17:08:00] [EMAIL PROTECTED]
You changed the wrong thing, $string[0] still works.
[EMAIL PROTECTED]:~$ php -r '$foo = abc; var_dump($foo[0]);'
string(1) a
Also, the second example doesn't seem to produce a fatal error.
[EMAIL PROTECTED]:~$ php -r '$link = ; var_dump(count($link[two]));'
Notice: Uninitialized string offset: 0 in Command line code on line 1
int(1)
[EMAIL PROTECTED]:~$ php -v
PHP 5.1.0-dev (cli) (built: Dec 28 2004 20:03:13)
[2004-12-29 16:43:35] [EMAIL PROTECTED]
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
I believe it is already documented in Backward Incompatible Changes
under Migrating from PHP 4 to PHP 5 in the sentence Illegal use of
string offsets causes E_ERROR instead of E_WARNING.
However, I have added this to the String Type chapter: However, this
syntax is deprecated as of PHP 4 and produces fatal error in PHP 5.
[2004-12-26 22:29:16] [EMAIL PROTECTED]
opening..
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/31303
--
Edit this bug report at http://bugs.php.net/?id=31303edit=1
[PHP-DOC] #32570 [Opn-Csd]: mysqli_data_seek documentation says that it can be used with unbuffered results
ID: 32570 Updated by: [EMAIL PROTECTED] Reported By: jmarbas at hotmail dot com -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: n/a PHP Version: 5.0.3 New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: [2005-04-04 17:46:39] jmarbas at hotmail dot com Description: http://ca3.php.net/manual/en/function.mysqli-data-seek.php Documentation for mysqli_data_seek function says: Note: This function can only be used with unbuffered results attained from the use of the mysqli_store_result() or mysqli_query() functions. Shouldnt that be 'buffered' and not 'unbuffered' because mysqli_store_result() returns a buffered result set object. -- Edit this bug report at http://bugs.php.net/?id=32570edit=1
[PHP-DOC] #32671 [Opn]: Array keys converted from float to integer
ID: 32671 User updated by: marek at lewczuk dot com Reported By: marek at lewczuk dot com Status: Open Bug Type: Documentation problem Operating System: Linux PHP Version: 5.0.3 New Comment: Maybe is same for PHP4 - I just never had a chance check how this works. So, I understand that this is a proper behavior, right ? Previous Comments: [2005-04-11 17:45:20] [EMAIL PROTECTED] This is nothing new for PHP 5, same happens with PHP 4. [2005-04-11 16:24:44] marek at lewczuk dot com One more example, what problem this bug/behavior may cause: $value1 = 345.654; $value2 = 345.655; $array = array(); $array[$value1] = $value1; $array[$value2] = $value2; Result: array ( 345 = 345.655, ) If this is a normal behavior you should put a note about this in the manual. [2005-04-11 16:19:04] marek at lewczuk dot com Description: Suppose we have a float value: $value = 345.332 and we want to use this value as an array key: $array[$value] = $value. This will cause that key will be truncated to integer 345 not to string 345.332. It is written in the manual that: ...A key may be either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. 8 will be interpreted as 8, while 08 will be interpreted as 08)... From this point of view floats should be converted to strings. I'm not saying that this is a bug, rather I would like to be sure if this is a proper behavior. Simple solution is to type cast float value to string (string), but we have to know that given value is a float (and sometimes, we don't know that). IMHO any other type than integer should be treat as string. Reproduce code: --- $value = 345.654; $array = array(); $array[$value] = Float; Expected result: array ( 345.654 = Float ) Actual result: -- array ( 345 = Float ) -- Edit this bug report at http://bugs.php.net/?id=32671edit=1
[PHP-DOC] #31672 [Csd-Opn]: [PATCH] /script is not considered closing tag if preceded by one-line comment
ID: 31672 Updated by: [EMAIL PROTECTED] Reported By: tomc at wanadoo dot fr -Status: Closed +Status: Open -Bug Type: Scripting Engine problem +Bug Type: Documentation problem Operating System: * PHP Version: 4CVS, 5CVS (2005-01-24) New Comment: Fixing this appears to open a can of worms. The fix was reverted. Changing to a documentation issue - we need to change the docs to reflect that /script doesn't end scripting within a one line comment. Previous Comments: [2005-02-25 16:59:31] [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-01-24 04:40:29] [EMAIL PROTECTED] I'm not any flex guru, but this patch fixes the problem: http://www.php.net/~jani/patches/bug31672.patch (need to get some guru to approve this one :) [2005-01-24 02:23:10] [EMAIL PROTECTED] This is valid bug, all other closing tags ( ?, % ) work fine in same situation, as the provided test case proves. [2005-01-23 23:08:59] tomc at wanadoo dot fr Description: in the manual : The one-line comment styles actually only comment to the end of the line or the current block of PHP code, whichever comes first. Everything is working as described in the manual except that if you are using the /script closing tag, PHP will consider the end of the PHP block as part of the comment. Reproduce code: --- ?php // line comment ? echo out of PHP ? // line comment ? echo out of PHP % // line comment % echo out of PHP script language=php// line comment/script echo how come I'm still in PHP ?\n ; /script echo out of PHP Expected result: echo out of PHP echo out of PHP echo out of PHP echo how come I'm still in PHP ?\n ; echo out of PHP Actual result: -- echo out of PHP echo out of PHP echo out of PHP how come I'm still in PHP ? echo out of PHP -- Edit this bug report at http://bugs.php.net/?id=31672edit=1
[PHP-DOC] #32665 [Opn-Csd]: Premature flushing of output buffer when register_shutdown function called
ID: 32665
Updated by: [EMAIL PROTECTED]
Reported By: prathap at ee dot pdn dot ac dot lk
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Gentoo Linux
PHP Version: 5.0.3
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Previous Comments:
[2005-04-12 09:58:47] [EMAIL PROTECTED]
It has been already documented: There is currently no way to process
the data after the request has been completed.
I tried to clarify it to: There is currently no way to process the
data with output buffering functions in the shutdown function.
[2005-04-11 17:53:28] [EMAIL PROTECTED]
It should be said in manual that you can't use ob_* functions in the
shutdown funcs since the ob-stuff is already ended before we run
these.
[2005-04-11 08:24:05] prathap at ee dot pdn dot ac dot lk
Description:
Hello,
I've posted a miniature version of my code here to explain my doubt.
CODE
?
phpinfo();
ob_start();
register_shutdown_function(hello);
echo (HELLO);
die();
function hello()
{
$logfile = logfile;
$error_string = ob_get_contents();
if(!$handle = fopen($logfile, a))
{
echo(Could not open logfile for writing!);
ob_end_flush();
exit;
}
if(fwrite($handle, $error_string) === FALSE)
{
echo(Could not write to logfile!);
ob_end_flush();
exit;
}
fclose($handle);
ob_end_clean();
}
?
/CODE
This simply does not work the way it should. i.e ob_get_contents doen't
return
any string and the buffer just gets flushed by itself at termination.
Though the PHP manual says it is not possible to retrieve the contents
of any
output buffers using ob_get_contents() with PHP 4.0.6. But I am using
PHP 5.
x.x
I posted this problem in the mailing list and I got this response from
skrol29:
I've tested your code on PHP 4.3.3 and I have the same behavior has
yours.
Hello is output at the end of the PhpInfo data, followed by a PHP
notice :
Notice: ob_end_clean(): failed to delete buffer. No buffer to delete.
in
...
And there is an empty logfile file created in the Apache directory
insteaf
of the script's directory.
If you change in your script:
***
register_shutdown_function(hello);
echo (HELLO br);
die();
***
by
***
// register_shutdown_function(hello);
echo (HELLO br);
hello()
die();
***
then it runs as expected and the logfile file is created in the
script's
directory.
It seems that when calling the shutdown function, all the buffered
output is
immedialty sent to the client and the buffer mode is closed.
You maybe have PHP bug here, or the manual is wrong about the
possibility to
retrieve the contents.
But we can notice that this also happens at the end of a script when
there
is no shutdown function.
I am still not sure if this is a bug. But I would be very grateful if
someone generously volunteers to see to this.
Thank you and congrats on for the good work you have been carrying on
all throughout.
Prathap
--
Edit this bug report at http://bugs.php.net/?id=32665edit=1
[PHP-DOC] #32648 [Opn-Csd]: register_shutdown_function output corrupted if zlib.output_compression is On
ID: 32648
Updated by: [EMAIL PROTECTED]
Reported By: interghost at crovortex dot com
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Windows XP/Linux
PHP Version: 5.0.4
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Shutdown function is called after closing all opened output buffers
thus, for example, its output will not be compressed if
zlib.output_compression is enabled.
Previous Comments:
[2005-04-11 17:59:06] [EMAIL PROTECTED]
Manual is wrong here.
[2005-04-09 21:17:08] interghost at crovortex dot com
Description:
When using an echo/print inside a function called by
register_shutdown_function, AND while zlib.output_compression is set to
On, the last part of the output (whatever was echoed/printed in the
shutdown function) isn't compressed.
PS:
I've found that this bug was already reported before but was classified
as Bogus with the explanation:
The registered shutdown functions are called after the request has
been completed (including sending any output buffers), so it is not
possible to send output to the browser using echo() or print(), or
retrieve the contents of any output buffers using ob_get_contents().
However it clearly states in the manual that:
...Since PHP 4.1, the shutdown functions are called as the part of the
request so that it's possible to send the output from them...
Reproduce code:
---
function blah()
{
echo Shut down;
}
register_shutdown_function('blah');
echo testing bugp;
Expected result:
testing bugpShut down
Actual result:
--
With zlib.output_compression set to On in php.ini
In Mozilla based browsers:
testing bugp
In IE:
an empty document
The difference above is because of different error handling in the
browsers (I think) where Mozilla simply truncates the corrupted part
while IE displays nothing
Note: Set zlib.output_compression to Off and both browsers will
display:
testing bugpShut down
--
Edit this bug report at http://bugs.php.net/?id=32648edit=1
[PHP-DOC] #28371 [NoF-Opn]: Different behaviour of fopen depending on r+,w+,a+
ID: 28371 User updated by: rc at opelgt dot org Reported By: rc at opelgt dot org -Status: No Feedback +Status: Open Bug Type: Documentation problem Operating System: MacOSX 10.3 PHP Version: 4.3.4 New Comment: Which language do you prefer: english or Deutsch? Previous Comments: [2005-04-01 01:00:04] 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-03-24 16:09:12] [EMAIL PROTECTED] Tell us what's wrong or missing mainly in the table A list of possible modes for fopen() using mode. The behavior of the modes is explained well there IMHO. [2005-03-23 11:53:50] rc at opelgt dot org I have written all things that should be mentioned. Please read it carefully and if you do not understand it, ask me again ;-) [2005-03-23 01:00:04] 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-03-15 14:24:05] [EMAIL PROTECTED] Please tell us what exactly is not documented. In my eyes, everything works exactly as described on fopen page, mainly in the table A list of possible modes for fopen() using mode. 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/28371 -- Edit this bug report at http://bugs.php.net/?id=28371edit=1
[PHP-DOC] #32499 [Opn-Csd]: resource context not documented in file_get_contents, file, readfile
ID: 32499 Updated by: [EMAIL PROTECTED] Reported By: csaba at alum dot mit dot edu -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: irrelevant PHP Version: 5CVS-2005-03-30 (dev) New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: [2005-03-30 12:18:02] csaba at alum dot mit dot edu Description: There are a huge lot of file functions (e.g. file_put_contents, file_get_contents, file, readfile, etc.) that take a 'resource context' argument, but I don't find this documented under the manual entry for the individual functions, nor under the File system entry (http://at.php.net/manual/en/ref.filesystem.php), nor does google.com show an obvious location for it when I put in resource context and tell PHP to search within the online documentation. This might not be such an issue, but file_get_contents take additional arguments (offset, maxlen) AFTER the resource context and there isn't even an example for the default to use. Nor is there mention of the type (eg. string) that this argument should be. There is mention of Stream contexts at http://at2.php.net/stream but a reasonable person reading through would have to conclude that they are different animals since the function documentation so consistently sticks with 'resource context' whereas the streams section talks exclusively about 'stream context'. Furthermore, the example (number 2 at the link above) cited at http://bugs.php.net/bug.php?id=27628edit=2 does not directly address this either Csaba Gabor from Vienna Expected result: It would be nice to have a link to the centralized documentation for 'resource context' along with an example -- Edit this bug report at http://bugs.php.net/?id=32499edit=1
[PHP-DOC] #32050 [Bgs-Csd]: ? instead of accents in the french doc
ID: 32050 User updated by: skrol29 at freesurf dot fr Reported By: skrol29 at freesurf dot fr -Status: Bogus +Status: Closed Bug Type: Documentation problem Operating System: WinXP PHP Version: Irrelevant New Comment: My misteak. This is a diplicated bug. I did make researchs before to post, but didn't found bug #32043. Previous Comments: [2005-02-21 15:18:38] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. Dup of #32043. [2005-02-21 15:13:47] skrol29 at freesurf dot fr Description: In the french doc online, lot of accents( all ?) are replaced with character '?'. Example, see page: http://fr.php.net/manual/fr/function.count.php This is the same of other fench pages. It seems that '?' is coded in the source of the Html page. -- Edit this bug report at http://bugs.php.net/?id=32050edit=1
[PHP-DOC] #29877 [Ver-Csd]: variable assign by reference works even when methods don't return by reference
ID: 29877 Updated by: [EMAIL PROTECTED] Reported By: bharat at menalto dot com -Status: Verified +Status: Closed Bug Type: Documentation problem Operating System: FreeBSD 4.8 PHP Version: 4CVS, 5CVS (2004-12-10) New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. by function definition is optional in class methods. Previous Comments: [2004-12-14 02:59:28] [EMAIL PROTECTED] This is definitely not how the current documentation describes how references work. Does this require a trivial documentation change, or is it something in the engine/language that is not copasetic? [2004-12-13 09:54:21] bharat at menalto dot com I left the old script with the bug intact, but have created a second one with the fix that Jakub suggests, here: http://www.menalto.com/.outgoing/php/ref2.php [2004-12-13 09:47:15] [EMAIL PROTECTED] There's a small mistake in the sample script but it doesn't affect the issue: There should be $test2-_data instead of $test1-_data on the last line. It's worth noting that if get() method returns literal instead of variable, PHP doesn't issue any warning and the variable is not bound. [2004-12-13 09:09:23] bharat at menalto dot com Jani, I appreciate that this behaviour hasn't changed in a while. If it's part of the language, I'm ok with it. However, in the documentation that I referenced, it clearly states: --- Note: Unlike parameter passing, here you have to use in both places - to indicate that you return by-reference, not a copy as usual, and to indicate that reference binding, rather than usual assignment, should be done for $foo. --- But as my sample code indicates (unless you can demonstrate a bug in my code), the is not required on the function. So if this is the desired behaviour, then let us please update the documentation to state that it is NOT required that there be an on the function for you to get back a reference. Either way we resolve this, there's a discrepancy that should be removed. Thanks! [2004-12-12 16:29:31] [EMAIL PROTECTED] Note: Tested with 4.2.2 and it works exactly the same. IMO this is not a bug. 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/29877 -- Edit this bug report at http://bugs.php.net/?id=29877edit=1
[PHP-DOC] #20966 [Asn]: CHM search index includes irrelevant words
ID: 20966 User updated by: steve at holdenweb dot com -Reported By: sholden at holdenweb dot com +Reported By: steve at holdenweb dot com Status: Assigned Bug Type: Documentation problem Operating System: Windows, any PHP Version: 4.3.0RC3 Assigned To: goba New Comment: [Changing my logged email address] Previous Comments: [2005-04-07 10:04:03] richard dot quadling at bandvulc dot co dot uk I think the only way this could be handled is to have the navigation links generated in JavaScript rather than in plain HTML. This way it would not be searched by the full text searching of MS CHM Viewer. The only normal way to have things NOT included in the full text search is to produce a word stop list (limited to 512 bytes! Gee! They really know how to be generous at MS!!!), but this is then across the entire manual - not much use. There does not seem to be any tag you can put around text to make it NOT indexable (which would be nice). This would probably have to be handled by the htmlhelp/make_chm.php script(s). Thinking out loud, what happens if the text is not ascii? Use the %xx code or #xxx; code. Seems daft though doesn't it? Taking abc and converting it into something just so it doesn't get searched? The JS solution would fix the problem, but changes to the CHM build process would also know onto the skins too. But, if this is a really requirement, how about introducing a docbook element specifically dealing with text that is NOT searchable and then because it is in the system from the ground up, those system which can support it can! So, the CHM build process could take the XML and create a specific div class which can be looked for and then converted into a simple bunch of JavaScript's document.writeln()'s. This would also allow documentors to exclude parts of the documentation from the CHM full text search. (Not sure why - but a perfect example is the search including navigation links! grin /). Richard. [2002-12-13 01:36:41] [EMAIL PROTECTED] Well the, search index is created by the CHM compiler after it compiled in the HTML files. So there is no method to index the pages without the navigation parts and then replace the files with the full ones. I even don't know any method to put some HTML parts into some ignored section in the HTML files, so I really don't know how to fix this. I'll try to look up some info, but I hardly beleive I'll find something useful. Microsoft HH compiler is not too smart... [2002-12-12 11:28:14] steve at holdenweb dot com The CHM file is somewhat over-indexed. For example, when I search for payment, among the relevant hits I also see the curl_version page because the next page link in the footer is entitled Cybercash *payment* options. This seems redundant and likely to render searches less useful than they would otherwise be. Can't find any other reports of this, hence the new bug report. -- Edit this bug report at http://bugs.php.net/?id=20966edit=1
[PHP-DOC] #32414 [Csd]: session_start(): Cannot send session cache limiter
ID: 32414
User updated by: d dot geels at grape dot ru
Reported By: d dot geels at grape dot ru
Status: Closed
Bug Type: Documentation problem
Operating System: any
PHP Version: 4.3.10, also 5
New Comment:
Sorry.
session_cache_limiter(''); to not use ANY cache limiter, because
'none' is being sent too
So, this is the problem? Documentation says nothing about '', only
'none' is documented.
Previous Comments:
[2005-03-23 12:35:53] [EMAIL PROTECTED]
Nope.
Use ini_set('session.use_cookies', false); to turn off cookie sending
and session_cache_limiter(''); to not use ANY cache limiter, because
'none' is being sent too.
Please, do not reclassify existing and already closed bugs, fill a new
report if you feel that there is *really* a bug.
For further questions please use support forums and mailing lists.
[2005-03-23 12:08:27] d dot geels at grape dot ru
No, you misunderstood me: I want to say, that problem is that
session_start() ALWAYS tries to send headers. Even if all reasons for
sending are eliminated by ini_set('session.use_cookies', 0) and
session_cache_limiter('none'), it still tries to send empty headers,
which cause bug subject warning.
[2005-03-23 11:43:40] [EMAIL PROTECTED]
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Shutdown function is called during the script shutdown so headers are
always already sent.
[2005-03-23 01:10:03] d dot geels at grape dot ru
The problem is that session_start() tries to send headers, but it must
not.
Try 'curl -v url to above example' and just call function a() at the
end, without registering shutdown function, you'll see, that
session_start() doesn't send any headers if second call to
session_cache_limiter has parameter 'none'. So, why does it complain,
when called from shutdown function? That is the bug actually.
[2005-03-22 22:56:05] [EMAIL PROTECTED]
This is actually just documentation problem:
You can't send any headers from a register_shutdown_function() call.
Or use any functions in such function that might send headers..such as
almost any session function.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/32414
--
Edit this bug report at http://bugs.php.net/?id=32414edit=1
[PHP-DOC] #31775 [Csd]: Undefined behavior when uploaded file post_max_size
ID: 31775 User updated by: rudolf at softwares dot ch Reported By: rudolf at softwares dot ch Status: Closed Bug Type: Documentation problem Operating System: Windows XP Pro PHP Version: 4.3.9 New Comment: You're right; it doesn't belong in $_FILES. But having to check the states of three arrays is also not the ideal way to check for the error. Previous Comments: [2005-04-01 10:33:00] [EMAIL PROTECTED] post_max_size is not necessarily bound to $_FILES. You can exceed it by sending e.g. big textarea. Thus $_FILES['userfile']['error'] is not the right place to report this error. [2005-04-01 10:24:13] rudolf at softwares dot ch Upon further testing, only Safari reacts to an uploaded file whose size is greater than post_max_size by saying it cannot connect to the server. Other browsers do indeed receive what is written to stdout. Would it not be a more consistent solution if a new error code was defined for $_FILES['userfile']['error'] for this situation, instead of having to check for certain (not necessarily intuitive) states in the $_POST and $_FILES and $_GET arrays? [2005-03-31 12:00:24] [EMAIL PROTECTED] This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. If the size of post data is greater than post_max_size, $_POST and $_FILES arrays are empty. You can track this condition various ways, e.g. by passing $_GET variable to the script processing the data, i.e. form action=edit.php?processed=1 and cheching this variable. [2005-03-31 11:44:02] [EMAIL PROTECTED] Are you sure nothing is written to stdout? On the same environment, I experienced $_POST and $_FILES empty in case of data-size greater than post_max_size, but everything is written to stdout as usual. Can you please give us a link to source of fileupload.php? [2005-03-29 10:32:58] markusg at cants dot no dot spam dot de PHP also completely truncates the POST request, so you can't even tell there was one. Perhaps it would be more useful to process the incoming data up to the point where the post_max_size limit is reached, and then set a flag the programmer can check for. 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/31775 -- Edit this bug report at http://bugs.php.net/?id=31775edit=1
[PHP-DOC] #32122 [Bgs-Opn]: header(Status: 404 Not Found); does not work
ID: 32122 User updated by: OvdSpek at LIACS dot NL Reported By: OvdSpek at LIACS dot NL -Status: Bogus +Status: Open Bug Type: Documentation problem Operating System: Linux, Windows XP, 2003 PHP Version: 5CVS-2005-03-01 New Comment: 2. you can achieve the same effect with Status header only in PHP 3. No, it doesn't mean that. That statement means that the status header method always works, except in PHP 3, where it only works if PHP is ran as module. Previous Comments: [2005-03-15 14:08:12] [EMAIL PROTECTED] This is in the docs: header that starts with the string HTTP/ ... In PHP 3, this only works when PHP is compiled as an Apache module. You can achieve the same effect using the Status header. IMHO it's obvious that 1. this means header that starts with the string HTTP/ and 2. you can achieve the same effect with Status header only in PHP 3. [2005-03-10 12:49:17] [EMAIL PROTECTED] I don't think that's expected to work for anything other than the CGI SAPI, so I think this is a docs bug if anything. Certainly sapi_header_op doesn't special-case Status:; so this isn't apache2-SAPI-specific. [2005-03-04 17:08:25] OvdSpek at LIACS dot NL But this bug report wasn't about that, it was about Status: 404 Not Found not working. If that's not supposed to work, please mention that in the documentation. [2005-03-04 16:51:25] [EMAIL PROTECTED] This works: ?php header(HTTP/1.0 404 Not Found); ? [2005-02-28 22:09:22] OvdSpek at LIACS dot NL :( GET /temp/404.php HTTP/1.1 HTTP/1.1 200 OK Date: Mon, 28 Feb 2005 21:04:06 GMT Server: Apache/2.0.53 (Win32) PHP/5.1.0-dev X-Powered-By: PHP/5.1.0-dev Status: 404 Not Found Content-Length: 0 Keep-Alive: timeout=15, max=96 Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32122 -- Edit this bug report at http://bugs.php.net/?id=32122edit=1
[PHP-DOC] #32122 [Bgs-Opn]: header(Status: 404 Not Found); does not work
ID: 32122 User updated by: OvdSpek at LIACS dot NL Reported By: OvdSpek at LIACS dot NL -Status: Bogus +Status: Open Bug Type: Documentation problem Operating System: Linux, Windows XP, 2003 PHP Version: 5CVS-2005-03-01 New Comment: Opened again (sorry, my mistake). Previous Comments: [2005-03-15 14:12:56] OvdSpek at LIACS dot NL Note: In PHP 3, this only works when PHP is compiled as an Apache module. You can achieve the same effect using the Status header. This would be correct: Note: In PHP 3 you can achieve the same effect using the Status header, but only when PHP is compiled as Apache module. [2005-03-15 14:10:54] OvdSpek at LIACS dot NL 2. you can achieve the same effect with Status header only in PHP 3. No, it doesn't mean that. That statement means that the status header method always works, except in PHP 3, where it only works if PHP is ran as module. [2005-03-15 14:08:12] [EMAIL PROTECTED] This is in the docs: header that starts with the string HTTP/ ... In PHP 3, this only works when PHP is compiled as an Apache module. You can achieve the same effect using the Status header. IMHO it's obvious that 1. this means header that starts with the string HTTP/ and 2. you can achieve the same effect with Status header only in PHP 3. [2005-03-10 12:49:17] [EMAIL PROTECTED] I don't think that's expected to work for anything other than the CGI SAPI, so I think this is a docs bug if anything. Certainly sapi_header_op doesn't special-case Status:; so this isn't apache2-SAPI-specific. [2005-03-04 17:08:25] OvdSpek at LIACS dot NL But this bug report wasn't about that, it was about Status: 404 Not Found not working. If that's not supposed to work, please mention that in the documentation. 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/32122 -- Edit this bug report at http://bugs.php.net/?id=32122edit=1
[PHP-DOC] #32122 [Opn-Bgs]: header(Status: 404 Not Found); does not work
ID: 32122 User updated by: OvdSpek at LIACS dot NL Reported By: OvdSpek at LIACS dot NL -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Linux, Windows XP, 2003 PHP Version: 5CVS-2005-03-01 New Comment: Note: In PHP 3, this only works when PHP is compiled as an Apache module. You can achieve the same effect using the Status header. This would be correct: Note: In PHP 3 you can achieve the same effect using the Status header, but only when PHP is compiled as Apache module. Previous Comments: [2005-03-15 14:10:54] OvdSpek at LIACS dot NL 2. you can achieve the same effect with Status header only in PHP 3. No, it doesn't mean that. That statement means that the status header method always works, except in PHP 3, where it only works if PHP is ran as module. [2005-03-15 14:08:12] [EMAIL PROTECTED] This is in the docs: header that starts with the string HTTP/ ... In PHP 3, this only works when PHP is compiled as an Apache module. You can achieve the same effect using the Status header. IMHO it's obvious that 1. this means header that starts with the string HTTP/ and 2. you can achieve the same effect with Status header only in PHP 3. [2005-03-10 12:49:17] [EMAIL PROTECTED] I don't think that's expected to work for anything other than the CGI SAPI, so I think this is a docs bug if anything. Certainly sapi_header_op doesn't special-case Status:; so this isn't apache2-SAPI-specific. [2005-03-04 17:08:25] OvdSpek at LIACS dot NL But this bug report wasn't about that, it was about Status: 404 Not Found not working. If that's not supposed to work, please mention that in the documentation. [2005-03-04 16:51:25] [EMAIL PROTECTED] This works: ?php header(HTTP/1.0 404 Not Found); ? 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/32122 -- Edit this bug report at http://bugs.php.net/?id=32122edit=1
[PHP-DOC] #30698 [Bgs]: preg_replace with /e does not escape single quotes as per documentation
ID: 30698
User updated by: php at richardneill dot org
Reported By: php at richardneill dot org
Status: Bogus
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.3.9
New Comment:
Sorry if I'm being daft here, but my reading of the documentation is
that both single and double quotes are always escaped.
However, as per your post:
modify('\\1') resulting in
single quote ', a double quote \, and a backslash\
modify(\\1) ... resulting in
single quote \', a double quote , and a backslash\
My reading of this is that the first time (single quoted
backreference), only the double quotes, but not the single quotes are
escaped. The reverse is true the second time.
Perhaps a better sentence for the documentation would be
Single XOR double quotes are escaped by backslashes in substituted
backreferences
I apologise for getting them the wrong way round earlier!
My main point isn't that it works wrongly, but that the behaviour may
be confusing, and that especially for less wizardly programmers such as
myself, it would be helpful if it were spelled out a little more. I made
a mistake, which I was lucky to catch before I received an SQL injection
attack, and that's why I hope that other people will at least have more
warning before they err similarly.
Best wishes,
Richard
Previous Comments:
[2005-04-05 19:28:03] [EMAIL PROTECTED]
The code is escaped, then executed. Read again the post from 5 Apr
3:46pm CEST.
[2005-04-05 17:47:04] php at richardneill dot org
Sorry - I'm not thinking clearly today - need more coffee! Anyway, the
parts (ii) in my previous comment are complete nonsense, but the parts
(i) are true.
I still think that the documentation is wrong: it reads:
Single AND double quotes are escaped by backslashes in substituted
backreferences
whereas it should read:
In single-quoted backreferences, single-quotes are escaped by
backslashes; double quotes are not escaped. The reverse applies for
double-quoted backreferences.
--
I also think that some sort of warning is important here (even if it's
just a link to another page). This is necessary because a double
escaped quote becomes an SQL injection issue. Eg:
User writes:
Here's a test.
After magic quoting:
Here\'s a test.
After preg_replace using (\\1)
Here\\'s a test
SQL:
$sql=UPDATE table SET value='$input';
Database query is:
UPDATE table SET value='Here\\'s a test'
which is parsed as literal \ followed by unescaped '
Which will fail.
Thus the user thinks that they are always safe because of magic-quotes,
but in fact they are NOT.
[2005-04-05 16:59:43] [EMAIL PROTECTED]
Unescaped quotes doesn't cause parse error thanks to escaping provided
by /e.
?php
echo preg_replace('~.*~e', '\\0', ''); // , no parse error
?
I'm against messing this part with magic_qutes and SQL injection
issues.
[2005-04-05 16:47:43] php at richardneill dot org
I don't think this is exactly bogus, since I think the documentation is
not clear. The documentation for /e says just:
If this modifier is set, preg_replace() does normal substitution of
backreferences in the replacement string, evaluates it as PHP code, and
uses the result for replacing the search string. Single and double
quotes are escaped by backslashes in substituted backreferences.
--
Given that this is a really awkward potential gotcha, especially when
it interacts with PHP's magic quotes and SQL, I think it is worth
stressing that:
a)If the backreference is single quoted, eg:
('\\1')
then
i)Double quotes will become escaped by \
ii)Unescaped single quotes will cause a parse error.
b)If the backreference is double quoted, eg:
(\\1)
then
i)single quotes will become escaped by \
ii)Unescaped double quotes will cause a parse error.
c)If the source is user-input which has had magic-quotes applied, then
quotes of type (i) will end up doubly escaped causing an SQL error,
and one of the escapes must be removed
quotes of type (ii) will lose their magic quoting, and need to have
the escape restored.
[2005-04-05 15:46:35] [EMAIL PROTECTED]
It works as expected and documented:
modify('\\1') is translated to modify('single quote \', a double quote
\, and a backslash\\') resulting in
single quote ', a double quote \, and a backslash\
---
modify(\\1) is translated to modify(single quote \', a double quote
\, and a backslash\\) resulting in
single quote \', a double quote , and a backslash\
[PHP-DOC] #16111 [Com]: IIS + PHP CGI == special administrative concerns
ID: 16111 Comment by: richard dot quadling at bandvulc dot co dot uk Reported By: ramac10 at hotmail dot com Status: Open Bug Type: Documentation problem Operating System: Windows PHP Version: 4.2.1 New Comment: WOW! This is a 3 year old bug. Ok. My comment would be to drop IIS/PWS. I use Sambar (http://www.sambar.com) which is free and has a commercial license for those needing more support (and a lot of additional facilities). NOTE: Sambar and Samba are NOT related. Both the PHP manual and the Sambar documentation have details about using each other. I've used Sambar from Win98SE up to Windows 2000 Server. I've used it on customer sites for intranet web servers. If you can't fix the issue, then try something else. I'd normally get Sambar, PHP5 and mySQL installed and running in under 15 minutes. Nothing goes into the Windows directory other than a few INI files. All the apps run from there own directories. The registry is not polluted either. Nice and clean and liked by me! Richard. Previous Comments: [2005-03-14 01:02:11] amr at msexpert dot com i tried all that on win2003 machine , noting works at all full permissions , restart , file copy and the =0 option and register globals . I closed the window and opened the door and still not working . any ideas ? [2004-09-21 07:10:25] rajesh at glidemail dot com To Everyone complaining that cgi.force_redirect = 0 is not working, I must say that remove ; (semi-colon) before that line. That is for comment. Remove line and it might work. [2004-07-13 11:03:15] chooilai at yahoo dot com i using php 4.3.0 with PWS on a Win98 system. when i try to run phpinfo to test for the installation it comes like below: Security Alert! PHP CGI cannot be accessed directly. This PHP CGI binary was compiled with force-cgi-redirect enabled. This means that a page will only be served up if the REDIRECT_STATUS CGI variable is set. This variable is set, for example, by Apache's Action directive redirect. i try a lot of way to do but still the same. t set the cgi.force_redirect to 0 , the error will ( no file selected) i am sure that pws is not the problem because i already test for which i type http://localhost. pls help me to solve this problem , i already try for two but still cannot solve it. thanks [2004-06-21 17:19:55] c dot clix at tiscali dot it I have the solution for the reported problem by domingodjf at terra dot es: He says that with iis+php he had to generate redirects by javascript. I also had the same problem. I solved the problem when I switched to full absolute URL. For example: header( 'Location: http://' . $_SERVER['HTTP_HOST'] . $path ); I hope this will help. [2003-05-12 14:06:43] [EMAIL PROTECTED] The issue of IIS permissions is related to this report but is difficult (at least for me) to come up with a straight forward comment on the issue. In doing some research it appears there are many factors that come into play here most of which fall under IIS Administration. A few PHP related resources: http://www.iis-resources.com/modules/news/article.php?storyid=4 http://forums.devshed.com/archive/5/2002/10/3/45479 Basically the IIS user (usually IUSR_MACHINENAME) needs permission to read various files and directories, such as php.ini, docroot, and the session tmp directory... I don't feel comfortable documenting this without raising potential security issues (aka chmod 777 everything!!!) but will reopen for future comment. Maybe someone has a nice solution to this problem and actually knows the topic (I don't). Also some people have treated this report as a support forum, well, it's not. Do not ask support questions here. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16111 -- Edit this bug report at http://bugs.php.net/?id=16111edit=1
[PHP-DOC] #28448 [Com]: php.ini location change to enable multiple versions of PHP
ID: 28448 Comment by: peter dot ordal at rochester dot edu Reported By: gidmanma at hotmail dot com Status: Open Bug Type: Documentation problem Operating System: Windows Server 2003 PHP Version: Irrelevant New Comment: I'm not seeing this behavior. I followed the instructions exactly but php never seems to check its directory for php.ini. I watched where it was looking with FileMon (systeminternals.com) and it looked in the web server folder, and c:\windows, but not its own folder (both 4 and 5). When PHP didn't find php.ini in either of those locations, it just reverted to using default values. Previous Comments: [2004-05-19 22:12:14] [EMAIL PROTECTED] You can easily acheive it this way: install PHP 4 to C:\php4 put your PHP 4 specific php.ini file into C:\php4 rearrange the contents of that folder so that all the .dll files from the dlls and extensions folders live in C:\php4. Make sure your extensions_dir=c:\php4 in your c:\php4\php.ini [this creates a self-contained PHP 4 distro] install PHP 5 to C:\php5 put your PHP 5 specific php.ini into C:\php5\php.ini move all the extension .dlls into C:\php5 [this creates a self-contained PHP 5 distro] Make sure that NEITHER C:\php4 nor C:\php5 are listed in your PATH. Remove all PHP related DLLs from your windows system directly. Remove the global php.ini from C:\windows\php.ini [this removes global stuff that might confuse things] Making this a docu problem, since we should have it mentioned somewhere. [2004-05-19 20:57:07] gidmanma at hotmail dot com Description: IIS 6.0 on Windows Server 2003 allows seperate MIME mappings for each web site on the server. Using site specific MIME mappings I am running both PHP 4.3.6 and PHP 5.0.0 RC2 (both in ISAPI) at the same time on the same server. The only problem is that there is no way to specify a seperate php.ini for each version of PHP installed. Can something be changed in PHP that either causes it to look for the ini in the same folder/directory as the dll? Or, is there another way around this problem? TIA -- Edit this bug report at http://bugs.php.net/?id=28448edit=1
[PHP-DOC] #20966 [Com]: CHM search index includes irrelevant words
ID: 20966 Comment by: richard dot quadling at bandvulc dot co dot uk Reported By: sholden at holdenweb dot com Status: Assigned Bug Type: Documentation problem Operating System: Windows, any PHP Version: 4.3.0RC3 Assigned To: goba New Comment: I think the only way this could be handled is to have the navigation links generated in JavaScript rather than in plain HTML. This way it would not be searched by the full text searching of MS CHM Viewer. The only normal way to have things NOT included in the full text search is to produce a word stop list (limited to 512 bytes! Gee! They really know how to be generous at MS!!!), but this is then across the entire manual - not much use. There does not seem to be any tag you can put around text to make it NOT indexable (which would be nice). This would probably have to be handled by the htmlhelp/make_chm.php script(s). Thinking out loud, what happens if the text is not ascii? Use the %xx code or #xxx; code. Seems daft though doesn't it? Taking abc and converting it into something just so it doesn't get searched? The JS solution would fix the problem, but changes to the CHM build process would also know onto the skins too. But, if this is a really requirement, how about introducing a docbook element specifically dealing with text that is NOT searchable and then because it is in the system from the ground up, those system which can support it can! So, the CHM build process could take the XML and create a specific div class which can be looked for and then converted into a simple bunch of JavaScript's document.writeln()'s. This would also allow documentors to exclude parts of the documentation from the CHM full text search. (Not sure why - but a perfect example is the search including navigation links! grin /). Richard. Previous Comments: [2002-12-13 01:36:41] [EMAIL PROTECTED] Well the, search index is created by the CHM compiler after it compiled in the HTML files. So there is no method to index the pages without the navigation parts and then replace the files with the full ones. I even don't know any method to put some HTML parts into some ignored section in the HTML files, so I really don't know how to fix this. I'll try to look up some info, but I hardly beleive I'll find something useful. Microsoft HH compiler is not too smart... [2002-12-12 11:28:14] sholden at holdenweb dot com The CHM file is somewhat over-indexed. For example, when I search for payment, among the relevant hits I also see the curl_version page because the next page link in the footer is entitled Cybercash *payment* options. This seems redundant and likely to render searches less useful than they would otherwise be. Can't find any other reports of this, hence the new bug report. -- Edit this bug report at http://bugs.php.net/?id=20966edit=1
[PHP-DOC] #32545 [Bgs-Opn]: error control operator on include() supresses Parse Errors
ID: 32545
User updated by: mailfrom-bugs dot php dot net at kopka dot net
-Summary: @include() supresses even Parse Errors
Reported By: mailfrom-bugs dot php dot net at kopka dot net
-Status: Bogus
+Status: Open
-Bug Type: Scripting Engine problem
+Bug Type: Documentation problem
Operating System: Gentoo
PHP Version: 5.0.3
New Comment:
If the behavior is intended then please make the
Note: The @ error-control operator prefix will not disable messages
that are the result of parse errors.
(which is wrong in the case of include) on page
http://de2.php.net/manual/en/language.operators.errorcontrol.php
more clear about this.
Thanks for your support.
Previous Comments:
[2005-04-02 18:05:10] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
[2005-04-02 17:38:43] mailfrom-bugs dot php dot net at kopka dot net
The @include() also eats error messages for exceptions thrown inside
the included file which are not catched later on !
a.php
=
?php
class Test_Exception extends Exception {}
try [EMAIL PROTECTED](b.php);}
catch (Test_Exception $e) {echo Test_Exception thrown;}
echo OK;
?
b.php
=
?php
throw new Exception(something wrong);
?
Expected result:
Fatal error: Uncaught exception 'Exception' with message 'something
wrong' in b.php:2
Stack trace:
#0 a.php(3): unknown()
#1 a.php(6): include_once('b.php)
#2 {main} thrown in b.php on line 2
Actual result:
--
OK
[2005-04-02 17:21:33] mailfrom-bugs dot php dot net at kopka dot net
Description:
I don't know how to classify this so i leave it to someone who might
have a better idea how to deal with this:
BUG DESCRIPTION
===
@include() supresses all error messages, INCLUDING PARSE ERRORS, in the
included script and all descendents.
This also affects __autoload so that there are no warnings whatsoever
when something goes wrong.
This makes a script using @include undebugable!
DOCUMENTATION PROBLEM
=
http://de2.php.net/manual/en/language.operators.errorcontrol.php states
that:
Note: The @ error-control operator prefix will not disable messages
that are the result of parse errors.
which is clearly wrong (see example).
It also states in the follwing warning:
Currently the @ error-control operator prefix will even disable error
reporting for critical errors that will terminate script execution.
Among other things, this means that if you use @ to suppress errors
from a certain function and either it isn't available or has been
mistyped, the script will die right there with no indication as to why.
which also quite misses the current behavior.
It seems to me that the current implementation of the @ operator is to
set error_reporting to E_NONE for the evaluation of the following
expression This is OK for something like
@list($a, $b, $c) = explode($sep, $string);
where it catches the 'Undefined offset' note.
I ran into this doing the following:
if ([EMAIL PROTECTED]($path1.$filename))
{require_once($path2.$filename);}
wondering why the script terminates somewhere silently without giving a
notice about a reason.
After some hours of digging i found the error which aborted the script
and then traced the missing fatal back to the @include().
FEATURE REQUEST
===
@ should modify error_reporting only for the current expression, and
not globally until the evaluation is complete.
RELATED
===
Effect is also visible in example of Bug #31736
Reproduce code:
---
File include.php
--
?php
@include(included.php);
?
File included.php
--
?php
[parse error of your choice]
?
Expected result:
Parse error: parse error, unexpected [something] in included.php on
line 2
Actual result:
--
FATAL error message is supressed.
--
Edit this bug report at http://bugs.php.net/?id=32545edit=1
[PHP-DOC] cvs: phpdoc /en/reference/spl/functions class-implements.xml
helly Tue Apr 12 18:10:08 2005 EDT Modified files: /phpdoc/en/reference/spl/functions class-implements.xml Log: - Update http://cvs.php.net/diff.php/phpdoc/en/reference/spl/functions/class-implements.xml?r1=1.4r2=1.5ty=u Index: phpdoc/en/reference/spl/functions/class-implements.xml diff -u phpdoc/en/reference/spl/functions/class-implements.xml:1.4 phpdoc/en/reference/spl/functions/class-implements.xml:1.5 --- phpdoc/en/reference/spl/functions/class-implements.xml:1.4 Mon Apr 11 11:21:20 2005 +++ phpdoc/en/reference/spl/functions/class-implements.xml Tue Apr 12 18:10:08 2005 @@ -1,5 +1,5 @@ ?xml version='1.0' encoding='iso-8859-1'? -!-- $Revision: 1.4 $ -- +!-- $Revision: 1.5 $ -- refentry id=function.class-implements refnamediv refnameclass_implements/refname @@ -14,7 +14,7 @@ methodparamtypemixed/typeparameterclass/parameter/methodparam /methodsynopsis para - This function returns an array with the name of the interfaces that the + This function returns an array with the names of the interfaces that the given parameterclass/parameter implements. /para /refsect1 @@ -27,7 +27,7 @@ termparameterclass/parameter/term listitem para - An object or a string of the class + An object (class instance) or a string (class name). /para /listitem /varlistentry
[PHP-DOC] cvs: phpdoc /en/reference/ibm_db2 configure.xml constants.xml reference.xml /en/reference/ibm_db2/functions db2-autocommit.xml db2-close.xml db2-connect.xml db2-pconnect.xml
dbs Tue Apr 12 19:45:14 2005 EDT Added files: /phpdoc/en/reference/ibm_db2configure.xml Modified files: /phpdoc/en/reference/ibm_db2constants.xml reference.xml /phpdoc/en/reference/ibm_db2/functions db2-autocommit.xml db2-close.xml db2-connect.xml db2-pconnect.xml Log: Add real details and examples for basic functions. http://cvs.php.net/diff.php/phpdoc/en/reference/ibm_db2/constants.xml?r1=1.1r2=1.2ty=u Index: phpdoc/en/reference/ibm_db2/constants.xml diff -u phpdoc/en/reference/ibm_db2/constants.xml:1.1 phpdoc/en/reference/ibm_db2/constants.xml:1.2 --- phpdoc/en/reference/ibm_db2/constants.xml:1.1 Tue Apr 12 17:12:48 2005 +++ phpdoc/en/reference/ibm_db2/constants.xml Tue Apr 12 19:45:14 2005 @@ -1,5 +1,5 @@ ?xml version='1.0' encoding='iso-8859-1'? -!-- $Revision: 1.1 $ -- +!-- $Revision: 1.2 $ -- !-- Generated by xml_proto.php v2.2. Found in /scripts directory of phpdoc. -- section id=ibm_db2.constants reftitle.constants; @@ -11,8 +11,7 @@ (typeinteger/type) /term listitem -simpara - +simpara /simpara /listitem /varlistentry @@ -44,8 +43,10 @@ (typeinteger/type) /term listitem -simpara - +simpara + Specifies a scrollable cursor for a statement resource. This mode enables + random access to rows in a result set, but currently is supported only by + IBM DB2 Universal Database. /simpara /listitem /varlistentry @@ -56,7 +57,8 @@ /term listitem simpara - + Specifies a forward-only cursor for a statement resource. This is the + default cursor type and is supported on all database servers. /simpara /listitem /varlistentry @@ -67,7 +69,8 @@ /term listitem simpara - + Specifies the PHP variable should be bound as an IN parameter for a + stored procedure. /simpara /listitem /varlistentry @@ -78,7 +81,8 @@ /term listitem simpara - + Specifies the PHP variable should be bound as an OUT parameter for a + stored procedure. /simpara /listitem /varlistentry @@ -89,7 +93,8 @@ /term listitem simpara - + Specifies the PHP variable should be bound as an INOUT parameter for a + stored procedure. /simpara /listitem /varlistentry @@ -100,7 +105,8 @@ /term listitem simpara - + Specifies that the column should be bound directly to a file for input or + output. /simpara /listitem /varlistentry @@ -111,7 +117,7 @@ /term listitem simpara - + Specifies that autocommit should be turned on. /simpara /listitem /varlistentry @@ -122,7 +128,7 @@ /term listitem simpara - + Specifies that autocommit should be turned off. /simpara /listitem /varlistentry @@ -133,7 +139,8 @@ /term listitem simpara - + Specifies that the variable should be bound as a DOUBLE, FLOAT, or REAL + data type. /simpara /listitem /varlistentry @@ -144,7 +151,8 @@ /term listitem simpara - + Specifies that the variable should be bound as a SMALLINT, INTEGER, or + BIGINT data type. /simpara /listitem /varlistentry @@ -155,7 +163,7 @@ /term listitem simpara - + Specifies that the variable should be bound as a CHAR or VARCHAR data type. /simpara /listitem /varlistentry http://cvs.php.net/diff.php/phpdoc/en/reference/ibm_db2/reference.xml?r1=1.1r2=1.2ty=u Index: phpdoc/en/reference/ibm_db2/reference.xml diff -u phpdoc/en/reference/ibm_db2/reference.xml:1.1 phpdoc/en/reference/ibm_db2/reference.xml:1.2 --- phpdoc/en/reference/ibm_db2/reference.xml:1.1 Tue Apr 12 17:12:48 2005 +++ phpdoc/en/reference/ibm_db2/reference.xml Tue Apr 12 19:45:14 2005 @@ -1,35 +1,54 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.1 $ -- +!-- $Revision: 1.2 $ -- !-- Generated by xml_proto.php v2.2. Found in /scripts directory of phpdoc. -- reference id=ref.ibm_db2 - titleibm_db2 Functions/title + titleIBM DB2, Cloudscape and Apache Derby Functions/title titleabbrevibm_db2/titleabbrev partintro section id=ibm_db2.intro reftitle.intro; para -This is the ibm_db2 extension. It enables you to connect to IBM DB2 -Universal Database, IBM Cloudscape, or Apache Derby databases. +These functions enable you to access IBM DB2 Universal Database, IBM +Cloudscape, and Apache Derby databases using the DB2 Call Level Interface +(DB2 CLI). /para /section section id=ibm_db2.requirements reftitle.required; para To connect to IBM DB2 Universal Database for Linux, UNIX, and Windows, or -IBM Cloudscape, or Apache Derby, you must install an IBM DB2 client on the -same computer on
[PHP-DOC] cvs: phpdoc /en/reference/ibm_db2/functions db2-connect.xml db2-exec.xml
dbs Tue Apr 12 20:37:16 2005 EDT Modified files: /phpdoc/en/reference/ibm_db2/functions db2-connect.xml db2-exec.xml Log: Add details for db2_exec(). Correct typo in db2_connect(). http://cvs.php.net/diff.php/phpdoc/en/reference/ibm_db2/functions/db2-connect.xml?r1=1.2r2=1.3ty=u Index: phpdoc/en/reference/ibm_db2/functions/db2-connect.xml diff -u phpdoc/en/reference/ibm_db2/functions/db2-connect.xml:1.2 phpdoc/en/reference/ibm_db2/functions/db2-connect.xml:1.3 --- phpdoc/en/reference/ibm_db2/functions/db2-connect.xml:1.2 Tue Apr 12 19:45:14 2005 +++ phpdoc/en/reference/ibm_db2/functions/db2-connect.xml Tue Apr 12 20:37:15 2005 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.2 $ -- +!-- $Revision: 1.3 $ -- !-- Generated by xml_proto.php v2.2. Found in /scripts directory of phpdoc. -- refentry id=function.db2-connect refnamediv @@ -117,7 +117,7 @@ termparameteroptions/parameter/term listitem para - An associative array connection options that affect the behavior + An associative array of connection options that affect the behavior of the connection, where valid array keys include: variablelist varlistentry http://cvs.php.net/diff.php/phpdoc/en/reference/ibm_db2/functions/db2-exec.xml?r1=1.1r2=1.2ty=u Index: phpdoc/en/reference/ibm_db2/functions/db2-exec.xml diff -u phpdoc/en/reference/ibm_db2/functions/db2-exec.xml:1.1 phpdoc/en/reference/ibm_db2/functions/db2-exec.xml:1.2 --- phpdoc/en/reference/ibm_db2/functions/db2-exec.xml:1.1 Tue Apr 12 17:12:48 2005 +++ phpdoc/en/reference/ibm_db2/functions/db2-exec.xml Tue Apr 12 20:37:15 2005 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.1 $ -- +!-- $Revision: 1.2 $ -- !-- Generated by xml_proto.php v2.2. Found in /scripts directory of phpdoc. -- refentry id=function.db2-exec refnamediv @@ -13,11 +13,28 @@ methodsynopsis typeresource/typemethodnamedb2_exec/methodname methodparamtyperesource/typeparameterconnection/parameter/methodparam - methodparamtypestring/typeparameterstmt_string/parameter/methodparam + methodparamtypestring/typeparameterstatement/parameter/methodparam methodparam choice=opttypearray/typeparameteroptions/parameter/methodparam /methodsynopsis - warn.undocumented.func; + warn.experimental.func; + + para + Prepares and executes an SQL statement. + /para + para + If you plan to interpolate PHP variables into the SQL statement, understand + that this is one of the more common security exposures. Consider calling + functiondb2_prepare/function to prepare an SQL statement with parameter + markers for input values. Then you can call functiondb2_execute/function + to pass in the input values and avoid SQL injection attacks. + /para + para + If you plan to repeatedly issue the same SQL statement with different + parameters, consider calling functiondb2_prepare/function and + functiondb2_execute/function to enable the database server to reuse its + access plan and increase the efficiency of your database access. + /para /refsect1 refsect1 role=parameters @@ -26,117 +43,162 @@ variablelist varlistentry termparameterconnection/parameter/term - listitem - para -Its description - /para - /listitem - /varlistentry + listitem + para + A valid database connection resource variable as returned from + functiondb2_connect/function or functiondb2_pconnect/function. + /para + /listitem +/varlistentry varlistentry - termparameterstmt_string/parameter/term - listitem - para -Its description - /para - /listitem - /varlistentry + termparameterstatement/parameter/term + listitem + para + An SQL statement. + /para + /listitem +/varlistentry varlistentry termparameteroptions/parameter/term - listitem - para -Its description - /para - /listitem - /varlistentry + listitem + para + An associative array containing statement options. You can use this + parameter to request a scrollable cursor on database servers that + support this functionality. + variablelist +varlistentry + termparametercursor/parameter/term + listitem + para + Passing the literalDB2_FORWARD_ONLY/literal value requests a + forward-only cursor for this SQL statement. This is the default + type of cursor, and it is supported by all database servers. It is + also much faster than a scrollable cursor. + /para + para + Passing the literalDB2_SCROLLABLE/literal value requests a + scrollable cursor for this SQL statement. This type of cursor + enables you to fetch rows non-sequentially from the database + server.
