[PHP-DOC] #37543 [Opn]: xml_set_character_data_handler documentation
ID: 37543 Updated by: [EMAIL PROTECTED] Reported By: mpalmer at usa dot com Status: Open -Bug Type: Website problem +Bug Type: Documentation problem Operating System: irrelevant PHP Version: Irrelevant New Comment: Documentation problem. Previous Comments: [2006-05-21 16:16:12] mpalmer at usa dot com Description: XML documentation for xml_set_character_data_handler nowhere says when the event handler callback is invoked. I am left guessing. Maybe I can look at the examples and run some tests, but, come on, guys, any decent event specification explains when or what triggers the event. Thanks. -- Edit this bug report at http://bugs.php.net/?id=37543&edit=1
[PHP-DOC] #36645 [Opn]: Information error
ID: 36645 Updated by: [EMAIL PROTECTED] Reported By: rubens_ss at yahoo dot com dot br Status: Open -Bug Type: Website problem +Bug Type: Documentation problem Operating System: irrelevant PHP Version: Irrelevant New Comment: Documentation problem then. Previous Comments: [2006-03-07 15:02:59] rubens_ss at yahoo dot com dot br Description: in http://www.php.net/manual/pt_BR/ref.zip.php in Installation: "You may download this PECL extension DLL from the PHP Downloads" But in Windows Binaries in the downloads page, the extension php_zip.dll no exists! I do not find this DLL. -- Edit this bug report at http://bugs.php.net/?id=36645&edit=1
[PHP-DOC] #36448 [Opn->Fbk]: Meaningless tag in docs
ID: 36448 Updated by: [EMAIL PROTECTED] Reported By: gareth dot adams at gmail dot com -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: Quoting from the HTML spec: --- The ABBR and ACRONYM elements allow authors to clearly indicate occurrences of abbreviations and acronyms. [...] Marking up these constructs provides useful information to user agents and tools such as spell checkers, speech synthesizers, translation systems and search-engine indexers. [...] The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression. --- It is clear from this text, that the title attribute is not required, and it is quite useful to mark up such content with the acronym tag regardless. Previous Comments: [2006-02-18 21:13:22] gareth dot adams at gmail dot com Description: The introduction to PHP page on the website contains an tag with no title attribute, thereby making it useless as an acronym tag. >From http://php.net/manual/en/introduction.php What is PHP? PHP (recursive ... I'm pretty sure the master manual is not stored in HTML format, so either this is a simple mistake in the documentation or a problem with the HTML converter I think the problem was pointed out at http://bugs.php.net/bug.php?id=10498 but marked bogus due to a bad description -- Edit this bug report at http://bugs.php.net/?id=36448&edit=1
[PHP-DOC] #35989 [Opn]: Page missing
ID: 35989 Updated by: [EMAIL PROTECTED] Reported By: th at domainbox dot de Status: Open -Bug Type: Website problem +Bug Type: Documentation problem Operating System: Windows XP PHP Version: Irrelevant New Comment: Docproblem. Previous Comments: [2006-01-13 09:31:53] th at domainbox dot de Description: The Page http://www.php.net/manual/de/function.ini-set.php refers to a List of changeable Values in the Appendix, but this Page is missing for some Weeks. Instead the Link points to http://www.php.net/manual/de/missing-stuff.php#ini.list The Englisch Version http://www.php.net/manual/en/function.ini-set.php links correct to http://www.php.net/manual/en/ini.php#ini.list -- Edit this bug report at http://bugs.php.net/?id=35989&edit=1
[PHP-DOC] #35947 [Opn]: PHP insists on being on being UTF-8 when it isn't!
ID: 35947 Updated by: [EMAIL PROTECTED] Reported By: php at mytrashmail dot com Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: The php site remembers the last language you have used. Otherwsie it would be a pain to get to manual pages without the handy shortcuts. Once you switch to English, you are going to get English pages. See php.net/my for details and settings. Previous Comments: [2006-01-09 18:47:00] php at mytrashmail dot com If you keep your contents in MySQL, all you have to do is export the files, encode them to UTF-8 and re-import them. And how come I don't see Hebrew anymore after being re-directed? [2006-01-09 18:23:10] [EMAIL PROTECTED] The hebrew translation doesn't build for years now, so we can't update it to use UTF8. When the hebrew team fixes this the problem will be gone. [2006-01-09 17:28:03] php at mytrashmail dot com Hebrew - and I'm not trying to view it on purpose. It's your site that forces me to see everything that has a Hebrew version in Hebrew (by redirecting me il.php.net). Hmm, strangely currently the pages in il.php.net are all in English. Did you do something? [2006-01-09 16:39:50] [EMAIL PROTECTED] What language are you trying to view? We are supposed to actually use UTF-8 for all languages. [2006-01-09 16:32:04] php at mytrashmail dot com I assume there aren't a lot of complaints about it as obviously it doesn't effect English users. Even in fake UTF-8 mode, they still see English letters. 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/35947 -- Edit this bug report at http://bugs.php.net/?id=35947&edit=1
[PHP-DOC] #35477 [Opn]: typo on "if" page
ID: 35477 Updated by: [EMAIL PROTECTED] Reported By: nkoch at rcn dot com Status: Open -Bug Type: Website problem +Bug Type: Documentation problem Operating System: Windows 98 PHP Version: Irrelevant New Comment: Docproblem. Previous Comments: [2005-11-29 17:33:34] nkoch at rcn dot com Description: On this web page http://us3.php.net/if you have a small typo. The word "of" should be "or" in this sentence: A statement can be an assignment, a function call, a loop, a conditional statement *of* even a statement that does nothing (an empty statement). I am planning to send my students to that page. Unfortunately the "of" makes grammatical sense so that it changes the meaning of the sentence. -- Edit this bug report at http://bugs.php.net/?id=35477&edit=1
[PHP-DOC] #35299 [Bgs]: Missing tags in ref.pcre.html
ID: 35299 Updated by: [EMAIL PROTECTED] Reported By: leonard-php-bugzilla at ottolander dot nl Status: Bogus Bug Type: Documentation problem Operating System: irrelevant PHP Version: Irrelevant New Comment: And Leonard, you will probably also find out that generating your files from the XML sources of the documentation is a much better idea, as it done by the phpedit.net team for example. Look at: http://www.waterproof.fr/products/PHPEdit/download.php (PHP Functions definition files maker) It works from our XML sources. Previous Comments: [2005-11-20 01:47:31] [EMAIL PROTECTED] Of course your help would be appreciated. Read here: http://www.php.net/manual/en/about.howtohelp.php and here http://doc.php.net/php/dochowto/ about that. Yes, I guess it'd be good to have all the docs consistent, so feel free to send your patches to the phpdoc@lists.php.net mailing list. [2005-11-20 01:36:03] leonard-php-bugzilla at ottolander dot nl Well, it would be convenient for such purposes as I described. Indeed I see more inconsistencies: ref.tidy.html is ugly as it tags some pseudo constants but not most of the real ones. What's the use of the tag in some pages if it's not used consistently and you don't even want to make an effort to implement this consistently? Who maintains these documentation pages anyway? Can I help? Maybe the consistent use of these tags should be promoted? [2005-11-20 01:24:34] [EMAIL PROTECTED] >From what I can see, there are lots of constants that are documented in such way. Look for example at http://www.php.net/manual/en/ref.mysql.php and http://www.php.net/manual/en/ref.network.php . I agree, this is a small incosistency, but this is definitely not a bug, since noone and nowhere told you that all constants will be enclosed with tag. [2005-11-20 01:04:02] leonard-php-bugzilla at ottolander dot nl In table 1 in http://www.php.net/manual/en/ref.pcre.php all the constants in the left column miss these tags. Only the constant mentioned in the right column of the third row is properly tagged. You can compare other pages as well if you need to. [2005-11-20 00:47:29] [EMAIL PROTECTED] Which exactly are missing ? 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/35299 -- Edit this bug report at http://bugs.php.net/?id=35299&edit=1
[PHP-DOC] #21970 [Asn]: Creating a new Tutorial section
ID: 21970 Updated by: [EMAIL PROTECTED] Reported By: philip at cornado dot com Status: Assigned Bug Type: Documentation problem Operating System: all PHP Version: Irrelevant Assigned To: aidan New Comment: Newbies don't use the manual for just reference purposes, it is quite on the contrary. Previous Comments: [2005-09-09 11:59:09] [EMAIL PROTECTED] >- techniques.patterns >PHP 4 / 5 singleton + factory patterns Before you'll do such an evil thing consider writing an article "patterns misusing borders". There was once a good article about that on phppatterns, but the site seems to be closed. And consider new chapters like "Debugging PHP" and "Debugging Patterns" first. My IMHO, but before patterns one should use project planning tools like rationale to avoid his mind wasting time doing coding for coding. Also consider alternative chapter "Framework approach" with OO, function-like and pattern-built framework problems overview. I know this is complicated, but these are questions every developer is interested in - not about what is patterns and how they cool. Patterns are good in reversed languages like Java and mostly for complex projects with complicated structure (observers). Without project planning and product development methodologies patterns are not maintanable. >- techniques.magic-quotes >Info moved and aggregated from the security / faq > >- techniques.register-globals >Info moved and aggregated from the security / faq No. Security features should be in securty section. Users should not read through all PHP manual and especially through patterns just to figure out how to secure their server. >* All the material in the features section will be >incorporated into the techniques section. I think there is clear distinction from "language feature" and "techniques of using language feature" + Using PHP in... ...scripting (command line) ...scripting (application) ...integration (Java) ...integration (.NET) ...platform independent/dependent ...interfaces (smarty, GTK, plugins) ...enterprise ...PHP bussiness dictionary (like what is thin client, multitier arch and so on - the basics everybody is speaking about, but nobody wants to explain in common words) Well, seems like all this info is subject to separate documentation pack - it can contain a lot of info and clutter search results for those newbies, who use PHP manual solely as reference to functions and PHP bugs. [2005-09-09 09:33:27] [EMAIL PROTECTED] Hmm, forgot about this in my last reply, but if we're adding "common techniques" and such we should add a techniques.design.pagination, as it's something extremely common that I see a lot of new programmers asking about. [2005-09-09 09:27:40] [EMAIL PROTECTED] Certainly techniques.patterns should be techniques.design.patterns? [2005-09-09 08:28:49] [EMAIL PROTECTED] Summarising the feedback, * I think we've agreed "techniques" is the way to go in terms of naming the new section. * I think getting-started will stay where it is. * The new techniques section will be placed after the security section. * All the material in the features section will be incorporated into the techniques section. And the following new sections will be created, - techniques.include-path See philip's original post. Also, I notice a lot of questions regarding include_paths in included files, where the include path is relative to, getcwd, etc. This would make a nice addition to the include-path section. - techniques.patterns PHP 4 / 5 singleton + factory patterns - techniques.magic-quotes Info moved and aggregated from the security / faq - techniques.register-globals Info moved and aggregated from the security / faq - techniques.command-line All the information about running PHP from the CLI ?- techniques.databasing general good database practices (also moved from security section) So far I think everyone has agreed on these. The ones we're not too sure about being the tutorial-type sections. Perhaps these could be placed in a subsection of techniques called "design". - techniques.design.black-box Detailing the foo.php?page=contact design [2005-01-25 07:44:08] [EMAIL PROTECTED] Somewhere down the line this bug report got renamed so be sure it's not closed until include_path is properly (extensively) documented. Not everything belongs in a tutorial...I agree with Goba on all points. --
[PHP-DOC] #34363 [Opn]: Possibly wrong description of a function
ID: 34363 Updated by: [EMAIL PROTECTED] Reported By: invisible at hidden-city dot net Status: Open -Bug Type: Website problem +Bug Type: Documentation problem Operating System: irrelevant PHP Version: Irrelevant New Comment: Doc problem. Previous Comments: [2005-09-04 01:42:48] invisible at hidden-city dot net Description: on the http://www.php.net/array_reduce under example it is written: "$c containing 1200 (= 1*2*3*4*5*10)," but since the "If the optional initial is available, it will be used at the beginning of the process," the process of getting the value of $c is (10*1*2*3*4*5). The result is the same, but I think it should be changed so that the explanation starts with the 10*1*2... -- Edit this bug report at http://bugs.php.net/?id=34363&edit=1
[PHP-DOC] #32012 [Opn]: Request for revisiting your online manual
ID: 32012 Updated by: [EMAIL PROTECTED] Reported By: soletan at toxa dot de Status: Open -Bug Type: Website problem +Bug Type: Documentation problem Operating System: WinXP PHP Version: 5.0.3 New Comment: This is indeed a doc (or livedocs) problem, since the rendering code lives there. DSSSL could be fixed to do this, and Livedocs definitely should be. Previous Comments: [2005-08-13 21:14:06] [EMAIL PROTECTED] Myabe its a a good idea to add anchor links to install intructions, functions list, etc.. [2005-02-17 17:48:30] soletan at toxa dot de Description: Hi, I'm using your online manual as reference while coding each and every day. I prefer to use that over any book or similar since I consider it to be always most uptodate over those. Furthermore user notes are quite helpful very often. BUT: Again and again I don't see any sense in having such huge front page on each extension. Did you ever try to find the list of supported methods on Multibyte String Extension's front page? While looking for that I'm neither interested in information how to install that extension, how to configure transparent IO-encoding or on what each charset is about to be. Even "moving to bottom of page" doesn't satisfy as there might be lots of user notes with further suggestions on how to install here, configure there etc. Of course, ALL these information are worth to be available, but why couldn't you have some subpages since they become more and more complex with each new release of PHP. And normally users stop installing some day and even configuration is done, right before the developer starts to use your manual as a reference for daily work. Sometimes I simply can't remember what was the name of a single function or what options I have to do this or that using single selection. So using shorthand access using URL is no good tool just like searching whole PHP's function list. Well, simplest adjustment would be to have a page menu on top to click for the function list (as well as installation notes, list of defined constants, user notes, etc.). This would avoid getting more files in PHP manual folder. -- Edit this bug report at http://bugs.php.net/?id=32012&edit=1
[PHP-DOC] #33945 [Opn->Bgs]: error in .chm file ciompiling
ID: 33945 Updated by: [EMAIL PROTECTED] Reported By: huszti dot roland at freemail dot hu -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: .chm file PHP Version: Irrelevant New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. This was reported countless times before Previous Comments: [2005-08-01 14:41:09] huszti dot roland at freemail dot hu Description: Hi! The latest Hungarian PHP documentation .html files had been compiled absolutelly badly into .chm file. It is absolutely unuseful, because a permanent error. It says: 'H:/phpdoc/hu/html' is missing. Expected result: Correct work. Actual result: -- 'H:/phpdoc/hu/html' is missing. -- Edit this bug report at http://bugs.php.net/?id=33945&edit=1
[PHP-DOC] #33834 [Opn]: docs.php.net, search feature is not working fine.
ID: 33834 Updated by: [EMAIL PROTECTED] Reported By: sanjeev at adari dot net Status: Open -Bug Type: Website problem +Bug Type: Livedocs problem Operating System: Linux PHP Version: Irrelevant New Comment: docs.php.net is not intended to be viewed by end users, it is just a test machine for a new rendering engine. This is a livedocs (deployment) problem. Previous Comments: [2005-07-23 08:13:58] sanjeev at adari dot net Description: After I enter some words in the search box and press enter.. I was directed to http://docs.php.net/search.php and this has just a white page with a search box, strict check box abd search button. when i again use this search box and click on search, i get these messages: Warning: sqlite_exec() [function.sqlite-exec]: cannot attach empty database: sc in /local/Web/sites/livedocs/search.php on line 34 Warning: sqlite_array_query() [function.sqlite-array-query]: no such table: search_cache in /local/Web/sites/livedocs/search.php on line 36 Warning: sqlite_exec() [function.sqlite-exec]: no such table: search_cache in /local/Web/sites/livedocs/search.php on line 40 Warning: sqlite_exec() [function.sqlite-exec]: no such table: cache_data in /local/Web/sites/livedocs/search.php on line 44 Warning: sqlite_single_query() [function.sqlite-single-query]: no such table: cache_data in /local/Web/sites/livedocs/search.php on line 46 Strict: No Results Found -- Edit this bug report at http://bugs.php.net/?id=33834&edit=1
[PHP-DOC] #33810 [Opn->Bgs]: Documentation structure change
ID: 33810 Updated by: [EMAIL PROTECTED] Reported By: php at karsites dot net -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Linux PHP Version: Irrelevant New Comment: Most of the PHP users have some provider having a custom PHP setup with some additional extensions given and some configuration options tightened. It is important for our manual to be general, so that you don't need to think like: "ok, my provider has this extension, is it core or not?" We are aware of this issue, and have an extension categorization item on our todo list, as well as an item to allow people to download customized manuals for their own needs, so we are not putting our heads in the sand, it is just that there is no such thing as core PHP, since the different hosting providers configure it differently. Previous Comments: [2005-07-21 20:31:43] php at karsites dot net Description: It it possible to split the PHP function reference into 'core' extensions, and 'external' extensions. including those in PECL? I think this would make it alot easier for people to identify the functions that are part of th core PHP language - ie built-in to PHP directly. Keith Roberts -- Edit this bug report at http://bugs.php.net/?id=33810&edit=1
[PHP-DOC] #33553 [Opn]: get_html_translation_table() ambiguous
ID: 33553
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.3.10
New Comment:
Sorry, I mean single quote, as it is evidenced by the lxr link I
provided.
Previous Comments:
[2005-07-03 17:15:31] [EMAIL PROTECTED]
You surely mean slash here, and not ampersand? Anyway, this is not a
PHP bug but a documentation issue.
[2005-07-03 17:09:54] [EMAIL PROTECTED]
Description:
get_html_translation_table() returns an array with two keys having
value "'" (the ampersand). When array_flip()-ed, as suggested by the
manual, the second one overwrites the first, thus giving a reverse
table with only one ampersand key. Using this reverse table to convert
back a string is not possible, since the original table had the other
representation of the ampersand first, and used that for translation.
See http://lxr.php.net/source/php-src/ext/standard/html.c#466
Note that if this is not deemed to be a PHP bug, then this
irreversibility issue should be documented.
Reproduce code:
---
var_dump(htmlspecialchars("'", ENT_QUOTES));
var_dump(get_html_translation_table(HTML_SPECIALCHARS, ENT_QUOTES));
var_dump(array_flip(get_html_translation_table(HTML_SPECIALCHARS,
ENT_QUOTES)));
Expected result:
No ambigous array elements in the translation table.
Actual result:
--
Two entries for the ampersand.
--
Edit this bug report at http://bugs.php.net/?id=33553&edit=1
[PHP-DOC] #33029 [Opn]: Bug in translation of constructor example
ID: 33029
Updated by: [EMAIL PROTECTED]
Reported By: aiv at intertop dot pl
Status: Open
-Bug Type: Website problem
+Bug Type: Documentation problem
Operating System: N/A
PHP Version: Irrelevant
New Comment:
This is a Polish documentation problem
Previous Comments:
[2005-05-13 21:32:07] aiv at intertop dot pl
Description:
http://www.php.net/manual/pl/language.oop.php
You have to change Cart() in second example to Koszyk() becouse is not
working exmaple of constructor
Reproduce code:
---
class Koszyk
{
var $dzisiejsza_data;
var $nazwa;
var $wlasciciel;
var $artykuly;
function Cart()
{
$this->dzisiejsza_data = date("Y-m-d");
$this->nazwa = $GLOBALS['imie'];
/* itp. . . */
}
}
Expected result:
class Koszyk
{
var $dzisiejsza_data;
var $nazwa;
var $wlasciciel;
var $artykuly;
function Koszyk()
{
$this->dzisiejsza_data = date("Y-m-d");
$this->nazwa = $GLOBALS['imie'];
/* itp. . . */
}
}
--
Edit this bug report at http://bugs.php.net/?id=33029&edit=1
[PHP-DOC] #32779 [Bgs->Opn]: language error in online documentation
ID: 32779 Updated by: [EMAIL PROTECTED] Reported By: josh at luminsphere dot com -Status: Bogus +Status: Open -Bug Type: Documentation problem +Bug Type: Livedocs problem Operating System: XP PHP Version: Irrelevant New Comment: This is probably worth keeping as a livedocs bug. Keeping in mind that docs.php.net is not intended for endusers - it might be a task to point out this in the generated header or something. Previous Comments: [2005-04-20 19:42:28] [EMAIL PROTECTED] While that's technically true, http://docs.php.net/ isn't yet (to my knowledge) officially supported -- it's a livedocs test install. If this were happening to the "real" manual (at www.php.net), then please, by all means, complain. S [2005-04-20 19:38:32] josh at luminsphere dot com Description: The mysql_query page on the online documentation does not show up in english... All other links show english properly. The URL is http://docs.php.net/en/function.mysql-query.html -- Edit this bug report at http://bugs.php.net/?id=32779&edit=1
[PHP-DOC] #31902 [Opn->Bgs]: #27563 us4 using phonetics on redirect
ID: 31902 Updated by: [EMAIL PROTECTED] Reported By: ceo at l-i-e dot com -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: The mirrors using phonetic search are utilizing the sqlite lookup database, which is faster to work with then the file based lookups (which are used by mirrors without this phonetic search feature). Now if we would disable the mirrors using the file based lookups, we would end up with really few mirrors. This will only get more consistent over time. Previous Comments: [2005-02-09 16:53:09] ceo at -l-i-e dot com Doh! The "Add Comment" tab is missing from: http://bugs.php.net/bug.php?id=27563&edit=2 I got there from being about to submit a bug report, then you guys show me the other report, so I go check it out in a new window, and, sure enough, it's the same bug, but then I can't add a comment to help you out, so I submit a NEW bug report (sorry) and then find out there *IS* an "Add Comment" tab, only sometimes. :-) [2005-02-09 16:49:42] ceo at l-i-e dot com Description: Some additional data points and a hypothesis. I would have added this to a comment on: http://bugs.php.net/bug.php?id=27563 had the facility to do so been provided... Reproduce code: --- http://us4.php.net/sysv -> sizeof http://us2.php.net/sysv -> search page Presumably a phonetic lookup is involved on us4, then. Tried it with sysov and got the same thing. Expected result: What I WANTED was to end up searching for that SYS V Shared Memory stuff. I'm thinking the phonetic thing is maybe a bit "too much" especially as I have to go to the search popup and change to "whole site" to get to what I want, which might not be obvious to a frustrated user who keeps putting in "sysv" and keeps ending up on the "sizeof" page... Either way, us2 and us4 should be "the same", no? -- Edit this bug report at http://bugs.php.net/?id=31902&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: 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! Previous Comments: [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! [2005-01-22 21:39:05] [EMAIL PROTECTED] s/info moved from/info copied from/ We should not move anything from other sections that currently have a "home" just because a new tutorial is being added. Eg, the things in the security section need to stay there. We can either reiterate the points mentioned, or link to the chapters containing the information. [2005-01-22 13:57:53] aj_gemmell at yahoo dot com I suggest features.safe-mode should also be added to this (how it works, what it does [,when you should use it]) --GwaiLo 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] #31497 [Opn]: "Variable functions" term ambiguous
ID: 31497 Updated by: [EMAIL PROTECTED] Reported By: php dot devel at homelinkcs dot com Status: Open Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: I also had problems with the suggested meaning, that is behind the "variable functions" title, so it would be nice to fix, indeed. Previous Comments: [2005-01-11 21:34:36] php dot devel at homelinkcs dot com Description: Since it's a complex problem, I would like to stir up some discussion about the best way to solve the ambiguity of terms between "variable functions" (i.e. a function call in which the name of the function is contained in a varable: http://www.php.net/manual/en/functions.variable-functions.php) and "variable functions" (i.e. built-in functions for handling varables: http://www.php.net/manual/en/ref.var.php). In my learning and use of PHP, I have repeatedly encountered this term in both senses, requiring me to seek clarification of its meaning in contexts that are ambiguous. Therefore, I was wondering if it would be possible to change one of the terms. My suggestion would be to change the second sense to "variable handling functions" or something of a similar nature. Such a solution would preserve the analogue between "variable variables" and "variable functions" (in the first sense) and is also somewhat backwards-compatable. But I would like to know what others think. Any thoughts, suggestions on this issue? Anyone else had problems with it? If a conclusion can be reached, I'd be willing to do some, if not all, of the work to update the documentation. -- Edit this bug report at http://bugs.php.net/?id=31497&edit=1
[PHP-DOC] #31450 [Opn]: http://de3.php.net/manual/de/build.log.gz not found
ID: 31450 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Mac OS X PHP Version: Irrelevant New Comment: The build logs are not available for quite some time now. Derick? Previous Comments: [2005-01-08 11:37:38] [EMAIL PROTECTED] Description: http://de.php.net/manual/howto/translation-practical.html states that build.log.gz should be available at "http://www.php.net/de/blog";. This resolves to http://de3.php.net/manual/de/build.log.gz and gives a HTTP 404 Error. Might as well be a PHP.net website problem... -- Edit this bug report at http://bugs.php.net/?id=31450&edit=1
[PHP-DOC] #30035 [Opn->Csd]: php.net/instanceof leads nowhere
ID: 30035 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 5.0.1 New Comment: Alias added. Previous Comments: [2004-12-30 19:30:07] [EMAIL PROTECTED] What about other names operators? I know they have quite common names like 'and' and 'or' :) [2004-12-30 16:43:54] [EMAIL PROTECTED] instanceof is found at http://www.php.net/manual/en/language.operators.type.php This will never be catched by find_manual_page_slow(). A possible solution could be a shortcut in error.php like: $ cvs diff error.php Index: error.php === RCS file: /repository/phpweb/error.php,v retrieving revision 1.29 diff -u -r1.29 error.php --- error.php 27 Nov 2004 16:49:41 - 1.29 +++ error.php 30 Dec 2004 15:42:34 - @@ -225,6 +225,7 @@ "magicquotes" => "security.magicquotes", "gd" => "image", +"instanceof=> "language.operators.type", "htaccess" => "configuration.changes", "php_value"=> "configuration.changes", Regards Friedhelm [2004-12-30 13:14:56] [EMAIL PROTECTED] http://php.net/something is not only for function lookups, there are quite a few shortcuts, like http://php.net/getphp or http://php.net/whatisphp or http://php.net/install and even http://php.net/pear Look into find_manual_page_slow() in http://php.net/source.php?url=/include/manual-lookup.inc to get an idea of how manual pages are looked up. Reference sections, control structures and other stuff are also matched. If the manual page has a proper ID, then it should end up being found by such a php.net lookup. [2004-12-30 10:59:38] [EMAIL PROTECTED] But instanceof is a bitdifferent, as we don't have those hardcoded redirects for any of our control keywords AFAIK. [2004-12-29 23:30:00] [EMAIL PROTECTED] Not possible that it only relies on functions. I made a similiar request about http://php.net/php5 and at was promptly done by Derick. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/30035 -- Edit this bug report at http://bugs.php.net/?id=30035&edit=1
[PHP-DOC] #30035 [Opn]: php.net/instanceof leads nowhere
ID: 30035 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type:Documentation problem PHP Version: 5.0.1 New Comment: What about other names operators? I know they have quite common names like 'and' and 'or' :) Previous Comments: [2004-12-30 16:43:54] [EMAIL PROTECTED] instanceof is found at http://www.php.net/manual/en/language.operators.type.php This will never be catched by find_manual_page_slow(). A possible solution could be a shortcut in error.php like: $ cvs diff error.php Index: error.php === RCS file: /repository/phpweb/error.php,v retrieving revision 1.29 diff -u -r1.29 error.php --- error.php 27 Nov 2004 16:49:41 - 1.29 +++ error.php 30 Dec 2004 15:42:34 - @@ -225,6 +225,7 @@ "magicquotes" => "security.magicquotes", "gd" => "image", +"instanceof=> "language.operators.type", "htaccess" => "configuration.changes", "php_value"=> "configuration.changes", Regards Friedhelm [2004-12-30 13:14:56] [EMAIL PROTECTED] http://php.net/something is not only for function lookups, there are quite a few shortcuts, like http://php.net/getphp or http://php.net/whatisphp or http://php.net/install and even http://php.net/pear Look into find_manual_page_slow() in http://php.net/source.php?url=/include/manual-lookup.inc to get an idea of how manual pages are looked up. Reference sections, control structures and other stuff are also matched. If the manual page has a proper ID, then it should end up being found by such a php.net lookup. [2004-12-30 10:59:38] [EMAIL PROTECTED] But instanceof is a bitdifferent, as we don't have those hardcoded redirects for any of our control keywords AFAIK. [2004-12-29 23:30:00] [EMAIL PROTECTED] Not possible that it only relies on functions. I made a similiar request about http://php.net/php5 and at was promptly done by Derick. [2004-12-29 22:50:01] [EMAIL PROTECTED] actually doesn't the /whatever only reference functions? as instanceof isn't a function it wont be referenced by that. I'm not too sure why the google search isn't picking it up though 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/30035 -- Edit this bug report at http://bugs.php.net/?id=30035&edit=1
[PHP-DOC] #30035 [Opn]: php.net/instanceof leads nowhere
ID: 30035 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type:Documentation problem PHP Version: 5.0.1 New Comment: http://php.net/something is not only for function lookups, there are quite a few shortcuts, like http://php.net/getphp or http://php.net/whatisphp or http://php.net/install and even http://php.net/pear Look into find_manual_page_slow() in http://php.net/source.php?url=/include/manual-lookup.inc to get an idea of how manual pages are looked up. Reference sections, control structures and other stuff are also matched. If the manual page has a proper ID, then it should end up being found by such a php.net lookup. Previous Comments: [2004-12-30 10:59:38] [EMAIL PROTECTED] But instanceof is a bitdifferent, as we don't have those hardcoded redirects for any of our control keywords AFAIK. [2004-12-29 23:30:00] [EMAIL PROTECTED] Not possible that it only relies on functions. I made a similiar request about http://php.net/php5 and at was promptly done by Derick. [2004-12-29 22:50:01] [EMAIL PROTECTED] actually doesn't the /whatever only reference functions? as instanceof isn't a function it wont be referenced by that. I'm not too sure why the google search isn't picking it up though [2004-12-29 22:46:42] [EMAIL PROTECTED] Ah, I understand what you mean now. Not sure whether possible for me to fix this, so I'll flag it up as verified for now [2004-12-29 22:35:09] [EMAIL PROTECTED] Go to http://php.net/instanceof , it should bring you to http://www.php.net/manual/en/language.operators.type.php or at least should show the page in the search result. 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/30035 -- Edit this bug report at http://bugs.php.net/?id=30035&edit=1
[PHP-DOC] #31008 [Opn]: Possible bug in the example code
ID: 31008
Updated by: [EMAIL PROTECTED]
Reported By: afjoijojifaj9foobar dot 5 dot rdancer at spamgourme
Status: Open
-Bug Type:Website problem
+Bug Type:Documentation problem
PHP Version: Irrelevant
New Comment:
Docproblem.
Previous Comments:
[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] #30947 [Opn->Fbk]: http://php.net/lists.php
ID: 30947 Updated by: [EMAIL PROTECTED] Reported By: ceo at l-i-e dot com -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: php.net PHP Version: Irrelevant New Comment: I see the function search page popping up for that address. I cannot reproduce your problem... Previous Comments: [2004-11-30 22:37:01] ceo at l-i-e dot com Description: http://php.net/lists.php yeilds: This is probably not intended behaviour. Once upon a time the mailing lists page was at that URL, which might be relevant... Probably not, as we are talking 3.0RC2 days, I believe :-) Expected result: I guess the function search page thingie where you go when you mis-type a function name. Or maybe a 404 page of some kind. Or, I dunno, the mailing lists page would have been nice. Actual result: -- -- Edit this bug report at http://bugs.php.net/?id=30947&edit=1
[PHP-DOC] #30537 [Csd]: Predefined Constants Missing Magic constants
ID: 30537 Updated by: [EMAIL PROTECTED] Reported By: ammar at gnuix dot com Status: Closed Bug Type: Documentation problem Operating System: * PHP Version: Irrelevant New Comment: Philip, feel free to touch the file, modify as you see fit. If you need translateable text in it, use snippets (entities). If some text is not applicable to go to an entity, then we need to discuss this a bit further. Previous Comments: [2004-10-29 20:34:38] [EMAIL PROTECTED] The file reserved.constants contains only entities and no translatable text. I believe it's the only reason to not copy this file to other language versions (to let compiler fall to English). [2004-10-29 19:51:00] [EMAIL PROTECTED] The issue of translation has not been resolved. [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. 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/30537 -- Edit this bug report at http://bugs.php.net/?id=30537&edit=1
[PHP-DOC] #22264 [Bgs]: Posting notes to the manual
ID: 22264 Updated by: [EMAIL PROTECTED] Reported By: wyvern at greywyvern dot com Status: Bogus Bug Type: Documentation problem Operating System: XP PHP Version: 4.3.1 New Comment: jmmolina: we check whether lines are wrappable, because people *hate* to scroll horizontally. If your user note is not wrappable, then it will not get accepted. Too long commands without whitespace are not readable anyway. Previous Comments: [2004-10-22 19:28:26] jmmolina at free dot fr I tried to post a note and got the following error message : « Your note contains a bit of text that will result in a line that is too long, even after using wordwrap(). » It seems the note I tried to post contains too long lines. It both contains text and a PHP script. You can get the note at http://jmmolina.free.fr/t_29327 I don't understand why the note system uses the wordwrap function. You need to word wrap text in a text based environment, not in a browser. The browser itself word wraps the text it displays. So does the wordwrap function apply to the text or the script ? At least the error message should be updated to help users to correctly format their notes. Better the noting system should be able to reformat the code without displaying this error message. [2003-02-18 06:23:00] [EMAIL PROTECTED] PHP has that cool string concatenation feature, don't you know? ;) $regexp = "/\\w" . "+" . "$/"; [2003-02-18 00:23:53] wyvern at greywyvern dot com The wordwrap thingy when you try to post notes to the manual SUCKS! I'm trying to post a LONG regexp to the preg_replace list and I cannot unless I break it up. As you know, if you break up a regexp pattern, IT WILL NOT WORK. And you know as well as I that there'll be lusers who won't understand to glue it back together before using it. What's up with this? Grey -- Edit this bug report at http://bugs.php.net/?id=22264&edit=1
[PHP-DOC] #30443 [Csd->Bgs]: Documentation error on language.oop5.basic.php
ID: 30443
Updated by: [EMAIL PROTECTED]
Reported By: alex at passant dot org
-Status: Closed
+Status: Bogus
Bug Type:Documentation problem
PHP Version: 5.0.1
New Comment:
User error -> bogus.
Previous Comments:
[2004-10-15 12:39:32] alex at passant dot org
You're right, I thaught it was dealing about class name, (instead of
class definition).
Sorry.
[2004-10-15 12:24:32] [EMAIL PROTECTED]
I quote "Every class definition begins with the keyword class". It
seems it does begin with the keyword 'class' ('class' is the keyword).
And THEN it shows the name of the class to be defined, in this example
being 'SimpleClass'. So, first the keyword, followed by a valid class
name.
There is no such bug in documentation.
[2004-10-15 11:50:39] alex at passant dot org
Description:
On http://www.php.net/manual/en/language.oop5.basic.php, you wrote:
"Every class definition begins with the keyword class, followed by a
class name, which can be any name that isn't a reserved word in PHP."
Then:
"
http://bugs.php.net/?id=30443&edit=1
[PHP-DOC] #30427 [Opn->Bgs]: Documentation page
ID: 30427 Updated by: [EMAIL PROTECTED] Reported By: jax at 64n dot net -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: ANY PHP Version: 5.0.1 New Comment: Yep, firefox is a fine piece of software but it is not without its bugs... Previous Comments: [2004-10-15 00:39:57] [EMAIL PROTECTED] Actually, this is a GRE rendering bug it seems. Just reloading the paige usually fixes it. I think it's been reported already, but don't have the reference to it anymore... Might want to mark this bug as Bogus. [2004-10-15 00:23:54] [EMAIL PROTECTED] Frequent problem for me also, I find selecting another mirror somehow fixes the problem. This will be fixed when we switch to livedocs, so I don't think any action is required. [2004-10-14 07:35:32] ppmm at wuxinan dot net no problem with my firefox 1.0 PR. My system is windows xp english version. [2004-10-14 05:25:40] jax at 64n dot net Description: Documentation html pages examples sometimes show up badly in firefox and other browsers these sections sometimes appear as small as possible, which makes reading the examples impossible. test with: http://www.php.net/manual/en/language.oop5.iterations.php example 19-21 -- Edit this bug report at http://bugs.php.net/?id=30427&edit=1
[PHP-DOC] #30260 [Opn]: Obsolete link to PHP Editors List
ID: 30260 Updated by: [EMAIL PROTECTED] Reported By: larryw24 at hotmail dot com Status: Open -Bug Type: Website problem +Bug Type: Documentation problem Operating System: n/a PHP Version: Irrelevant New Comment: Doc problem. Previous Comments: [2004-09-28 03:46:36] larryw24 at hotmail dot com Description: The people that support the PHP Editors List are jerking you around some more. On page: http://www.php.net/manual/en/tutorial.firstpage.php Is an obsolete link to "PHP Editors List". The bad link is: http://phpeditors.linuxbackup.co.uk/ The correct link is: http://www.thelinuxconsultancy.co.uk/phpeditors/ -- Edit this bug report at http://bugs.php.net/?id=30260&edit=1
[PHP-DOC] #17795 [Opn]: PostgreSQL documentation should have entry for deprecated function name
ID: 17795 Updated by: [EMAIL PROTECTED] Reported By: caugustin at alcyonis dot fr Status: Open Bug Type: Documentation problem Operating System: any PHP Version: 4.2.0 New Comment: 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. Previous Comments: [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 :) [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] #29941 [Bgs]: Online documentation contains mixed languages
ID: 29941 Updated by: [EMAIL PROTECTED] Reported By: tilspaam at hotmail dot com Status: Bogus Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant New Comment: If you provide no language code, we need to make assumptions. Whether it is good practice or not, we need to do it. If you provide the langauge code, than it is used. Previous Comments: [2004-09-02 14:34:04] tilspaam at hotmail dot com [EMAIL PROTECTED] wrote: "If the page that you're trying to view in a language other than english has not yet been translated, as is the case with the Danish session chapter, you will recieve the same page in English." No - I recieve a page in both danish and english. This is the case with http://www.php.net/session - all general content such as headers and warnings are in danish while the main content is in english. [EMAIL PROTECTED] wrote: "If you have cookies turned on, the last language you have seen is remembered..." I have allowed cookies for php.net and this seems to work. All previous mentioned URLs now display english and english only. [EMAIL PROTECTED] wrote: "BTW this is a feature, not a bug" I strongly disagree. Making assumptions about your users preferences is bad usability, but this discussion I believe belongs elsewhere. I know this problem is hardly a 'bug' but I didn't know where else to write. I'm sorry if I have posted the wrong place. /AP [2004-09-02 12:20:42] [EMAIL PROTECTED] BTW this is a feature, not a bug. If you have cookies turned on, the last language you have seen is remembered, so next time, the URL shortcuts will lead to that language (no need to select the language in every page view). If you would like to directly specify the language in your shortcut, you can do so. See http://php.net/urlhowto This page also links the My PHP.net page, which will explain you the language selection mechanism (http://php.net/my). [2004-09-02 12:04:29] [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 [2004-09-02 12:03:46] [EMAIL PROTECTED] It is actually much simpler. If the page that you're trying to view in a language other than english has not yet been translated, as is the case with the Danish session chapter, you will recieve the same page in English. If we would not do that, we'd be stuck with dozens of broken manuals where half of the content was missing. So, until someone translates it and adds it to CVS, it will appear in English. [2004-09-02 11:34:04] tilspaam at hotmail dot com Using the explicit manual path http://www.php.net/manual/en/ref.session.php provides a page all in english. Using http://www.php.net/session or http://www.php.net/manual/da/ref.session.php provides a page in mixed languages. I guess I'll just use the explicit path from now on :) /AP 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/29941 -- Edit this bug report at http://bugs.php.net/?id=29941&edit=1
[PHP-DOC] #26311 [Asn->Csd]: [chm] bug on _index.html
ID: 26311 Updated by: [EMAIL PROTECTED] Reported By: steven at pdsnet dot co dot za -Status: Assigned +Status: Closed Bug Type: Documentation problem Operating System: windows PHP Version: 4.3.4 Assigned To: goba New Comment: Fixed in CVS. Will be fixed in next docbuild. Previous Comments: [2003-11-19 13:09:52] [EMAIL PROTECTED] That link should work for all pages except _index.html (which does not exist in the online version). Note that the CHM has two index files, while the online manual has all that info on one page. The JS used to redirect you to the online version could be a bit more intelligent though to direct you to index.php if you click on _index.html though... Assinging to myself. [2003-11-19 05:06:41] steven at pdsnet dot co dot za Description: I have found a bug on page _index.html [chm date: 2003-09-06]... If you click "Navigate to this page online" - it will return error 404. It uses the filename _index and not just index. -- Edit this bug report at http://bugs.php.net/?id=26311&edit=1
[PHP-DOC] #29749 [Opn->Fbk]: [chm] bug on tutorial.html
ID: 29749 Updated by: [EMAIL PROTECTED] Reported By: jccviking at att dot net -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: Irrelevant New Comment: What skin are you using? Previous Comments: [2004-08-19 02:33:12] jccviking at att dot net Description: I have found a bug on page tutorial.html [chm date: 2003-09-06]... When I try to: "Print the selected heading and all subtopics" I get a bunch of script errors starting with: Line: 43 Char: 4 Error: Object Expected If I keep clicking the Yes button I get a bunch more. All have a different line but all say Char 4, Object Expected. JCC -- Edit this bug report at http://bugs.php.net/?id=29749&edit=1
[PHP-DOC] #29941 [Bgs]: Online documentation contains mixed languages
ID: 29941 Updated by: [EMAIL PROTECTED] Reported By: tilspaam at hotmail dot com Status: Bogus Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant New Comment: BTW this is a feature, not a bug. If you have cookies turned on, the last language you have seen is remembered, so next time, the URL shortcuts will lead to that language (no need to select the language in every page view). If you would like to directly specify the language in your shortcut, you can do so. See http://php.net/urlhowto This page also links the My PHP.net page, which will explain you the language selection mechanism (http://php.net/my). Previous Comments: [2004-09-02 12:04:29] [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 [2004-09-02 12:03:46] [EMAIL PROTECTED] It is actually much simpler. If the page that you're trying to view in a language other than english has not yet been translated, as is the case with the Danish session chapter, you will recieve the same page in English. If we would not do that, we'd be stuck with dozens of broken manuals where half of the content was missing. So, until someone translates it and adds it to CVS, it will appear in English. [2004-09-02 11:34:04] tilspaam at hotmail dot com Using the explicit manual path http://www.php.net/manual/en/ref.session.php provides a page all in english. Using http://www.php.net/session or http://www.php.net/manual/da/ref.session.php provides a page in mixed languages. I guess I'll just use the explicit path from now on :) /AP [2004-09-02 08:30:48] [EMAIL PROTECTED] I believe this has to do with the content-negotiation we use for displaying the manual. Based on your browser accept langauge, a selected version of the manual is displayed. This bug will need to be looked into further, as I've experienced it myself - Pages a mix between english and another langauge, often after I've just visited the manual in another language. But, could you tell me if the problem still happens when you use the explicit manual path? http://www.php.net/manual/en/ Or in Danish, http://www.php.net/manual/da/ [2004-09-02 00:23:43] tilspaam at hotmail dot com Description: Hello I recently found out that the online documentation contains a mixture of english and (in my case) danish. Some of the headlines and warnings are in danish while the rest is still in english. Translating the documentation into local languages might be a good idea for those not accustomed to english, but I would very much like to have the option of selecting english and nothing but english. Having to switch languages while reading is very annoying so please provide this functionality. I thank you in advance and for the great work that you put into continuously developing PHP. /AP -- Edit this bug report at http://bugs.php.net/?id=29941&edit=1
[PHP-DOC] #29862 [Opn]: CHM file not update since 2004-3
ID: 29862 Updated by: [EMAIL PROTECTED] Reported By: admin at spbdev dot com Status: Open Bug Type: Documentation problem Operating System: Windows 2000 PHP Version: 5.0.1 New Comment: We have a README on how to build it, and that should work. I have called for help, since I am not able to build this edition anymore. I hope that someone from the docteam will be able to help out. Previous Comments: [2004-08-27 11:09:49] admin at spbdev dot com Description: see http://cn.php.net/get/php_manual_zh.chm/from/a/mirror the CHM Document for download not update for a long time. This is the information: chm Size: 4664Kb Date: 11 Mar 2004 -- Edit this bug report at http://bugs.php.net/?id=29862&edit=1
[PHP-DOC] #29810 [Bgs]: explode function, separator parameter
ID: 29810 Updated by: [EMAIL PROTECTED] Reported By: toni dot helminen at par dot as Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: This kind of reference is also explained in the about section: | Explanation is often added for features not available | in the current PHP release, but which will be | available in a known future PHP version. Previous Comments: [2004-08-24 10:48:47] [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 No bug here, it's just that PHP 5.1 is not yet released. [2004-08-24 10:47:27] toni dot helminen at par dot as Description: In the PHP online manual there is a sentence: "This feature was added in PHP 5.1.0." See: http://www.php.net/manual/en/function.explode.php -- Edit this bug report at http://bugs.php.net/?id=29810&edit=1
[PHP-DOC] #29614 [Opn]: Documentation error
ID: 29614 Updated by: [EMAIL PROTECTED] Reported By: nramsbottom at hotmail dot com Status: Open -Bug Type:Website problem +Bug Type:Documentation problem PHP Version: Irrelevant New Comment: PHP Manual problem, so classify as such Previous Comments: [2004-08-11 14:14:13] nramsbottom at hotmail dot com Description: There appears to be an error in the PHP manual for PHP5 class member visibility located at: http://www.php.net/manual/en/language.oop5.visibility.php >Protected limits access access to only classes inherited. Protected limits visiblity only to the class that defines the item. Also... > Class members must be defined with public, private, or private. -- Edit this bug report at http://bugs.php.net/?id=29614&edit=1
[PHP-DOC] #24861 [Asn]: Categorize function references
ID: 24861 Updated by: [EMAIL PROTECTED] Reported By: tim at zer0-interactive dot com Status: Assigned Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant Assigned To: goba New Comment: verdy_p, you also submitted a duplicate. What bug do we choose from multiple issues dealing with the same problem is upon is. It is not the earliest timestamp we choose, but it is the most relevant bug report. The xml.in file itself does not solve the problem, since there are no tools currently supporting the building of the docs with that structure. This bug is not forgotten, just noone had the time yet to take care of it. If you are willing to help, you could equally offer your time as others do in this project. Previous Comments: [2004-08-09 13:05:17] verdy_p at wanadoo dot fr This bug is quite old and I reported it 2 years ago: http://bugs.php.net/bug.php?id=17164 Nothing was done about it, and bug 17164 was forgotten. Now bug 17164 is closed (it was not bogous as stated now, but is now a duplicate with this newer bug report). before this bug was incorrectly reopened here. The solution proposed here with the xml.in file seems good and replies correctly to bug report 17164... [2004-08-08 19:57:38] [EMAIL PROTECTED] The suggested and soon to be implemented grouping is here: http://cvs.php.net/co.php/phpdoc/RFC/manual.xml.in Livedocs needs to be able to handle this type of TOC on the index page (and elsewhere). We are not going to implement support for this in the DSSSL or XSLT sheets IMHO. [2003-07-30 05:03:45] [EMAIL PROTECTED] I can assure you that such a categorization will be in place, hopefully in the near future. We are working on a better manual presentation system for our website (and all mirror sites), which will include categorized listing of extensions too. This is planned for a long time, but we need more time to complete the background programs. Assigning to myself, I will close this bug, when the solution is in place (despite that I will not implement the solution ;). [2003-07-29 17:50:06] tim at zer0-interactive dot com Description: This isn't so much a problem with any piece of documentation in particular, but rather the usability of the documentation as a whole. Having watched PHP grow over the last few years and trying to keep on top of the numerous extensions that keep appearing over time, it is getting increasingly hard to detirmine what each extension is for without going further into the documentation to read about it. I would say that is more of a problem with non *nix developers who may not have heard of what some of the extensions are and what they are for. In light of this, I think that it would be beneficial, particularly for the newbie developer, if the online documentation where organised slightly differently. Namely in the area of categorising the function reference section into high level chunks. Take for example the following question: what different databases does php support? This is not an easy question to answer unless you know what all the extensions do first when you are reading through the index. If it were reorganised slightly so it was something like this: Database Functions . MySQL Server Functions . MS SQL Server Functions . ODBC Functions Filesystem Functions . Directory Functions . File Functions An addition to this format would be the ability to collapse these sections on the page so that you do not have this massive list staring back at you. The documentation provided so far has been great, but I think the format of the index is holding it back from growing much further while still making it easy to locate what you are looking for. This index format would bring it into consistency with indexes such as how the PEAR packages are listing. A high level category with the actual packages listing inside those categories. I believe this indexing solution to accomdate not only for future growth of the documentation, but also makes it easier to use while still maintaining the integrity of the current documentation. -- Edit this bug report at http://bugs.php.net/?id=24861&edit=1
[PHP-DOC] #17164 [Bgs]: please group sections in the functions reference
ID: 17164 Updated by: [EMAIL PROTECTED] Reported By: verdy_p at wanadoo dot fr Status: Bogus Bug Type: Documentation problem Operating System: any PHP Version: 4.2.0 Assigned To: goba New Comment: As I have said it is not the content which makes this bogus, but it is being a duplicate (the bogus status is used for duplicates). What do we choose from the duplicates is our freedom. There were three bugs for this stuff. I have choosen the latest one to track the progress there, since none of the bugs really added any value to the discussion (we already have a grouping in place, just the infrastructure is not ready yet to handle it). Previous Comments: [2004-08-09 13:45:27] [EMAIL PROTECTED] And http://bugs.php.net/2352 is even older than this :-). [2004-08-09 13:01:12] verdy_p at wanadoo dot Fr May be the same as http://bugs.php.net/24861 But THIS report is MUCH older than newer bug 24861 that caught this one. So THIS bug 17164 was not bogous: close it if you want, because the solution proposed in Bug 24861 is a good reply to this bug report. But get sure to make the job in newer bug 24861... Thanks. [2004-08-08 19:59:29] [EMAIL PROTECTED] We track this issue at the bug Jakub pointed to (this makes this bugreport bogus, not the content). [2004-08-07 18:25:52] [EMAIL PROTECTED] Same as http://bugs.php.net/24861 [2002-07-24 11:52:25] [EMAIL PROTECTED] We already have a manual.xml.in file at http://cvs.php.net/co.php/phpdoc/RFC/manual.xml.in with groupings already accepted by the PHP documentation guys (there were not too many opinions about it, but at least no arguments against it). Are problems with this are that we still need to work out how to make new chunks of those s which is not the default (see the ref pages with s), and how to control the TOCs display [deepness] we get.. All these both in the DSSSL sheets and in the XSL sheets. So there is still some work to do. 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/17164 -- Edit this bug report at http://bugs.php.net/?id=17164&edit=1
[PHP-DOC] #17164 [Ana->Bgs]: please group sections in the functions reference
ID: 17164 Updated by: [EMAIL PROTECTED] Reported By: verdy_p at wanadoo dot fr -Status: Analyzed +Status: Bogus Bug Type: Documentation problem Operating System: any PHP Version: 4.2.0 Assigned To: goba New Comment: We track this issue at the bug Jakub pointed to (this makes this bugreport bogus, not the content). Previous Comments: [2004-08-07 18:25:52] [EMAIL PROTECTED] Same as http://bugs.php.net/24861 [2002-07-24 11:52:25] [EMAIL PROTECTED] We already have a manual.xml.in file at http://cvs.php.net/co.php/phpdoc/RFC/manual.xml.in with groupings already accepted by the PHP documentation guys (there were not too many opinions about it, but at least no arguments against it). Are problems with this are that we still need to work out how to make new chunks of those s which is not the default (see the ref pages with s), and how to control the TOCs display [deepness] we get.. All these both in the DSSSL sheets and in the XSL sheets. So there is still some work to do. [2002-07-24 11:15:30] paulo at isnet dot com dot br Great idea... Another one is to list new extensions/functions somewhere, because it's hard to know when something new appears - I usually find a new extension by quickly looking through the list and try to see if something catches my attention. [2002-05-12 12:17:13] [EMAIL PROTECTED] Erm... something messed up... fixed that... [2002-05-12 12:05:13] [EMAIL PROTECTED] we are already working on that. 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/17164 -- Edit this bug report at http://bugs.php.net/?id=17164&edit=1
[PHP-DOC] #2352 [Ana->Bgs]: Create subgroup of database functions
ID: 2352 Updated by: [EMAIL PROTECTED] Reported By: zik at msu dot edu -Status: Analyzed +Status: Bogus Bug Type:Documentation problem PHP Version: 4.0 Assigned To: goba New Comment: We track this issue at the bug Jakub pointed to (this makes this bugreport bogus, not the content). Previous Comments: [2004-08-07 18:24:29] [EMAIL PROTECTED] Same as http://bugs.php.net/24861. [2002-06-18 14:20:43] [EMAIL PROTECTED] Here is a proposal for the grouping of extension documentation (it's there since quite a long time): http://cvs.php.net/co.php/phpdoc/RFC/manual.xml.in It's not used right now, because the rendering problems of nested sections is not solved in the DSSSL style sheets... Goba [2002-06-17 14:44:59] [EMAIL PROTECTED] News on this? [2002-02-24 07:01:56] [EMAIL PROTECTED] this will be discussed on the phpdoc meeting in some weeks. [2002-02-24 06:57:16] [EMAIL PROTECTED] Any news on this? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/2352 -- Edit this bug report at http://bugs.php.net/?id=2352&edit=1
[PHP-DOC] #24861 [Asn]: Categorize function references
ID: 24861 Updated by: [EMAIL PROTECTED] Reported By: tim at zer0-interactive dot com Status: Assigned Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant Assigned To: goba New Comment: The suggested and soon to be implemented grouping is here: http://cvs.php.net/co.php/phpdoc/RFC/manual.xml.in Livedocs needs to be able to handle this type of TOC on the index page (and elsewhere). We are not going to implement support for this in the DSSSL or XSLT sheets IMHO. Previous Comments: [2003-07-30 05:03:45] [EMAIL PROTECTED] I can assure you that such a categorization will be in place, hopefully in the near future. We are working on a better manual presentation system for our website (and all mirror sites), which will include categorized listing of extensions too. This is planned for a long time, but we need more time to complete the background programs. Assigning to myself, I will close this bug, when the solution is in place (despite that I will not implement the solution ;). [2003-07-29 17:50:06] tim at zer0-interactive dot com Description: This isn't so much a problem with any piece of documentation in particular, but rather the usability of the documentation as a whole. Having watched PHP grow over the last few years and trying to keep on top of the numerous extensions that keep appearing over time, it is getting increasingly hard to detirmine what each extension is for without going further into the documentation to read about it. I would say that is more of a problem with non *nix developers who may not have heard of what some of the extensions are and what they are for. In light of this, I think that it would be beneficial, particularly for the newbie developer, if the online documentation where organised slightly differently. Namely in the area of categorising the function reference section into high level chunks. Take for example the following question: what different databases does php support? This is not an easy question to answer unless you know what all the extensions do first when you are reading through the index. If it were reorganised slightly so it was something like this: Database Functions . MySQL Server Functions . MS SQL Server Functions . ODBC Functions Filesystem Functions . Directory Functions . File Functions An addition to this format would be the ability to collapse these sections on the page so that you do not have this massive list staring back at you. The documentation provided so far has been great, but I think the format of the index is holding it back from growing much further while still making it easy to locate what you are looking for. This index format would bring it into consistency with indexes such as how the PEAR packages are listing. A high level category with the actual packages listing inside those categories. I believe this indexing solution to accomdate not only for future growth of the documentation, but also makes it easier to use while still maintaining the integrity of the current documentation. -- Edit this bug report at http://bugs.php.net/?id=24861&edit=1
[PHP-DOC] #25496 [Ana->Csd]: two levels in the security toc
ID: 25496 Updated by: [EMAIL PROTECTED] Reported By: travis at tsihomephone dot com -Status: Analyzed +Status: Closed Bug Type: Documentation problem Operating System: windows PHP Version: Irrelevant Assigned To: goba New Comment: Fixed in the sources. Also done this for all the translations. Will be up next time the documentation is built. Previous Comments: [2003-09-11 13:31:39] [EMAIL PROTECTED] This is not a bug, this is how the current manual is structured. It does not look to good, but this is the same for the online version: http://php.net/security. It is definirely not nice, but we need this method to be backward compatible with translations AFAIK. It will be better sometime in the future. Leaving the bug open as a reminder (also modified the summary). [2003-09-11 13:10:29] travis at tsihomephone dot com Description: I have found a bug on page security.index.html [chm date: 2003-09-06]... in the table of contents there is a section for security. when expanded the security section contains only one sub-section, security. it looks like php +--security +security +---blah when it should be php +--- security +- blah -- Edit this bug report at http://bugs.php.net/?id=25496&edit=1
[PHP-DOC] #28255 [Asn]: DLL directory missing
ID: 28255 Updated by: [EMAIL PROTECTED] Reported By: pburden98 at yahoo dot com Status: Assigned Bug Type: Documentation problem Operating System: windows 98 2nd Edition PHP Version: 5.0.0RC2 Assigned To: nlopess New Comment: None of them need to be put to system32 (according to our very latest install instructions, which are in effect in the manual sources since yestarday). Watch out for new manual builds coming out in the comings days or next week, or a bit later containing the completely rewritten windows instructions with more tips, information and an easier install method. The INSTALL file in the windows distribution probably still needs to be changed. Previous Comments: [2004-08-07 01:01:53] steve at aquiel dot net Bring back the dll directory so we can see which ones need to be put into system32 ok it might all run from the one directory but as a sysadmin running it form that one directory involves changes to enviromental variables etc to get php5 working properly and please update your documentation to reflect any changes!!! the installation docs are far from easy to read [2004-07-16 04:30:12] bradley at scrapcode dot com There is no dlls/ directory - the dlls in the root directory of php work, but without copying them to system32 during an upgrade, many problems arise. [2004-05-05 13:28:38] pburden98 at yahoo dot com I found another on line 181 of INSTALL. "Since PHP 4.0.5 MySQL, ODBC, FTP...and XML support is built-in." This is not true. I was told by a friend, "MySQL is not loaded because of licensing problems" Will you be patching the whole chapter "Installation of Windows extensions" on the INSTALL? [2004-05-03 15:32:19] [EMAIL PROTECTED] I don't have karma to update the INSTALL file, but I'll make a patch for it and I'll update this in the migration appendix. [2004-05-03 13:51:21] [EMAIL PROTECTED] That's correct; we moved them to avoid the need to put anything outside of you PHP install dir, as that causes people many problems when they upgrade (they always forget to check their system dir). Making this a documentation problem. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/28255 -- Edit this bug report at http://bugs.php.net/?id=28255&edit=1
[PHP-DOC] #26334 [Ana]: global and static keywords
ID: 26334
Updated by: [EMAIL PROTECTED]
Reported By: christian at freemails dot at
Status: Analyzed
Bug Type:Documentation problem
PHP Version: Irrelevant
New Comment:
No, Philip, the file is named after the sect2 id.
Previous Comments:
[2004-08-05 23:33:09] [EMAIL PROTECTED]
Goba, would this solve it?
Index: en/language/variables.xml
===
RCS file: /repository/phpdoc/en/language/variables.xml,v
retrieving revision 1.79
diff -u -r1.79 variables.xml
--- en/language/variables.xml 23 Jul 2004 00:18:21 - 1.79
+++ en/language/variables.xml 5 Aug 2004 08:09:57 -
@@ -374,7 +374,7 @@
-The global keyword
+The global keyword
First, an example use of global:
@@ -473,7 +473,7 @@
- Using static variables
+ Using static variables
Another important feature of variable scoping is the
static variable. A static variable exists
I wouldn't feel write changing the sect2 ids but maybe we have to?
[2003-11-20 12:39:55] [EMAIL PROTECTED]
Erm, the URL shortcuts and the PHP function list search only find nodes
having a file named after the name of the keyword/function/control
structure, etc. So modifying the ID would not be enough. As sect2s are
not put onto their own pages, these need to be sect1s to get recognized
by any of the quicref tools we have.
Also 'variables.scope.' is not a searched prefix, thought it can be
added if need be. But still only file names are searched for, so if the
file name does not contain the searched keyword, it will not be found.
Since the documentation is not reindexed to make these keywords be more
easy to find, the current solution is for speed reasons.
[2003-11-20 12:28:06] [EMAIL PROTECTED]
I thought I fixed this here:
http://cvs.php.net/diff.php/phpdoc/en/language/variables.xml?r1=1.67&r2=1.68
Why doesn't the following pick this up?
This is related to bug #16234
[2003-11-20 12:18:04] [EMAIL PROTECTED]
There is no global() function in PHP. There is a global keyword. It is
like return or continue. It is not a function. Some keywords are
accessible with URL shortcuts. It might be a good idea to let global be
accessed this way.
Note to the doc guys: possible to fix this by using
id="language.keyword.global" and id="language.keyword.static" in the
XML files.
[2003-11-20 11:40:51] christian at freemails dot at
Description:
www.php.net/global
does not work. But a global-function exists in PHP.
example of the global function:
function foobar() {global $foo; /* this makes $foo aviable here */}
--
Edit this bug report at http://bugs.php.net/?id=26334&edit=1
[PHP-DOC] #29331 [WFx->Csd]: Incorrect links within the Hebrew translation
ID: 29331 Updated by: [EMAIL PROTECTED] Reported By: mail at burningsnowman dot net -Status: Wont fix +Status: Closed Bug Type: Documentation problem Operating System: Win2k PHP Version: Irrelevant New Comment: I have committed a fix, though it only works around your ugly old workarounds, so it does not get better. Waiting for livedocs is not a good option yet... :( The next docbuild (coming days) will fix the online Hebrew doc links. Previous Comments: [2004-08-04 12:30:57] [EMAIL PROTECTED] the LANG=he is old hack that lets us bypass some jade mysteries. LANGDIR (he) is the relavant parameter that have to be used on the links path. currently, i have no compilable phpdoc around to find out where the LANG is used instead of LANGDIR, anyway the hebrew docs on the old build system are broken for a while on some platforms and not supported. we waiting for livedocs release. [2004-08-03 22:59:33] [EMAIL PROTECTED] This is a documentation build system issue. Someone from the Hebrew team needs to inform us, why LANG=en is needed in the build (which makes links point to the English manual on the genarated pages). Moshe? [2004-07-22 17:01:50] mail at burningsnowman dot net Description: It seems that all the links within the Hebrew translation of the online php documentation point to the English version of the docs. Changing /en/ to /he/ in the URL reveals that the translated pages are there, just not linked to correctly. I was accessing the php site via the uk2 subdomain, although this probably isn't related to a specific mirror. -- Edit this bug report at http://bugs.php.net/?id=29331&edit=1
[PHP-DOC] #29331 [Opn->Ver]: Incorrect links within the Hebrew translation
ID: 29331 Updated by: [EMAIL PROTECTED] Reported By: mail at burningsnowman dot net -Status: Open +Status: Verified -Bug Type: Website problem +Bug Type: Documentation problem Operating System: Win2k PHP Version: Irrelevant New Comment: This is a documentation build system issue. Someone from the Hebrew team needs to inform us, why LANG=en is needed in the build (which makes links point to the English manual on the genarated pages). Moshe? Previous Comments: [2004-07-22 17:01:50] mail at burningsnowman dot net Description: It seems that all the links within the Hebrew translation of the online php documentation point to the English version of the docs. Changing /en/ to /he/ in the URL reveals that the translated pages are there, just not linked to correctly. I was accessing the php site via the uk2 subdomain, although this probably isn't related to a specific mirror. -- Edit this bug report at http://bugs.php.net/?id=29331&edit=1
[PHP-DOC] #29186 [Opn->Bgs]: ch.php.net too slow to use
ID: 29186 Updated by: [EMAIL PROTECTED] Reported By: gaess at websource dot ch -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: winXP PHP Version: Irrelevant New Comment: Please see http://php.net/my.php for a place to specify your settings. Others have not reported ch.php.net being so slow. Previous Comments: [2004-07-15 16:04:35] gaess at websource dot ch Description: I'm using your online-manual on a daily base, because it's far teh best avaiable site for php. Some time ago, you placed the mirror ch.php.net somewhere in switzerland, I think. Sadly, this server is too slow to be used. Today, I've requested the manual for the str_replace-Command. After a loading time two minutes (without exagerating) without anything happening, I gave up. Earlier I was requestig the manual page for the "for"-Statement. After hiting the "reload" button about ten times, the page was loaded (took me about 2 minutes also). As you can see, this is far too slow for any productive work. I urgently bet you to shut down the ch.php.net-mirror, so php-users from switzerland will again be able to use your manual. Regards Daniel Gasser -- Edit this bug report at http://bugs.php.net/?id=29186&edit=1
[PHP-DOC] #28768 [Asn]: docs in Extended CHM Format is not up-to-date
ID: 28768 Updated by: [EMAIL PROTECTED] Reported By: kingoleg at mail dot ru Status: Assigned Bug Type: Documentation problem Operating System: windows PHP Version: Irrelevant Assigned To: goba New Comment: It always needs some special care... Previous Comments: [2004-06-14 12:01:11] kingoleg at mail dot ru Thanks, goba. If you "build" a .bat file and all needed programs/files in one archive, I can build it every month. [2004-06-14 11:44:46] [EMAIL PROTECTED] I'll build a new version sometime soon at the beginning/middle of the next month. It needs a Windows machine and quite some preparation to do. I have no Windows machine and no adequate time currently. [2004-06-14 11:09:38] kingoleg at mail dot ru Thanks for link. But I wrote about download version with comments. [2004-06-14 10:48:58] [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 It's an example, not meant to be used "in production". [2004-06-14 10:04:42] kingoleg at mail dot ru Description: The latest (12th) build of the Extended CHM Format released on the 6th September 2003. Reproduce code: --- none Expected result: The latest (13th) build of the Extended CHM Format released on the 14th June 2004. Actual result: -- The latest (12th) build of the Extended CHM Format released on the 6th September 2003. -- Edit this bug report at http://bugs.php.net/?id=28768&edit=1
[PHP-DOC] #28768 [Bgs->Asn]: docs in Extended CHM Format is not up-to-date
ID: 28768 Updated by: [EMAIL PROTECTED] Reported By: kingoleg at mail dot ru -Status: Bogus +Status: Assigned Bug Type: Documentation problem Operating System: windows PHP Version: Irrelevant -Assigned To: +Assigned To: goba New Comment: I'll build a new version sometime soon at the beginning/middle of the next month. It needs a Windows machine and quite some preparation to do. I have no Windows machine and no adequate time currently. Previous Comments: [2004-06-14 11:09:38] kingoleg at mail dot ru Thanks for link. But I wrote about download version with comments. [2004-06-14 10:48:58] [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 It's an example, not meant to be used "in production". [2004-06-14 10:04:42] kingoleg at mail dot ru Description: The latest (12th) build of the Extended CHM Format released on the 6th September 2003. Reproduce code: --- none Expected result: The latest (13th) build of the Extended CHM Format released on the 14th June 2004. Actual result: -- The latest (12th) build of the Extended CHM Format released on the 6th September 2003. -- Edit this bug report at http://bugs.php.net/?id=28768&edit=1
[PHP-DOC] #28731 [Opn]: Document what is in the windows package
ID: 28731 Updated by: [EMAIL PROTECTED] -Summary: Action option in Apache needs more detail Reported By: cross_phil at hotmail dot com Status: Open Bug Type: Documentation problem Operating System: Windows XP PHP Version: 5.0.0RC2 New Comment: Ups, title change too Previous Comments: [2004-06-10 22:15:55] [EMAIL PROTECTED] IMHO the manual installation page should have details on what can be found in the package. We can add this after Wez reviewed the docs (so we know what to add more info about). [2004-06-10 17:16:09] [EMAIL PROTECTED] I've already fixed this in the new installation part. The php-win.exe is refered in the command line page and in the migration appendix. Thanks for your report, Nuno [2004-06-10 16:58:59] cross_phil at hotmail dot com Description: Installation instructions into Apache as a CGI say to include the following: ScriptAlias /php/ "c:/php/" AddType application/x-httpd-php .php Action application/x-httpd-php "/php/php.exe" I found that I had to modify the php.exe to say php-cgi.exe. In my PHP folder there is: php.exe php-win.exe php-cgi.exe with no documentation regarding which one does what. I found php-cgi worked for me. Expected result: Expected more detail regarding the different EXE files packaged in the distribution. Actual result: -- Internal server error was coming up instead of PHP processed HTML. -- Edit this bug report at http://bugs.php.net/?id=28731&edit=1
[PHP-DOC] #28731 [Bgs->Opn]: Action option in Apache needs more detail
ID: 28731 Updated by: [EMAIL PROTECTED] Reported By: cross_phil at hotmail dot com -Status: Bogus +Status: Open Bug Type: Documentation problem Operating System: Windows XP PHP Version: 5.0.0RC2 New Comment: IMHO the manual installation page should have details on what can be found in the package. We can add this after Wez reviewed the docs (so we know what to add more info about). Previous Comments: [2004-06-10 17:16:09] [EMAIL PROTECTED] I've already fixed this in the new installation part. The php-win.exe is refered in the command line page and in the migration appendix. Thanks for your report, Nuno [2004-06-10 16:58:59] cross_phil at hotmail dot com Description: Installation instructions into Apache as a CGI say to include the following: ScriptAlias /php/ "c:/php/" AddType application/x-httpd-php .php Action application/x-httpd-php "/php/php.exe" I found that I had to modify the php.exe to say php-cgi.exe. In my PHP folder there is: php.exe php-win.exe php-cgi.exe with no documentation regarding which one does what. I found php-cgi worked for me. Expected result: Expected more detail regarding the different EXE files packaged in the distribution. Actual result: -- Internal server error was coming up instead of PHP processed HTML. -- Edit this bug report at http://bugs.php.net/?id=28731&edit=1
[PHP-DOC] #28657 [Opn]: two bad links in a row
ID: 28657 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at atu dot cjb dot net Status: Open -Bug Type: Website problem +Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: Docproblem. Previous Comments: [2004-06-07 00:58:39] phpbugs at atu dot cjb dot net Description: Broken links. Reproduce code: --- Go to the glob function page: http://fr3.php.net/glob Scroll down to: "See also opendir(), readdir(), closedir(), and fnmatch()." Click on: "fnmatch()" Brings you to Not Found page: http://fr3.php.net/manual/en/function.fnmatch.php Click on: "contact the webmasters" Brings you to a "License and Copyright" page with no contact form: http://fr3.php.net/copyright.php#contact >From there you can click on the "contact" link in the bottom navigation bar: http://fr3.php.net/contact.php Expected result: See above. Actual result: -- See above. -- Edit this bug report at http://bugs.php.net/?id=28657&edit=1
[PHP-DOC] #28580 [Opn]: Typo in documentation
ID: 28580 Updated by: [EMAIL PROTECTED] Reported By: chruker at tiscali dot dk Status: Open Bug Type: Documentation problem Operating System: All PHP Version: Irrelevant New Comment: It should only print if the function returns false, so I would not be surprised... Previous Comments: [2004-05-30 23:19:45] chruker at tiscali dot dk I just tried: echo xml_parser_get_option($xml, 1241243243).""; but it doesn't print anything at all. [2004-05-30 21:48:23] jed at jed dot bz It also generates a Warning, but it still might return FALSE. [2004-05-30 21:46:11] jed at jed dot bz Although I was able to find this "typo" in the documentation, I have some doubts it is a typo. If you submit a bogus 'option' to xml_parser_get_option() it might return FALSE if that option isn't really an option. For example: $x = xml_parser_get_option($xml, 135971923752512); May return FALSE because there is no option that *can be set* by that number. Just a thought. [2004-05-30 17:52:25] chruker at tiscali dot dk Direct link to the page in the online documentation: http://www.php.net/manual/en/function.xml-parser-get-option.php [2004-05-30 17:48:57] chruker at tiscali dot dk Description: Hi On the page describing the xml_parser_get_option function there is a typo in the documentation. Its the line reading: 'This function returns FALSE if parser does not refer to a valid parser, or if the option could not be set. Else the option's value is returned.' The typo is this part: 'or if the option could not be set.' I don't assume that a *get_option function actually sets an option :-) Expected result: I don't know if the code returns false if the option isn't set or doesn't exists. -- Edit this bug report at http://bugs.php.net/?id=28580&edit=1
[PHP-DOC] #28519 [Opn]: TASK: identify orphan user notes and mass assign
ID: 28519
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: irrelevant
PHP Version: Irrelevant
New Comment:
Nuno, could you please commit the script to the phpdoc scripts folder,
where these kind of scripts are supposed to be? Also it would be nice
to rename it to orphan notes, or something, since bogus can really mean
anything, while the script is targeted at finding orphan notes.
Previous Comments:
[2004-05-26 16:50:19] [EMAIL PROTECTED]
I've made a script to collect bogus notes.
I needs a phpweb checkout (just backend/notes and manual/en).
Source: http://testes.aborla.net/bogus_notes.php
Result: http://testes.aborla.net/bogus_notes.txt
There are 63 bogus notes!!
[2004-05-25 20:35:03] [EMAIL PROTECTED]
Description:
{I open this up here, so someone can assign it to himself and hopefully
complete the task. Plus we will not forget :) This is the best task
management software we have now...}
While moving around and restructuring stuff in the manual, notes have
been orphaned in the past and notes will be orphaned in the future.
Currently we need to ask system admins to change the note association,
so they are displayed under the new IDs. Since we have not done so some
times in the past, there must be quite a few orphan attachments (and
there is going to be more with current restructuring).
We do need a tool to identify orphan user notes. Since the notes are
glued to the manual IDs, it is just a matter of comparing the list of
current manual IDs and IDs in the note table. I am sure that some
orpahns will be uncovered.
First we need a GUI to edit the manual IDs of these notes, so we can
attach them to new places, then we need a mass reattachment feature,
where we can specify the old and new ID and the program automatically
updates all notes pointing to the old ID to point to the new one. For
page splits we still need the manual interface to distribute the notes
to the splitted pages as needed.
This task is up for someone to grab :) Completion would greatly help
the install stuff restructuring, so we would have better chances of
assigning new IDs.
--
Edit this bug report at http://bugs.php.net/?id=28519&edit=1
[PHP-DOC] #28295 [Opn]: 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 Bug Type:Documentation problem PHP Version: Irrelevant New Comment: 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? Previous Comments: [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). [2004-05-06 10:33:34] m at bytech dot fi I imagine this could initially be done so that the version information that already exists in the current documentation would be automatically parsed, and then the remaining version information could be applied later. And the version checking could also be done by a community effort. I'm not familiar with the documentation system that the php.net docs use, but the version data that is already available there is pretty extensive (especially with PHP5 specific functions), and generally speaking in a format that could easily be automatically parsed from the documentation. And of course, good things often require some effort. :) [2004-05-06 10:24:20] [EMAIL PROTECTED] Would be good, but also a lot of effort for the doc team to audit the whole text. I'm not even sure if DocBook has a way to version sections of text. [2004-05-06 09:55:16] m at bytech dot fi Description: It would be very helpful if it was possible to better distinguish PHP5 specific functions when browsing the documentation. A lot of people will be coding for PHP4 for quite some time, and showing functions that are only available in PHP5 or in CVS might be confusing to them. Of course the version compatibility of the function is displayed on the top of every help page, but this is very easy to miss. And considering the sheer amount of functions that are available, some kind of limiting would be quite beneficial. This separation could be done in several ways, for example: - Separate documentations in different locations - Through a "My php.net" setting - Displaying new functions in different color - Hiding new functions completely This setting could naturally also be used to otherwise customize the help system, for example hiding functions for extensions that are rarely used, or setting the preferred PHP version number and showing only the functions that are relevant to that version, etc. -- Edit this bug report at http://bugs.php.net/?id=28295&edit=1
[PHP-DOC] #28019 [Bgs]: language selection is a disaster
ID: 28019 Updated by: [EMAIL PROTECTED] Reported By: wimroffel at planet dot nl Status: Bogus Bug Type: Documentation problem Operating System: Windows XP PHP Version: Irrelevant New Comment: We used to list all the languages with links, but it is not possible anymore with this long list of languages. The My PHP.net page also lets you specify a favourite mirror. The www.php.net site itself cannot be a favourite, since the whole redirection is built to protect the php.net server from being too slow, overwhelmed with traffic. As far as I know, a lot of sites have the same "My example.com" page to set your preferences... It is very much common... Previous Comments: [2004-04-16 04:41:37] wimroffel at planet dot nl The pulldown menu with the language version was standing for me at "printer friendly". It is not a logical thing to expect that you will find under that drop down box the possibility to change the language. [2004-04-16 04:03:29] [EMAIL PROTECTED] The redirection to the mirrors is *necessary*, you can change the language yourself by: 1. selecting it from the drop down box which exists on EVERY manual page. 2. go to nl2.php.net/my.php and select the language you want. [2004-04-16 04:00:15] wimroffel at planet dot nl Description: When I go to the page www.php.net/pcre I automatically end on the page nl2.php.net/pcre or another dutch mirror. There is no way to switch this off and there is no link on the dutch page to get the english page. I find this really very annoying. It is nice when a computer does some thinking for you, but this is Big Brother watching you. -- Edit this bug report at http://bugs.php.net/?id=28019&edit=1
[PHP-DOC] #27944 [Asn]: features section has nothing on Sessions
ID: 27944 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Documentation problem Operating System: irrelevant PHP Version: Irrelevant Assigned To: irchtml New Comment: Kenneth offered to move the session info from ref.session to features.session. The intention so far was to work the other way around (and provide compact and all-in-one reference sections). See the preg section for example. It contains info on preg formatting. Though regular expressions would be a possible feature section cadidate, we decided to keep the documentation for one extension in one place. This does not mean that pointers might not be added to the features section (short pages on regex extensions or session handling). But I am strongly opposed to the idea to move out stuff from the reference sections to the features section, since we have worked the other way around so far. There used to be an image generation section in the features part which we moved to the gd docs for example... [Kenneth, it is better to store comments in the bug system for future reference...] Previous Comments: [2004-04-10 13:00:46] [EMAIL PROTECTED] Description: The features section (http://www.php.net/manual/en/features.php) in the Manual misses a short introduction/tutorial on sessions. It doesn't have to be covering everything, but the basic session_start() and use of $_SESSION[] would be a very good idea. (And of course points to more information in the manual about it). -- Edit this bug report at http://bugs.php.net/?id=27944&edit=1
[PHP-DOC] #27676 [Opn]: OCI8 functions missing from documentation
ID: 27676 Updated by: [EMAIL PROTECTED] Reported By: jimdoolittle at comcast dot net Status: Open -Bug Type:Website problem +Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Docu problem. Previous Comments: [2004-03-24 10:54:28] jimdoolittle at comcast dot net Description: The function ocilogon() and dozens of other Oracle OCI8 functions that don't have an underscore in their names seem to have gone missing from the English online PHP Manual. Google has a cached manual page for ocilogon(), for example, that was updated as recently as 9 March 2004 (see http://www.google.com/search?q=cache:Bv_g7HLnMEIJ:www.php.net/OCILogon+ocilogon+site:www.php.net&hl=en&ie=UTF-8), but that page is now gone from www.php.net. Searching the php.net Function List gets you "Sorry, but the function ocilogon is not in the online manual." Have these function pages been deleted from the manual? If so, I can't find that documented anywhere on php.net. Hope I'm not missing something obvious here. Thanks! -- Edit this bug report at http://bugs.php.net/?id=27676&edit=1
[PHP-DOC] #27127 [Bgs]: http://uk.php.net/manual/sv/ref.session.php is now mingled with non-English text
ID: 27127 Updated by: [EMAIL PROTECTED] Reported By: michael dot emmott at aeat dot co dot uk Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: | Noticed that foreign language appears in various | places throughout the document. What would you expect from a Swedish manual? :) Previous Comments: [2004-02-03 07:03:14] [EMAIL PROTECTED] The English texts are used on places where the translation version is missing. [2004-02-03 05:45:48] michael dot emmott at aeat dot co dot uk Noticed that foreign language appears in various places throughout the document. [2004-02-03 05:36:36] michael dot emmott at aeat dot co dot uk Description: I was viewing http://uk.php.net/manual/sv/ref.session.php on 3-Feb-04. -- Edit this bug report at http://bugs.php.net/?id=27127&edit=1
[PHP-DOC] #26096 [Opn]: Manual release date format
ID: 26096
Updated by: [EMAIL PROTECTED]
Reported By: david at acz dot org
Status: Open
Bug Type: Documentation problem
Operating System: Any
PHP Version: Irrelevant
New Comment:
The iso format is fine. As I have said, only numbers should be used in
dates IMHO, since those will appear in the translated manuals too...
Previous Comments:
[2004-01-26 14:27:48] [EMAIL PROTECTED]
What should we do to this?
Suggestions:
date -R (Mon, 26 Jan 2004 19:30:23 +)
date +%Y-%m-%d (2004-01-26)
...
date +%c (Mon Jan 26 19:34:07 2004) - I vote on this!!
Or simply leave as it is??
[2003-11-03 22:08:58] david at acz dot org
I should have indicated that I was referring to the downloadable
documentation. That is where it needs to be fixed. My apologies for
not being specific.
[2003-11-03 13:02:00] [EMAIL PROTECTED]
The 'textier' format is not available in downloadable versions. Also we
have the same date format for all the languages, so having a common
date format would be nice (only with numbers).
[2003-11-03 12:57:25] cheezy at php dot be
You can also see the date in a more 'textier' ('Thu, 21
Aug 2003') form on the top of every documentation page.
This avoids all confusion.
[2003-11-03 12:39:26] david at acz dot org
Description:
I realize this seems trivial, but I feel it is worth mentioning.
It would be very nice if the release date on the index page of the
manual was in ISO format (-MM-DD) instead of the European centric
DD-MM- format. ISO format should be a good compromise for American
and European users. More importantly, it has the advantage of not
being ambiguous when the day is twelve or less.
--
Edit this bug report at http://bugs.php.net/?id=26096&edit=1
[PHP-DOC] #26898 [Opn]: The tutorial page only links rpmfind, and it should link apt-get.org too
ID: 26898 Updated by: [EMAIL PROTECTED] Reported By: mtgontijo at yahoo dot com dot br Status: Open -Bug Type: Website problem +Bug Type: Documentation problem Operating System: Linux (Irrelevant) PHP Version: Irrelevant New Comment: Documentatio problem. Previous Comments: [2004-01-13 15:45:26] mtgontijo at yahoo dot com dot br Description: In the first tutorial page, it has a link for rpmfind, which searches for RPM's that are used in some GNU/Linux distributions. I think that you should be democratic and put there a link for apt-get.org, which searches for .deb's. This must be used for that all distributions have the same treat, but, as we remember, Debian was the first one to make packages easy to configure and to use apt-get. Expected result: I expect that would be a link to every kind of package. Actual result: -- It only shows the rpmfind. -- Edit this bug report at http://bugs.php.net/?id=26898&edit=1
[PHP-DOC] #26943 [Opn->Bgs]: The portuguese tradution is wrong
ID: 26943 Updated by: [EMAIL PROTECTED] Reported By: mtgontijo at yahoo dot com dot br -Status: Open +Status: Bogus -Bug Type: Website problem +Bug Type: Documentation problem Operating System: Linux (Irrelevant) PHP Version: Irrelevant New Comment: Please report documentation translation errors to the translation team at [EMAIL PROTECTED] Thanks. Previous Comments: [2004-01-17 07:57:17] mtgontijo at yahoo dot com dot br Description: The Portuguese tradution for the "PHP: Booleanos - Manual" page is wrong. In the first line of the Sintaxe topic, is not "insensitivas ao caso", e sim "não são sensíveis a maiúsculas ou minúsculas". -- Edit this bug report at http://bugs.php.net/?id=26943&edit=1
[PHP-DOC] #26808 [Opn]: Russian docs error in the name of Stig
ID: 26808 Updated by: [EMAIL PROTECTED] -Summary: Could not find 4.3.2 enhancements Reported By: abonentu at pisem dot net Status: Open Bug Type: Documentation problem Operating System: N/A -PHP Version: 4.3.1 +PHP Version: irrelevant New Comment: Don't know how the summary was changed... Previous Comments: [2004-01-07 05:12:56] [EMAIL PROTECTED] Docproblem. [2004-01-06 02:32:26] abonentu at pisem dot net Description: PHP documentation in Russian hosted at http://www.php.net/manual/ru/ has an error already at the second line - in the name of Mr. Bakken. There's a nonstandard letter used in the name S[ae]ther - ligature ae. Because of using Russian 8bit charset, this letter removed by Russian letter [zh] (U+0436). Reproduce code: --- http://www.php.net/manual/ru/ (twice) Expected result: The æ or æ entity reference should be use instead of simple letter. Actual result: -- Now I see at my screen something like: Stig Sжther Bakken -- Edit this bug report at http://bugs.php.net/?id=26808&edit=1
[PHP-DOC] #26808 [Opn]: Could not find 4.3.2 enhancements
ID: 26808 Updated by: [EMAIL PROTECTED] -Summary: PHP Documentation in Russian has an error in the name "Stig Saether Bakken" Reported By: abonentu at pisem dot net Status: Open -Bug Type: Website problem +Bug Type: Documentation problem -Operating System: Win 2000 Server (doesn't matter) +Operating System: N/A -PHP Version: 4.3.4 +PHP Version: 4.3.1 New Comment: Docproblem. Previous Comments: [2004-01-06 02:32:26] abonentu at pisem dot net Description: PHP documentation in Russian hosted at http://www.php.net/manual/ru/ has an error already at the second line - in the name of Mr. Bakken. There's a nonstandard letter used in the name S[ae]ther - ligature ae. Because of using Russian 8bit charset, this letter removed by Russian letter [zh] (U+0436). Reproduce code: --- http://www.php.net/manual/ru/ (twice) Expected result: The æ or æ entity reference should be use instead of simple letter. Actual result: -- Now I see at my screen something like: Stig Sжther Bakken -- Edit this bug report at http://bugs.php.net/?id=26808&edit=1
[PHP-DOC] #26766 [Opn]: Upgrading to PHP5 from PHP4
ID: 26766 Updated by: [EMAIL PROTECTED] Reported By: jmurtari at thebook dot com Status: Open -Bug Type: Website problem +Bug Type: Documentation problem Operating System: Linux PHP Version: 4.3.4 New Comment: Documentation issue. Previous Comments: [2004-01-02 11:03:12] jmurtari at thebook dot com Description: I've been reading more and more about PHP5. I went to the website and was looking for info on what changes (if any), were required to updates site from 4 to 5. Didn't see anything. The FAQ had stuff on upgrading from 2 to 3, and 3 to 4. Is something in the works for 4 to 5? Many thanks. John Murtari -- Edit this bug report at http://bugs.php.net/?id=26766&edit=1
[PHP-DOC] #26754 [Opn->Csd]: testing the new customized quickfix
ID: 26754 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Linux PHP Version: Irrelevant New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: [2003-12-31 11:03:25] [EMAIL PROTECTED] Repoening just for another quickfix try :) [2003-12-31 08:15:41] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2003-12-31 08:14:23] [EMAIL PROTECTED] Description: Please ignore. Expected result: You ignore this post :) Actual result: -- You will probably not ignore it :) -- Edit this bug report at http://bugs.php.net/?id=26754&edit=1
[PHP-DOC] #26754 [Csd->Opn]: testing the new customized quickfix
ID: 26754 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Documentation problem Operating System: Linux PHP Version: Irrelevant New Comment: Repoening just for another quickfix try :) Previous Comments: [2003-12-31 08:15:41] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2003-12-31 08:14:23] [EMAIL PROTECTED] Description: Please ignore. Expected result: You ignore this post :) Actual result: -- You will probably not ignore it :) -- Edit this bug report at http://bugs.php.net/?id=26754&edit=1
[PHP-DOC] #26754 [Opn->Csd]: testing the new customized quickfix
ID: 26754 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Linux PHP Version: Irrelevant New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-12-31 08:14:23] [EMAIL PROTECTED] Description: Please ignore. Expected result: You ignore this post :) Actual result: -- You will probably not ignore it :) -- Edit this bug report at http://bugs.php.net/?id=26754&edit=1
[PHP-DOC] #25653 [Csd]: German translation incomplete for function "get_parent_class"
ID: 25653 Updated by: [EMAIL PROTECTED] Reported By: h_hoefer at hotmail dot com Status: Closed Bug Type: Documentation problem Operating System: n/a PHP Version: Irrelevant New Comment: Unless you report a bug in English, we will not know that the bug is regarding the German manual... You should at least prepend some English text, that the report is about the German manual... Previous Comments: [2003-12-14 03:37:05] [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. [2003-12-13 15:43:50] h_hoefer at hotmail dot com Though I _really_ don't understand why I have to report a bug in the german documentation in english, here's my try of a translation: The german version of the documentation for the function "get_parent_class" doesn't contain the fact, that you can pass a string with a classname instead of an object as a parameter. Since this can save one a lot of instantiation problems I do think, it's important to add this to the german documentation, too. [2003-12-07 16:39:14] [EMAIL PROTECTED] In english please... [2003-09-25 07:31:23] h_hoefer at hotmail dot com Description: In der deutschen Version des Manuals fehlt der Hinweis, daß man auch ohne eine Instanz die Superklasse einer beliebigen Klasse herausbekommen kann (als obj muß dann ein String mit dem Klassennamen übergeben werden). Kann einem viel Instanziierung sparen ;-) -- Edit this bug report at http://bugs.php.net/?id=25653&edit=1
[PHP-DOC] #26581 [Bgs]: extension_dir is wrong for Windows
ID: 26581 Updated by: [EMAIL PROTECTED] Reported By: sire at acc dot umu dot se Status: Bogus Bug Type: Documentation problem Operating System: All Windows PHP Version: 4.3.4 New Comment: Setting it to ./extensions might not work for all installation methods. The current directory is not guaranteed to be the PHP.exe folder on all servers and all methods (ISAPI, CGI, FastCGI, NSAPI, etc.). Best practice is to provide a full path in there, which is dependant on your local machine, so it cannot be provided as a default... Previous Comments: [2003-12-10 10:46:37] [EMAIL PROTECTED] It's described in install.txt. If someone installs without reading install.txt, he probably knows what is he doing. [2003-12-10 10:37:11] sire at acc dot umu dot se Reopened. [2003-12-10 10:34:32] sire at acc dot umu dot se So you don't agree that it would be HELPFUL if the windows installation actually worked without the need to edit the php.ini file? EVERY Windows user is going to have to make this php.ini modification if they want to use more extensions. If this will have consequences I don't know of, atleast add a comment in the php.ini-dist file! Thanks. [2003-12-10 09:18:41] [EMAIL PROTECTED] You can unzip extensions wherever you want. It's in extensions/ directory just in distribution archive. It's stated also in install.txt. [2003-12-10 09:10:29] sire at acc dot umu dot se Description: The variable extension_dir is set to "./", it must be "./extensions" for Windows users. Please state this in the php.ini file, and in the manual... and make it default when installing the Windows exe?? When set to ./ and you enable gd2 (probably anything), and try to load a php page, it justs loads forever. Thanks for fixing this! Read more here: http://se.php.net/function.imagecreatefromjpeg -- Edit this bug report at http://bugs.php.net/?id=26581&edit=1
[PHP-DOC] #26414 [Bgs->Csd]: No documentation on modifying a string by indexing and assignment
ID: 26414
Updated by: [EMAIL PROTECTED]
Reported By: stephen dot fromm at verizon dot net
-Status: Bogus
+Status: Closed
Bug Type: Documentation problem
Operating System: irrelevant
PHP Version: Irrelevant
New Comment:
Closed, not bogus, as there was a confirmed bug and it was fixed. The
manual only documented access by index and not modification...
Previous Comments:
[2003-11-25 17:01:29] [EMAIL PROTECTED]
Here:
http://www.php.net/manual/en/language.types.type-juggling.php
you find the behaviour documented. I'll will add a small example to
the "Strings" section, so that it will be clarified and seen faster.
[2003-11-25 16:17:20] stephen dot fromm at verizon dot net
Description:
The PHP documentation nowhere indicates whether it's legal to *modify*
a string by accessing an individual character in the string with the
index operator (curly braces) and an assignment statement, as in:
$str = '0123456789';
$str{4} = 'd';
// Now $str should be '0123d56789'
While it does work on my machine, I feel the behavior
should be documented, as
* for all I know, there may be strange side effects (given php's
complex copy semantics);
* using undocumented language features can result in code that doesn't
age or port well;
* this is a fundamental aspect of any computer language.
--
Edit this bug report at http://bugs.php.net/?id=26414&edit=1
[PHP-DOC] #26365 [Opn->Bgs]: dbx_fetch_row() missing altogether
ID: 26365 Updated by: [EMAIL PROTECTED] Reported By: konstantin at boyandin dot info -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Windows PHP Version: 4.3.4 New Comment: The CHM versions also include version information... Please reopen this, if you see some bogus version info in the CHM. Previous Comments: [2003-11-24 03:55:46] [EMAIL PROTECTED] dbx_fetch_row is only available in CVS, so it will appear once PHP 5 gets out the door. This should be mentioned in the manual, but I don't know about the CHM version of the manual. All rows are automatically returned by dbx_query, so there's no need for a dbx_fetch_row unless you retrieve a LOT of data. In that case, you may need to pull the dbx extension from cvs and compile it for PHP 4.3.x, or have some friendly person do it for you. [2003-11-23 21:35:29] konstantin at boyandin dot info In the PHP manual, CHM version, there IS such function mentioned. So the problem is with manual, actually. [2003-11-23 21:18:33] [EMAIL PROTECTED] There is no such function in the extension, so of course it doesn't exist. [2003-11-23 11:17:32] konstantin at boyandin dot info Description: I have installed PHP 4.3.4 for Windows and discovered that the following function dbx_fetch_row() isn't defined in the corresponding extension DLL. That effectively makes the whole DBX extension useless in case of Windows PHP distribution. Note: the same problem is with Windows distribution of PHP 4.3.2 and, perhaps, 4.3.3 (since the extension DLL wasn't changed since 4.3.2) Reproduce code: --- Any DBX-using code will do. Actual result: -- Fatal error: dbx_fetch_row(): undefined function -- Edit this bug report at http://bugs.php.net/?id=26365&edit=1
[PHP-DOC] #26367 [Opn->Csd]: Spelling mistake
ID: 26367 Updated by: [EMAIL PROTECTED] Reported By: sebastian dot haller at freesurf dot ch -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: Irrelevant -Assigned To: +Assigned To: goba New Comment: Fixed. Thanks for the report. Previous Comments: [2003-11-23 14:43:35] sebastian dot haller at freesurf dot ch Description: http://ch.php.net//manual/add-note.php spelling error, it should read: "There is no need to obfuscate your email address..." instead of: "There is no need to obsfuscate your email address..." -- Edit this bug report at http://bugs.php.net/?id=26367&edit=1
[PHP-DOC] #26352 [Opn]: strpos() webpage missing an example for the use of offset attriubte
ID: 26352 Updated by: [EMAIL PROTECTED] Reported By: scott at abcoa dot com Status: Open -Bug Type:Website problem +Bug Type:Documentation problem PHP Version: Irrelevant New Comment: This is a docbug. Previous Comments: [2003-11-21 12:11:56] scott at abcoa dot com Boy! Bad example I put down. --snip-- $HTML_End = strpos($res_str,"]]>",$HTML_Start); $XML_End = strpos($res_str,"]]>",$HTML_End); --snip-- Would cause the variable $HTML_End and $XML_End to have the save value. So, an better example would be --snip-- $HTML_End = strpos($res_str,"]]>",$HTML_Start); $XML_End = strpos($res_str,"]]>",($HTML_End+1)); --snip-- But you get the drift about the need for a better example and a better example to clarify the understanding of hte word, 'offset'. [2003-11-21 11:47:24] scott at abcoa dot com Description: Read the strpos() function at http://us3.php.net/manual/en/function.strpos.php and had some trouble with it for a while, it took me a while to better understand it because I never use this function before. There are two problem here. Problem #1: The word 'offset' is a bad choice of word because the definition of it can be anything to what anyone's interpretation of the definition. Like mine, I assumed that offset meant to cancel each other out but when playing around with the script, I then knew that is not what it meant so I had no idea of what it meant. This problem can be overcome by the Problem #2. Problem #2: There is no example script of a strpos() with the use of offset attribute. So, how about updating the webpage to include the example. That would help to reduce the confusion and struggling in the long run. An example of it would be like this but don't take my word for it and you can use a simplier example -- $res_str = "blah blah blah blah"; $XML_Start = (strpos($res_str,"",$HTML_Start); $XML_End = strpos($res_str,"]]>",$HTML_End); --snip-- Thanks!! -- Edit this bug report at http://bugs.php.net/?id=26352&edit=1
[PHP-DOC] #26334 [Ana]: global and static keywords
ID: 26334
Updated by: [EMAIL PROTECTED]
Reported By: christian at freemails dot at
Status: Analyzed
Bug Type:Documentation problem
PHP Version: Irrelevant
New Comment:
Erm, the URL shortcuts and the PHP function list search only find nodes
having a file named after the name of the keyword/function/control
structure, etc. So modifying the ID would not be enough. As sect2s are
not put onto their own pages, these need to be sect1s to get recognized
by any of the quicref tools we have.
Also 'variables.scope.' is not a searched prefix, thought it can be
added if need be. But still only file names are searched for, so if the
file name does not contain the searched keyword, it will not be found.
Since the documentation is not reindexed to make these keywords be more
easy to find, the current solution is for speed reasons.
Previous Comments:
[2003-11-20 12:28:06] [EMAIL PROTECTED]
I thought I fixed this here:
http://cvs.php.net/diff.php/phpdoc/en/language/variables.xml?r1=1.67&r2=1.68
Why doesn't the following pick this up?
This is related to bug #16234
[2003-11-20 12:18:04] [EMAIL PROTECTED]
There is no global() function in PHP. There is a global keyword. It is
like return or continue. It is not a function. Some keywords are
accessible with URL shortcuts. It might be a good idea to let global be
accessed this way.
Note to the doc guys: possible to fix this by using
id="language.keyword.global" and id="language.keyword.static" in the
XML files.
[2003-11-20 11:40:51] christian at freemails dot at
Description:
www.php.net/global
does not work. But a global-function exists in PHP.
example of the global function:
function foobar() {global $foo; /* this makes $foo aviable here */}
--
Edit this bug report at http://bugs.php.net/?id=26334&edit=1
[PHP-DOC] #26334 [Opn->Ana]: global and static keywords
ID: 26334
Updated by: [EMAIL PROTECTED]
-Summary: php.net/global does not work
Reported By: christian at freemails dot at
-Status: Open
+Status: Analyzed
-Bug Type:Website problem
+Bug Type:Documentation problem
PHP Version: Irrelevant
New Comment:
There is no global() function in PHP. There is a global keyword. It is
like return or continue. It is not a function. Some keywords are
accessible with URL shortcuts. It might be a good idea to let global be
accessed this way.
Note to the doc guys: possible to fix this by using
id="language.keyword.global" and id="language.keyword.static" in the
XML files.
Previous Comments:
[2003-11-20 11:40:51] christian at freemails dot at
Description:
www.php.net/global
does not work. But a global-function exists in PHP.
example of the global function:
function foobar() {global $foo; /* this makes $foo aviable here */}
--
Edit this bug report at http://bugs.php.net/?id=26334&edit=1
[PHP-DOC] #25983 [WFx->Opn]: All printer functions show as only in cvs
ID: 25983 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Wont fix +Status: Open Bug Type: Documentation problem Operating System: windows me PHP Version: Irrelevant New Comment: Erm, since PECL extensions are currently documented in the PHP manual, this should be fixed somehow... Previous Comments: [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] #26311 [Opn->Asn]: [chm] bug on _index.html
ID: 26311 Updated by: [EMAIL PROTECTED] Reported By: steven at pdsnet dot co dot za -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: windows PHP Version: 4.3.4 -Assigned To: +Assigned To: goba New Comment: That link should work for all pages except _index.html (which does not exist in the online version). Note that the CHM has two index files, while the online manual has all that info on one page. The JS used to redirect you to the online version could be a bit more intelligent though to direct you to index.php if you click on _index.html though... Assinging to myself. Previous Comments: [2003-11-19 05:06:41] steven at pdsnet dot co dot za Description: I have found a bug on page _index.html [chm date: 2003-09-06]... If you click "Navigate to this page online" - it will return error 404. It uses the filename _index and not just index. -- Edit this bug report at http://bugs.php.net/?id=26311&edit=1
[PHP-DOC] #26096 [Opn]: Manual release date format
ID: 26096
Updated by: [EMAIL PROTECTED]
Reported By: david at acz dot org
Status: Open
Bug Type: Documentation problem
Operating System: Any
PHP Version: Irrelevant
New Comment:
The 'textier' format is not available in downloadable versions. Also we
have the same date format for all the languages, so having a common
date format would be nice (only with numbers).
Previous Comments:
[2003-11-03 12:57:25] cheezy at php dot be
You can also see the date in a more 'textier' ('Thu, 21
Aug 2003') form on the top of every documentation page.
This avoids all confusion.
[2003-11-03 12:39:26] david at acz dot org
Description:
I realize this seems trivial, but I feel it is worth mentioning.
It would be very nice if the release date on the index page of the
manual was in ISO format (-MM-DD) instead of the European centric
DD-MM- format. ISO format should be a good compromise for American
and European users. More importantly, it has the advantage of not
being ambiguous when the day is twelve or less.
--
Edit this bug report at http://bugs.php.net/?id=26096&edit=1
[PHP-DOC] #25913 [Opn]: Update for global entities and PHP history (patch included)
ID: 25913 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant New Comment: I am also fine with Martin committing the patch :) Previous Comments: [2003-10-19 17:19:18] didou at nexen dot net Not sure that a bug report is a good place to propose a patch for the documentation (as there's _no_ bug), but I'm +1 with you commit if make test succeed :) didou [2003-10-19 17:10:42] [EMAIL PROTECTED] Description: The following diff changes the global entities that refer to PEAR packages so that they conform to PEAR's new URL scheme. (The old links will work as well, but it's cleaner that way.) Additionally it adds links to PEAR, PHP QA and PHP-GTK in the PHP history. I have phpdoc karma myself, but I'm not sure if the history patch conforms with what you expect. ? en/reference/cybermut/functions.xml ? en/reference/monetra/functions.xml Index: en/appendices/history.xml === RCS file: /repository/phpdoc/en/appendices/history.xml,v retrieving revision 1.21 diff -u -r1.21 history.xml --- en/appendices/history.xml 16 Jul 2003 18:30:49 - 1.21 +++ en/appendices/history.xml 19 Oct 2003 21:07:47 - @@ -168,11 +168,11 @@ PEAR -PEAR, the PHP Extension and Application Repository (originally, -PHP Extension and Add-on Repository) is PHP's version of -foundation classes, and may grow in the future to be one -of the key ways to distribute both PHP and C-based PHP -extensions among developers. +PEAR, the PHP Extension and +Application Repository (originally, PHP Extension and Add-on +Repository) is PHP's version of foundation classes, and may grow in +the future to be one of the key ways to distribute both PHP and +C-based PHP extensions among developers. PEAR was born in discussions held in the PHP Developers' @@ -189,15 +189,19 @@ for database access, content caching, mathematical calculations, eCommerce and much more. + +More information about PEAR can be found in the manual. + PHP Quality Assurance Initiative -The PHP Quality Assurance Initiative was set up in the -summer of 2000 in response to criticism that PHP releases -were not being tested well enough for production -environments. The team now consists of a core group of +The PHP Quality Assurance +Initiative was set up in the summer of 2000 in response to +criticism that PHP releases were not being tested well enough for +production environments. The team now consists of a core group of developers with a good understanding of the PHP code base. These developers spend a lot of their time localizing and fixing bugs within PHP. In addition @@ -210,9 +214,9 @@ PHP-GTK -PHP-GTK is the PHP solution for writing client side -GUI applications. Andrei Zmievski remembers the planing -and creation process of PHP-GTK: +PHP-GTK is the PHP solution for +writing client side GUI applications. Andrei Zmievski remembers the +planing and creation process of PHP-GTK: Index: entities/global.ent === RCS file: /repository/phpdoc/entities/global.ent,v retrieving revision 1.133 diff -u -r1.133 global.ent --- entities/global.ent 14 Oct 2003 05:12:44 - 1.133 +++ entities/global.ent 19 Oct 2003 21:07:55 - @@ -66,7 +66,7 @@ http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40";> ftp://ftp.gnu.org/pub/gnu/emacs/";> http://www.gnu.org/software/emacs/windows/";> -http://pear.php.net/Mail_Mime";> +http://pear.php.net/package/Mail_Mime";> http://www.zend.com/zend/spotlight/sendmimeemailpart1.php";> http://www.oreilly.com/catalog/progintemail/noframes.html";> @@ -187,7 +187,7 @@ http://www.potentialtech.com/ppl.php";> http://www.ros.co.nz/pdf/";> http://www.pdflib.com/corporate/tm.html";> -http://pear.php.net/Net_DNS";> +http://pear.php.net/package/Net_DNS";> http://snaps.php.net/win32/PECL_STABLE/";> http://www.verisign.com/products/payflow/pro/index.html";> https://manager.verisign.com/";> @@ -215,6 +215,7 @@ http://museum.php.net/";> news://news.php.net/";> http://news.php.net/";> +http://pear.php.net/manual/";> http://pear.php.net/";> http://qa.php.net/";> http://groups.google.com/[EMAIL PROTECTED]"> -- Edit this bug report at http://bugs.php.net/?id=25913&edit=1
[PHP-DOC] #25773 [Opn]: OCIError documentation incorrect about "last error"
ID: 25773
Updated by: [EMAIL PROTECTED]
Reported By: cjbj at hotmail dot com
Status: Open
Bug Type: Documentation problem
Operating System: Windows 2000
PHP Version: 4.3.3
New Comment:
Yes it will definitely help if you write up something to cut and paste.
Thanks for contributing, Goba.
Previous Comments:
[2003-10-07 05:50:42] cjbj at hotmail dot com
Description:
This is similar to http://bugs.php.net/bug.php?id=9510, which was
closed two years ago saying the docs need to be updated. However the
docs have still not been updated. Also there are no real useful
user-supplied notes in the manual entry despite them being referred to
in http://bugs.php.net/bug.php?id=8993
How do we get the OCIError documentation updated? Will
it help if I write something to cut-and-paste?
Re-description of the problem:
The OCIError documentation
http://www.php.net/manual/en/function.ocierror.php says that if no
parameter is given, then the most recent error is displayed:
"If the optional stmt|conn|global is not provided, the last
error encountered is returned"
I am not seeing this with OCIParse or OCIExecute. I am seeing
OCIError return false. This is consistent with the comment in
http://bugs.php.net/bug.php?id=9510 :
"the documentation needs to be updated - ocierror always
stores the error in the most appropiate (parent-)handle. "
Reproduce code:
---
$t: ".$err['message']."\n";
}
echo "Connecting . . . ";
$con = @OCILogon("scott", "tiger", "T920");
if (!$con) {
PrintOCIError(@OCIError());
}
// Deliberate syntax error: missing a single quote
$stid = @OCIParse($con, "select 'x from dual");
if (!$stid) {
$e = OCIError();
PrintOCIError("First error ", $e);
// The correct error is displayed when $con is passed to OCIError
$e = OCIError($con);
PrintOCIError("Second error ", $e);
}
?>
Expected result:
According to the documentation the testcase should give:
Connecting . . .
First error : ORA-01756: quoted string not properly terminated
Second error : ORA-01756: quoted string not properly terminated
Actual result:
--
The testcase gives:
Connecting . . .
First error :
Second error : ORA-01756: quoted string not properly terminated
--
Edit this bug report at http://bugs.php.net/?id=25773&edit=1
[PHP-DOC] #25667 [Opn->Bgs]: Strange switch-case behaviour
ID: 25667 Updated by: [EMAIL PROTECTED] Reported By: zeug at delirium dot ch -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: * PHP Version: Irrelevant New Comment: It is documented (http://php.net/language.basic-syntax) that will print "abcdef" (without any space), as the closing newline after the ?> is ignored. If you put any HTML code between the two blocks, then it is not ignored. PHP does not mangle the contents of HTML blocks. Previous Comments: [2003-09-26 06:05:50] zeug at delirium dot ch Legalize it :-) After all, with there's also a newline finishing the switch-clause that's residing outside the PHP-block. It should be clear, that HTML blah blah is illegal. But I guess I grab the point: An empty line is considered an empty line of HTML rather than an empty line of PHP. So the parser strips whitespace AFTER a block, but doesn't ignore empty lines. This behaviour makes sense in most cases but maybe this switch-whitespace-case one. Never mind, it smells like tweaking the parser for no big issue, so adding a phrase to the docs will do I guess. Thanks for the fast replies, that's really cool! [2003-09-26 05:24:16] tony2001 at phpclub dot net as Wez already said, and are not the same things. first is equal to: and this is invalid syntax. [2003-09-26 05:18:56] zeug at delirium dot ch Now, that's a matter of taste. I code 99% as classes in external files. So only very little PHP remains in the actual page file, mainly to arrange the HTML output. Picture this: * SOME HTML CODE * * A BUNCH OF HTML CODE * * OTHER HTML CODE * ... * FINAL HTML CODE * I currently omit the empty line between the switch and the first case, yet why is one Newline after the swtich okay, but two Newlines fail parsing? [2003-09-26 05:01:18] tony2001 at phpclub dot net just don't open/close php-tags on every line of your script. [2003-09-26 04:52:07] zeug at delirium dot ch Wow, that was fast :-) Why shouldn't you be allowed to have whitespace between the opening switch and the first case clause when it's okay to have whitespace between case clauses and the final case/default clause and endswitch - unless of cause eliminating this exception means messing up the parser code? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/25667 -- Edit this bug report at http://bugs.php.net/?id=25667&edit=1
[PHP-DOC] #25564 [Opn->Asn]: Can't read CHM manual in spanish
ID: 25564 Updated by: [EMAIL PROTECTED] Reported By: ppalacios at planetanet dot cl -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: Windows 2000 PHP Version: Irrelevant -Assigned To: +Assigned To: derick New Comment: Thanks for the report. We know of this problem, and Derick will solve it as soon as he has the time. Previous Comments: [2003-09-16 17:17:38] ppalacios at planetanet dot cl Description: Can't read CHM manual in spanish. at open the file only see, "No se puede mostrar la página" -- Edit this bug report at http://bugs.php.net/?id=25564&edit=1
[PHP-DOC] #25537 [Opn->Csd]: Incorrect URL for PHP Editors page
ID: 25537 Updated by: [EMAIL PROTECTED] Reported By: keith at midnighthax dot com -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: n/a PHP Version: Irrelevant New Comment: I have fixed the URL in cvs so it will be updated with the next docbuild. Previous Comments: [2003-09-15 03:13:32] keith at midnighthax dot com Description: On page http://www.php.net/manual/en/tutorial.firstpage.php you have a link to the list of PHP Editors that I maintain. The link is incorrect - if the link you give is used viewers won't get the style sheet definitions and "other stuff". Please change it to: http://phpeditors.linuxbackup.co.uk/ -- Edit this bug report at http://bugs.php.net/?id=25537&edit=1
[PHP-DOC] #25496 [Opn->Ana]: two levels in the security toc
ID: 25496 Updated by: [EMAIL PROTECTED] -Summary: [chm] bug on security.index.html Reported By: travis at tsihomephone dot com -Status: Open +Status: Analyzed Bug Type: Documentation problem Operating System: windows PHP Version: Irrelevant New Comment: This is not a bug, this is how the current manual is structured. It does not look to good, but this is the same for the online version: http://php.net/security. It is definirely not nice, but we need this method to be backward compatible with translations AFAIK. It will be better sometime in the future. Leaving the bug open as a reminder (also modified the summary). Previous Comments: [2003-09-11 13:10:29] travis at tsihomephone dot com Description: I have found a bug on page security.index.html [chm date: 2003-09-06]... in the table of contents there is a section for security. when expanded the security section contains only one sub-section, security. it looks like php +--security +security +---blah when it should be php +--- security +- blah -- Edit this bug report at http://bugs.php.net/?id=25496&edit=1
[PHP-DOC] #25495 [Opn->Bgs]: [chm] bug on _index.html
ID: 25495 Updated by: [EMAIL PROTECTED] Reported By: travis at tsihomephone dot com -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: windows PHP Version: Irrelevant New Comment: The entities are not properly used on the master index, this is a known bug (and listed on the edition's page). It is true, that only is mentioned there, but » is bogus for the same reason... All the other pages should be fine. After recompiling countless times to fix different errors, I had no nerve to recompile the stuff again (takes a long time) just to fix those entities. This will be fixed in the next build. Previous Comments: [2003-09-11 12:54:59] travis at tsihomephone dot com Description: I have found a bug on page _index.html [chm date: 2003-09-06]... » entity is displayed as » , not as the entity it represents. The members of the PHP Documentation Group are listed on the front page of this manual. In case you would like to contact the group, please write to » [EMAIL PROTECTED] The 'Extending PHP 4.0' section of this manual is copyright © 2000 by Zend Technologies, Ltd. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at » http://www.opencontent.org/openpub/). -- Edit this bug report at http://bugs.php.net/?id=25495&edit=1
[PHP-DOC] #25363 [Opn->Asn]: [chm] bug on index.html
ID: 25363 Updated by: [EMAIL PROTECTED] Reported By: gvcompernolle at tiscali dot be -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: windows PHP Version: 4.3.3 -Assigned To: +Assigned To: goba New Comment: This is a known bug, and it will be corrected in future revisions Previous Comments: [2003-09-02 12:03:29] gvcompernolle at tiscali dot be Description: I have found a bug on page index.html [chm date: 2002-12-27]... At the bottom of the right screen in the chm-file, I see the ' ' character sequence (next to the 'Report a bug' link). This character sequence should normally represent a 'hard coded' space in a HTML document. Reproduce code: --- Just open the chm-file on a Windows XP Pro OS (don't know for other OS'es). -- Edit this bug report at http://bugs.php.net/?id=25363&edit=1
[PHP-DOC] #25219 [Ana->Csd]: Wrong type for DIRECTORY_SEPERATOR constant
ID: 25219
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Analyzed
+Status: Closed
Bug Type: Documentation problem
Operating System: irrelevant
PHP Version: Irrelevant
New Comment:
So I have fixed the XML.
Previous Comments:
[2003-08-23 09:12:11] [EMAIL PROTECTED]
"ext/standard/dir.c" states on line 136:
REGISTER_STRING_CONSTANT("DIRECTORY_SEPARATOR", dirsep_str,
CONST_CS|CONST_PERSISTENT);
I did not take a closer look at REGISTER_STRING_CONSTANT, but the name
of this macro lets me assume, thats it really is a string-constant.
But maybe someone wants to correct me.
-ali
[2003-08-23 08:13:27] [EMAIL PROTECTED]
Description:
On the page http://uk.php.net/manual/en/reserved.constants.standard.php
the constant DIRECTORY_SEPERATOR has a TYPE of (integer) when in actual
fact it is a (string) (a / or \) unless I'm missing something?
- Davey
--
Edit this bug report at http://bugs.php.net/?id=25219&edit=1
[PHP-DOC] #25208 [Csd->Opn]: Typos in the security chapter
ID: 25208
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: Documentation problem
Operating System: Irrelevant
PHP Version: Irrelevant
New Comment:
Erm, using & and & interchangeably in URLs is not a solution. That
page should either use & or & for every URL parameter. IMHO the
later would be good.
Previous Comments:
[2003-08-22 07:39:18] [EMAIL PROTECTED]
I have fixed the error (b) in CVS, the bug is closed now.
+1 for a XHTML compliant documentation, but this shuold be discussed on
[EMAIL PROTECTED], not in a bug report ;)
didou
[2003-08-22 07:21:27] [EMAIL PROTECTED]
Actually for XHTML/HTML Conformance, that first & *should* be an
& and so should the the second &.
Which brings about the question, should we start to change things like
this to bring examples upto standards compliant (X)HTML? Has the
decision been made whether HTML in the manual should be HTML or XHTML
yet?
He is right about the extraneous " after the 1 though.
- Davey
[2003-08-22 06:58:46] [EMAIL PROTECTED]
Description:
The second example included in the section `security.errors' ("Error
Reporting"), goes something like this:
There's a couple of errors in the `form' tag: (a) the `&' entity
shouldn't be there, and (b) there is one `"' too many.
Thanks.
--
Edit this bug report at http://bugs.php.net/?id=25208&edit=1
[PHP-DOC] #24833 [Bgs]: can't find documentation for open_basedir
ID: 24833 Updated by: [EMAIL PROTECTED] Reported By: john at webital dot de Status: Bogus Bug Type: Documentation problem Operating System: linux PHP Version: 4.3.1 New Comment: As far as I see, the original report says, that a file *below* the open_basedir cannot be included, just because the guy used ../filename.php to include the file. Is this exlpained on the link you have sent? I cannot see it... Previous Comments: [2003-08-01 09:44:17] [EMAIL PROTECTED] Here: http://www.php.net/features.safe-mode#ini.open-basedir It's not the documentations teams fault that the manual search isn't "working so well" these days, a problem that is well known. Status->bogus. [2003-08-01 05:04:45] [EMAIL PROTECTED] Opening again. Try to give a *good* reason when marking a bug bogus. [2003-08-01 03:25:27] [EMAIL PROTECTED] And would be great for us too, so we can see that is is really explained :) [2003-07-31 18:43:03] [EMAIL PROTECTED] nicos, maybe you can supply a link ? It will be great for John [2003-07-31 15:44:38] john at webital dot de Answer from bugs.php.net was " You probably don't know where to find it. But its documented. " Okay but that's exactly my point - why sould I have to know where to find it ? Why is it not documented by open_basedir ?? That is my point - not that if I search for ages I can find 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/24833 -- Edit this bug report at http://bugs.php.net/?id=24833&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #24901 [Opn]: Remove mirrors of PHP website from google to make finding solutions easier
ID: 24901 Updated by: [EMAIL PROTECTED] Reported By: webmaster at geog dot cam dot ac dot uk Status: Open Bug Type: Documentation problem Operating System: n/a PHP Version: Irrelevant New Comment: OK, so let the generated files be disallowed for robots. I have added a meta tag for printed pages immediately, so those will not be indexed anymore (this cannot be expressed in robots.txt AFAIK)... Previous Comments: [2003-08-01 07:18:38] [EMAIL PROTECTED] had the very same problem yesterday ... pdf_setdash() documentation is lousy and i tried to find some example script that uses it on google no way! and it is not only the official mirrors, i also got lots of hits for copies of the manual pages on other servers even if we want the official mirrors to be indexed (i seem to have missed these discussions so i don't know the pros and cons) we should IMHO add an option to generate noindex meta tags for the HTML formats of the manual this should be controlable using configure and enabled by default manuals for php.net would then be created with the option explicitly turned off (with the option of overriding it in robots.txt on mirrors) [2003-08-01 06:44:35] webmaster at geog dot cam dot ac dot uk > We have discussed this point several times, and the > outcome was always the same But might this be worth reconsidering now that the redirection system is in place? > If you would like to restrict the search to > www.php.net only No, the problem is when you're trying to find results that are _not_ from the PHP documentation, i.e. when the documentation doesn't solve the problem. [2003-08-01 06:40:02] [EMAIL PROTECTED] We have discussed this point several times, and the outcome was always the same. We would not like to disallow mirrors to be indexed. If you would like to restrict the search to www.php.net only, you can do it on Google, and many other search sites. Our current site search excatly does this. [2003-08-01 06:35:16] webmaster at geog dot cam dot ac dot uk Description: Can consideration be given to putting a robots.txt containing User-agent: * Disallow: / for mirrors of the PHP website? I.e. only php.net would not disallow google in. It is very annoying when using google/whatever to find a solution to a problem to be confronted with continual multiple copies of the same thing. Given that the main www.php.net has redirections to local mirrors installed, google searching will take people to the local mirror anyway. Presumably this would take a while to filter through to all the mirrors. There might be an issue with using site:[mirrorname] [searchterms] but this would be outweighed by not having to plough through multiple copies (many of which are out of date) of the PHP documentation. -- Edit this bug report at http://bugs.php.net/?id=24901&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #24901 [Opn->Bgs]: Remove mirrors of PHP website from google to make finding solutions easier
ID: 24901 Updated by: [EMAIL PROTECTED] Reported By: webmaster at geog dot cam dot ac dot uk -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: n/a PHP Version: Irrelevant New Comment: We have discussed this point several times, and the outcome was always the same. We would not like to disallow mirrors to be indexed. If you would like to restrict the search to www.php.net only, you can do it on Google, and many other search sites. Our current site search excatly does this. Previous Comments: [2003-08-01 06:35:16] webmaster at geog dot cam dot ac dot uk Description: Can consideration be given to putting a robots.txt containing User-agent: * Disallow: / for mirrors of the PHP website? I.e. only php.net would not disallow google in. It is very annoying when using google/whatever to find a solution to a problem to be confronted with continual multiple copies of the same thing. Given that the main www.php.net has redirections to local mirrors installed, google searching will take people to the local mirror anyway. Presumably this would take a while to filter through to all the mirrors. There might be an issue with using site:[mirrorname] [searchterms] but this would be outweighed by not having to plough through multiple copies (many of which are out of date) of the PHP documentation. -- Edit this bug report at http://bugs.php.net/?id=24901&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #24833 [Bgs]: not clearly explained open_basedir
ID: 24833 Updated by: [EMAIL PROTECTED] Reported By: john at webital dot de Status: Bogus Bug Type: Documentation problem Operating System: linux PHP Version: 4.3.1 New Comment: And would be great for us too, so we can see that is is really explained :) Previous Comments: [2003-07-31 18:43:03] [EMAIL PROTECTED] nicos, maybe you can supply a link ? It will be great for John [2003-07-31 15:44:38] john at webital dot de Answer from bugs.php.net was " You probably don't know where to find it. But its documented. " Okay but that's exactly my point - why sould I have to know where to find it ? Why is it not documented by open_basedir ?? That is my point - not that if I search for ages I can find it ! [2003-07-31 14:24:04] [EMAIL PROTECTED] You probably don't know where to find it. But its documented. [2003-07-27 17:33:55] john at webital dot de to do with open_basedir [2003-07-27 17:32:02] john at webital dot de Description: THIS IS A DOCUMENTATION BUG ! when its set for the following /home/www/netsh128/ and I have a file /home/www/netsh128/bits/neu/file.php which includes a file in /home/www/netsh128/bits/file2.php eg include '../file2.php'; I get loads of warnings a open_basedir restrictions ! If I change my include to include '/home/www/netsh128/bits/file2.php'; then no problems - this took a lot searching to find out !!! It is not well documented ! Hope it helps someone ! -- Edit this bug report at http://bugs.php.net/?id=24833&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #24861 [Opn->Asn]: Documentation Index
ID: 24861 Updated by: [EMAIL PROTECTED] Reported By: tim at zer0-interactive dot com -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant -Assigned To: +Assigned To: goba New Comment: I can assure you that such a categorization will be in place, hopefully in the near future. We are working on a better manual presentation system for our website (and all mirror sites), which will include categorized listing of extensions too. This is planned for a long time, but we need more time to complete the background programs. Assigning to myself, I will close this bug, when the solution is in place (despite that I will not implement the solution ;). Previous Comments: [2003-07-29 17:50:06] tim at zer0-interactive dot com Description: This isn't so much a problem with any piece of documentation in particular, but rather the usability of the documentation as a whole. Having watched PHP grow over the last few years and trying to keep on top of the numerous extensions that keep appearing over time, it is getting increasingly hard to detirmine what each extension is for without going further into the documentation to read about it. I would say that is more of a problem with non *nix developers who may not have heard of what some of the extensions are and what they are for. In light of this, I think that it would be beneficial, particularly for the newbie developer, if the online documentation where organised slightly differently. Namely in the area of categorising the function reference section into high level chunks. Take for example the following question: what different databases does php support? This is not an easy question to answer unless you know what all the extensions do first when you are reading through the index. If it were reorganised slightly so it was something like this: Database Functions . MySQL Server Functions . MS SQL Server Functions . ODBC Functions Filesystem Functions . Directory Functions . File Functions An addition to this format would be the ability to collapse these sections on the page so that you do not have this massive list staring back at you. The documentation provided so far has been great, but I think the format of the index is holding it back from growing much further while still making it easy to locate what you are looking for. This index format would bring it into consistency with indexes such as how the PEAR packages are listing. A high level category with the actual packages listing inside those categories. I believe this indexing solution to accomdate not only for future growth of the documentation, but also makes it easier to use while still maintaining the integrity of the current documentation. -- Edit this bug report at http://bugs.php.net/?id=24861&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #23760 [WFx->Opn]: using virtual() causes segmentation faults
ID: 23760
Updated by: [EMAIL PROTECTED]
Reported By: php-general at pennysaverusa dot net
-Status: Wont fix
+Status: Open
-Bug Type: Apache related
+Bug Type: Documentation problem
Operating System: RedHat 7.3
PHP Version: 4.3.2RC4
New Comment:
What sniper says is not in line with the current manual. The current
manual says that as of PHP 4.0.6 virtual() can be used on PHP files. So
the manual is not correct I assume. Changing this to be a doc problem.
Previous Comments:
[2003-05-27 13:43:18] php-general at pennysaverusa dot net
I am aware of that.
However, this was not a PHP file. It is merely an html file with a .php
extension.
There is no good reason for it to segfault.
If the policy is that .php files will not be loaded with virtual, then
DON'T LOAD IT. GIVE AN ERROR. DON'T RANDOMLY CRASH.
Random crashes are inexcusable. At least try to make the software
idiot-proof. Give the idiot an error or warning message.
At least, the documentation for virtual should mention this problem if
it's not going to be fixed.
Thank you,
Barry Gould
[2003-05-23 20:53:22] [EMAIL PROTECTED]
FYI: Using virtual() for this is absolutely useless, you really should
be using include(). And as manual says:
"virtual() cannot be used to include a document which is itself a PHP
file."
As otherwise the results are unpredictable..
(I didn't get any crash anyway)
[2003-05-23 20:38:23] php-general at pennysaverusa dot net
OK.
To reproduce this,
please download:
http://www2.pennysaverusa.com/barry/virtual_php_crash.tgz
Tested on RC3 and RC4 and php4-STABLE-200305222330
all segfault.
Notes:
1 unset session variable is _not_ enough to trigger the crash. 2
variables seems to be sufficient on my server.
The head and footer files are plain html. I named them with .php out of
habit. With .txt, it does not crash.
I know php won't (or at least shouldn't) parse them as php when using
virtual, so I see no reasonable excuse for it to crash.
As I mentioned before, with DBG enabled or disabled, it still
segfaults.
Thanks,
Barry Gould
[2003-05-22 16:18:24] [EMAIL PROTECTED]
Please provide a complete, self-contained script(s) so we can try and
reproduce this ourselves.
[2003-05-22 15:56:07] php-general at pennysaverusa dot net
After making a mistake (forgetting to set a session variable), one of
my pages started crashing apache ("child pid 7413 exit signal
Segmentation fault (11)" in apache error log).
After a lot of hair-pulling, it turns out that changing a virtual()
statement to an include() statement fixes the segfaulting. There is no
PHP code in the included file, only html & client-side JS.
This is the error that _should_ display if it doesn't segfault:
Notice: Undefined index: product in
/var/www/html/mercury/order_review.php on line 122
line 122:
I tried using DBG, but it still segfaults!
This happens in 4.3.2RC4 and RC3
Configure command:
./configure --with-mysql --with-gd --with-zlib-dir=/usr/lib
--with-apxs=/usr/sbin/apxs --with-config-file-path=/etc
--enable-sockets
mysql is version 4.0.12 (mysql Ver 12.18 Distrib 4.0.12, for pc-linux
(i686))
I tried following the backtrace instructions, but I am unable to get a
core dump, and running inside of gdb doesn't seem to let me hit the
webserver.
Server is SMP (Dual P4 Xeon).
Apache is
apache-1.3.27-2 from RedHat's RPM.
/usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY -DHAVE_AUTH_ANON
-DHAVE_ACTIONS -DHAVE_ALIAS -DHAVE_ASIS -DHAVE_AUTH -DHAVE_AUTOINDEX
-DHAVE_AUTH_DB -DHAVE_AUTH_DBM -DHAVE_PHP4 -DHAVE_CERN_META -DHAVE_CGI
-DHAVE_DIGEST -DHAVE_DIR -DHAVE_ENV -DHAVE_EXAMPLE -DHAVE_EXPIRES
-DHAVE_HEADERS -DHAVE_IMAP -DHAVE_INCLUDE -DHAVE_INFO -DHAVE_LOG_AGENT
-DHAVE_LOG_CONFIG -DHAVE_LOG_REFERER -DHAVE_MIME -DHAVE_MIME_MAGIC
-DHAVE_MMAP_STATIC -DHAVE_NEGOTIATION -DHAVE_REWRITE -DHAVE_SETENVIF
-DHAVE_SPELING -DHAVE_STATUS -DHAVE_UNIQUE_ID -DHAVE_USERDIR
-DHAVE_USERTRACK -DHAVE_VHOST_ALIAS -DHAVE_SSL
Thanks,
Barry Gould
--
Edit this bug report at http://bugs.php.net/?id=23760&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #23835 [Opn]: setcookie doc out of date
ID: 23835 Updated by: [EMAIL PROTECTED] Reported By: kruemelmonster at cookiecan dot de Status: Open Bug Type:Documentation problem PHP Version: 4.3.2RC4 New Comment: The text says: "The following table explains each parameter of the setcookie() function, be sure to read the Netscape cookie specification for specifics." Then the table says that the user need to use an integer for the time. That is inconsistent. As there is no note that the time is converted automatically. Linking to the RFC instead of the Netscape docs is also more "standard". Previous Comments: [2003-05-27 12:59:29] [EMAIL PROTECTED] The documentation tells the user correctly how to use setcookie(). IMHO, he doesn't need to know about RFC822 dates - in fact, it doesn't help him at all. I'm not against adding a note in the manual page, but i consider it unneccessary, especially since the netscape document which states that the time in the header is a RFC822 date string is linked for those who are interested in the internals, but the average PHP user is not. [2003-05-27 12:23:55] [EMAIL PROTECTED] I don't agree that this is not a bug. The reference refers that the netscape info, and there the expiration date is a string. This time->string conversion is done by PHP however. This is not documented. Also some links to the new RFCs would be good. They are more official then the Netscape docs. Even if we don't support all of the options fully. BTW the question that the setcookie function needs a maxage paramater is a feature request, please open another bug as a feature request for that. [2003-05-27 12:11:34] [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 parameter you pass to setcookie() as a timestamp gets converted to a date as specified by the rfc automatically. And there is nothing wrong with using the netscape specification, it is supported by the broadest range of browsers. [2003-05-27 11:25:56] kruemelmonster at cookiecan dot de the documentation of setcookie() suffers major inconsistencies. from the setcookie() man page: expire: The time the cookie expires. This is a unix timestamp so is in number of seconds since the epoch. In otherwords, you'll most likely set this with the time() function plus the number of seconds before you want it to expire. Or you might use mktime(). refers to the old netscape-spec http://www.netscape.com/newsref/std/cookie_spec.html which clearly states: expires=DATE The expires attribute specifies a date string that defines the valid life time of that cookie. Once the expiration date has been reached, the cookie will no longer be stored or given out. The date string is formatted as: Wdy, DD-Mon- HH:MM:SS GMT This is based on RFC 822, RFC 850, RFC 1036, and RFC 1123,... [snip] unix_ts datestring?what gives? please also consider the new specs published by the ietf: http://www.ietf.org/rfc/rfc2109.txt http://www.ietf.org/rfc/rfc2965.txt as posted by a user, implementing 'max-age'. either remove the explanation completely or correct it with a list of the type: expires: - unix_ts - datestring and you might want to include max_age thanx -- Edit this bug report at http://bugs.php.net/?id=23835&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #23835 [Bgs->Opn]: setcookie doc out of date
ID: 23835 Updated by: [EMAIL PROTECTED] Reported By: kruemelmonster at cookiecan dot de -Status: Bogus +Status: Open Bug Type:Documentation problem PHP Version: 4.3.2RC4 New Comment: I don't agree that this is not a bug. The reference refers that the netscape info, and there the expiration date is a string. This time->string conversion is done by PHP however. This is not documented. Also some links to the new RFCs would be good. They are more official then the Netscape docs. Even if we don't support all of the options fully. BTW the question that the setcookie function needs a maxage paramater is a feature request, please open another bug as a feature request for that. Previous Comments: [2003-05-27 12:11:34] [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 parameter you pass to setcookie() as a timestamp gets converted to a date as specified by the rfc automatically. And there is nothing wrong with using the netscape specification, it is supported by the broadest range of browsers. [2003-05-27 11:25:56] kruemelmonster at cookiecan dot de the documentation of setcookie() suffers major inconsistencies. from the setcookie() man page: expire: The time the cookie expires. This is a unix timestamp so is in number of seconds since the epoch. In otherwords, you'll most likely set this with the time() function plus the number of seconds before you want it to expire. Or you might use mktime(). refers to the old netscape-spec http://www.netscape.com/newsref/std/cookie_spec.html which clearly states: expires=DATE The expires attribute specifies a date string that defines the valid life time of that cookie. Once the expiration date has been reached, the cookie will no longer be stored or given out. The date string is formatted as: Wdy, DD-Mon- HH:MM:SS GMT This is based on RFC 822, RFC 850, RFC 1036, and RFC 1123,... [snip] unix_ts datestring?what gives? please also consider the new specs published by the ietf: http://www.ietf.org/rfc/rfc2109.txt http://www.ietf.org/rfc/rfc2965.txt as posted by a user, implementing 'max-age'. either remove the explanation completely or correct it with a list of the type: expires: - unix_ts - datestring and you might want to include max_age thanx -- Edit this bug report at http://bugs.php.net/?id=23835&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22493 [Opn->Bgs]: SERVER_ADDR not listed at php.net/reserved.variables
ID: 22493 Updated by: [EMAIL PROTECTED] Reported By: eric at evilwalrus dot com -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: 4.3.1 New Comment: | The entries in this array are created by the | webserver. There is no guarantee that every | webserver will provide any of these; servers | may omit some, or provide others not listed here. That is, you need to check your own phpinfo() if those variables are set, or there are any others... It is not an intention to list all variables there... Previous Comments: [2003-03-01 13:02:55] eric at evilwalrus dot com When browsing the manual I noticed that SERVER_ADDR, part of the $_SERVER/$HTTP_SERVER_VARS, is not listed on http://www.php.net/reserved.variables. I don't know if it is supposed to be like this... but it would seem sensable to me to have this variable listed on that page with the rest. I notice that not all of the variables in $_SERVER are not on that page, so I'm assuming this was done by design. Another one that I've noticed is SCRIPT_URI which only shows up when RewriteEngine is on. I personally think these should be documentated to save confusion, instead of just supprises to find later on when looking in a phpinfo() page. -- Edit this bug report at http://bugs.php.net/?id=22493&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
