Re: [PHP-DOC] Notes system (again)
> > Well, if someone has no CVS account then he will not > > be able to fix the > > docbug in the documentation CVS, so he can only mark > > it 'to be fixed in > > the toc' AKA 'docbugreport', so someone with a CVS > > account can fix it. > > If the note maintainer system would enable someone > > to move a manual user > > note to be a bug, then this would not require a CVS > > account. Some > > authentication will be needed throughout the process > > (which requires a > > CVS account now), but the bug can be opened with the > > email address of > > the original user note submitter > > That was my original idea. Anyone can submit a bug > report, fixing it should be left to whoever has CVS > access to phpdoc. We can even use for the bug report > originator the php-notes lists address, that way the > other editors will know that someone did mark a > particular entry as such and does not duplicate the > effort. Some good points here :) I'm leaning towards weaning the entire PHP documentation process away from the general php bugs system, as the two just don't seem to be the best of friends. This new notes system can be a big part of the new setup. Regards, Philip
[PHP-DOC] #23907 [Com]: Need additional installation step for IIS 6.0 / Windows Server 2003
ID: 23907 Comment by: thenry at mysideproject dot com Reported By: bryn at mrpath dot com Status: Open Bug Type: Documentation problem Operating System: Windows Server 2003 PHP Version: 4.3.2 New Comment: Okay, I have been having the same issue for a week now on Windows 2003 server/PHP 4.3.4. I added the web service extension as noted in this post. I am still getting the "HTTP Error 404 - File or directory not found. Internet Information Services (IIS)" When I initially installed the Window binary the following alert windows popped up. 1. IIS has been configured. 2. IIsext : Windows cannot find 'iisext' make sure you typed the name correctlly, and try again. To search for a file, click the start button, and then click search. 3. Could not execute the external program iisext. Should I try the zipped version? Any help would be appreciated. Previous Comments: [2003-09-06 23:39:29] bs_469 at hotmail dot com Thanks for the Help, I have been trying to fix this problem for over a week now. Your the greatest.. [2003-08-07 00:31:13] palash at cargofusion dot com well i find this lines on install.txt -- Note that this version does *NOT* install any extensions or server api versions of PHP. --- -palash [2003-06-28 13:26:30] nospam at teddyb dot com This worked great to solve my problem, thanks! [2003-06-27 13:25:00] bryn at mrpath dot com So, I think it's specific to windows server 2003 due to being preconfigured for "security". Having said that, I don't think you can get IIS 6 for other platforms (not speaking with knowledge here) since win2k3 comes with IIS6 I doubt many people are going to be running other versions of IIS. It is specific to IIS though, as win2k3 won't be able to prevent Apache from serving up php. Regarding if it applies to ISAPI, I don't know. I vaguely recall thinking that it might apply only to cgi only to be surprised that it was censoring ISAPI as well. I'll try and look in to this when I get back from vacation. [2003-06-27 13:12:58] [EMAIL PROTECTED] The following article explains how to do it for both ISAPI and CGI, this type of information needs to live in the PHP manual: http://www.macromedia.com/devnet/mx/dreamweaver/articles/php_iis.html Various user comments also refer to this type of information. AFAICT, this new information is specific to IIS 5 and above and we can add a IIS 5 or newer subsection here: http://www.php.net/manual/en/install.iis.php The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/23907 -- Edit this bug report at http://bugs.php.net/?id=23907&edit=1
Re: [PHP-DOC] RE: quickref.swf
Test: www.xs0.com/php/index.html D/L: www.xs0.com/php/funclist.zip Hm, what code you have used to compress (ie. obfuscate) the JS file implementing the functionality? I would like to clen up the code, plus add some requested features, while retaining the small size of the file with compressing (ie. obfuscating) the JS. Goba
Re: [PHP-DOC] Notes system (again)
--- Gabor Hojtsy <[EMAIL PROTECTED]> wrote: > >>>The "integration" bit could be done as a > documentation > >>>bug report, with the advantage that there will be > a > >>>track record of the action/contents. > >> > >>Do you mean that user notes would be automatically > turned into > >>documentation bug reports if decided by a note > admin? This sounds good > >>to me :) Others will surely point out the > downsides :) > > > > One huge downside is the bugs system didn't have > such a > > task in mind when it was created, and a seperate > system > > would be more useful and well used. Since we're > > talking about actually implementing the note > maintainer > > system[1], I think said system should handle this > and > > not bugs.php.net All the ideas in this thread[2] > and > > other[3] threads seem to make this the desirable > option. > > And this was discussed at the 2003 phpdoc > meeting[4] > > and some interesting findings[5] came about. > Because > > people agreed that non-CVS users should be able to > > maintain notes, this is yet another reason why > > bugs.php.net shouldn't get involved. > > Well, if someone has no CVS account then he will not > be able to fix the > docbug in the documentation CVS, so he can only mark > it 'to be fixed in > the toc' AKA 'docbugreport', so someone with a CVS > account can fix it. > If the note maintainer system would enable someone > to move a manual user > note to be a bug, then this would not require a CVS > account. Some > authentication will be needed throughout the process > (which requires a > CVS account now), but the bug can be opened with the > email address of > the original user note submitter That was my original idea. Anyone can submit a bug report, fixing it should be left to whoever has CVS access to phpdoc. We can even use for the bug report originator the php-notes lists address, that way the other editors will know that someone did mark a particular entry as such and does not duplicate the effort. > Or I was unable to interpret your thoughts properly? > :) > > Goba = --- Jesus M. Castagnetto <[EMAIL PROTECTED]> __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: [PHP-DOC] Using the submitted code
Hi Drago! In the web manual for PHP I've found some function that some of the visitors submitted. As the notes on your site inform the users that everything they submitted is the property of the php documentation group, I ask you whether I can use that code in my program. Feel free to use code you have found on the PHP manual pages (including user comments) in your programs. Regards, Goba
[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
Re: [PHP-DOC] Request for using PHP Manual as base for Lerning Guide.
OK, we can keep on discussing the matters from here. This manual is not fully translated. Would you like to publish this manual unmodified (print it out and multiply), or translate the untranslated parts, or something else? Yes some parts of the manual are still in english... I shall translate them for the students if it is required. The question is if you are willing to give back something to the cummnity by fixing the errors you find in the parts of the manual you use, and expanding those sections, while preparing the book. So that the version used by the people would get better with this solution. This way you would get the content for the book, while the community would profit from a better manual (at least regarding those sections you would use for your book from the manual). Goba
Re: [PHP-DOC] Downloadable w/User Comments
Are there any versions of the manual available that are both downloadable for offline viewing, and that include User Comments. I don't have broadband, so i can't always be online, but the user comments really help me out a lot. Only a special CHM version is available with all the notes, and only in English currently. We have nice plans but we are also short on time. :( It would take a l(insert a large amount of o's here)ooong time to translate the comments into other languages. It would probably be better to have a small section of each translation team devoted to comments alone, rather than everyone concentrating on the entire manual (initial manual and comments). Noone will translate the comments. Period. Good comments should be integrated into the manual, bad ones should be deleted. The ones left (which are too specific) are stil not guaranteed to stay in the manual. So it would probably be wasted time at best. You translate a note, someone removes it a few minutes later or integrated a rewritten version of the contents into the manual... I would be willing to work on the comments in the Japanese translation, as well as the overall manual (if I ever get karma, my request has thus far gone un-answered). It's a large undertaking, but the comments are a very important part of the manual... The manual is translateable in small pieces, not much larger than the users notes :) Could you elaborate on "nice plans"? As I am new I'm not 'in the know' :) Search for 'livedocs' in the archives. Goba
Re: [PHP-DOC] Notes system (again)
The "integration" bit could be done as a documentation bug report, with the advantage that there will be a track record of the action/contents. Do you mean that user notes would be automatically turned into documentation bug reports if decided by a note admin? This sounds good to me :) Others will surely point out the downsides :) One huge downside is the bugs system didn't have such a task in mind when it was created, and a seperate system would be more useful and well used. Since we're talking about actually implementing the note maintainer system[1], I think said system should handle this and not bugs.php.net All the ideas in this thread[2] and other[3] threads seem to make this the desirable option. And this was discussed at the 2003 phpdoc meeting[4] and some interesting findings[5] came about. Because people agreed that non-CVS users should be able to maintain notes, this is yet another reason why bugs.php.net shouldn't get involved. Well, if someone has no CVS account then he will not be able to fix the docbug in the documentation CVS, so he can only mark it 'to be fixed in the toc' AKA 'docbugreport', so someone with a CVS account can fix it. If the note maintainer system would enable someone to move a manual user note to be a bug, then this would not require a CVS account. Some authentication will be needed throughout the process (which requires a CVS account now), but the bug can be opened with the email address of the original user note submitter Or I was unable to interpret your thoughts properly? :) Goba
Re: [PHP-DOC] current manual build broken?
/me bugs Derick Anyway I won't bug no more.. for this month :p didou On Sat, 15 Nov 2003, Mehdi Achour wrote: On Wed, 5 Nov 2003, Derek Ford wrote:^ ^^^ It seems the extending php4 sections are missing. I doubt something like that would be removed intentionally, regardless, the extending php3 section remains :) They are added to the running running build, it will be online as soon as the build is done. (In a day or so) ^^ 10 days after, nothing have changed. The online doc haven't been updated since August. Is there a particular reason ? Why do you keep rejecting all the help that different persons offered if you don't do nothing ? Derick, I'm not dissin' or blaming you here, but I just want to know *why* ? Lack of free time :) You should try to bug me at a correct time, ie. in the evening so that I have time to do it on the spot :) Derick
[PHP-DOC] #26309 [Opn->Csd]: imageftbbox() requires the optional parameter
ID: 26309 Updated by: [EMAIL PROTECTED] Reported By: kputnam at putnamcabinets dot com -Status: Open +Status: Closed -Bug Type: GD related +Bug Type: Documentation problem Operating System: Debian GNU/Linux (Sid) PHP Version: 5.0.0b2 (beta2) New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. This is a documentation problem. The imagettfbbox() allows the Previous Comments: [2003-11-19 01:02:06] kputnam at putnamcabinets dot com Description: The documentation shows that the last parameter is optional (extrainfo) but an error is generated when it is left out. Calling with an empty array as the last parameter resolves the issue. Reproduce code: --- $box = imageftbbox($size,$angle,$this->fonts[$font],$text); Actual result: -- PHP Warning: Wrong parameter count for imageftbbox() -- Edit this bug report at http://bugs.php.net/?id=26309&edit=1
[PHP-DOC] Using the submitted code
Hallo, In the web manual for PHP I've found some function that some of the visitors submitted. As the notes on your site inform the users that everything they submitted is the property of the php documentation group, I ask you whether I can use that code in my program. Thank you in advance for your reply. Drago
[PHP-DOC] #25598 [Opn->Csd]: strtotime can't handle dates before 1970, and the documentation doesn't say it.
ID: 25598 Updated by: [EMAIL PROTECTED] Reported By: bens at benjamindsmith dot com -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: 2.4.x Linux, Windows PHP Version: 4.3.2 New Comment: Fixed in CVS :) Hartmut, this was mentionned in strftime() but too specific to make an entity. Previous Comments: [2003-10-13 05:30:29] [EMAIL PROTECTED] UNIX timestamps for dates before Jan 1st 1970 are undefined anyway some platforms treat negative timestamps as dates before 1970 while others just consider negative values as undefined ... so this is a 'won't fix' problem unless we come up with a portable PHP C-lib ;) AFAIR this *is* documented in other places in the manual? [2003-09-18 17:57:42] bens at benjamindsmith dot com Description: No matter what I do, strtotime can't seem to handle dates prior to 1970. The answer returned is always -1. The manual doesn't indicate this fact. Reproduce code: --- echo phpversion(); echo "\n--\n"; $time1="1/1/1970"; $time2="31-dec-1969"; $time3="31-dec-1949"; echo strtotime($time1); echo "\n"; echo strtotime($time2); echo "\n"; echo strtotime($time3); echo "\n"; Expected result: 4.3.2 - 28800 -{some integer other than 1} -{some bigger integer other than 1} Actual result: -- 4.3.2 -- 28800 -1 -1 -- Edit this bug report at http://bugs.php.net/?id=25598&edit=1
[PHP-DOC] cvs: phpdoc /en/reference/datetime/functions strtotime.xml
didou Wed Nov 19 08:00:31 2003 EDT Modified files: /phpdoc/en/reference/datetime/functions strtotime.xml Log: fixing #25598 Index: phpdoc/en/reference/datetime/functions/strtotime.xml diff -u phpdoc/en/reference/datetime/functions/strtotime.xml:1.3 phpdoc/en/reference/datetime/functions/strtotime.xml:1.4 --- phpdoc/en/reference/datetime/functions/strtotime.xml:1.3Fri Mar 21 10:46:14 2003 +++ phpdoc/en/reference/datetime/functions/strtotime.xmlWed Nov 19 08:00:31 2003 @@ -1,5 +1,5 @@ - + @@ -70,6 +70,10 @@ 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.) + Additionally, not all platforms support negative timestamps, therefore + your date range may be limited to no earlier than the unix epoch. This + means that e.g. dates prior to Jan 1, 1970 will not work on Windows, + some Linux distributions, and a few other operating systems.
[PHP-DOC] #25983 [Opn->WFx]: All printer functions show as only in cvs
ID: 25983 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Wont fix Bug Type: Documentation problem Operating System: windows me PHP Version: Irrelevant New Comment: printer functions are going to be moved into PECL Previous Comments: [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
Re: [PHP-DOC] current manual build broken?
On Sat, 15 Nov 2003, Mehdi Achour wrote: > > On Wed, 5 Nov 2003, Derek Ford wrote:^ > ^^^ > > > > > >>It seems the extending php4 sections are missing. I doubt something like > >>that would be removed intentionally, regardless, the extending php3 > >>section remains :) > > > > > > They are added to the running running build, it will be online as soon > > as the build is done. (In a day or so) > ^^ > > 10 days after, nothing have changed. The online doc haven't been updated > since August. Is there a particular reason ? Why do you keep rejecting > all the help that different persons offered if you don't do nothing ? > > Derick, I'm not dissin' or blaming you here, but I just want to know *why* ? Lack of free time :) You should try to bug me at a correct time, ie. in the evening so that I have time to do it on the spot :) Derick
[PHP-DOC] #26100 [Opn]: [de] bad protos for imagecopyresized()
ID: 26100 Updated by: [EMAIL PROTECTED] -Summary: [german] Reported By: sunbox at gmx dot net Status: Open Bug Type: Documentation problem Operating System: khj PHP Version: Irrelevant New Comment: fixing summary Previous Comments: [2003-11-03 15:53:25] sunbox at gmx dot net Description: thereĀ“s a bug in the german online documentation. The topic is http://www.php.net/manual/de/function.imagecopyresized.php Thes "dest_im" und the other "_im" are from type resource but not the type int! *gg* Reproduce code: --- ghk Expected result: hgk Actual result: -- ljkl -- Edit this bug report at http://bugs.php.net/?id=26100&edit=1
Re: [PHP-DOC] Downloadable w/User Comments
Derek Ford wrote: Gabor Hojtsy wrote: Only a special CHM version is available with all the notes, and only in English currently. We have nice plans but we are also short on time. :( It would take a l(insert a large amount of o's here)ooong time to translate the comments into other languages. I don't think Goba was talking about translating the comments, only the manual itself. Right now, you have CHM versions in all languages, but if you want a version with comments, you can only choose the English manual. It would be nice if there would be a French, Dutch, German, ... version with the (original, English) comments, just like you can see them on the on-line version. Greetings, Jan Fabry
[PHP-DOC] #26314 [Bgs->Opn]: Decimal numbers starting with 0 always treated as octals, even when invalid
ID: 26314 User updated by: matteo at beccati dot com Reported By: matteo at beccati dot com -Status: Bogus +Status: Open -Bug Type: Scripting Engine problem +Bug Type: Documentation problem Operating System: Debian GNU/Linux 3.0 PHP Version: 4.3.4 New Comment: [Changed category to "Documentation problem"] OK, I understand... Can I suggest adding a warning in the manual to let people know what happens when the provided number is invalid? IMHO that isn't much clear now. P.S. Sorry for reopening it by changing the summary... I didn't know you already answered :) Previous Comments: [2003-11-19 06:48:40] [EMAIL PROTECTED] Fixed status [2003-11-19 06:40:55] matteo at beccati dot com Fixed summary... [2003-11-19 06:39:40] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is exactly as it should be. If you prefix the 0 on a non-octal number, PHP still treats it as an octal number as is described in the manual. [2003-11-19 06:37:32] matteo at beccati dot com Description: According to the manual, integers can be specified in the octal notation preceding the number with a zero. Some lines below I can see this regexp: octal : 0[0-7]+ What I don't understand is why an invalid octal number preceded by a 0 is treated as an octal, having a value of 0. I know that you'll probably answer that it's a feature and not a bug, but I think that this behaviour should be highlighted in the manual :) Also checked on PHP 4.1.2, 4.3.0 and 4.3.3 Reproduce code: --- Expected result: int(7) int(8) int(8) Actual result: -- int(7) int(8) int(0) -- Edit this bug report at http://bugs.php.net/?id=26314&edit=1
[PHP-DOC] #26311 [NEW]: [chm] bug on _index.html
From: steven at pdsnet dot co dot za Operating system: windows PHP version: 4.3.4 PHP Bug Type: Documentation problem Bug description: [chm] bug on _index.html 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 bug report at http://bugs.php.net/?id=26311&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26311&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26311&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26311&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26311&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26311&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26311&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26311&r=support Expected behavior: http://bugs.php.net/fix.php?id=26311&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26311&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26311&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26311&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26311&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26311&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26311&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26311&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26311&r=float
Re: [PHP-DOC] Request for using PHP Manual as base for Lerning Guide.
> OK, we can keep on discussing the matters from here. This manual is not > fully translated. Would you like to publish this manual unmodified > (print it out and multiply), or translate the untranslated parts, or > something else? Yes some parts of the manual are still in english... I shall translate them for the students if it is required. It will be small textbook of methodics, with a size of 30-50 pages. It will be contain only: bases of language, some examples of a code, plus the description of the most simple receptions of programming on PHP, for that that students would understand elements of language. Their further training will be constructed on acquaintance with the "PHP manual" and the another specialized literature. The textbook of methodics should only help to make him first steps on a way of studying PHP. Accordingly, I gather (if I shall receive the corresponding sanction): - to take a part of a material from sections "Language Reference" and "Features", - to add examples specific to our institute, - to add a quantity of materials for the help to students at lectures, seminars and laboratory works, - to publish it in a printing house of institute, that students would have basic methodical manuals. -- Alex Welens MADI(GTU), f. ASU mailto:[EMAIL PROTECTED]