[PHP-DOC] #29936 [Opn->Bgs]: Depricated but valid php 4 postgres functions not listed
ID: 29936 Updated by: [EMAIL PROTECTED] Reported By: jason at linenplace dot com -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Website problem PHP Version: Irrelevant New Comment: Duplicate of PHP bug #17795 so please add comments there. Previous Comments: [2004-09-14 16:06:17] jason at linenplace dot com pg_exec() is depricated relative to the latest versions of php. However, in earlier versions still fully supported on the website, pg_exec() is a valid function without alias. Documentation standards such as: "Functions which are kept only for backwards compatibility should be listed under their current parent names, and not documented as separate functions." are very reasonable. However, that does not apply yet. We are not talking about some function from a version of PHP that practically no one runs anymore. A large percentage of webservers still run on php 4.0-4.2. Thus, for many users, the function pg_exec is neither depricated nor aliased. [2004-09-14 12:56:06] [EMAIL PROTECTED] So also http://www.php.net/manual/howto/chapter-what-to-document.html should be changed: "Only major functions should be documented; functions which are deprecated variants may be mentioned, but should not be documented as separate functions. They instead should be referenced in the parent function as an alias." [2004-09-14 12:40:10] [EMAIL PROTECTED] They should be, as the documentation is for 4.0.0-4.3.8 and people looking for a function used in an application that they maintain should not be made harder. [2004-09-14 11:40:25] [EMAIL PROTECTED] There's a note at http://www.php.net/manual/en/function.pg-query.php and there's a list of deprecated functions at http://www.php.net/manual/en/ref.pgsql.php#AEN102913. Deprecated functions should not be listed in the function list. [2004-09-01 21:36:28] jason at linenplace dot com Description: I just started working with php's postgres functions. I found out (after hours of frustration some of which is admittedly my fault) that there are depricated names for certain functions. For example, pg_exec was replaced with pg_query in php <= 4.2 All php programmers access the same function list. pg_exec is a valid function for many of us. It should be on the function list as long as the website provides support for versions < 4.2 Thank you very much for your consideration. Jason Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/?id=29936&edit=1
[PHP-DOC] #17795 [WFx->Opn]: PostgreSQL documentation should have entry for deprecated function name
ID: 17795 Updated by: [EMAIL PROTECTED] Reported By: caugustin at alcyonis dot fr -Status: Wont fix +Status: Open Bug Type: Documentation problem Operating System: any PHP Version: 4.2.0 New Comment: Should this be revisited? If we do this, we'll have to do it for every deprecated function in all of PHP >= 4.0.0. If done, we should do something like not show these aliases in the function lists/sidebar. Looks like I'm one reason this never happenend, not sure how that happened exactly. I think we discussed this once. Previous Comments: [2003-01-21 02:34:44] [EMAIL PROTECTED] It's been a long time since this all happened, we sorta missed the boat :) Since it's been so long and search.php will indirectly redirect users to the proper places ... I think it's okay if we don't add all these aliases so am marking this as won't fix. Note that the old names still work although they are deprecated. They'll most likely work for quite awhile. In the future we need to handle this more gracefully. The same approach that's applied to extensions (deletions and moves->pecl) can be applied here. [2003-01-05 05:22:02] [EMAIL PROTECTED] I don't see problems with listing old functions in the manual. (create xml files that point to new functions) I didn't create old function name xml files, since aliases aren't supposed to be documented. I'm not sure if it applies in this case. If everyone agrees, please feel free to add entries. [2002-11-19 00:34:45] [EMAIL PROTECTED] This sounds reasonable. The current docs make it sound as if the aliases are going away very soon ... why? It's a recent change. In fact, old mysql aliases have been around since the 90's and afaik the mysql alias docs have only recently been removed. It makes sense to encourage a move but not to scare people. I vote +1 we create these alias entries because the move is so recent and will do so unless someone feels otherwise (then we can discuss it :) [2002-06-17 05:47:26] caugustin at alcyonis dot fr I went to PostgreSQL documentation and didn't find most of the function I know. When you change a function name in the documentation, the old name have to be avaible and noted deprecated, not only removed. It is very important for how people see php in the professional world. It doesn't help us to promote it to our customers if such important things can change any time. Please re-introduce old function name. Cedric. -- Edit this bug report at http://bugs.php.net/?id=17795&edit=1
[PHP-DOC] #30537 [Opn]: Predefined Constants Missing Magic constants
ID: 30537 Updated by: [EMAIL PROTECTED] Reported By: ammar at gnuix dot com Status: Open Bug Type: Documentation problem Operating System: * PHP Version: Irrelevant New Comment: Some notes: - These constants are linked to from here: http://php.net/constants - reserved.constants should link to language.constants but as of now reserved.constants contains the following text: So perhaps it shouldn't be touched, or, the above note be removed. - The [predefined/reserved] constants pages should in the very least be 'grouped together' a little better. Previous Comments: [2004-10-23 03:16:27] ammar at gnuix dot com Description: I checked the reserved constants page http://www.php.net/manual/en/reserved.constants.php And followed both links, Core Predefined Constants -- Constants defined in the PHP core, Zend, and SAPI modules Standard Predefined Constants -- Constants defined in PHP by default I didn't find the following constants: __FILE__ __LINE__ __FUNCTION__ __CLASS__ __METHOD__ Maybe they are somewhere else, but for usability and convenience I think they should be added to this page, maybe in a seperate category. P.S: Please reply to my email address directly, as i'm not subscribed to this list Regards, Ammar Ibrahim -- Edit this bug report at http://bugs.php.net/?id=30537&edit=1
[PHP-DOC] #30537 [Csd->Opn]: Predefined Constants Missing Magic constants
ID: 30537 Updated by: [EMAIL PROTECTED] Reported By: ammar at gnuix dot com -Status: Closed +Status: Open Bug Type: Documentation problem Operating System: * PHP Version: Irrelevant New Comment: The issue of translation has not been resolved. Previous Comments: [2004-10-28 10:19: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. "See also: Magic constants." in Core Predefined Constants. [2004-10-28 02:44:58] ammar at gnuix dot com But I think they need to be also linked from the reserved constants page. Information should be available wherever appropriate, I had hard time finding those magic constants, if they were linked from that page things would have been better :) [2004-10-26 06:39:04] [EMAIL PROTECTED] Some notes: - These constants are linked to from here: http://php.net/constants - reserved.constants should link to language.constants but as of now reserved.constants contains the following text: So perhaps it shouldn't be touched, or, the above note be removed. - The [predefined/reserved] constants pages should in the very least be 'grouped together' a little better. [2004-10-23 03:16:27] ammar at gnuix dot com Description: I checked the reserved constants page http://www.php.net/manual/en/reserved.constants.php And followed both links, Core Predefined Constants -- Constants defined in the PHP core, Zend, and SAPI modules Standard Predefined Constants -- Constants defined in PHP by default I didn't find the following constants: __FILE__ __LINE__ __FUNCTION__ __CLASS__ __METHOD__ Maybe they are somewhere else, but for usability and convenience I think they should be added to this page, maybe in a seperate category. P.S: Please reply to my email address directly, as i'm not subscribed to this list Regards, Ammar Ibrahim -- Edit this bug report at http://bugs.php.net/?id=30537&edit=1
[PHP-DOC] #31008 [Fbk]: Possible bug in the example code
ID: 31008
Updated by: [EMAIL PROTECTED]
Reported By: afjoijojifaj9foobar dot 5 dot rdancer at spamgourme
Status: Feedback
Bug Type:Documentation problem
PHP Version: Irrelevant
New Comment:
The code in question is actually here:
http://php.net/manual/en/language.oop.php
Previous Comments:
[2004-12-07 21:40:14] [EMAIL PROTECTED]
Where is that code?
Tha page you specified doesn't have any example.
[2004-12-07 16:17:00] [EMAIL PROTECTED]
Docproblem.
[2004-12-07 12:35:50] afjoijojifaj9foobar dot 5 dot rdancer at
spamgourme
Description:
The test in the remove_item() function should be
if ($this->items[$artnr] >= $num)
^^
Cheers,
Jan Minář
"http://uk2.php.net/manual/en/language.oop5.php":
items[$artnr] += $num;
}
// Take $num articles of $artnr out of the cart
function remove_item($artnr, $num) {
if ($this->items[$artnr] > $num) {
$this->items[$artnr] -= $num;
return true;
} else {
return false;
}
}
}
?>
--
Edit this bug report at http://bugs.php.net/?id=31008&edit=1
[PHP-DOC] #30935 [Opn->Csd]: compact fails for superglobals
ID: 30935
Updated by: [EMAIL PROTECTED]
Reported By: bugs-php-net at schirmeier dot com
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Linux x86
PHP Version: 5.0.2
New Comment:
This behavior has been documented. Thank you for the report, and
locating the problem. Here's the diff:
http://cvs.php.net/diff.php/phpdoc/en/reference/array/functions/compact.xml?r1=1.7&r2=1.8
Previous Comments:
[2004-11-29 23:17:53] [EMAIL PROTECTED]
This is indeed a Documentation problem, marking as such.
[2004-11-29 22:39:53] bugs-php-net at schirmeier dot com
Well, Keita Ito thankfully informed me about the "Warning: Please note
that variable variables cannot be used with PHP's Superglobal arrays
within functions or class methods." on
http://www.php.net/variables.variable -- which also seems to be valid
for compact().
It'd be helpful if this could be included in the documentation for
compact().
Or even better: Remove this weird behaviour for variable variables AND
compact().
[2004-11-29 22:22:48] bugs-php-net at schirmeier dot com
"Version:" corrected to latest "stable" version the bug was reproduced
with.
[2004-11-29 22:19:05] bugs-php-net at schirmeier dot com
Description:
compact() does not "see" superglobals like $_GET/$_POST/etc. when
called within a function (documentation says: "Any strings that are not
set will simply be skipped.").
Tested on PHP versions 4.3.2, 4.3.9 (both Apache module and cli),
5.0.0, 5.0.1 (cli), 5.0.2, php5.1-dev-cli.
Reproduce code:
---
Expected result:
A dump of an array with indexes '_GET', '_POST' etc. pointing to the
contents of the respective superglobals, then a dashed line, then the
same dump again.
Actual result:
--
The expected dump, the dashed line, and a:0:{}.
--
Edit this bug report at http://bugs.php.net/?id=30935&edit=1
[PHP-DOC] #23907 [Ctl]: Need additional installation step for IIS 6.0 / Windows Server 2003
ID: 23907 Updated by: [EMAIL PROTECTED] Reported By: bryn at mrpath dot com Status: Critical Bug Type: Documentation problem Operating System: Windows Server 2003 PHP Version: 4.3.2 New Comment: When this bug report is dealt with (and closed!), also solve the following bug reports: #29275 and #21833 Previous Comments: [2004-12-17 01:46:47] unknown at simplemachines dot org I can confirm that: - this affects Windows Server 2003 and IIS 6 only. - this is needed for both CGI or ISAPI mode. - this is currently not in the documentation. A tutorial I wrote earlier this year covers many of the major steps involved, although it hasn't been updated for PHP 5 yet (it was written while PHP 5 was still in beta.) The relevant section of said tutorial can be found here: http://unknown.network32.net/tutorial.basic-server#configure.php.iis The Macromedia tutorial linked to in one of the previous comments does *not* describe the necessary information either. However, some comments to the documentation page do. Any other problems are not related to this bug; notably, the whole CGI issue *is* properly documented already (although ISAPI is more efficient...) Thanks, -[Unknown] [2004-09-07 19:57:18] joel at preacherboy dot net I have my moments. [2004-09-06 20:55:10] m_deheneffe at hotmail dot com you're a genius... [2004-09-01 17:53:38] joel at preacherboy dot net I couldn't for the life of me get IIS 5.1 and PHP 5 in CGI mode to work. I ignored all previous PHP 4 related instructions as I figured them to be irrelevant. After reading Philip's comments about the Macromedia tutorial, I finally decided using their method for CGI mode just might work. All it took to get IIS 5.1 and PHP 5 to work in CGI mode was the following lines, never referenced in the official documentation as what you *must* do: cgi.force_redirect = 0 // Default must be 1 when commented out. cgi.redirect_status_env = ENV_VAR_NAME Now that I'm not running in ISAPI mode, all of my scripts aren't open handles of dllhost.exe. dllhost.exe is no longer crashing every time the system is restarted. Yay! [2004-08-22 20:55:33] [EMAIL PROTECTED] The IIS docs need help, someone who uses IIS should really update these docs. Marking as critical. The PHP installer should also look into being updated for this (although IMHO nobody should use the PHP installer!) 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/23907 -- Edit this bug report at http://bugs.php.net/?id=23907&edit=1
[PHP-DOC] #31591 [Ver->Opn]: apache_getenv() is an 'undefined function'
ID: 31591
Updated by: [EMAIL PROTECTED]
Reported By: aronnax_98 at yahoo dot com
-Status: Verified
+Status: Open
Bug Type: Documentation problem
Operating System: Mac OS X 10.3.7
PHP Version: 4.3.9
New Comment:
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.
Previous Comments:
[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=31591&edit=1
[PHP-DOC] #21970 [Ver]: Creating a new Tutorial section
ID: 21970 Updated by: [EMAIL PROTECTED] Reported By: philip at cornado dot com Status: Verified Bug Type: Documentation problem Operating System: all PHP Version: N/A Assigned To: aidan New Comment: Somewhere down the line this bug report got renamed so be sure it's not closed until include_path is properly (extensively) documented. Not everything belongs in a tutorial...I agree with Goba on all points. Previous Comments: [2005-01-24 16:44:24] [EMAIL PROTECTED] I agree with both Anatoly & Goba, here. - Getting started needs to be easily found by new developers. - And ~"Techniques" is a good name for the section we envisioned as "Tutorials" they're programming (usually php-specific or web-specific) techniques. - Perhaps a note should be dropped into the intro to "features/techniques" section that links to Getting Started. S [2005-01-23 15:09:06] [EMAIL PROTECTED] I think 'getting started' should be left alone, it is quite good for a beginner to start. If you look a bit closely at 'features' though, it is the exact place where tutorials are located already. We agreed on it before AFAIR that extension specific tutorials should go into their reference part, while broader scope tutorials or core tutorials should go into 'features'. Now we can rename it to 'PHP Programming Techniques' or something more flashy, but I think it is the right place to push tutorials into (except the getting started tutorial). Derek: 'reference' should be very far from being confused with 'tutorial' IMHO! [2005-01-23 14:50:02] [EMAIL PROTECTED] No, getting started is for beginners and they should be able to get to this page as fast as possible by just clicking "next" link or by looking at Table of Contents. Being good attractor for newbies "Getting Started" should be located at the top of ToC and visible by default. "Language Reference" is too dull to reflect how clear and easy PHP is. [2005-01-23 08:23:39] [EMAIL PROTECTED] I believe we should rename Getting Started to Tutorials (or something similar and relevant), and move it below Language Reference. The introduction section of Getting Started should be moved to the beginning of the Language Reference section. This seems to fit best. Right now 'Getting Started' is an oddball. [2005-01-23 08:19:10] [EMAIL PROTECTED] I disagree. I think a lot of that content was added because there was no other good place for it. It would be nice to get some feedback from Goba! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21970 -- Edit this bug report at http://bugs.php.net/?id=21970&edit=1
[PHP-DOC] #31698 [Opn->Bgs]: install.txt Apache2 dangling FAQ ref
ID: 31698 Updated by: [EMAIL PROTECTED] Reported By: fumanchu at amor dot org -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Win2k PHP Version: 4.3.10 New Comment: The piece of text that refers to the FAQ was changed to: We do not recommend using a threaded MPM in production with Apache2. Use the prefork MPM instead, or use Apache1. For information on why, read the following And the FAQ title to: Why shouldn't I use Apache2 with a threaded MPM in a production environment? See these diffs: http://cvs.php.net/diff.php/phpdoc/en/language-snippets.ent?r1=1.125&r2=1.126 http://cvs.php.net/diff.php/phpdoc/en/faq/installation.xml?r1=1.40&r2=1.41 This bug report is due to an "old" install.txt compared to a new PHP Manual build. So, this bug is officially bogus although it's understandable why it was opened. If someone feels the script that generates install.txt from the doc sources should include links then open a new bug report as that's a different issue. Previous Comments: [2005-01-26 01:51:28] [EMAIL PROTECTED] I changed this FAQ entry. The install.txt file also needs to be changed, though. S [2005-01-26 01:03:02] [EMAIL PROTECTED] The Apache2 threading FUD is what the INSTALL file is referring to, and this is located at: http://us2.php.net/manual/en/faq.installation.php#faq.installation.apache2 It appears someone got lazy and converted text to INSTALL, without preserving links -- this problem appears in more than one place. [2005-01-26 00:01:57] fumanchu at amor dot org Description: Upon a fresh install of PHP 4.3.10, install.txt contains the following text: Apache 2.0.x on Microsoft Windows This section contains notes and hints specific to Apache 2.0.x installs of PHP on Microsoft Windows systems. We also have instructions and notes for Apache 1.3.x users on a separate page. Note: You should read the manual installation steps first! Warning Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows. For information on why, read the following FAQ entry There doesn't seem to be any FAQ entry to read, nor does nay other portion of install.txt explain why Apache 2 should not be used in production. Perhaps that limitation has been lifted? Or perhaps a URL is missing? -- Edit this bug report at http://bugs.php.net/?id=31698&edit=1
[PHP-DOC] #31697 [Opn]: foreach doc doesn't mention object-iteration
ID: 31697 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: n/a PHP Version: Irrelevant Assigned To: tularis New Comment: Jed, there is no such general rule. If you find places in the manual that "aren't clear" on this then please fix it or submit a bug report. The only real difference between PHP 4 and PHP 5 is the OOP model which is why a separate OOP section exists. Previous Comments: [2005-01-26 01:09:12] [EMAIL PROTECTED] It's mentioned in the PHP 5 docs, and includes implementing Iterator from the SPL. http://www.php.net/manual/en/language.oop5.iterations.php I think the general rule is place things where it doesn't seem like they'd be, since PHP 5 is so radically different it deserves its own manual section, and the rest of the manual isn't clear on what PHP 4 and PHP 5 is anymore. [2005-01-25 23:51:07] [EMAIL PROTECTED] assigning to myself (so I don't forget) [2005-01-25 23:50:42] [EMAIL PROTECTED] Description: The foreach documentation page doesn't mention the fact that foreach can also be used to iterate trough an object's properties. Reproduce code: --- - Expected result: foreach contains a notice about objects Actual result: -- none -- Edit this bug report at http://bugs.php.net/?id=31697&edit=1
[PHP-DOC] #31698 [Opn->Bgs]: install.txt Apache2 dangling FAQ ref
ID: 31698 Updated by: [EMAIL PROTECTED] -Summary: update php-src INSTALL files Reported By: fumanchu at amor dot org -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Win2k PHP Version: 4.3.10 New Comment: This bug is bogus. If it were to remain open (every time a word is changed in the install section), it would remain open for an eternity. The INSTALL docs are updated before every release. Previous Comments: [2005-01-26 13:48:13] [EMAIL PROTECTED] here they are: http://testes.aborla.net/install-docs.zip INSTALL -> php-src/INSTALL install.txt -> php-src/win32/install.txt [2005-01-26 04:10:12] [EMAIL PROTECTED] Sorry. Rasmus had changed the FAQ. For some reason I thought he'd sent a patch. Excuse my inaccuracy. S [2005-01-26 02:09:09] [EMAIL PROTECTED] The piece of text that refers to the FAQ was changed to: We do not recommend using a threaded MPM in production with Apache2. Use the prefork MPM instead, or use Apache1. For information on why, read the following And the FAQ title to: Why shouldn't I use Apache2 with a threaded MPM in a production environment? See these diffs: http://cvs.php.net/diff.php/phpdoc/en/language-snippets.ent?r1=1.125&r2=1.126 http://cvs.php.net/diff.php/phpdoc/en/faq/installation.xml?r1=1.40&r2=1.41 This bug report is due to an "old" install.txt compared to a new PHP Manual build. So, this bug is officially bogus although it's understandable why it was opened. If someone feels the script that generates install.txt from the doc sources should include links then open a new bug report as that's a different issue. [2005-01-26 01:51:28] [EMAIL PROTECTED] I changed this FAQ entry. The install.txt file also needs to be changed, though. S [2005-01-26 01:03:02] [EMAIL PROTECTED] The Apache2 threading FUD is what the INSTALL file is referring to, and this is located at: http://us2.php.net/manual/en/faq.installation.php#faq.installation.apache2 It appears someone got lazy and converted text to INSTALL, without preserving links -- this problem appears in more than one place. 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/31698 -- Edit this bug report at http://bugs.php.net/?id=31698&edit=1
[PHP-DOC] #17795 [Opn->Csd]: PostgreSQL documentation should have entry for deprecated function name
ID: 17795 Updated by: [EMAIL PROTECTED] Reported By: caugustin at alcyonis dot fr -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: any PHP Version: 4.2.0 New Comment: http://www.php.net/pgsql lists 20 entries. IMHO too much to list on the sidebar... I'm closing this bug for a few reasons: 1) The "new" search mechanism works fine for this. For example going to php.net/pg_getlastoid (doing a function search) lists function names with the first being pg_getlast_oid. 2) This bug is so old. 3) The names are so close that someone looking for pg_getlastoid should assume pg_getlast_oid from the function list. In the future we'll resolve this type of issue right away although I don't see this sort of problem ever coming up again unless done for core functions (like strlen->str_len). Previous Comments: [2004-09-22 18:50:24] [EMAIL PROTECTED] I would be interested in a list of aliases, which would need documentation, so we can see, what impact would this have on the manual... Without this picture, it is hard to decide on what to do. BTW when old function names become aliases of new names, then they are not "aliases" in terms of how people see them. So they don't fit the "we are not documenting aliases" rule. [2004-09-14 17:13:52] [EMAIL PROTECTED] Should this be revisited? If we do this, we'll have to do it for every deprecated function in all of PHP >= 4.0.0. If done, we should do something like not show these aliases in the function lists/sidebar. Looks like I'm one reason this never happenend, not sure how that happened exactly. I think we discussed this once. [2003-01-21 02:34:44] [EMAIL PROTECTED] It's been a long time since this all happened, we sorta missed the boat :) Since it's been so long and search.php will indirectly redirect users to the proper places ... I think it's okay if we don't add all these aliases so am marking this as won't fix. Note that the old names still work although they are deprecated. They'll most likely work for quite awhile. In the future we need to handle this more gracefully. The same approach that's applied to extensions (deletions and moves->pecl) can be applied here. [2003-01-05 05:22:02] [EMAIL PROTECTED] I don't see problems with listing old functions in the manual. (create xml files that point to new functions) I didn't create old function name xml files, since aliases aren't supposed to be documented. I'm not sure if it applies in this case. If everyone agrees, please feel free to add entries. [2002-11-19 00:34:45] [EMAIL PROTECTED] This sounds reasonable. The current docs make it sound as if the aliases are going away very soon ... why? It's a recent change. In fact, old mysql aliases have been around since the 90's and afaik the mysql alias docs have only recently been removed. It makes sense to encourage a move but not to scare people. I vote +1 we create these alias entries because the move is so recent and will do so unless someone feels otherwise (then we can discuss it :) 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/17795 -- Edit this bug report at http://bugs.php.net/?id=17795&edit=1
[PHP-DOC] #22005 [Opn->Csd]: mysql_stat space problems
ID: 22005
Updated by: [EMAIL PROTECTED]
Reported By: haafiz at ezwebsolutions dot ca
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: ALL
PHP Version: 4.3.0
New Comment:
If this was a MySQL bug it isn't listed in their Bug DB (so I can't
offer my information) but anyway I added an alternate example (that
parses SHOW STATUS) in the manual. Also, this bug is old and cosmetic.
Status->closed.
Here's the diff:
http://cvs.php.net/diff.php/phpdoc/en/reference/mysql/functions/mysql-stat.xml?r1=1.8&r2=1.10
Previous Comments:
[2003-06-02 09:41:19] mike at pcmedx dot com
I also added this workaround to the doc page.
$stat = explode(' ',mysql_stat($this->c_id));
list($stat[6],$stat[7]) =
preg_split('/\s(Q.+)/',$stat[6],-1,PREG_SPLIT_DELIM_CAPTURE);
[2003-02-03 07:17:03] [EMAIL PROTECTED]
Reclassified as a documentation bug
[2003-02-03 06:05:44] [EMAIL PROTECTED]
Ok, this is verified but this is not a PHP's bug, but a MySQL's. Please
post a MySQL's bug.
[2003-02-02 11:32:47] [EMAIL PROTECTED]
a) split/preg_split uses regex, not explode
b) it would not work well as it'd split up everything
c) this is not related to html but rather a php string
d) the example in the manual uses explode on two spaces
If this is indeed true (one space before Queries) than this is a bug
... somewhere.
[2003-02-02 03:23:43] [EMAIL PROTECTED]
In fact there are more space but the HTML output will read only one.
Use explode('[[:space:]]',$var) to divide it.
(You can verify that by looking at the HTML source.
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/22005
--
Edit this bug report at http://bugs.php.net/?id=22005&edit=1
[PHP-DOC] #31778 [Ver->Csd]: there's a broken URL on your site.
ID: 31778 Updated by: [EMAIL PROTECTED] Reported By: mike at openconcept dot ca -Status: Verified +Status: Closed Bug Type: Documentation problem Operating System: your site PHP Version: 4.3.10 New Comment: The link was already fixed (PHP Bug #31724) and regarding Yum... yum, apt-get, feta, fink, etc. are not PECL specific and since a ton of install wrappers exist out there I don't think listing a few is necessary, or a good idea. It would also require we keep track of which PHP extensions are and are not installable via all these methods, and we'd rather not support them as official means. For good measure, here's a link to various package managers: http://www.linuxlinks.com/Software/Utilities/Packagers/ Previous Comments: [2005-01-31 15:23:44] [EMAIL PROTECTED] I'm not too sure whether this fits in with a documentation problem or not. It seems though that there is no such PECL package at all... so I'll just set this as verified for now :D [2005-01-31 15:15:24] mike at openconcept dot ca Description: Hi Mike, Please report documentataion problems as documentation bugs in the bug system. On this page: http://ca.php.net/manual/en/ref.domxml.php In this paragraph: "This PECL extension is not bundled with PHP. Additional information such as new releases, downloads, source files, maintainer information, and a CHANGELOG, can be located here: http://pecl.php.net/package/domxml. " The link to: http://pecl.php.net/package/domxml is really busted. Would also be really good to include a simpler way to install this. Such as: # yum install php-domxml Not that everyone can use yum, but sure would be nice to know that there is a simple way to install this in many Linux distros. We do have a complete section on installing PECL extensions in the manual. Possible simpler methods need to be documented there. Regards, Gabor Hojtsy Reproduce code: --- Go here: http://ca.php.net/manual/en/ref.domxml.php Expected result: Install instructions Actual result: -- 404 -- Edit this bug report at http://bugs.php.net/?id=31778&edit=1
[PHP-DOC] #25983 [Opn->Ctl]: PECL Extensions lack PHP version information
ID: 25983 Updated by: [EMAIL PROTECTED] -Summary: All printer functions show as only in cvs Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: Documentation problem -Operating System: windows me +Operating System: Irrelevant PHP Version: Irrelevant Assigned To: vrana New Comment: 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? Previous Comments: [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=25983&edit=1
[PHP-DOC] #31677 [Opn->Fbk]: ibase functions
ID: 31677 Updated by: [EMAIL PROTECTED] Reported By: 3tantes at inbox dot lv -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: ANY PHP Version: 5.0.1 New Comment: Could you please explain what this means, and how/what ibase documentation should be changed? Previous Comments: [2005-01-24 10:11:46] 3tantes at inbox dot lv Description: PLEASE note in documentation that ibase functions now use services: * ibase_add_user * ibase_modify_user (maybe some other functions too, i haven't used others) it may cause some problems, when upgrading from php4 to php5! -- Edit this bug report at http://bugs.php.net/?id=31677&edit=1
[PHP-DOC] #31861 [Opn->Bgs]: The Documentation doesn't describe the language (PHP)
ID: 31861 Updated by: [EMAIL PROTECTED] Reported By: chvol at aol dot com -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: 4.3.10 New Comment: I don't understand what you're asking for here, or the problem. PHP is huge so the information is broken down into appropriate sections. Want to learn about for? Read about loops. Echo is documented in several places. All "commands" are described as per their extension, or section (like language reference). The search feature can be useful as well. If everything was on one page, that page would be enormous. Maybe you should download the HTML one-page version of the manual. Previous Comments: [2005-02-06 15:29:16] chvol at aol dot com Description: This documentation doesn't explain the PHP language. It gives low level constructs, and various categories where certain things can be found. However, it doesn't actually simply define the language itself: a line consists of statements separated by ";". Each statement consists of one of the following: MISSING LIST HERE If you poke around you can find reference to the FOR command in one place, and ECHO somewhere else in there. But the user isn't supposed to have to look through the entire manual to find one item: a certain command. I have been trying to find one particular command and have been searching through the different sections. Why don't you just list them out? You know, describe the PHP language commands? -- Edit this bug report at http://bugs.php.net/?id=31861&edit=1
[PHP-DOC] #32131 [Opn->Bgs]: Version information is missing from APD (PECL) docs
ID: 32131 Updated by: [EMAIL PROTECTED] -Summary: Version information is missing Reported By: MageOfChrisz at Gmail dot com -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: This is a duplicate (we mark those as Bogus) of PHP bug #25983 Previous Comments: [2005-02-28 06:26:03] MageOfChrisz at Gmail dot com Description: The APD version information (contained on all function pages) has no version information on it. APD Versions >=0.2 has all the funtions that are given, so there is actual information on it. I got the information above from http://pecl.php.net/package-changelog.php?package=apd&release=0.2 -- Edit this bug report at http://bugs.php.net/?id=32131&edit=1
[PHP-DOC] #31677 [Opn]: Document ibase changes in PHP 5
ID: 31677
Updated by: [EMAIL PROTECTED]
-Summary: ibase functions
Reported By: 3tantes at inbox dot lv
Status: Open
Bug Type: Documentation problem
Operating System: ANY
PHP Version: 5.0.1
New Comment:
I don't notice a code difference but AFAICT in PHP 5 the following
happened:
* interbase.c was split up into multiple files
* Using ibase_add_user() as an example, the following code remains the
same:
PHP_FUNCTION(ibase_add_user)
{
_php_ibase_user(INTERNAL_FUNCTION_PARAM_PASSTHRU,
isc_action_svc_add_user);
}
* but the paramaters apparently changed, here's the proto definition in
the source:
PHP 4:
/* {{{ proto bool ibase_add_user(string server, string dba_user_name,
string dba _password, string user_name, string password [, string
first_name [, string middle_name [, string last_name]]]) Add an user to
security database (only for IB6 or later) */
PHP 5:
/* {{{ proto bool ibase_add_user(resource service_handle, string
user_name, string password [, string first_name [, string middle_name
[, string last_name]]]) Add a user to security database */
Someone who knows ibase, and/or can confidently understand php-src,
should add appropriate CHANGELOG entries to the appropriate ibase docs
rather than depend only the on prototype comments.
I assume service_handle comes from ibase_connect(), right?
Previous Comments:
[2005-03-05 01:16:20] 3tantes at inbox dot lv
bool ibase_add_user ( resource service_handle, string user_name, string
password [, string first_name [, string middle_name [, string
last_name]]] )
i'm talking about the first paramater service_handle of function. in
earler versions it wasn't there. this may cause problems on upgrade,
cause this change is not backward-compatible.
is there any section, where php programmers can see the dangerous
areas, that must be changed when upgrading? it would be nice if there'd
be in documentation of ibase_add_user, ibase_modify_user etc a
note/warning, that this function has changed in php5 and that these
changes are not backward compatible.
[2005-03-05 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-02-24 17:11:08] [EMAIL PROTECTED]
Could you please explain what this means, and how/what ibase
documentation should be changed?
[2005-01-24 10:11:46] 3tantes at inbox dot lv
Description:
PLEASE note in documentation that ibase functions now use services:
* ibase_add_user
* ibase_modify_user
(maybe some other functions too, i haven't used others)
it may cause some problems, when upgrading from php4 to php5!
--
Edit this bug report at http://bugs.php.net/?id=31677&edit=1
[PHP-DOC] #32202 [Opn]: location of php4apache.dll in Loadmodule statement wrong
ID: 32202 Updated by: [EMAIL PROTECTED] Reported By: taylor at gol dot com Status: Open Bug Type: Documentation problem Operating System: Windows 2000 PHP Version: 4.3.10 New Comment: This isn't really a bug as according to the manual installation steps (which should be read first): Note: In PHP 4, you should move all files located in the dll and sapi folders to the main folder (e.g. C:\php). The manual steps example 6.1 shows the correct location. But, the Apache 1 docs do say the following: This assumes PHP is installed to c:\php. Adjust the path if this is not the case. So anyway the Apache 1 docs could easily again mention the sapi/dll file move right after the above quoted note...that might be useful. Previous Comments: [2005-03-06 03:01:18] taylor at gol dot com Description: The page http://www.php.net/manual/en/install.windows.apache1.php states For PHP 4: # Add to the end of the LoadModule section LoadModule php4_module "c:/php/php4apache.dll" but the location of the file php4apache.dll is actually in ~/php/sapi/ The install documentation that comes with the zipped bundle is wrong, too. -- Edit this bug report at http://bugs.php.net/?id=32202&edit=1
[PHP-DOC] #32212 [Opn->Fbk]: $_FILES with arrays
ID: 32212
Updated by: [EMAIL PROTECTED]
Reported By: gardan at gmx dot net
-Status: Open
+Status: Feedback
Bug Type: Documentation problem
Operating System: -
PHP Version: Irrelevant
New Comment:
What bug from 2002 are you talking about?
Previous Comments:
[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=32212&edit=1
[PHP-DOC] #32396 [Opn->Fbk]: Documentation About PECL Installation
ID: 32396 Updated by: [EMAIL PROTECTED] Reported By: duanematthew at msn dot com -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: Windows XP PHP Version: 5.0.3 New Comment: php5activescript.dll does not go inside ext/, please specify exactly where do the docs suggest this. The activescript documentation (and Windows manual installation instructions) are pretty clear on where it goes. Not all PECL extensions are treated identically, it depends on whether or not it's an extension (iisfunc) or SAPI (activescript). Previous Comments: [2005-03-21 18:40:25] duanematthew at msn dot com Hi It isn't really a bug but rather a confusion on my part. I'm a PHP newbie and I'm trying to install PHP 5.0.3. Based on the example 4.2 PHP 5 Package Structure in the documentation (chm) php5activescript should be placed in the PHP directory but it also mentioned in the other part of the documentation that it has been moved to PECL repository and need to be registered using regsvr32 but it also mentioned that to be able to use the PECL the php.ini file should be modified by changing the extension_dir and by adding it to the Dynamic Extensions, I also notice that php_iisfunc.dll is also included in the PECL but in the php.ini it is being treated as part of the bundled dll found in ext folder. Also if I want to use the PECL repository can I just copy it to the ext folder and add it to the Dynamic Extensions? and where php5activescript.dll fall inside the ext directory or under the PHP directory? Another thing why is php_java has a jar extension and not dll but in the Dynamic Extesions it is being reference as dll? I hope you can give me some shed about this matter Thanks [2005-03-21 18:39:01] duanematthew at msn dot com Description: Hi It isn't really a bug but rather a confusion on my part. I'm a PHP newbie and I'm trying to install PHP 5.0.3. Based on the example 4.2 PHP 5 Package Structure in the documentation (chm) php5activescript should be placed in the PHP directory but it also mentioned in the other part of the documentation that it has been moved to PECL repository and need to be registered using regsvr32 but it also mentioned that to be able to use the PECL the php.ini file should be modified by changing the extension_dir and by adding it to the Dynamic Extensions, I also notice that php_iisfunc.dll is also included in the PECL but in the php.ini it is being treated as part of the bundled dll found in ext folder. Also if I want to use the PECL repository can I just copy it to the ext folder and add it to the Dynamic Extensions? and where php5activescript.dll fall inside the ext directory or under the PHP directory? Another thing why is php_java has a jar extension and not dll but in the Dynamic Extesions it is being reference as dll? I hope you can give men some shed about this matter Thanks -- Edit this bug report at http://bugs.php.net/?id=32396&edit=1
[PHP-DOC] #32396 [Opn->Bgs]: Documentation About PECL Installation
ID: 32396 Updated by: [EMAIL PROTECTED] Reported By: duanematthew at msn dot com -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Windows XP PHP Version: 5.0.3 New Comment: If you want to use a DLL, uncomment it, otherwise, leave it commented. This is documented and the whole idea of what comments are and mean with php.ini being no exception. Where to put PECL is documented under the PECL installation instructions (and linked to within the Windows installation page): * http://php.net/manual/en/install.pecl.windows.php Please use the mailing lists for support questions, such as [email protected] * http://php.net/support.php Marking this bug as bogus. Previous Comments: [2005-03-22 03:57:14] duanematthew at msn dot com I'm not saying that the documentation tells that php5activescript should be in the ext folder, as I already mentioned earlier the documentation tells that php5activescript should be in the PHP folder where the php binaries are located, but I'm just a bit confuse about the installation of PECL on where should I place them and how am I going to activate them in php. And about the dll in the ext folder is it already usuable or I still need to uncomment them in the Dynamic Extension? and where should I put the PECL dll? does it fall to Dynamic Extension and need to be placed in the ext or I need to put them in a seperate directory like PECL? and how am I going to activate them so I can use their functions? If I need to put them in a seperate folder what happen to the extension_dir? And also again why is php_java has a jar entesion and not dll like the other file in the ext folder? Thanks and thanks for your answer I really appreciate it [2005-03-21 20:04:26] [EMAIL PROTECTED] php5activescript.dll does not go inside ext/, please specify exactly where do the docs suggest this. The activescript documentation (and Windows manual installation instructions) are pretty clear on where it goes. Not all PECL extensions are treated identically, it depends on whether or not it's an extension (iisfunc) or SAPI (activescript). [2005-03-21 18:40:25] duanematthew at msn dot com Hi It isn't really a bug but rather a confusion on my part. I'm a PHP newbie and I'm trying to install PHP 5.0.3. Based on the example 4.2 PHP 5 Package Structure in the documentation (chm) php5activescript should be placed in the PHP directory but it also mentioned in the other part of the documentation that it has been moved to PECL repository and need to be registered using regsvr32 but it also mentioned that to be able to use the PECL the php.ini file should be modified by changing the extension_dir and by adding it to the Dynamic Extensions, I also notice that php_iisfunc.dll is also included in the PECL but in the php.ini it is being treated as part of the bundled dll found in ext folder. Also if I want to use the PECL repository can I just copy it to the ext folder and add it to the Dynamic Extensions? and where php5activescript.dll fall inside the ext directory or under the PHP directory? Another thing why is php_java has a jar extension and not dll but in the Dynamic Extesions it is being reference as dll? I hope you can give me some shed about this matter Thanks [2005-03-21 18:39:01] duanematthew at msn dot com Description: Hi It isn't really a bug but rather a confusion on my part. I'm a PHP newbie and I'm trying to install PHP 5.0.3. Based on the example 4.2 PHP 5 Package Structure in the documentation (chm) php5activescript should be placed in the PHP directory but it also mentioned in the other part of the documentation that it has been moved to PECL repository and need to be registered using regsvr32 but it also mentioned that to be able to use the PECL the php.ini file should be modified by changing the extension_dir and by adding it to the Dynamic Extensions, I also notice that php_iisfunc.dll is also included in the PECL but in the php.ini it is being treated as part of the bundled dll found in ext folder. Also if I want to use the PECL repository can I just copy it to the ext folder and add it to the Dynamic Extensions? and where php5activescript.dll fall inside the ext directory or under the PHP directory? Another thing why is php_java has a jar extension and not dll but in the Dynamic Extesions it is being reference as dll? I hope you can give men some shed about this matter Thanks -- Edit this bug report at http://bugs.php.net/?id=32396&edit=1
[PHP-DOC] #32419 [Opn->Bgs]: change to php.net/htaccess
ID: 32419 Updated by: [EMAIL PROTECTED] Reported By: aj_gemmell at yahoo dot com -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Any PHP Version: Irrelevant New Comment: This is already fixed in CVS and will show up when the manual is next built. Although the online version still has this link, we mark these "already fixed" bugs as bogus. Thanks for the report. Here's the diff from around five weeks ago: * http://cvs.php.net/diff.php/phpdoc/en/install/ini.xml?r1=1.3&r2=1.4&ty=u The manual is built about every month or two or three. Previous Comments: [2005-03-23 00:13:21] aj_gemmell at yahoo dot com Description: With PHP 4 and PHP 5, there are several Apache directives that allow you to change the PHP configuration from within the Apache configuration files. For a listing of which directives are PHP_INI_ALL, PHP_INI_PERDIR, or PHP_INI_SYSTEM, have a look at the table found within the ini_set() documentation. the ini_set() link obviously points to the ini_set doc page which has recently been changed. The link needs to be changed to: ...found within Appendix H and have Appendix H link to ini.php#ini.list -- Edit this bug report at http://bugs.php.net/?id=32419&edit=1
[PHP-DOC] #32453 [Opn]: Confusing faq about emulating register_globals
ID: 32453
Updated by: [EMAIL PROTECTED]
Reported By: holliwell at gmx dot net
Status: Open
Bug Type: Documentation problem
Operating System: n/a
PHP Version: Irrelevant
New Comment:
It does have some effect in regards to sessions (at least it used to,
not sure since 4.2.3). And I assume the author of that FAQ put it there
in case the script uses ini_get('register_globals') somewhere else in
which case the script knows it's been polluted (behaving like it's on).
But to avoid confusion, I also think it should be removed.
Previous Comments:
[2005-03-25 15:07:27] [EMAIL PROTECTED]
You are absolutely right, sorry for the confusion. I removed the
ini_set('register_globals') from FAQ.
[2005-03-25 13:54:08] holliwell at gmx dot net
Hi,
The manual says very clear, that you cannot change register_globals
with ini_set, because it is changeable PHP_INI_DIR:
register_globals"0" PHP_INI_PERDIR PHP_INI_ALL in PHP <= 4.2.3.
Conclusion: using ini_set('register_globals', 'what_ever_value') has no
effect, no?
Kind regards
Friedhelm
[2005-03-25 13:42:26] [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.
It's for telling the rest of the script that globals are (not)
registered (if tested with ini_get).
[2005-03-25 12:19:02] holliwell at gmx dot net
Description:
Hi,
http://de2.php.net/manual/en/ini.core.php#ini.register-globals
says register_globals is changeable PHP_INI_PERDIR.
However the faq entry about "Emulating Register Globals"
http://de2.php.net/manual/en/faq.misc.php#faq.misc.registerglobals
uses statements like:
ini_set('register_globals', true);
and
ini_set('register_globals', false);
The purpose of this statements isn't really clear.
The usage of this ini_set statements is conflicting with the
explanation of register_globals in the manual and where and how this
setting can be changed.
Kind regards
Friedhelm
--
Edit this bug report at http://bugs.php.net/?id=32453&edit=1
[PHP-DOC] #28018 [Opn->Csd]: Document PECL extensions, especially for Windows users
ID: 28018 Updated by: [EMAIL PROTECTED] Reported By: hendrik dot schmieder at jedox dot com -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Windows PHP Version: 5CVS-2004-04-16 (dev) Assigned To: philip New Comment: The last step of this task (php.ini modification) has been completed, so, this bug is now closed :) Previous Comments: [2004-09-20 06:52:43] melvtim at yahoo dot com Hmmyea, think I got it this time. Nothing wrong really. Just the file permission of php_zip.dll that needs to be modified accordingly. [2004-09-20 06:26:03] melvtim at yahoo dot com I manage to download the PECL files and place the php_zip.dll into my c:\php\ext but it still doesn't work. I'm getting a: PHP Warning: PHP Startup: Unable to load dynamic library 'C:\PHP\ext\php_zip.dll' - Access is denied. in Unknown on line 0 error message. This can't be. My php_gd2.dll works. Why not this? [2004-07-28 10:39:15] [EMAIL PROTECTED] Also a brief note should exist in php.ini (above the list of dlls) mentioning that some of these are PECL extensions, a separate download. It's also worth mentioning that all of this is only as of PHP 5. Assigning to self! [2004-07-28 10:31:34] [EMAIL PROTECTED] PECL extensions such as ZIP are located in the PECL download, this is linked to on the main download page as "Collection of PECL modules for PHP 5.0.0". php_zip.dll exists in there as do all the other PECL files...there are a lot. Making this a documentation problem. EVERY extension that exists inside this Windows PECL download should be noted in the docs. For example the ZIP configure.xml should mention it. Also, the Windows extensions.xml should make reference to all of these too (or at least make some reference to it). To move beyond the PHP manual, downloads.php should let users know what PECL extensions are as many seem to be confused by this. install.txt should also mention it. [2004-07-28 09:29:53] ydhainaut at ifrance dot com i have the same problem : php.ini (V 5.0) is refering to php_zip.dll but no file in directory ext. so function "zip_open" doesnt work. i tried copy old version (v 4.36) of php_zip.dll in the directory ext and uncomment the significant line in php.ini but .. uhh.. doesn't work is there actually a solution ? best regards - Yves-Marie 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/28018 -- Edit this bug report at http://bugs.php.net/?id=28018&edit=1
[PHP-DOC] #32294 [Opn->Csd]: Intval doc doesn't mention return value
ID: 32294
Updated by: [EMAIL PROTECTED]
Reported By: mpr at er dot dtu dot dk
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Irrelevant
PHP Version: Irrelevant
New Comment:
These docs have been rewritten and will show up when the manual is next
built. Thanks for the report! Here's the diff:
*
http://cvs.php.net/diff.php/phpdoc/en/reference/var/functions/intval.xml?r1=1.3&r2=1.4
User notes and various return value information (including integer
overflow) was added.
Previous Comments:
[2005-03-13 23:26:39] mpr at er dot dtu dot dk
Ooops, "will return -1" should read "will return 0"
[2005-03-13 23:01:56] mpr at er dot dtu dot dk
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 this bug report at http://bugs.php.net/?id=32294&edit=1
[PHP-DOC] #23907 [Ctl->Csd]: Need additional installation step for IIS 6.0 / Windows Server 2003
ID: 23907 Updated by: [EMAIL PROTECTED] Reported By: bryn at mrpath dot com -Status: Critical +Status: Closed Bug Type: Documentation problem Operating System: Windows Server 2003 PHP Version: 4.3.2 New Comment: The documentation has been updated and will show up when the manual is next built. Thanks for the report :) For good measure, here's the diff: http://cvs.php.net/diff.php/phpdoc/en/install/windows/iis.xml?r1=1.10&r2=1.13 Previous Comments: [2005-01-18 04:09:51] [EMAIL PROTECTED] When this bug report is dealt with (and closed!), also solve the following bug reports: #29275 and #21833 [2004-12-17 01:46:47] unknown at simplemachines dot org I can confirm that: - this affects Windows Server 2003 and IIS 6 only. - this is needed for both CGI or ISAPI mode. - this is currently not in the documentation. A tutorial I wrote earlier this year covers many of the major steps involved, although it hasn't been updated for PHP 5 yet (it was written while PHP 5 was still in beta.) The relevant section of said tutorial can be found here: http://unknown.network32.net/tutorial.basic-server#configure.php.iis The Macromedia tutorial linked to in one of the previous comments does *not* describe the necessary information either. However, some comments to the documentation page do. Any other problems are not related to this bug; notably, the whole CGI issue *is* properly documented already (although ISAPI is more efficient...) Thanks, -[Unknown] [2004-09-01 17:53:38] joel at preacherboy dot net I couldn't for the life of me get IIS 5.1 and PHP 5 in CGI mode to work. I ignored all previous PHP 4 related instructions as I figured them to be irrelevant. After reading Philip's comments about the Macromedia tutorial, I finally decided using their method for CGI mode just might work. All it took to get IIS 5.1 and PHP 5 to work in CGI mode was the following lines, never referenced in the official documentation as what you *must* do: cgi.force_redirect = 0 // Default must be 1 when commented out. cgi.redirect_status_env = ENV_VAR_NAME Now that I'm not running in ISAPI mode, all of my scripts aren't open handles of dllhost.exe. dllhost.exe is no longer crashing every time the system is restarted. Yay! [2004-08-22 20:55:33] [EMAIL PROTECTED] The IIS docs need help, someone who uses IIS should really update these docs. Marking as critical. The PHP installer should also look into being updated for this (although IMHO nobody should use the PHP installer!) [2004-08-21 05:52:48] yo at momma dot org This need to go on the install.txt file. BIG TIME. Searching google for ""HTTP Error 404 - File or directory not found. PHP IIS 2003"" and this article came up 7th. Does not bode well for noobs (A turn off, as in why bother) as well as experienced developers (A serious irritant, as in "Oh great, another speed bump and another hour or 2 of my time"). 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/23907 -- Edit this bug report at http://bugs.php.net/?id=23907&edit=1
[PHP-DOC] #29275 [Opn->Csd]: IIS 5.1 needs special attention in the IIS docs
ID: 29275 Updated by: [EMAIL PROTECTED] Reported By: steve at ootac dot com -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: windows PHP Version: 5.0.0 New Comment: The documentation has been updated and will show up when the manual is next built. Thanks for the report :) Previous Comments: [2004-09-01 17:55:06] joel at preacherboy dot net Thanks for providing a link to that bug. It was exactly what I needed to get IIS 5.1 and PHP 5 to work in CGI mode. [2004-09-01 00:44:21] [EMAIL PROTECTED] The IIS Documentation is outdated/wrong/bad, this is known, but this is already in a bug report here: http://bugs.php.net/bug.php?id=23907 As far as php5isapi.dll, that's now in the the docs. Regarding that IIS 5.1 bug, that will be integrated when the IIS docs are updated (and the user notes are integrated) so will leave this bug open until that happens. [2004-09-01 00:04:26] joel at preacherboy dot net I've been able to get php5isapi.dll to work on IIS 5.1 following the official instructions. If you want I can go log the process on another development system I've been meaning to configure. I had to use ISAPI by choice. I'd much rather use php-cgi.exe, but I could never get it to work using the official instructions. Instead I have ISAPI leaving open handles on every file used until I kill dllhost.exe or restart the system (resulting in a crash of dllhost.exe). [2004-07-21 13:09:05] steve at ootac dot com The Add mapping dialogue puts the path in quotes; remove the quotes and the OK button is enabled. still cannot get it to work even after following all the FAQ advice! [2004-07-20 11:36:06] steve at ootac dot com Description: I have found a bug on page install.iis.html [chm date: 2003-09-06]... Installation/servers-IIS/PWS/WINDOWS NT/2000/XP and IIS 4 or newer IIS 5.1 on Win XP Help file says: To use the ISAPI module, do the following: Under 'Home Directory', click on the 'Configuration' button. Add a new entry to the Application Mappings. Use the path to the php4isapi.dll as the Executable, supply .php as the extension, leave Method exclusions blank, and check the Script engine checkbox. 1. File needs to be php5isapi.dll 2. Doing as above (using php5isapi.dll) will not enable the OK button in the dialogue. -- Edit this bug report at http://bugs.php.net/?id=29275&edit=1
[PHP-DOC] #32528 [Opn->Bgs]: If (comparison) {do} function not documented neither properly working
ID: 32528
Updated by: [EMAIL PROTECTED]
Reported By: grasso789 at versanet dot de
-Status: Open
+Status: Bogus
Bug Type: Documentation problem
Operating System: All
PHP Version: 4.3.10
New Comment:
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 ;
Previous Comments:
[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 (0<1) {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=32528&edit=1
[PHP-DOC] #23610 [Opn->Csd]: PATH_TRANSLATED is EMPTY when PATH_INFO is not set
ID: 23610 Updated by: [EMAIL PROTECTED] Reported By: support at sensvirtuel dot com -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Linux (redhat 8.0) PHP Version: 4.3.2 New Comment: All documentation has been updated and will show up when the manual is next built. Thanks for the report. Previous Comments: [2004-08-27 01:53:55] [EMAIL PROTECTED] Agreed, especially since this change took place in PHP 4.3.2 and not PHP 5.0.0. Should that note be removed from the migration5 docs? I added a note within the PATH_TRANSLATED docs, updated the note in ref.apache, and replaced PATH_TRANSLATED with SCRIPT_FILENAME in the highlight_file() example. Thank you Kevin for the report. There is another open bug report out there that requests every BC break to be documented...like this one. Once done, this information will be added there as well. [2004-08-26 21:01:37] phpbugs at kevin dot offwhite dot net I just spent a good amount of time trying to figure out why PATH_TRANSLATED suddenly stopped working on me. Therefore I think you still have a couple documentation issues regarding this. 1) The first place I looked, and the first place I would suspect other people would look, to see if the variable stopped being supported at a certain revision is: http://us3.php.net/reserved.variables 2) The example code for highlight_file() should be changed to not use the non-existant PATH_TRANSLATED variable: http://us4.php.net/highlight_file [2004-04-19 16:52:34] [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. This was already in the migration from PHP 4 to PHP 5 appendice. I've just copied the note to the apache function reference. [2004-04-18 01:03:47] [EMAIL PROTECTED] No, read the other comments. Resetting this to a Documentation problem, which it is. [2004-04-17 21:39:46] [EMAIL PROTECTED] Is there any chance to implement it? Some old scripts may rely on this feature, including REDIRECT_URL (used in phpdoc's livedocs). 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/23610 -- Edit this bug report at http://bugs.php.net/?id=23610&edit=1
[PHP-DOC] #28295 [Opn->Csd]: Ability to ignore / separate PHP5 functions when browing the documentation
ID: 28295 Updated by: [EMAIL PROTECTED] Reported By: m at bytech dot fi -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: Irrelevant New Comment: This bug is old :) Anyway, I don't think functions should ever be hidden. Highlighted, sure, but never hidden. Users should know they exist and usually these functions have examples for the older versions of PHP so viewing them is a benefit to all. This bug is closed. LiveDocs already implements this and we've mostly stopped adding features to DSSSL. All hail LiveDocs! Previous Comments: [2004-05-09 15:46:50] [EMAIL PROTECTED] may I suggest a small version of the "version 5 in a circle" graphic we have on php.net right now. This little graphic can live in the phpweb theme (but make a copy of it for the default livedocs theme too) as it is likely that different sites will want a different rendition of the version number. (remember to "cvs add -kb" the graphic) Also, thinking forward, I'd like to make this kind of generic by highlighting functions of the latest major version. We can achieve this by defining a LATEST_VERSION constant to have the value of 5; whenever a function is introduced in the LATEST_VERSION, we can pull in LATEST_VERSION . '.gif' as the graphic. When we get closer to PHP 6, all we'd need to do then is add a version 6 graphic and increment LATEST_VERSION. [2004-05-09 15:30:54] [EMAIL PROTECTED] The code for and the TOC in ref.pages is exactly the same, because the TOC returns: xpto_func - $title And then this is parsed by the format_function() function. This won't be hard to implement. If we agree in the presentation style, I may implement this. [2004-05-09 15:07:40] [EMAIL PROTECTED] Good idea :) It would be nice, if we could modify our presentation code (DSSSL and livedocs) to put a little [5] sign or something like that after all the function names that are supported in PHP 5 only. I mean if we have a php5_magic_function then the output would be php5_magic_function()[5] (with the [5] being some good looking image or a -ed text). This would not hide the functions but mark them in the manual occurances. Also it would be nice to do the same on the reference TOC pages (which is different rendering code). Anyone with interest to code this? [2004-05-06 11:01:32] m at bytech dot fi Well, hiding (or highlighting) PHP5 only functions alone would be a significant improvement. The functional differences between versions are less important to separate, because whether the functionality is the same or not the user is already reading the documentation for the function at that point. And of course, the function is available at least in some form regardless of the version. On the other hand, it's only annoying that the documentation for strpos() lists functions stripos() and strripos() in the "See also" part, since they are not available in any form in versions prior to PHP5. [2004-05-06 10:46:33] [EMAIL PROTECTED] Consider yourself privileged ;-) DocBook is a beast, and we have 30 or so different languages to maintain! It would be fairly simple to hide functions that are PHP 5 only, but in many cases we have features that differ by PHP version; these would be impossible to parse automatically without some kind of AI that understands English (and one for each of the other languages). 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/28295 -- Edit this bug report at http://bugs.php.net/?id=28295&edit=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:
A message was sent to php-internals with a patch for php.ini here:
* http://marc.theaimsgroup.com/?l=php-dev&m=111204914824598
Previous Comments:
[2005-02-25 22:31:07] [EMAIL PROTECTED]
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.11&r2=1.12&ty=h
[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=29514&edit=1
[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.net&l=en -- Edit this bug report at http://bugs.php.net/?id=32679&edit=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.11&r2=1.12&ty=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=29514&edit=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) \n"; include "$file"; ?> file.php: 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=32286&edit=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=31591&edit=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=phpdoc&m=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=3&edit=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=31303&edit=1
[PHP-DOC] #32785 [Asn]: negative limit doesn't work in explode()
ID: 32785 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Documentation problem Operating System: Debian GNU/Linux PHP Version: 4.3.10 Assigned To: nlopess New Comment: The documentation does mention this: If the limit parameter is negative, all components except the last limit are returned. This feature was added in PHP 5.1.0. Sure the 5.1+ example could have a comment specifying this version requirement but no need to get all crazy! :) When the explode() docs get converted to the new doc style the change will be much clearer as each function now has a CHANGELOG. We document future versions too, it's the way it is. A more appropriate question is "why not" but anyway it's so people using the manual can handle/know future changes/additions, and that we don't forget to document these changes. See also: http://php.net/manual/en/about.phpversions.php Previous Comments: [2005-04-21 00:49:40] [EMAIL PROTECTED] Assigned to Nuno: Thanks for wasting our time. [2005-04-21 00:45:31] [EMAIL PROTECTED] Also: Why the hell do you doc people put something like this in the manual WHEN THERE IS NO SUCH RELEASE ever made with such feature(s)???!!! [2005-04-21 00:43:54] [EMAIL PROTECTED] Reclassified as documentation problem: The examples should have BIG note about the being like that only with PHP 5.1 [2005-04-21 00:03:55] [EMAIL PROTECTED] It does the same on current PHP-version also. nandus% uname -a FreeBSD nandus.mikrolahti.fi 5.4-STABLE FreeBSD 5.4-STABLE #0: Tue Apr 19 23:27:27 EEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NANDUS i386 nandus% cat explode.php nandus% php explode.php Content-type: text/html X-Powered-By: PHP/5.0.4 Array ( [0] => one [1] => two|three|four ) Array ( [0] => one [1] => two [2] => three [3] => four ) [2005-04-20 23:45:39] [EMAIL PROTECTED] Description: http://www.php.net/explode Manual gives an example of limit-parameter used in explode(). Example 2 shows negative limit-value example and it seems not working like expected. Test-code at web: http://mikrolahti.fi/explode.php Reproduce code: --- Expected result: Array ( [0] => one [1] => two|three|four ) Array ( [0] => one [1] => two [2] => three ) Actual result: -- Array ( [0] => one [1] => two|three|four ) Array ( [0] => one [1] => two [2] => three [3] => four ) -- Edit this bug report at http://bugs.php.net/?id=32785&edit=1
[PHP-DOC] #32787 [Opn->Bgs]: [DOC] English : pgsql: function->literal
ID: 32787 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: We use not for these. If it's decided to not do this then it's a phpdoc wide problem and not specific to the pg_client_encoding() docs. Previous Comments: [2005-04-21 01:25:36] [EMAIL PROTECTED] renamed [2005-04-21 01:24:17] [EMAIL PROTECTED] Description: Index: pg-client-encoding.xml === RCS file: /repository/phpdoc/en/reference/pgsql/functions/pg-client-encoding.xml,v retrieving revision 1.7 diff -u -r1.7 pg-client-encoding.xml --- pg-client-encoding.xml 5 Apr 2005 08:56:09 - 1.7 +++ pg-client-encoding.xml 20 Apr 2005 23:22:58 - @@ -31,7 +31,7 @@ version. Refer to the PostgreSQL Documentation supported encodings. -The function used to be called pg_clientencoding. +The function used to be called pg_clientencoding(). -- Edit this bug report at http://bugs.php.net/?id=32787&edit=1
[PHP-DOC] #32787 [Bgs]: [DOC] English : pgsql: function->literal
ID: 32787 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: On a somewhat related note (okay not really), the following entity exists: In which case the following would belong in the notes refsect: &info.deprecated.alias; pg_clientencoding Previous Comments: [2005-04-21 01:36:58] [EMAIL PROTECTED] We use not for these. If it's decided to not do this then it's a phpdoc wide problem and not specific to the pg_client_encoding() docs. [2005-04-21 01:25:36] [EMAIL PROTECTED] renamed [2005-04-21 01:24:17] [EMAIL PROTECTED] Description: Index: pg-client-encoding.xml === RCS file: /repository/phpdoc/en/reference/pgsql/functions/pg-client-encoding.xml,v retrieving revision 1.7 diff -u -r1.7 pg-client-encoding.xml --- pg-client-encoding.xml 5 Apr 2005 08:56:09 - 1.7 +++ pg-client-encoding.xml 20 Apr 2005 23:22:58 - @@ -31,7 +31,7 @@ version. Refer to the PostgreSQL Documentation supported encodings. -The function used to be called pg_clientencoding. +The function used to be called pg_clientencoding(). -- Edit this bug report at http://bugs.php.net/?id=32787&edit=1
[PHP-DOC] #29819 [Opn->Bgs]: Extension documentation for Windows Flavor
ID: 29819 Updated by: [EMAIL PROTECTED] Reported By: gabe at horizondatacom dot com -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Windows 2003 PHP Version: 5.0.1 New Comment: This already exists: http://php.net/manual/en/install.windows.extensions.php And before installing an extension, one should read that extensions documentation. This is how the manual is written. Previous Comments: [2004-08-24 16:53:59] gabe at horizondatacom dot com Description: Do you think that you could post with the installation guide some material on the extensions and their requirements? I spend 2 hours trying to figure out why php_mycrypt.dll was locking up my webserver until I realized that I needed to download the binaries when I looked at the mcrypt function documentation. This would be a very useful section of the installation requirements to help people get going. I would be happy to contribute and help with this. -- Edit this bug report at http://bugs.php.net/?id=29819&edit=1
[PHP-DOC] #23714 [Opn->Ana]: Unix/HP-UX install documentation is outdated
ID: 23714 Updated by: [EMAIL PROTECTED] Reported By: ch at bumerang dot ro -Status: Open +Status: Analyzed Bug Type: Documentation problem Operating System: all PHP Version: 4.3.2RC3 New Comment: I believe the "best" method for installing PHP (and Apache) is to go here: http://www.software.hp.com/ And install one of the found packages. Searching for PHP yields several packages, for example: HP-UX Apache-based Web Server v.2.11 powered by Apache, Tomcat, Webmin We should most likely remove all current documentation and simply mention how to install one of these packages. Well, at least until someone who knows HP-UX can add additional information. Previous Comments: [2005-04-26 17:41:22] [EMAIL PROTECTED] wk at mailstation dot de, can you please write some notes for current version or at least point us to sources you used? Everlasting honor will be yours :-). [2004-10-20 13:39:06] wk at mailstation dot de I have installed PHP 4.x and 5.x on HP-UX 10.xx and 11.xx. a) The documentation *is* outdated and even wrong (e. g., you *can* build PHP as a shared module on HP-UX). The reference to an unspecified "Apache page" is misleading even. b) No, take it out completely. Having nothing about HP-UX is better than that stuff. c) is therefor irrelevant. [2003-05-20 14:15:52] [EMAIL PROTECTED] The documentation itself needs an update, the file in question: phpdoc/en/chapters/install.hpux.xml A few points: a) The documentation was written for PHP 4.0.4 so maybe it's outdated? It at least looks outdated. b) It's time we move it from email format to doc format c) The links themselves are dead and should be presented in a more "flexible" way. Instead of linking to specific versions, how about refer to the needed libraries plus a generic link, such as: http://hpux.connect.org.uk/ftp/hpux/Gnu/ So until someone knows (not guesses) the answer to (a), implements (b), and (c), this report should remain open. [2003-05-20 09:08:17] [EMAIL PROTECTED] reclassified. [2003-05-20 06:37:07] ch at bumerang dot ro There are broken links in the Romanian php manual. At the installation chapter, "How to install on Unix/HP-UX". All the urls in there are missing. I get a 404 every time. -- Edit this bug report at http://bugs.php.net/?id=23714&edit=1
[PHP-DOC] #32948 [Opn]: $HTTP_RAW_POST_DATA is empty if form's enctype="multipart/form-data"
ID: 32948 Updated by: [EMAIL PROTECTED] Reported By: chaz_meister_rock at yahoo dot com Status: Open Bug Type: Documentation problem Operating System: * PHP Version: Irrelevant New Comment: When $HTTP_RAW_POST_DATA exists is up for some debate. When this issue is tackled also refer to php://input as the preferred method. Here: http://marc.theaimsgroup.com/?t=9643787122&r=1&w=2 Also, it looks like chaz attempted to use $_SERVER as well which of course will never work but anyway that's of no matter... Previous Comments: [2005-05-06 18:40:58] chaz_meister_rock at yahoo dot com agreed, this really needs to be in the docs, because without some explanation, it sure sounds like a bug (with a setting like ALWAYS_populate_raw_post_data). does this mean that there is no way to get to a full enctype="multipart/form-data" HTTP request using php? [2005-05-06 03:02:56] [EMAIL PROTECTED] HTTP_RAW_POST_DATA is NOT set for multipart forms. Would be nice if this was said in the manual too. [2005-05-05 03:10:34] chaz_meister_rock at yahoo dot com Description: $HTTP_RAW_POST_DATA is empty when using a form with enctype="multipart/form-data" set. php.ini contains always_populate_raw_post_data = On this issue looks similar to: http://bugs.php.net/bug.php?id=23765 Reproduce code: --- Expected result: it=groovy&upFile= Actual result: -- Notice: Undefined index: HTTP_RAW_POST_DATA -- Edit this bug report at http://bugs.php.net/?id=32948&edit=1
[PHP-DOC] #34076 [Opn->Bgs]: Possible error in iis-get-service-state
ID: 34076 Updated by: [EMAIL PROTECTED] Reported By: phokus at gmail dot com -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: Already fixed in CVS (we mark already fixed bugs as bogus, but thanks for the report), the fix will show up when the manual is next built. Previous Comments: [2005-08-11 00:29:56] phokus at gmail dot com Description: The page is http://us2.php.net/manual/en/function.iis-get-service-state.php It states the following: iis_get_service_state -- Starts the service defined by ServiceId I think it should read "Gets the state of the service defined by ServiceId". Thanks, Louis -- Edit this bug report at http://bugs.php.net/?id=34076&edit=1
[PHP-DOC] #34555 [Opn->Csd]: Typo in imagecreatefromjpeg documentation page.
ID: 34555 Updated by: [EMAIL PROTECTED] Reported By: php-bugs at neothermic dot com -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: This bug has been fixed in CVS, and this fix will show up the next time the PHP manual is built. Thanks for the report! Previous Comments: [2005-09-20 00:54:48] php-bugs at neothermic dot com Description: In the documentation page for imagecreatefromjpeg, the first code example uses this line: $im = imagecreatruecolor(150, 30); /* Create a blank image */ However, the function has been typo-ed, it should be: $im = imagecreatetruecolor(150, 30); /* Create a blank image */ -- Edit this bug report at http://bugs.php.net/?id=34555&edit=1
[PHP-DOC] #28453 [Opn->Fbk]: zend.ze1_compatibility_mode needs documentation
ID: 28453 Updated by: [EMAIL PROTECTED] Reported By: philip at cornado dot com -Status: Open +Status: Feedback Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Please add specific information on what should be documented here. Previous Comments: [2005-09-26 11:04:32] [EMAIL PROTECTED] I think the documentation is still lacking. Eitherway http://www.php.net/manual/en/ini.core.php#ini.zend.ze1-compatibility-mode is still pointing to the migration guide and it seems all the migration guide (http://www.php.net/manual/en/migration5.newconf.php) does is point back to the ini directive list [2004-07-19 03:38:34] [EMAIL PROTECTED] This is now documented, here are the diffs: http://cvs.php.net/diff.php/phpdoc/en/appendices/migration5.xml?r1=1.22&r2=1.23 http://cvs.php.net/diff.php/phpdoc/en/appendices/ini.xml?r1=1.3&r2=1.4 [2004-05-20 07:59:59] philip at cornado dot com Description: The directive zend.ze1_compatibility_mode needs documentation in the PHP manual. This will need mention in the "Migrating from PHP 4 to PHP 5" section as well as an official configuration home, perhaps under "Miscellaneous configuration directives." FWIW this directive was renamed from zend2.implicit_clone in PHP5 RC1 but that doesn't need to be documented. -- Edit this bug report at http://bugs.php.net/?id=28453&edit=1
[PHP-DOC] #7741 [Csd->Opn]: [feature request] Document about every predefined variable
ID: 7741
Updated by: [EMAIL PROTECTED]
-Summary: .cgi does not adhere to quasi-RFC
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: Documentation problem
Operating System: Any
-PHP Version: 4.0.3pl1
+PHP Version: 4.4.0
New Comment:
IMHO this is now a feature request to document all possible predefined
variables, and should not be closed. Each predefined variable should
be documented in terms of when they'll be available. For example,
mod_rewrite makes a few available:
http://httpd.apache.org/docs/mod/mod_rewrite.html#EnvVar
I thought this request was marked elsewhere but couldn't find it... Am
reopening for now, and changing summary.
Previous Comments:
[2002-12-03 01:08:37] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
variables should now conform to CGI spec.
[2002-06-17 13:27:12] [EMAIL PROTECTED]
IMHO available variables should not be limited,
but documented for each SAPI (with special
non-standard additions for CGI sapi)
re-classified as doc problem
[2000-11-10 04:32:48] [EMAIL PROTECTED]
This is not a bug but a change request:
Several people seem to struggle with .cgi and non-apache
servers, especially as server-supplied environment variables are used
that are *not* defined in the current cgi/1.1 specifications (see
http://web.golux.com/coar/cgi/).
Only the following variables are defined there; everything else should
be treated as 'vendor extensions':
Quote from
http://web.golux.com/coar/cgi/draft-coar-cgi-v11-03-clean.html#6.1:
The canonical metavariables defined by this specification are:
AUTH_TYPE
CONTENT_LENGTH
CONTENT_TYPE
GATEWAY_INTERFACE
PATH_INFO
PATH_TRANSLATED
QUERY_STRING
REMOTE_ADDR
REMOTE_HOST
REMOTE_IDENT
REMOTE_USER
REQUEST_METHOD
SCRIPT_NAME
SERVER_NAME
SERVER_PORT
SERVER_PROTOCOL
SERVER_SOFTWARE
-
Therefore we should not rely on the presence of other variables; they
might be used as a shortcut if present, however:
My_script_filename = getenv("SCRIPT_FILENAME");
if (!My_script_filename) {
My_script_filename = mangle("PATH_INFO", "SCRIPT_NAME")
}
The mangle function does not really exist yet, right? ;-)
If we don't stick to a minimum, widely accept set of 'server
properties', we get a lot of long, frustrated and finally red faces.
Always keep in mind that the Apache is not the only tribesman out
there...
Regards, Ben
--
Edit this bug report at http://bugs.php.net/?id=7741&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #6513 [Opn]: get_browser() and register_globals
ID: 6513
Updated by: [EMAIL PROTECTED]
-Summary: get_browser() and $HTTP_USER_AGENT
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Feature/Change Request
+Bug Type: Documentation problem
-Operating System: NT4 Server SP6a
+Operating System: all
-PHP Version: 4.0.2
+PHP Version: 4.3.0-RC2
New Comment:
This is a doc problem, not a feature request. Not sure when this
behavior changed but I just tested and register_globals does not affect
get_browser() in PHP 4.3.0 but a user comment suggests this problem
existed as of 10-Jan-2002 so it needs to be researched.
a) When was this fixed? Document what it means.
b) Remove the $, and refer to $_SERVER in docs
c) If it turns out this wasn't fixed, reopen as a bug
Previous Comments:
[2000-09-03 09:20:11] [EMAIL PROTECTED]
I have a remark about the get_browser() function. When this function is
called without arguments it is supposed to use $HTTP_USER_AGENT for
argument. However if I use the
configuration directive
register_globals = Off
then the variable $HTTP_USER_AGENT is not defined and get_browser()
returns an error. In this case I have to do the following
$HTTP_USER_AGENT = getenv("HTTP_USER_AGENT");
$browser = get_browser();
or alternatively
$a = getenv("HTTP_USER_AGENT");
$browser = get_browser($a);
I suggest that get_browser() function should act more cleverly in this
case and use getenv() to get the HTTP_USER_AGENT.
--
Edit this bug report at http://bugs.php.net/?id=6513&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20557 [NoF->Opn]: pg_lo_export will not take 3 parameters
ID: 20557 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: Documentation problem Operating System: freebsd 4.7-RELEASE PHP Version: 4.2.3 New Comment: The proto in these docs are wrong. I looked into it once but couldn't find when the change took place exactly as the person who did the change did not mark it in the changelog. Anyway, it needs more research and at the very least the docs need updating. Please people, when you change a proto in php4 source at least note it in the changelog!!! Previous Comments: [2002-12-04 18:17:19] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-11-22 05:00:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-21 20:33:47] [EMAIL PROTECTED] the documentation lists a resource connection as a third optional parameter to pg_lo_export. when this is supplied, a "wrong parameter count" error is displayed. './configure' '--with-apxs=/home/httpd/apache/bin/apxs' '--enable-versioning' '--with-pgsql=/usr/local' '--enable-shmop' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-mbstring' '--with-gd' '--with-mbstr-enc-trans' '--enable-inline-optimization' -- Edit this bug report at http://bugs.php.net/?id=20557&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20601 [NoF->Opn]: A simple syntax parse error
ID: 20601
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: No Feedback
+Status: Open
-Bug Type: Unknown/Other Function
+Bug Type: Documentation problem
Operating System: Windows ME
PHP Version: 4.3.0RC1
-Assigned To:
+Assigned To: philip
New Comment:
Btw, this happens when you do:
print "a foo $bar['blah'] eh";
Don't do that. You can do either:
print "a foo {$bar['blah']} eh";
print "a foo $bar[blah] eh";
print "a foo " . $bar['blah'] . " eh";
But when outside of strings always quote your keys:
print $bar[blah]; // bad
print $bar['blah']; // good
Unless of course you defined blah as a constant earlier. Anyway I'm
making a faq out of this question and marking as a doc bug because this
question comes up a lot especially since 4.1.0 (autoglobals) and 4.2.0
(register_globals default change).
Previous Comments:
[2002-12-04 18:17:54] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2002-11-23 14:05:03] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
can you include a short script?
[2002-11-23 14:01:43] [EMAIL PROTECTED]
When using single quotes (i dont know if they will be allowed to show
here) (') inside double quote strings ("), a parse error is produced;
Parse error: parse error, unexpected T_ENCAPSED_AND_WHITESPACE,
expecting T_STRING or T_VARIABLE or T_NUM_STRING
This happened on Windows ME, using the latest Apache 1.3, and all
settings in php.ini are default.
This is very annoying, please fix it!
--
Edit this bug report at http://bugs.php.net/?id=20601&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20601 [Opn]: A simple syntax parse error
ID: 20601
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Windows ME
PHP Version: 4.3.0RC1
Assigned To: philip
New Comment:
As it turns out, the string docs are wrong and contain the following in
the example:
// This is wrong for the same reason
// as $foo[bar] is wrong outside a string.
echo "This is wrong: {$arr[foo][3]}";
I'll rewrite this part of the documention too. $foo[bar] is perfectly
fine inside strings, CONSTANTS aren't seen in strings. Anyway, this
will be further explained with a more specific example too. And a faq
entry :) This question comes up waaay too much these days.
Previous Comments:
[2002-12-05 13:26:22] [EMAIL PROTECTED]
The string type description includes a lengthy explanation of this
AFAIK.
[2002-12-04 19:03:14] [EMAIL PROTECTED]
Btw, this happens when you do:
print "a foo $bar['blah'] eh";
Don't do that. You can do either:
print "a foo {$bar['blah']} eh";
print "a foo $bar[blah] eh";
print "a foo " . $bar['blah'] . " eh";
But when outside of strings always quote your keys:
print $bar[blah]; // bad
print $bar['blah']; // good
Unless of course you defined blah as a constant earlier. Anyway I'm
making a faq out of this question and marking as a doc bug because this
question comes up a lot especially since 4.1.0 (autoglobals) and 4.2.0
(register_globals default change).
[2002-12-04 18:17:54] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2002-11-23 14:05:03] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
can you include a short script?
[2002-11-23 14:01:43] [EMAIL PROTECTED]
When using single quotes (i dont know if they will be allowed to show
here) (') inside double quote strings ("), a parse error is produced;
Parse error: parse error, unexpected T_ENCAPSED_AND_WHITESPACE,
expecting T_STRING or T_VARIABLE or T_NUM_STRING
This happened on Windows ME, using the latest Apache 1.3, and all
settings in php.ini are default.
This is very annoying, please fix it!
--
Edit this bug report at http://bugs.php.net/?id=20601&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20990 [Opn->Dup]: "List of reserved words" leads nowhere
ID: 20990 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: Documentation problem Operating System: All PHP Version: 4.3.0RC3 New Comment: This is a duplicate of bug #20870, see it for more details: http://bugs.php.net/bug.php?id=20870 Notice how your link has three language codes in it, don't go to links like that. One day such links won't be presented in the search.php page. If you got to this invalid link a different way let us know. Previous Comments: [2002-12-13 08:52:13] [EMAIL PROTECTED] The link http://www.php.net/manual/en/index.php/cs/fi/reserved.php is supposed to contain a list of reserved words, but it does not. It appears instead to be a copy of the documentation Table of Contents. The same error appears on one or two mirrors I checked. Steve Rapaport. -- Edit this bug report at http://bugs.php.net/?id=20990&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #17419 [Opn]: Complex objects not correctly stored in ssession
ID: 17419
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: BSDi
PHP Version: 4.2.1
New Comment:
Please further explain what circular references are so this can be
documented.
Previous Comments:
[2002-06-01 07:12:14] [EMAIL PROTECTED]
Reclassified as a documentation problem after a nice discussion with
Markus :)
[2002-06-01 07:03:28] [EMAIL PROTECTED]
Suspending.
[2002-06-01 06:43:25] [EMAIL PROTECTED]
I checked back with Zeev, circular references are simlpy not supported
in the Zend engine and won't be anytime soon.
[2002-06-01 06:19:11] [EMAIL PROTECTED]
Circular references don't work with the serializer
[2002-06-01 06:14:21] [EMAIL PROTECTED]
Consider the following sample script:
b = &new beta(&$this);
}
}
class beta {
function beta($t) {
$this->t = &$t;
}
}
if($_GET['set']) {
$_SESSION['a'] = &new alpha();
} else {
print_r($_SESSION['a']);
}
?>
First, call this script with ?set=1.
Then, call it without any arguments and nothing will happen. The
connection will close inmediately:
$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /test.php?PHPSESSID=dcfffa113d892c4320d6109c6bd07795 HTTP/1.1
Host: localhost
Connection closed by foreign host.
This was exactly what happend with the sample simpleclass.php script
provided by [EMAIL PROTECTED]
Apache logs show a couple of memleaks and a segfault:
home/sander/php/head/Zend/zend_hash.c(262) : Freeing 0x0821CD4C (37
bytes), script=/home/sander/public_html/test.php
Last leak repeated 1 time
/home/sander/php/head/Zend/zend_hash.c(178) : Freeing 0x0821B1BC (32
bytes), script=/home/sander/public_html/test.php
Last leak repeated 1 time
/home/sander/php/head/Zend/zend_API.c(597) : Freeing 0x0821B15C (44
bytes), script=/home/sander/public_html/test.php
/home/sander/php/head/Zend/zend_API.c(585) : Actual location (location
was relayed)
Last leak repeated 1 time
/home/sander/php/head/Zend/zend_execute.c(1937) : Freeing 0x0821B11C
(12 bytes), script=/home/sander/public_html/test.php
Last leak repeated 1 time
/home/rasmus/php4/ext/standard/url_scanner_ex.re(409) : Freeing
0x08219B6C (13 bytes), script=/home/sander/public_html/test.php
[Sat Jun 1 12:06:13 2002] [notice] child pid 4079 exit signal
Segmentation fault (11)
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x4010cf96 in malloc () from /lib/libc.so.6
(gdb) bt
#0 0x4010cf96 in malloc () from /lib/libc.so.6
#1 0x403d9a4f in _emalloc (size=35,
__zend_filename=0x404b0c80
"/home/sander/php/head/Zend/zend_hash.c",
__zend_lineno=406, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /home/sander/php/head/Zend/zend_alloc.c:165
#2 0x403f46cc in zend_hash_index_update_or_next_insert (ht=0xbfffef34,
h=23815, pData=0xbf800108, nDataSize=4, pDest=0x0, flag=4)
at /home/sander/php/head/Zend/zend_hash.c:406
#3 0x4038f81a in php_add_var_hash (var_hash=0xbfffef34, var=0x8219b9c,
var_old=0xbf800264) at
/home/sander/php/head/ext/standard/var.c:393
#4 0x4038ed6e in php_var_serialize_intern (buf=0xbfffef60,
struc=0x8219b10,
var_hash=0xbfffef34) at
/home/sander/php/head/ext/standard/var.c:497
#5 0x4038f277 in php_var_serialize_intern (buf=0xbfffef60,
struc=0x8219d00,
var_hash=0xbfffef34) at
/home/sander/php/head/ext/standard/var.c:606
#6 0x4038f277 in php_var_serialize_intern (buf=0xbfffef60,
struc=0x8219b10,
var_hash=0xbfffef34) at
/home/sander/php/head/ext/standard/var.c:606
#7 0x4038f277 in php_var_serialize_intern (buf=0xbfffef60,
struc=0x8219d00,
var_hash=0xbfffef34) at
/home/sander/php/head/ext/standard/var.c:606
#8 0x4038f277 in php_var_serialize_intern (buf=0xbfffef60,
struc=0x8219b10,
var_hash=0xbfffef34) at
/home/sander/php/head/ext/standard/var.c:606
#9 0x4038f277 in php_var_serialize_intern (buf=0xbfffef60,
struc=0x8219d00,
var_hash=0xbfffef34) at
/home/sander/php/head/ext/standard/var.c:606
etc etc etc
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/17419
--
Edit this bug report at http://bugs.php.net/?id=17419&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #17419 [Opn]: Complex objects not correctly stored in ssession
ID: 17419 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: BSDi PHP Version: 4.2.1 New Comment: This one is related too: http://bugs.php.net/bug.php?id=14645 Previous Comments: [2002-12-13 11:01:15] [EMAIL PROTECTED] Please further explain what circular references are so this can be documented. [2002-06-01 07:12:14] [EMAIL PROTECTED] Reclassified as a documentation problem after a nice discussion with Markus :) [2002-06-01 07:03:28] [EMAIL PROTECTED] Suspending. [2002-06-01 06:43:25] [EMAIL PROTECTED] I checked back with Zeev, circular references are simlpy not supported in the Zend engine and won't be anytime soon. [2002-06-01 06:19:11] [EMAIL PROTECTED] Circular references don't work with the serializer 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/17419 -- Edit this bug report at http://bugs.php.net/?id=17419&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #15461 [Opn]: configure fails for extension samples
ID: 15461 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: RedHat 6.2 and FreeBSD PHP Version: 4.1.1 New Comment: Where did you find that link? I don't see it in the manual. The doc team never touches these docs anyway and it's widely known (by php-dev) that the ZendAPI docs are (or were) out-of-date. They've been updated since this but am leaving open for now. See: http://www.php.net/manual/en/zend.php These docs live in the ZendAPI module in php cvs now, not at Zend.com anymore. See also the various README's in the php4 source, such as: http://cvs.php.net/co.php/php4/README.SELF-CONTAINED-EXTENSIONS Previous Comments: [2002-06-18 06:17:46] [EMAIL PROTECTED] Zend documentaton is outdated. [2002-02-09 01:04:59] [EMAIL PROTECTED] I've downloaded the Zend API code samples from http://www.zend.com/apidoc/examples.tar.gz. Untarred them and placed the first_module/ directory in ext/. Then I delete the existing ./configure and run ./buildconf. ./buildconf runs fine and --enable-first_module shows up in ./configure --help. I then run ./configure --enable-first_module which starts ok. But in a 4.1.1 source tree it dies with: Configuring extensions checking if the location of ZLIB install directory is defined... no checking whether to include ZLIB support... no : command not found checking BOOK: whether to enable the array experiments... no : command not found : command not found ./configure: ./configure: line 65325: syntax error: unexpected end of file and in a 4.0.6 source tree: checking whether to enable the bundled filePro support... no : command not found checking BOOK: whether to enable the first module... yes : command not found : command not found ./configure: ./configure: line 56828: syntax error: unexpected end of file The previous is run on a Redhat 6.2 box, where php-4.0.6 runs fine normally. I've tried the above on FreeBSD 4.1.1-STABLE box and 4.1.1 source, however ./configure --enable-first_module dies with: Configuring extensions checking if the location of ZLIB install directory is defined... no checking whether to include ZLIB support... no : not found checking BOOK: whether to enable the array experiments... no : not found : not found ./configure: 65312: Syntax error: end of file unexpected (expecting "then") Am I missing something or is this a bug? Thank you, Hans -- Edit this bug report at http://bugs.php.net/?id=15461&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #16239 [Opn->Csd]: Downloadable PDF is trucated at Chapter 46
ID: 16239 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: all PHP Version: 4.1.2 New Comment: This is known, and PDF isn't created anymore until it's solved. Previous Comments: [2002-06-17 10:45:41] [EMAIL PROTECTED] looks like we have hit yet another TeX limit ... :( [2002-03-23 17:38:02] [EMAIL PROTECTED] the summary says it all, I think. From the very beginning of Chapter 46 to the end of all the appendices is truncated on the acrobat formatted files of your 4.1.2 php manual. I verified this problem via all the us mirros and the UK mirrors and found the same problems exist. PS Extremely comprehensive site. thanks. -- Edit this bug report at http://bugs.php.net/?id=16239&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21013 [Opn->Bgs]: strip_tags doesn't work with regular HTML-Expression
ID: 21013 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Windows XP, FreeBSD PHP Version: 4.3.0RC3 New Comment: >From the docs: "You can use the optional second parameter to specify tags which should not be stripped." So, that parameter is named allowable_tags, not tags_to_remove Previous Comments: [2002-12-14 11:42:39] [EMAIL PROTECTED] strip_tags doesn't work as expected. When trying so trip -tags, strip_tags doesn't strip anything. It maybe strips somewhere else, but not on my screen. :-) Take this example code: blabla"; $res =strip_tags($fin, ""); echo $res; ?> echo outputs blablablabla in the HTML-Source. The solution is leaving the angle-brackets away like: blabla"; $res =strip_tags($fin, "br"); echo $res; ?> But this doesn't correspond with the Documentation at http://www.php.net/manual/en/function.strip-tags.php Escaping with $res =strip_tags($fin, "\"); does it, but why? -- Edit this bug report at http://bugs.php.net/?id=21013&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21007 [Opn]: html_errors off text-only output in phpinfo
ID: 21007 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem -Operating System: win2k +Operating System: all PHP Version: 4.3.0RC3 New Comment: Where? Put the information in this bug report. Previous Comments: [2002-12-14 13:39:31] [EMAIL PROTECTED] I've submitted a note to document this behavior in the PHP Manual. [2002-12-14 06:31:19] [EMAIL PROTECTED] If this is intended behaviour, this seems to be a doc problem, since I can't find anything about in the docs. Regards Friedhelm Betz [2002-12-14 06:19:32] [EMAIL PROTECTED] It's indeed intended like this (and I already forgave your typo :). Derick [2002-12-14 06:16:29] [EMAIL PROTECTED] Sorry a misleading typo, but the script should be: or php.ini html_errors=off Is it intended behaviour with this settings that phpinfo() produces text-only output no html-formated output? Sorry if my first post wasn't clear enough. BTW, I wasn'able to find anything in the docs, that setting html_errors off causes phpinfo() to display text-only output. Regards Friedhelm Betz [2002-12-14 06:05:28] [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 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/21007 -- Edit this bug report at http://bugs.php.net/?id=21007&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20601 [Opn]: A simple syntax parse error
ID: 20601
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Windows ME
PHP Version: 4.3.0RC1
Assigned To: philip
New Comment:
Sort of. This is a feature I was not aware of in PHP and imho is sort
of a bug :)
As it turns out, constants are only seen in strings if:
a) It's an array key
b) {braces} are around the array
So for example, NO E_NOTICE is generated from "a $arr[foo]" but "a
{$arr[foo]}" does! And btw, "a {foo}" does not look for the constant
foo.
And because multidimensional arrays inside strings require {braces}
this is an important point. IMHO this behavior of constants inside
strings is inconsistent and I'm writing php-dev now! :)
Previous Comments:
[2002-12-17 10:37:35] [EMAIL PROTECTED]
Philip, please do not change that part of the documentation. **It is
correct!**.
Try with this script:
For the first echo line, a NOTICE error is
echoed out... So the documentation is correct. It may not be clear
enough, but it is correct, the example is right.
[2002-12-05 13:49:27] [EMAIL PROTECTED]
As it turns out, the string docs are wrong and contain the following in
the example:
// This is wrong for the same reason
// as $foo[bar] is wrong outside a string.
echo "This is wrong: {$arr[foo][3]}";
I'll rewrite this part of the documention too. $foo[bar] is perfectly
fine inside strings, CONSTANTS aren't seen in strings. Anyway, this
will be further explained with a more specific example too. And a faq
entry :) This question comes up waaay too much these days.
[2002-12-05 13:26:22] [EMAIL PROTECTED]
The string type description includes a lengthy explanation of this
AFAIK.
[2002-12-04 19:03:14] [EMAIL PROTECTED]
Btw, this happens when you do:
print "a foo $bar['blah'] eh";
Don't do that. You can do either:
print "a foo {$bar['blah']} eh";
print "a foo $bar[blah] eh";
print "a foo " . $bar['blah'] . " eh";
But when outside of strings always quote your keys:
print $bar[blah]; // bad
print $bar['blah']; // good
Unless of course you defined blah as a constant earlier. Anyway I'm
making a faq out of this question and marking as a doc bug because this
question comes up a lot especially since 4.1.0 (autoglobals) and 4.2.0
(register_globals default change).
[2002-12-04 18:17:54] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
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/20601
--
Edit this bug report at http://bugs.php.net/?id=20601&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20895 [Ver]: dirname() behaviour changed
ID: 20895
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
-Bug Type: Filesystem function related
+Bug Type: Documentation problem
Operating System: Win 2000Pro SP3
PHP Version: 4.3.0RC2
New Comment:
Okay, marking as a documentation bug. A needs to exist in the
dirname docs for windows users as the current POSIX isn't
accurate as of PHP 4.3.0...
Previous Comments:
[2002-12-11 11:16:36] [EMAIL PROTECTED]
Suppose you have a file c:/file.txt and you want to open another file
from the same directory.
If dirname("c:/file.txt"); return '.', then fopen
("./another_file.txt") will fail because it is looking in the wrong
directory, the current current directory. If it returns c:/ or c: then
c: + / + file will resolve to the actual file and open it correctly.
[2002-12-10 20:05:55] [EMAIL PROTECTED]
A couple people just tested this and get the same results as the bug
report with 4.3.0RC2, please explain why this behavior changed.
[2002-12-08 23:56:53] [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
[2002-12-08 23:35:37] [EMAIL PROTECTED]
Hello.
Up to 4.2.3:
dirname("c:/");
// or
dirname("c:");
// both returned '.'
in 4.3.0 RC2, we got now:
dirname("c:/");
// gives you c:\
dirname("c:");
// gives you c:
(i) I'm not sure that such path shall be used with dirname(). But after
all, why not? And in fact I used it.
(ii) What's the reason for that behaviour change?
(iii) As some of my classes are now broken, will this new behaviour
become the rule for the future?
Apache independent.
Standarts php.ini (recommended) and httpd.conf
Mozilla 1.2
Thanks.
--
Edit this bug report at http://bugs.php.net/?id=20895&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21122 [Opn]: NOSPAM, spam protecting
ID: 21122 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Win98 PHP Version: 4.3.0RC3 New Comment: reclassified Previous Comments: [2002-12-20 17:23:36] [EMAIL PROTECTED] http://www.php.net/manual/add-note.php -- start -- (usual anti-spam practices are OK, e.g. [EMAIL PROTECTED]). -- end -- I think, this is obsolete, since all email adresses are replaced by "name at a dot com". A comment, that email adresses are 'edited' would be more convenient (in my view). -- Edit this bug report at http://bugs.php.net/?id=21122&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21157 [Bgs->Opn]: when ini settings are changable needs to be further documented
ID: 21157 Updated by: [EMAIL PROTECTED] -Summary: registry per directory entries ignored Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open -Bug Type: IIS related +Bug Type: Documentation problem Operating System: windows 2000 sp3 -PHP Version: 4.2.3 +PHP Version: 4.4.0-dev New Comment: Assuming that 'registry per directory' is an option similar to .htaccess for IIS, it's worth mentioning that for example safe_mode is listed as PHP_INI_SYSTEM so it can be set in httpd.conf or php.ini but not .htaccess (or whatever IIS uses). You will notice at php.net/ini_set that some options are PHP_INI_SYSTEM|PHP_INI_PERDIR and some are PHP_INI_ALL, those can be set per directory. This 'when changable' information should be mentioned within every configuration description in the manual as opposed to only in the ini_set() docs. Or at least pointed somewhere. That said, am marking this as a documentation problem. Also note that equivelents for apache's httpd.conf and .htaccess should be mentioned somewhere too, not sure where (yet). Previous Comments: [2002-12-23 10:43:13] [EMAIL PROTECTED] http://www.php.net/manual/en/function.ini-set.php Contains a comprehensive list of ini settings and it tells you whether a particular ini setting can be set per directory or not. [2002-12-23 10:41:51] [EMAIL PROTECTED] Thanks for the comments but I lodged the report *after* reading anything relevant in the docs I could find. I could find nothing about the 'registry per directory' win32 registry functionality but it exists. Where would I find info explaining which php.ini options are accepted for this function? I would be happy to accept any specific pointers to relevant docs from more knowledgable people than myself. [2002-12-23 10:34:19] [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 Options such as safe_mode, expose_php, etc.. can only be set via PHP.ini and are NOT 'per directory'. [2002-12-22 23:12:24] [EMAIL PROTECTED] When making use of the 'registry per directory' option to set per directory php.ini entries it would appear that only selected options from php.ini are parsed in this registry section. For example error_log and sendmail_from entries are parsed but safe_mode, user_dir, expose_php, smtp, doc_root are ignored when here. -- Edit this bug report at http://bugs.php.net/?id=21157&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21157 [Bgs->Opn]: when ini settings are changable needs to be further documented
ID: 21157 Updated by: [EMAIL PROTECTED] -Summary: registry per directory entries ignored Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open -Bug Type: IIS related +Bug Type: Documentation problem -Operating System: windows 2000 sp3 +Operating System: windows -PHP Version: 4.2.3 +PHP Version: 4.4.0-dev New Comment: Reclassified again :) Previous Comments: [2002-12-23 10:55:38] [EMAIL PROTECTED] Thank you for the pointer. [2002-12-23 10:54:26] [EMAIL PROTECTED] Assuming that 'registry per directory' is an option similar to .htaccess for IIS, it's worth mentioning that for example safe_mode is listed as PHP_INI_SYSTEM so it can be set in httpd.conf or php.ini but not .htaccess (or whatever IIS uses). You will notice at php.net/ini_set that some options are PHP_INI_SYSTEM|PHP_INI_PERDIR and some are PHP_INI_ALL, those can be set per directory. This 'when changable' information should be mentioned within every configuration description in the manual as opposed to only in the ini_set() docs. Or at least pointed somewhere. That said, am marking this as a documentation problem. Also note that equivelents for apache's httpd.conf and .htaccess should be mentioned somewhere too, not sure where (yet). [2002-12-23 10:43:13] [EMAIL PROTECTED] http://www.php.net/manual/en/function.ini-set.php Contains a comprehensive list of ini settings and it tells you whether a particular ini setting can be set per directory or not. [2002-12-23 10:41:51] [EMAIL PROTECTED] Thanks for the comments but I lodged the report *after* reading anything relevant in the docs I could find. I could find nothing about the 'registry per directory' win32 registry functionality but it exists. Where would I find info explaining which php.ini options are accepted for this function? I would be happy to accept any specific pointers to relevant docs from more knowledgable people than myself. [2002-12-23 10:34:19] [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 Options such as safe_mode, expose_php, etc.. can only be set via PHP.ini and are NOT 'per directory'. 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/21157 -- Edit this bug report at http://bugs.php.net/?id=21157&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21225 [Opn->Csd]: manual/en/wrappers.php is non-english
ID: 21225 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.3.0 New Comment: Fixed in CVS, and will show up shortly. Previous Comments: [2002-12-27 17:37:27] [EMAIL PROTECTED] http://www.php.net/manual/en/wrappers.php shows what appears to be Czech or Slovak version. -- Edit this bug report at http://bugs.php.net/?id=21225&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21227 [Opn->Dup]: Release announcement links to non-English page
ID: 21227
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Duplicate
Bug Type: Documentation problem
Operating System: N/A
PHP Version: 4.3.0
New Comment:
Fixed in CVS, and this is a duplicate of:
http://bugs.php.net/bug.php?id=21225
Previous Comments:
[2002-12-27 18:52:20] [EMAIL PROTECTED]
The link entitled "List of Supported Protocols/Wrappers" takes you to a
page that has an English URL
(http://www.php.net/manual/en/wrappers.php), but the page itself is in
another language ("Appendix I. Zoznam Podporovaných
Protokolov/Balíèkov").
Location:
http://www.php.net/release_4_3_0.php
peace,
dave
--
Edit this bug report at http://bugs.php.net/?id=21227&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #6513 [Opn]: get_browser() and register_globals
ID: 6513
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: all
PHP Version: 4.3.0-RC2
New Comment:
I'm leaving this open until someone can test with an older version, I
don't feel like it right now :) But, the docs are now register_globals
= off friendly.
Previous Comments:
[2002-12-04 10:31:49] [EMAIL PROTECTED]
This is a doc problem, not a feature request. Not sure when this
behavior changed but I just tested and register_globals does not affect
get_browser() in PHP 4.3.0 but a user comment suggests this problem
existed as of 10-Jan-2002 so it needs to be researched.
a) When was this fixed? Document what it means.
b) Remove the $, and refer to $_SERVER in docs
c) If it turns out this wasn't fixed, reopen as a bug
[2000-09-03 09:20:11] [EMAIL PROTECTED]
I have a remark about the get_browser() function. When this function is
called without arguments it is supposed to use $HTTP_USER_AGENT for
argument. However if I use the
configuration directive
register_globals = Off
then the variable $HTTP_USER_AGENT is not defined and get_browser()
returns an error. In this case I have to do the following
$HTTP_USER_AGENT = getenv("HTTP_USER_AGENT");
$browser = get_browser();
or alternatively
$a = getenv("HTTP_USER_AGENT");
$browser = get_browser($a);
I suggest that get_browser() function should act more cleverly in this
case and use getenv() to get the HTTP_USER_AGENT.
--
Edit this bug report at http://bugs.php.net/?id=6513&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #6513 [Opn->Csd]: get_browser() and register_globals
ID: 6513
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: all
-PHP Version: 4.3.0-RC2
+PHP Version: 4.3.0
New Comment:
This is now documented, this problem exists prior to 4.0.6 and the diff
to php4 source can be seen here:
http://cvs.php.net/diff.php/php4/ext/standard/browscap.c?r1=1.42&r2=1.43
Doc changes can be seen here:
http://cvs.php.net/cvs.php/phpdoc/en/reference/misc/functions/get-browser.xml
Thank you for the report and making PHP better :)
Previous Comments:
[2002-12-29 23:07:34] [EMAIL PROTECTED]
I'm leaving this open until someone can test with an older version, I
don't feel like it right now :) But, the docs are now register_globals
= off friendly.
[2002-12-04 10:31:49] [EMAIL PROTECTED]
This is a doc problem, not a feature request. Not sure when this
behavior changed but I just tested and register_globals does not affect
get_browser() in PHP 4.3.0 but a user comment suggests this problem
existed as of 10-Jan-2002 so it needs to be researched.
a) When was this fixed? Document what it means.
b) Remove the $, and refer to $_SERVER in docs
c) If it turns out this wasn't fixed, reopen as a bug
[2000-09-03 09:20:11] [EMAIL PROTECTED]
I have a remark about the get_browser() function. When this function is
called without arguments it is supposed to use $HTTP_USER_AGENT for
argument. However if I use the
configuration directive
register_globals = Off
then the variable $HTTP_USER_AGENT is not defined and get_browser()
returns an error. In this case I have to do the following
$HTTP_USER_AGENT = getenv("HTTP_USER_AGENT");
$browser = get_browser();
or alternatively
$a = getenv("HTTP_USER_AGENT");
$browser = get_browser($a);
I suggest that get_browser() function should act more cleverly in this
case and use getenv() to get the HTTP_USER_AGENT.
--
Edit this bug report at http://bugs.php.net/?id=6513&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21428 [Opn]: additional example for CLI SAPI page
ID: 21428 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: all PHP Version: 4.3.0 New Comment: If \r\n was used in the example, would this CLI example work fine on all OS's including macs? (which uses \r) Previous Comments: [2003-01-05 07:26:21] [EMAIL PROTECTED] I completely agree. fscanf() is for advanced users but one example with fgets() and fscanf() will be better IMHO. [2003-01-05 07:21:27] [EMAIL PROTECTED] Note: there should be an another one with fgets() IMHO. [2003-01-05 07:11:40] [EMAIL PROTECTED] sorry STDIN instead of $STDIN [2003-01-05 07:08:31] [EMAIL PROTECTED] Hi, few minutes ago I was asked by a friend : "How can I read the user input in CLI?" He proposed this : butthe user has to enter EOF (Ctrl-Z on Windows, Ctrl-D on *nix). This is not intuitive. So after some thinking I created this : I haven't found an example about that issue on the CLI SAPI page. Thanks, Andrey -- Edit this bug report at http://bugs.php.net/?id=21428&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20878 [Opn->Bgs]: IIS Server setup to run php code imbeded in html files
ID: 20878 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Windows 200 PHP Version: 4.2.3 New Comment: fletchsod's comments are misleading and wrong. This report is being marked bogus as it's not PHP's job to document how to configure web servers for every file extension. Previous Comments: [2003-01-06 12:10:39] [EMAIL PROTECTED] Um... If you're saying that the php code should work in the *.html and *.htm files. I hate to tell you this. This does not work that way. PHP script do not work in any files other than *.php and *.inc (if with include file function). It have been this way from day one. [2002-12-07 10:17:27] [EMAIL PROTECTED] After installing php-4.2.3-installer.exe per install.txt and configuring IIS as recommended in various help files, I found that my browser would run .php files ok but not .html files with inbedded php code. I wasted a lot of time trying to find the answer which is not mentioned anywhere in the install.txt, (or any other help of FAQ for that matter); The way install.txt describes setting up the IIS server works very well for getting the browser to work with .php files but does nothing at all for .html files that have imbedded php code. In the Internet Services Manager>Default Web Site>Properties page>Home Directory>configuration the following must be added to run php code imbedded in an HTML file:in addition to adding .php and the executable path,it is necessary to also add .html and .htm extensions + the executable path in order to run imbeded php code. Perhaps this solution should have been plain to see - but not! Thanks for your consideration, -- Edit this bug report at http://bugs.php.net/?id=20878&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21474 [Opn]: Bundled GD needs documenting
ID: 21474
Updated by: [EMAIL PROTECTED]
-Summary: Documentation inaccurate
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: FreeBSD 4.6
PHP Version: 4.3.0
New Comment:
To whoever updates the GD config docs, please do not use the term
"built-in" as it is not built-in but rather a php version of GD is
bundled. Windows has and still includes the GD dll's in the download.
Information should include what version of GD is bundled, what
differences occur from the boutell version for that given version, and
that it is strongly suggested to use the bundled
version.
Simply --with-gd or --enable-gd will use the bundled version. I'm not
sure the best way to describe that --with-gd does not look for a local
copy of GD on the system in {PREFIX} like most options do and like
--with-gd used to do before PHP 4.3.0.
Anyway, this is a tricky one so please do some research before
committing :)
Previous Comments:
[2003-01-06 17:24:50] [EMAIL PROTECTED]
The online documentation for the configure options doesn't list GD as
being built in now, I havn't checked the other options, but I think the
they need updating for 4.3.0.
--
Edit this bug report at http://bugs.php.net/?id=21474&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21502 [Opn->Fbk]: Spanish translation
ID: 21502 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type:Documentation problem PHP Version: 4.3.0 New Comment: What manual page is this from? Also, would you like to join the spanish translation team? :) Previous Comments: [2003-01-07 19:36:44] [EMAIL PROTECTED] Hi, there is a problem with a word in spanish that is not correct. Parser is analizador in spanish, so in the part named ¿Qué se puede hacer con PHP? You have: *Scripts en la parte del servidor. Este es el campo más tradicional y el principal campo de trabajo. Se necesitan tres cosas para que esto funcione. El parseador PHP (CGI ó módulo), un servidor web y un navegador. You should have: Scripts en la parte del servidor. Este es el campo más tradicional y el principal campo de trabajo. Se necesitan tres cosas para que esto funcione. El analizador PHP ^^ -- Edit this bug report at http://bugs.php.net/?id=21502&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21506 [Opn]: Latest CVS missing php4apache2.dll?
ID: 21506 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Windows XP PHP Version: 4CVS-2003-01-07 (dev) New Comment: I *HIGHLY* doubt this is a doc problem as most likely that dll just forgot to make its way into the distro. Nobody is perfect :) Previous Comments: [2003-01-07 22:48:28] [EMAIL PROTECTED] sorry about the above! my dog was 'nosing' my mouse! :\ [2003-01-07 22:46:15] [EMAIL PROTECTED] Changed category to Documentation Problem, since its not REALLY a problem with apache2 [2003-01-07 22:45:42] [EMAIL PROTECTED] Changed category to Documentation Problem, since its not REALLY a problem with apache2 [2003-01-07 22:45:09] [EMAIL PROTECTED] Changed category to Documentation Problem, since its not REALLY a problem with apache2 [2003-01-07 22:42:09] [EMAIL PROTECTED] I have been using php4.4.0-dev for a while now (ive used a few snapshots of it, but this one since December 26th) (BTW: I use dev becuase i am not in a production environment, and i like to test things and help out in any ways that i can) I decided to update to a newer snapshot, but php4apache2.dll is missing from all the latest snapshots... php4apache.dll is for 1.x as it gives a load error in 2.x. Is this a planned omision of the dll, or a mistake? The install.txt also points to a URL for installing apache 2.x w/ php4, and the URL only mentions CGI & php4apache2.dll, yet there is no php4apache2.dll. The news.txt also has no mention of a 'different' dll, or the removal of the dll. -- Edit this bug report at http://bugs.php.net/?id=21506&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21515 [Opn]: Show the current functionname
ID: 21515
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: all
PHP Version: 4.3.0
New Comment:
You can use the __FUNCTION__ constant as of PHP 4.3.0 It's documented
somewhere with the other magical sorta-constants __FILE__, __LINE__,
and __CLASS__. __CLASS__ also became available in PHP 4.3.0
I think there's a bug somewhere for documented these sorta-constants as
the manual doesn't document them very well.
Previous Comments:
[2003-01-08 04:27:05] [EMAIL PROTECTED]
hah, nu even de daad by het woord voegen :-)
[2003-01-08 04:26:25] [EMAIL PROTECTED]
You can use debug_backtrace() for this (which is new in PHP 4.3.0).
(Try var_dump(debug_backtrace()); to see what output it gives), marking
this bug as a doc problem, as debug_backtrace() has not been documented
yet.
Derick
[2003-01-08 04:20:36] [EMAIL PROTECTED]
Is it possible to create a getCurrentFunctionName() function?
If an user defined error occured (for example: you are not getting a
valid SQL-resultset with your query) in a function, it would be handy
to show the functionname where the error is generated.
Possible example:
function getQueryResultSet() {
// requested code
$currentFunctionName = getCurrentFunctionName();
$query="select * from table";
$result = mysql_query($query) or die ("The error occured in ".
$currentFunctionName);
return $result;
}
--
Edit this bug report at http://bugs.php.net/?id=21515&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21145 [Opn->Csd]: CLI version of PHP always prints HTTP headers.
ID: 21145
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Linux - Debian Woody
PHP Version: 4CVS-2002-12-22 (stable)
New Comment:
This has been documented. The user was actually confused between CLI
and CGI as only CGI prints HTTP headers. Simply --enable-cli does not
mean PHP will for sure copy sapi/cli/php to {prefix}/bin/php. Anyway,
this is now documented/closed.
Previous Comments:
[2003-01-15 09:43:49] [EMAIL PROTECTED]
So what is the bug here? Does the documentation not mention the -q flag
or something?
[EMAIL PROTECTED], call your CLI/CGI version with the -q flag to
suppress headers.
[2002-12-22 17:57:04] [EMAIL PROTECTED]
When you compile both the CGI and CLI (without specifying install paths
and without other sapi's) make install will overwrite the installed CLI
version with the CGI one (both are installed by default into
/usr/local/bin). You can solve this by make install-cli (to overwrite
the installed CGI again).
[2002-12-22 15:14:38] [EMAIL PROTECTED]
Please explain to the doc team how to document this new behavior in
PHP, regarding the CLI/CGI build process. And the various problems
(such as this ncurses one) that may/will arise.
[2002-12-22 12:55:46] [EMAIL PROTECTED]
I just reconfigured with --enable-cli and recompiled with the same
results. It always says cgi in php -v, no matter if I configure it as a
CLI or not.
[2002-12-22 12:49:55] [EMAIL PROTECTED]
Just in case I wasn't clear enough on what HTTP headers where printed,
they follow:
Content-type: text/html
X-Powered-By: PHP/4.3.0-dev
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/21145
--
Edit this bug report at http://bugs.php.net/?id=21145&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #16660 [Opn]: conspiracy continues - Documentation bz2 archive format is not appropriate
ID: 16660 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Windows PHP Version: 4.2.2 New Comment: muahahahaha Previous Comments: [2002-08-10 18:40:36] [EMAIL PROTECTED] So the filthy bz2 conspiracy continues - almost 4 month passed and the tar.gz files are still not available... [2002-07-01 10:02:55] [EMAIL PROTECTED] It's a feature request. Let's close it when it has been done, not before. [2002-07-01 09:54:20] [EMAIL PROTECTED] I think there are a lot of links to programs for Windows which extract bzip2. And since we will (according to Simone's comment) switch to .zip and tar.gz/.bz2, I close this bug. IMHO it is no real "bug", since everyone is able to extract the files. [2002-06-10 09:08:09] [EMAIL PROTECTED] Uh, it seems like I was the only one missing from LinuxTag ;(( I still have examtime... BTW we already agreen on providing BOTH bz2 and tar.gz but as only Jim Winstead can modify this, and (it seems) he had no time to do it, it's not done... ;(( [2002-06-10 06:13:45] [EMAIL PROTECTED] I have brought this issue to Rasmus attention during LinuxTag 2002, and he agreed that it is a Good Thing to go back to tar.gz or even to provide both zip and tar.gz for download 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/16660 -- Edit this bug report at http://bugs.php.net/?id=16660&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21694 [Bgs->Opn]: pcntl_alarm
ID: 21694 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type:Documentation problem PHP Version: 4.3.0 New Comment: It's still not bogus, it's open. Previous Comments: [2003-01-16 15:18:03] [EMAIL PROTECTED] we know. There's loads of undocumented functions still around We're constantly documenting new functions, and modifying current documentation to keep you informed the best we can...! To see all undocumented features, have a look here: http://zend.com/phpfunc/nodoku.php [2003-01-16 14:44:17] [EMAIL PROTECTED] Function pcntl_alarm is not documented yet. -- Edit this bug report at http://bugs.php.net/?id=21694&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18403 [Opn]: changable directive information (ini_set)
ID: 18403
Updated by: [EMAIL PROTECTED]
-Summary: ini_set documentation outdated in other languages
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type:Documentation problem
-PHP Version: 4.2.1
+PHP Version: 4.5.0
New Comment:
This important topic needs more analysis.
The generated table found at php.net/ini_set (which is created by
phpdoc/scripts/mk_ini_set_table.sh) should not be listed at
php.net/ini_set but rather it should be listed somewhere near
config.xml as this table is certainly not ini_set specific.
Also, this table needs a third description column which somehow should
not be affected by mk_ini_set_table.sh. This would be, for example, a
place to explain why register_globals is PHP_INI_ALL.
And lastly, this information should be related to {extension}/ini.xml
somehow as currently the information is kept track of in two places.
This deserves some thought too.
Regarding the original purpose of this bug report, when
mk_ini_set_table.sh is run it should be run on all translations, not
just /en/. This would mean translations of this wouldn't get
out-of-date.
Previous Comments:
[2002-07-23 14:58:43] [EMAIL PROTECTED]
Because it is sometimes really nice to have comments on settings (not
much like the indexes), they may be better to be kept as normal XML
files updated by hand.
A new idea is that maybe we can autogenerate it from the source, and
keep it language independent, and make all names links to their
corresponding parts (now in configure.xml and in the future in several
ini.xml files in ext docs)
[2002-07-23 14:05:17] [EMAIL PROTECTED]
The list of ini_set() configuration options is manually autogenerated.
Sometimes changes are made, though, to reflect real world (imho)
behavior. And, sometimes php4 is modified through discussion of this
list.
Here are some options:
(a) Have this list autogenerated with every manual build.
(b) Have a centralized copy of this table, have all languages use it.
Doing (a) assumes no changes will be made (as they won't be kept),
currently we do make changes so this may not be viable. (b) is good as
this table is only in english anyways although it'd make it more
difficult to add a third "description" column for these settings. A
description column would be good to describe why the PHP4 source is the
way it is, and why one might not have expected behavior.
Feel free to discuss. A related documentation feature request is bug
#18372
[2002-07-18 06:26:23] [EMAIL PROTECTED]
Anyway there is a mistake in the french version of the doc which views
it as a PHP_INI_ALL configuration option.
[2002-07-18 04:45:26] [EMAIL PROTECTED]
The documentation is correct. It's not possible to change
it anymore (4.3.0-dev) and changing it now does not affect it in
anyway.
[2002-07-18 03:50:40] [EMAIL PROTECTED]
There seems to have an error in the english documentation of ini_set
function. The upload_max_filesize is describe as PHP_INI_SYSTEM
configuration option, but it appears to be sizeable via ini_set
function.
Please care about it !
--
Edit this bug report at http://bugs.php.net/?id=18403&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21680 [WFx->Opn]: heredoc breaks with mac text format
ID: 21680 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Wont fix +Status: Open -Bug Type: Strings related +Bug Type: Documentation problem Operating System: FreeBSD 4 PHP Version: 4.3.0 -Assigned To: +Assigned To: philip New Comment: This needs to be documented sometime, assigning to self. Previous Comments: [2003-01-17 02:05:30] [EMAIL PROTECTED] Cool with me, I was just taken by suprise, by this behavior. [2003-01-16 15:02:22] [EMAIL PROTECTED] The 1st character before 'EOD;' must be a newline as defined by your operating system. Meaning that it can only be \r if you are using a MAC or an OS where \r is EOL. [2003-01-16 02:49:28] [EMAIL PROTECTED] It appears that the heredoc string type breaks if the script is in mac text format. This has been noticed before http://www.zend.com/lists/php-dev/200110/msg00815.html, but i havn't been able to find a bugreport? Im working in Windows with UltraEdit, and the following code breaks, when I use UltrEdit to convert from dos format to mac format: This error is produced: Parse error: parse error, unexpected $ in /usr/home/nej/public_html/heredoc.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=21680&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #15461 [Opn->Csd]: configure fails for extension samples
ID: 15461 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: RedHat 6.2 and FreeBSD PHP Version: 4.1.1 New Comment: Closing for reasons already mentioned. Previous Comments: [2002-12-13 11:25:05] [EMAIL PROTECTED] Where did you find that link? I don't see it in the manual. The doc team never touches these docs anyway and it's widely known (by php-dev) that the ZendAPI docs are (or were) out-of-date. They've been updated since this but am leaving open for now. See: http://www.php.net/manual/en/zend.php These docs live in the ZendAPI module in php cvs now, not at Zend.com anymore. See also the various README's in the php4 source, such as: http://cvs.php.net/co.php/php4/README.SELF-CONTAINED-EXTENSIONS [2002-06-18 06:17:46] [EMAIL PROTECTED] Zend documentaton is outdated. [2002-02-09 01:04:59] [EMAIL PROTECTED] I've downloaded the Zend API code samples from http://www.zend.com/apidoc/examples.tar.gz. Untarred them and placed the first_module/ directory in ext/. Then I delete the existing ./configure and run ./buildconf. ./buildconf runs fine and --enable-first_module shows up in ./configure --help. I then run ./configure --enable-first_module which starts ok. But in a 4.1.1 source tree it dies with: Configuring extensions checking if the location of ZLIB install directory is defined... no checking whether to include ZLIB support... no : command not found checking BOOK: whether to enable the array experiments... no : command not found : command not found ./configure: ./configure: line 65325: syntax error: unexpected end of file and in a 4.0.6 source tree: checking whether to enable the bundled filePro support... no : command not found checking BOOK: whether to enable the first module... yes : command not found : command not found ./configure: ./configure: line 56828: syntax error: unexpected end of file The previous is run on a Redhat 6.2 box, where php-4.0.6 runs fine normally. I've tried the above on FreeBSD 4.1.1-STABLE box and 4.1.1 source, however ./configure --enable-first_module dies with: Configuring extensions checking if the location of ZLIB install directory is defined... no checking whether to include ZLIB support... no : not found checking BOOK: whether to enable the array experiments... no : not found : not found ./configure: 65312: Syntax error: end of file unexpected (expecting "then") Am I missing something or is this a bug? Thank you, Hans -- Edit this bug report at http://bugs.php.net/?id=15461&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #17002 [Opn->Csd]: Unable to load php_oci8.dll ONLY in command line mode
ID: 17002 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Win98 PHP Version: 4.2.0 New Comment: This has now been documented, see: http://cvs.php.net/cvs.php/phpdoc/en/chapters/install.windows.xml Thanks for the report :) Previous Comments: [2002-05-05 12:09:28] [EMAIL PROTECTED] Hm... it seems to me a good idea to note somewhere in the manual that PHP (or Windows) searches for DLL's in %PATH% and %SYSTEM%. Reopening as a documentation problem. [2002-05-05 12:04:48] [EMAIL PROTECTED] Of course, it is NOT a bug of php. [2002-05-05 12:01:11] [EMAIL PROTECTED] After failed many times, I happened to find the cause. I think it maybe helpful for many people who reported or asked the same question that I have seen on www.php.net . It is the PATH has not been correctly set. When loading php_oci8.dll, this DLL file search for the other DLL file "oci.dll" in current directory, PATH environment and %SYSTEM%(on Windows). If oci.dll can not be found, the OS will tell you "Unable to load dynamic library : php_oci8.dll". If you installed Oracle RDBMS on your system, then the file "oci.dll" is in Oralce Home directory. So you must include "Oracle Home Directory " in PATH environment, on my computer it is "D:\Oracle\ora81\Bin". Perhaps, the same problem on different platform can be solved in same way, try it. I am lucky to find the cause in almost ten days, I hope people will not be worried about this problem any longer. Dong Peng Lanzhou Railway Universiy China 2002-5-6 00:06 [2002-05-04 05:15:29] [EMAIL PROTECTED] The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php [2002-05-04 05:00:24] [EMAIL PROTECTED] Unable to load php_oci8.dll ONLY in command line mode I have just installed php 4.2.0 for win32 on my computer. I found the same bug as php (4.1.2). There is nothing wrong when I use php in ISAPI mode, and I can connect to Oracle 8i(8.1.7 Personal Edition) successfully and manipulate data too. but when I use php in command line mode to process some task which can only run once, the system show a message box with the text below : 'Unable to load dynamic library "c:\php420\extensions\php_oci8.dll". ' The extension file "php_oci8.dll" does exist in the above directory, and can work correctly in ISAPI mode. So I considered that there is a bug in "php.exe" on loading dynamic library. Is it? Please help me. Dong Peng 2002-5-4 -- Edit this bug report at http://bugs.php.net/?id=17002&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #17324 [Opn->Csd]: charset in polish chm is wrong
ID: 17324 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: winxp PHP Version: 4.2.1 New Comment: This is fixed, from phpdoc/chm/make_chm.php "pl" => array( "langcode" => "0x415 Polish", "preferred_charset" => "Windows-1250", "preferred_font" => $DEFAULT_FONT ), Previous Comments: [2002-11-01 04:10:10] [EMAIL PROTECTED] There are actually no 10th edition of the Polish manual... But there is a new one available from php.net approx. every week, if all goes well.. [2002-10-31 18:01:12] [EMAIL PROTECTED] Strangely there is still sth wrong with coding. All charset and coding is ok, but chm seems to set ISO-8859-1 or in some files also it is set to windows-1250 and letters coding is in ISO-8859-2. I suppose that coding it all to windows-1250 should make it work, because it's the only "right" coding in polish windows, and I don't think that anyone would use it outside of Poland and on other system than windows :) [2002-10-31 13:57:34] [EMAIL PROTECTED] Does the problem still exist in the latest version (10th edition) of the chm manual? [2002-05-21 02:13:27] [EMAIL PROTECTED] It's true. Additionaly, users can't search the manual because of incompatible charsets. I've investigated this problem about month ago. There is no other way to solve it than converting the whole manual to cp-1250 and changing meta before compiling chm. I hope it would be possible with the new version of chm. [2002-05-20 19:50:39] [EMAIL PROTECTED] codepage in polish chm is wrong. In head of all html files included into chm documentation charset is set to iso8952-2 but letters are written like this: Rozdzia³ instead of Rozdzia³ But also in list on the left, polish letters are shown wrong despite of that are written ok. best regards Andrzej Korcala -- Edit this bug report at http://bugs.php.net/?id=17324&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19068 [Opn->Csd]: $_SESSION behaves like session_register(), but doesn't call session_start()
ID: 19068 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Any PHP Version: 4CVS-2002-08-23 New Comment: This has now been documented: http://cvs.php.net/cvs.php/phpdoc/en/reference/session/functions/session-register.xml http://cvs.php.net/cvs.php/phpdoc/en/reference/session/reference.xml Thanks for the report :) Previous Comments: [2002-08-23 08:12:00] [EMAIL PROTECTED] Damn, doc problem of course. [2002-08-23 08:10:38] [EMAIL PROTECTED] The manual page about session_register (http://www.php.net/manual/en/function.session-register.php) says: "Caution: If you are using $_SESSION (or $HTTP_SESSION_VARS), do not use session_register(), session_is_registered() and session_unregister()." and a few lines later "If session_start() was not called before this function is called, an implicit call to session_start() with no parameters will be made." But the latter is not true if only $_SESSION is used to register a session variable. The current implementation requires a manual call to session_start(). This should be noted there. Idially, it should be mentioned also at http://www.php.net/manual/en/ref.session.php (where it says: Note: As of PHP 4.1.0, $_SESSION is available as global variable just like ...) and maybe also at http://www.php.net/manual/en//language.variables.predefined.php (which may be too much good will though ;) -- Edit this bug report at http://bugs.php.net/?id=19068&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19208 [Opn->Csd]: get_meta_tags appropriate for strings functions?
ID: 19208 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.2.2 New Comment: It has been moved to the URL section. Thanks for the report :) Previous Comments: [2002-08-30 23:19:41] [EMAIL PROTECTED] The function get_meta_tags listed in the string function does not operate on a string. The fact that it returns a string does not seem to be appropriate justification for it's placement here. It seems as if it should be in an html parsing functions sections. I would definately like to see more functions like this for parsing html content. -- Edit this bug report at http://bugs.php.net/?id=19208&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19196 [Opn->Csd]: Explanation of "magic constants" not included in documentation
ID: 19196 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.3.0 New Comment: These have now been documented: http://cvs.php.net/cvs.php/phpdoc/en/language/constants.xml Thanks for the report :) Previous Comments: [2002-09-16 18:47:50] [EMAIL PROTECTED] On a related note, the new __CLASS__ and __FUNCTION__ constants should be documented with these too. These four magical "constants" are also listed here: http://www.php.net/manual/en/reserved.php (__CLASS__ and __FUNCTION__ were added in 4.3.0) [2002-08-30 07:58:55] [EMAIL PROTECTED] This bug report has little to do with the implementation of PHP itself. This is about the documentation for the language. I was having a very hard time finding information about the so-called "magic constants", namely __FILE__ and __LINE__. Apparently, the use of these constants is very common. The problem is, throughout the entire PHP.net web site, there is only one reference made to these "magic constants", and their mention is not very informative at all. See this page: http://www.php.net/manual/en/language.constants.php The only other references to "__FILE__" I could find, using Google on the PHP.net site, were in user comments, and they were only used in examples, so there was no clear definition of the use of these constants. After searching the web for any sort of definition for the magic constants, I finally found one at this page: http://www.sunsite.ualberta.ca/Documentation/Misc/php-3.0.15/language.constants.html In any case, the reason I was writing is because I just thought it would be a good idea to include a definition of this sort somewhere in the online documentation of PHP. If it is included somewhere that I haven't looked or wasn't able to find, then I apologize for the intrusion. -- Edit this bug report at http://bugs.php.net/?id=19196&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19491 [Opn->Csd]: Missing part of PWS 4 installation steps
ID: 19491 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Windows PHP Version: 4CVS-2002-09-19 New Comment: This has now been documented: http://cvs.php.net/cvs.php/phpdoc/en/chapters/install.iis.xml Thanks for the report :) Previous Comments: [2002-09-19 03:03:33] [EMAIL PROTECTED] In manual page: http://www.php.net/manual/en/install.iis.php Windows and PWS 4 or newer part, it said: [QUOTE] If you choose the CGI binary, do the following: Edit the enclosed pws-php4cgi.reg file (look into the SAPI dir) to reflect the location of your php.exe. Forward slashes should be escaped, for example: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w3svc\parameters\Script Map] ".php"="c:\\php\\php.exe" [QUOTE ENDS] That's all? At least you should double click this file and MERGE it to your registry. Also for ISAPI module part. There's more. It call '\' as Forward slash, but I call it backslash ... :-D -- Edit this bug report at http://bugs.php.net/?id=19491&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20521 [Opn->Csd]: pdf_set_font: Deprecated function in use (Examples)
ID: 20521 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.2.2 New Comment: This has been fixed. http://cvs.php.net/cvs.php/phpdoc/en/reference/pdf/reference.xml Thanks for the report :) Previous Comments: [2002-11-20 10:22:12] [EMAIL PROTECTED] I was visiting the following documentation part: http://www.php.net/manual/en/ref.pdf.php The first example contains the function pdf_set_font() which is deprecated. I guess it would be better to write examples without deprecated functions. Maybe this can be fixed in future, to avoid the use of deprecated functions. Greetings. -- Edit this bug report at http://bugs.php.net/?id=20521&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20572 [Opn->Csd]: recommend of move_uploaded_file should be also remind in "handling file uploads
ID: 20572 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: independcy PHP Version: 4.3.0RC1 New Comment: These docs have been updated to focus on move_uploaded_file(). Changes can be seen here: http://cvs.php.net/cvs.php/phpdoc/en/features/file-upload.xml Thanks for the report :) Previous Comments: [2002-11-22 08:53:02] [EMAIL PROTECTED] main >> features >> handling file uploads the example should say that, move_uploaded_file is recommend, this make sure it works under restriction mode. although there's a comment in user note about this, and it also documented in "make_uploaded_file" section. but remind here will help a lot of ppl, also free a lot of php-helpers :) btw: there're so many important user note that should be refine to official document, yet i know, document should be keep simple :) -- Edit this bug report at http://bugs.php.net/?id=20572&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21680 [Opn->Csd]: heredoc breaks with mac text format
ID: 21680 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: FreeBSD 4 PHP Version: 4.3.0 Assigned To: philip New Comment: This is now documented: http://cvs.php.net/cvs.php/phpdoc/en/language/types.xml Thanks for the report :) Previous Comments: [2003-01-17 02:37:11] [EMAIL PROTECTED] This needs to be documented sometime, assigning to self. [2003-01-17 02:05:30] [EMAIL PROTECTED] Cool with me, I was just taken by suprise, by this behavior. [2003-01-16 15:02:22] [EMAIL PROTECTED] The 1st character before 'EOD;' must be a newline as defined by your operating system. Meaning that it can only be \r if you are using a MAC or an OS where \r is EOL. [2003-01-16 02:49:28] [EMAIL PROTECTED] It appears that the heredoc string type breaks if the script is in mac text format. This has been noticed before http://www.zend.com/lists/php-dev/200110/msg00815.html, but i havn't been able to find a bugreport? Im working in Windows with UltraEdit, and the following code breaks, when I use UltrEdit to convert from dos format to mac format: This error is produced: Parse error: parse error, unexpected $ in /usr/home/nej/public_html/heredoc.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=21680&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21515 [Opn]: debug_backtrace() needs documentation.
ID: 21515
Updated by: [EMAIL PROTECTED]
-Summary: Show the current functionname
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: all
PHP Version: 4.3.0
New Comment:
__FUNCTION__ is now documented as per bug #19196.
Am changing the topic of this bug report to reflect everyones deep
desire for debug_backtrace() to be documented.
We all agreed that the section on "Error Handling and Logging
Functions" is the best place for debug_backtrace.
Previous Comments:
[2003-01-08 11:22:35] [EMAIL PROTECTED]
You can use the __FUNCTION__ constant as of PHP 4.3.0 It's documented
somewhere with the other magical sorta-constants __FILE__, __LINE__,
and __CLASS__. __CLASS__ also became available in PHP 4.3.0
I think there's a bug somewhere for documented these sorta-constants as
the manual doesn't document them very well.
[2003-01-08 04:27:05] [EMAIL PROTECTED]
hah, nu even de daad by het woord voegen :-)
[2003-01-08 04:26:25] [EMAIL PROTECTED]
You can use debug_backtrace() for this (which is new in PHP 4.3.0).
(Try var_dump(debug_backtrace()); to see what output it gives), marking
this bug as a doc problem, as debug_backtrace() has not been documented
yet.
Derick
[2003-01-08 04:20:36] [EMAIL PROTECTED]
Is it possible to create a getCurrentFunctionName() function?
If an user defined error occured (for example: you are not getting a
valid SQL-resultset with your query) in a function, it would be handy
to show the functionname where the error is generated.
Possible example:
function getQueryResultSet() {
// requested code
$currentFunctionName = getCurrentFunctionName();
$query="select * from table";
$result = mysql_query($query) or die ("The error occured in ".
$currentFunctionName);
return $result;
}
--
Edit this bug report at http://bugs.php.net/?id=21515&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20850 [Opn->Csd]: str_shuffle needs documentation
ID: 20850
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type:Documentation problem
PHP Version: 4CVS-2002-12-05 (dev)
New Comment:
Documentation for this function now exists. See:
http://cvs.php.net/cvs.php/phpdoc/en/reference/strings/functions/str-shuffle.xml
Thanks for the report :)
Previous Comments:
[2002-12-06 01:15:24] [EMAIL PROTECTED]
That thing @ zend.com is usually not what people use. It's a bug, and
thus it belongs in the bugsystem.
[2002-12-05 22:05:47] [EMAIL PROTECTED]
Nevermind. I see that this function appears on the list at
http://www.zend.com/phpfunc/nodoku.php. There's not much point to me
doubling up the information. :)
[2002-12-05 20:36:33] [EMAIL PROTECTED]
Please add str_shuffle to the documentation. Here's the comment from
the source code (ext/standard/string.c):
/* {{{ proto void str_shuffle(string str)
Shuffles string. One permutation of all possible is created */
--
Edit this bug report at http://bugs.php.net/?id=20850&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #16685 [Ana->Csd]: safe_mode_include_dir check is not correct
ID: 16685
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Analyzed
+Status: Closed
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.2.0
New Comment:
This has now been documented:
http://cvs.php.net/cvs.php/phpdoc/en/features/safe-mode.xml
Thanks for the report :)
Previous Comments:
[2002-09-29 22:59:57] [EMAIL PROTECTED]
Unless you specify / at the end PHP will allow any path that will be
begin with a specified string. Meaning that if /a/b/c is specified then
/a/b/cde will be allowed. A note about this exists for nearly all
directory limiting function, however it is absent from the docs on the
safe_mode_include_dir option. Consquently, I am making this report a
documentation issue.
[2002-04-18 12:32:11] [EMAIL PROTECTED]
I found that safe_mode_include_dir check is not correct.
Here's why:
resolved_name (the path in question) and ptr (a next directory from the
safe_mode_include_dir list) are compared so:
if (strncmp(ptr, resolved_name, strlen(ptr) ==0 )
let ptr="/var/www/script" and resolved_name="/var/www/scripts"
obviously, they will match though it's wrong.
It is necessary to add an extra check for trailing char
(valid one is either a slash or \0)
In fact, checking lengthes of those may save a bit CPU time
(especially with the long list).
Here's suggested patch (it also is available at
http://www.cf1.ru/~byg/patch/php/safe_mode_include_dir.patch
ftp://ftp.cf1.ru/pub/patches/php/safe_mode_include_dir.patch
):
--- main/fopen_wrappers.c.orig Thu Apr 18 21:40:57 2002
+++ main/fopen_wrappers.c Thu Apr 18 23:02:55 2002
@@ -233,6 +233,7 @@
char *ptr;
char *end;
char resolved_name[MAXPATHLEN];
+ int len;
/* Resolve the real path into resolved_name */
if (expand_filepath(path, resolved_name TSRMLS_CC) ==
NULL)
@@ -250,15 +251,20 @@
}
/* Check the path */
+len = strlen(ptr);
+ if (strlen(resolved_name) >= len) {
#ifdef PHP_WIN32
- if (strncasecmp(ptr, resolved_name,
strlen(ptr)) == 0)
+ if (strncasecmp(ptr, resolved_name, len) ==
0)
#else
- if (strncmp(ptr, resolved_name, strlen(ptr)) ==
0)
+ if (strncmp(ptr, resolved_name, len) == 0)
#endif
- {
- /* File is in the right directory */
- efree(pathbuf);
- return 0;
+ {
+ if ((*(resolved_name + len) ==
DEFAULT_SLASH) || (*(resolved_name + len) == '\0')) {
+ /* File is in the right directory
*/
+ efree(pathbuf);
+ return 0;
+ }
+ }
}
ptr = end;
--
Edit this bug report at http://bugs.php.net/?id=16685&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21728 [Opn]: Additional (kindly weird example) for sort()
ID: 21728
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: All
-PHP Version: 4.3.0
+PHP Version: 4.4.0-dev
New Comment:
How about:
Which gives:
array(10) {
[0]=>
bool(false)
[1]=>
string(4) "TRUE"
[2]=>
string(1) "a"
[3]=>
string(4) "true"
[4]=>
bool(true)
[5]=>
string(1) "b"
[6]=>
string(1) "c"
[7]=>
int(4)
[8]=>
string(1) "4"
[9]=>
int(5)
}
Which is weird as "4" looks misplaced. For example in this:
We get different results (all I added was "d" to the end):
array(11) {
[0]=>
bool(false)
[1]=>
string(1) "4"
[2]=>
string(4) "TRUE"
[3]=>
string(1) "a"
[4]=>
string(1) "b"
[5]=>
string(1) "c"
[6]=>
string(1) "d"
[7]=>
string(4) "true"
[8]=>
bool(true)
[9]=>
int(4)
[10]=>
int(5)
}
Notice the different order, is this a genuine bug?
Previous Comments:
[2003-01-18 10:26:27] [EMAIL PROTECTED]
Today I closed bug #21444. The user has to master the type juggling to
know the expected output. I think that it is good idea to add it's
example as comprehensive one.
The script goes here (the explanation is after it) :
The output is :
array(10) {
[0]=>
bool(true)
[1]=>
int(4)
[2]=>
string(1) "4"
[3]=>
string(4) "TRUE"
[4]=>
string(1) "a"
[5]=>
string(1) "b"
[6]=>
string(1) "c"
[7]=>
string(1) "d"
[8]=>
string(4) "true"
[9]=>
int(5)
}
It may look strange - why (int)5 is after all the strings. This is
because "4" is lower than (int) 5, "4" is before "true" and "true" is
before 5. The first 2 are obvious, the third one is not. But it is ok.
It's better not to mix types in the array. If 5 is changed to "5" then
"5" goes right after "4".
Thanks
--
Edit this bug report at http://bugs.php.net/?id=21728&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21728 [Opn]: Additional (kindly weird example) for sort()
ID: 21728
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: All
PHP Version: 4.4.0-dev
New Comment:
I swear I get different results by just adding a "d" to the end. This
should not happen.
Previous Comments:
[2003-01-18 12:05:10] [EMAIL PROTECTED]
As I said this is very complicated case because of the type juggling.
I needed 30 minute to realize that 21444 is not a bug but a bogus (for
me and Derick). I agree that the result is weird. I modified the the
compare function to see what comparisons are made. All of them look
ok.
On my php I have the same results on the script with "d" added at the
end. A little modification changes the order of comparisons and thus
the result is different. Maybe this is because the default sort type is
SORT_REGULAR. If SORT_STRING is used the result is expected. I think
that the case I provided is good to show the users that the results are
kinda unexpected when both the array contains values from various
datatypes and SORT_REGULAR is used. So if the users use such array they
have to be warned of the "unexpected" results.
[2003-01-18 11:48:56] [EMAIL PROTECTED]
How about:
Which gives:
array(10) {
[0]=>
bool(false)
[1]=>
string(4) "TRUE"
[2]=>
string(1) "a"
[3]=>
string(4) "true"
[4]=>
bool(true)
[5]=>
string(1) "b"
[6]=>
string(1) "c"
[7]=>
int(4)
[8]=>
string(1) "4"
[9]=>
int(5)
}
Which is weird as "4" looks misplaced. For example in this:
We get different results (all I added was "d" to the end):
array(11) {
[0]=>
bool(false)
[1]=>
string(1) "4"
[2]=>
string(4) "TRUE"
[3]=>
string(1) "a"
[4]=>
string(1) "b"
[5]=>
string(1) "c"
[6]=>
string(1) "d"
[7]=>
string(4) "true"
[8]=>
bool(true)
[9]=>
int(4)
[10]=>
int(5)
}
Notice the different order, is this a genuine bug?
[2003-01-18 10:26:27] [EMAIL PROTECTED]
Today I closed bug #21444. The user has to master the type juggling to
know the expected output. I think that it is good idea to add it's
example as comprehensive one.
The script goes here (the explanation is after it) :
The output is :
array(10) {
[0]=>
bool(true)
[1]=>
int(4)
[2]=>
string(1) "4"
[3]=>
string(4) "TRUE"
[4]=>
string(1) "a"
[5]=>
string(1) "b"
[6]=>
string(1) "c"
[7]=>
string(1) "d"
[8]=>
string(4) "true"
[9]=>
int(5)
}
It may look strange - why (int)5 is after all the strings. This is
because "4" is lower than (int) 5, "4" is before "true" and "true" is
before 5. The first 2 are obvious, the third one is not. But it is ok.
It's better not to mix types in the array. If 5 is changed to "5" then
"5" goes right after "4".
Thanks
--
Edit this bug report at http://bugs.php.net/?id=21728&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #11940 [Opn->Csd]: ill side effect of open_basedir
ID: 11940 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Solaris 8/sparc PHP Version: 4.0.6 New Comment: This has been clarified in the docs: http://cvs.php.net/cvs.php/phpdoc/en/features/safe-mode.xml Thanks for the report :) Previous Comments: [2001-07-07 01:41:02] [EMAIL PROTECTED] Jason, thanks for the clarification. I apologize for persistence, but I'm re-opening the bug under the different category. There are two issues here now: 1. The documentation does not describe this configuration option clearly. It only talks about (quote) "When a script tries to open a file...". It should mention that the restriction applies to the script itself. The first sentence may imply this, but only very vaguely. http://www.php.net/manual/en/configuration.php 2. The error message logged by PHP is not helpful. It talks about opening file for inclusion, which actually is probably what let into confusion even you when you replied to this bug in the first place. Also, the words "Unknown" in both sentences of the error message are not very helpful, too. Thanks again, -- Arcady Genkin [2001-07-06 23:26:52] [EMAIL PROTECTED] Sorry, I wrote that in a hurry. ANY file open operation performed by php has to be in open_basedir. ( Including your main script. ) This is actually by design. -Jason [2001-07-06 18:25:15] [EMAIL PROTECTED] I may be missing something, but there is no include() or any other file-related operation in the sample script that I posted. All it has is 'echo "hello"'. [2001-07-06 17:43:40] [EMAIL PROTECTED] This is not a bug, include calls a file open operation, and as such must be in the open_basedir path -Jason [2001-07-06 17:36:45] [EMAIL PROTECTED] safe_mode = On doc_root = /homes/u0/apache open_basedir = "/var/www/htdocs/workathome:/var/www/secure:/var/www/tmp" (/var/www is a symlink for /homes/u0/apache) In such a setting I should be able to execute PHP scripts from any directory under /homes/u0/apache, but not access any files unless they are under one of the directories in open_basedir. However, I cannot place any scripts in, say, /homes/u0/apache/cdf/deadlines/. A minimal file foo.php, saved there, containing only: Hello"; ?> Results in the script not executed, with the following error messages: [Fri Jul 6 17:24:53 2001] [error] PHP Warning: open_basedir restriction in effect. File is in wrong directory in Unknown on line 0 [Fri Jul 6 17:24:53 2001] [error] PHP Warning: Failed opening '/homes/u0/apache/htdocs/cdf/deadlines/foo.php' for inclusion (include_path='') in Unknown on line 0 open_basedir's documentation says that it should only restrict directories from where a file can be opened by a PHP script. http://www.php.net/manual/en/configuration.php Many thanks, -- Arcady Genkin -- Edit this bug report at http://bugs.php.net/?id=11940&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #16000 [Opn]: fpassthru and timeouts
ID: 16000
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: 2000 Server
PHP Version: 4.1.2
New Comment:
Anyone have a clue on how or where to document this? All suggestions
and ideas welcome :)
It's related to:
Directive: max_execution_time
Function: set_time_limit
Docs: features.connection-handling
Stated is a default 300 second limit in IIS/CGI, do other web servers
and SAPI combinations have such issues?
Previous Comments:
[2002-05-08 03:48:27] [EMAIL PROTECTED]
> I did find the solution. In IIS there is a CGI timeout function
defaulted
> to 300 seconds. THIS MUST BE raised in order for slow dialups to
download
> large files. If it is not raised, IIS assumes that the script is done
or
> hung and kills it.
Made this to a doc problem.
[2002-05-03 23:33:38] [EMAIL PROTECTED]
Some browsers have hard coded timeout.
Try different browsers see if it helps.
[2002-03-11 11:28:34] [EMAIL PROTECTED]
There seems to be a timeout problems with using fpassthru.
Code :
header( "Content-type: application/octet-stream" );
header( "Content-Length: $c_ByteSize" );
header( "Content-Disposition: attachment; filename=\"$F\"" );
$fp = fopen("D:\\CarrierFTP_Files\\".odbc_result($result,
"FilePath").$F,"r") or die("Can't find file.");
fpassthru($fp);
When the person starts getting the file, after 5 min 2 sec it quits and
tells me it has finished.
I have increased timeouts everywhere, but it never gets the file.
Suggestions on this?
--
Edit this bug report at http://bugs.php.net/?id=16000&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #17180 [Ana->Csd]: Operator Precedence
ID: 17180 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type:Documentation problem PHP Version: 4.2.0 New Comment: This has now been documented: http://cvs.php.net/cvs.php/phpdoc/en/language/operators.xml Thanks for the report :) Previous Comments: [2002-05-16 13:27:03] [EMAIL PROTECTED] Marking this as a doc problem. [2002-05-14 13:46:58] [EMAIL PROTECTED] Actually this is a bug, since in PHP manual it's clearly stated that ! operator has a priority over = operator. > It makes no sense to assign anything to NOT(a variable), > so PHP takes care of that by > changing the precedence a little in this case. In other words - if user makes a mistake and writes illegal code, PHP takes care about that and makes this code work (but in a way different from what developer has expected). Also if you consider any other programming languages, if you write a code which should not compile by language specifications (like the above code in PHP), no compiler will try to "take care" of that. If you insist on that "care", then you definetely have to reflect that in the manual, otherwise it's nothing but a bug. [2002-05-13 18:30:31] [EMAIL PROTECTED] This behaviour is capable to confuse the developer and if this is "features" it must be documented in manual. [2002-05-13 18:20:14] [EMAIL PROTECTED] Well, but it's stupid to do something like that. It makes no sense to assign anything to NOT(a variable), so PHP takes care of that by changing the precedence a little in this case. [2002-05-13 17:56:54] [EMAIL PROTECTED] Yes, I want ASSIGN value to $a and check assigned value. But parser must say: "parser error", becouse it can not assign value to constant. Please reopen. 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/17180 -- Edit this bug report at http://bugs.php.net/?id=17180&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #16745 [Opn->Csd]: HTTP_Compress should auto detect if output_handler = ob_gzhandler is in php.ini
ID: 16745 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: mdk 8.1 smp PHP Version: 4.2.0 New Comment: Documentation at ob_gzhandler() has been updated to reflect some of this behavior: http://cvs.php.net/cvs.php/phpdoc/en/reference/outcontrol/functions/ob-gzhandler.xml Now the PEAR docs may need some updating although I don't think this class exists anymore, at least I can't find it in CVS. I'm closing this bug. Previous Comments: [2002-09-30 22:19:24] [EMAIL PROTECTED] Make this a documentaion problem. We need to document users are responsible for buffer usage. Including buffer dependecy/confulict, etc. Detecting error could be too expensive when there are many buffers. Users can shoot themselves with their buffer, etc. [2002-05-03 23:37:45] [EMAIL PROTECTED] We can check if zlib.output compression is on or off. (zlib.output compressioin buffer is nest level 2) Use of ob_gzhandler is not recommended, but this should be fixed. [2002-04-23 09:42:32] [EMAIL PROTECTED] We really need to make ob_gzhandler and PEAR HTTP_Compress a obsolete feature. To reporter: use zlib.output_compression if you need compression... [2002-04-23 07:46:33] [EMAIL PROTECTED] Reclassified. [2002-04-23 05:51:07] [EMAIL PROTECTED] I was using chora 1.0 and cvs versions (2.0) and had this bizarre mem leak under either php4.2.0rc4 or php4.2.0 final. It would show up in the apache logs as Last leak repeated 2 times ./zend_execute.c(1999) : Freeing 0x0825CE0C (12 bytes), script=/www/sj/horde/chora/cvs.php Last leak repeated 2 times zend_operators.c(1047) : Freeing 0x081EFCBC (31 bytes), script=/www/sj/horde/chora/cvs.php Last leak repeated 1 time zend_API.c(596) : Freeing 0x081EF56C (44 bytes), script=/www/sj/horde/chora/cvs.php zend_API.c(584) : Actual location (location was relayed) zend_compile.c(1647) : Freeing 0x0817CB6C (12 bytes), script=/www/sj/horde/chora/cvs.php etc, etc. I tried numerous compilations, etc. but in the end it turned out to be the fact that in my php.ini, I have output_handler = ob_gzhandler and chora would try to use the PEAR class to compress it again. I was able to turn that feature off within chora, but it was a bitch to track down, and odd how it would only show up in 4.2.0, but not in 4.1.2 even with the same ./configure setup. It was suggested by a few that I report my findings, so I hope this helps. Perhaps the PEAR class could autodetect if gzip is already in use? Keep up the great work as always! PS. Just in case it helps somehow, here is my bitchin' configure line : './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-config-file-path=/usr/local/apache/conf' '--enable-inline-optimization' '--with-pgsql' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-ftp' '--with-zlib' '--with-zlib-dir=/usr/local/lib' '--with-gdbm' '--with-gd' '--with-jpeg-dir=/usr/local/lib' '--with-png-dir=/usr/local/lib' '--with-tiff-dir=/usr/local/lib' '--with-freetype-dir=/usr/local/lib' '--with-swf=/usr/local/lib' '--with-pdflib=/usr/local' '--with-curl' '--with-xml' '--with-mcrypt' '--with-gettext' '--with-pspell' '--with-mm=/usr/local/lib' '--enable-debug' I tried with and without --enable-inline-optimization and with and without --with-mm. Send me an email if you need any more info, glad to be of help. Take care. -- Edit this bug report at http://bugs.php.net/?id=16745&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
