ID: 7741
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Any
PHP Version: 4.4.0
New Comment:
google 'cgi variables' brings up tons of documentation, why waste time
do
ID: 7741
Updated by: [EMAIL PROTECTED]
-Summary: .cgi does not adhere to quasi-RFC
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: Documentation problem
Operating System: Any
-PHP Version: 4.0.3pl1
+PHP V
ID: 18349
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: FreeBSD 4.6-RELEASE
PHP Version: 4.2.1
New Comment:
This bug has been fixed in CVS
ID: 7741
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Any
PHP Version: 4.0.3pl1
New Comment:
This bug has been fixed in CVS.
In case thi
On Mon, 2 Dec 2002, Friedhelm Betz wrote:
>
> >> > removing dead links, and updating fr doc
> >>
> >> AHHH, my bad! Didn't take into account all
> >> the translations! :(
> >>
> >> I'm away from my CVS tree right now but if
> >> someone doesn't update them all I will
> >> eventually. I pro
>> > removing dead links, and updating fr doc
>>
>> AHHH, my bad! Didn't take into account all
>> the translations! :(
>>
>> I'm away from my CVS tree right now but if
>> someone doesn't update them all I will
>> eventually. I promise to keep this in mind
>> in the future.
> IMHO it would b
ID: 20767
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.3.0RC2
New Comment:
This bug has been fixed in CVS.
In case
On Mon, 2 Dec 2002, Gabor Hojtsy wrote:
> > die("foo");
> >
> > vs.
> >
> > trigger_error("foo", E_USER_ERROR);
> >
> > is IMO a complication.
> >
> > > If we leave errors unhandled in examples, that is simple,
> > > but harms the developers. I do think, that using too much
> > > error handlin
On Mon, 2 Dec 2002, Gabor Hojtsy wrote:
> > right, die() works fine for that.
>
> OK, let die() stay there. BUT big notes should be added to the
> die() docs then about unsafe usage (to print out error messages
> to users). So if someone is interested in what die() does, he
> get some explanation
> die("foo");
>
> vs.
>
> trigger_error("foo", E_USER_ERROR);
>
> is IMO a complication.
>
> > If we leave errors unhandled in examples, that is simple,
> > but harms the developers. I do think, that using too much
> > error handling code in examples hurts, but none is not
> > better...
>
> rig
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.3.0RC2
PHP Bug Type: Documentation problem
Bug description: & instead of & with references
Mistakes in German Documentation:
http://www.php.net/manual/de/language.references.whatdo.php
http://www.php.net/manua
On Mon, 2 Dec 2002, John Coggeshall wrote:
> >
> >Regarding the confusion factor this is a valid point. The
> >error handling docs should clearly describe how the error
> >directives such as display_errors, error_reporting, and
> >log_errors behave and why a blank page my result. And describe
>
>Regarding the confusion factor this is a valid point. The
>error handling docs should clearly describe how the error
>directives such as display_errors, error_reporting, and
>log_errors behave and why a blank page my result. And describe
>ideal production vs. development scenerios.
We're g
>Of course, this does introduce the problem of scripters
>leaving the verbose error messages in their code when they're
>ready for production.
IMHO I guess I'm still of the opinion that the PHPDocs aren't really a
resource for "Good practices", there are plenty of other resources
available onl
The examples won't be much longer. And the main focus
won't be trigger_error(), just like how the focus isn't
die(), mysql_error(), 'or', etc. right now.
Regarding the confusion factor this is a valid point. The
error handling docs should clearly describe how the error
directives such as displ
On Mon, 2 Dec 2002, Gabor Hojtsy wrote:
> > > +1 on using trigger_error() in examples, including in mysql_connect. In
> my
> > > experience, it needs more exposure to newbies as it is a far more
> efficient
> > > way of dealing with errors. (And it actually took me a couple years to
> > > discover
> > +1 on using trigger_error() in examples, including in mysql_connect. In
my
> > experience, it needs more exposure to newbies as it is a far more
efficient
> > way of dealing with errors. (And it actually took me a couple years to
> > discover it! :)
>
> I'm -1 on this; don't over complicate exa
On Mon, 2 Dec 2002, Roy Huggins wrote:
> +1 on using trigger_error() in examples, including in mysql_connect. In my
> experience, it needs more exposure to newbies as it is a far more efficient
> way of dealing with errors. (And it actually took me a couple years to
> discover it! :)
I'm -1 on th
> Unfortunately, we havn't answered the original concern. Is it proper to
> be dumping detailed error messages in the examples. I say yes. Showing
> the scripter how to do basic debugging until their program is working will
> help them learn faster.
>
> Of course, this does introduce the problem
> The only problem left is this means 404's will
> remain.
>
> During 'make test' it would be nice if it said
> something like:
>
> "Warning: file foo.xml is using a link from
> legacy.ent, please update it to
> reflect the en/ version"
>
> Something like that, it would
pollita Mon Dec 2 13:08:29 2002 EDT
Modified files:
/phpdoc/en/features file-upload.xml
Log:
Minor formatting.
Index: phpdoc/en/features/file-upload.xml
diff -u phpdoc/en/features/file-upload.xml:1.52 phpdoc/en/features/file-upload.xml:1.53
--- phpdoc/en/fea
trigger_error() does direct the new scripter in a more rational error
handling direction than a series of die() calls. Moreover, the first time
they want to output errors to logs or send administrative emails they'll
appreciate having something like this. +1 for using trigger_error()
instead of d
derick Mon Dec 2 12:43:47 2002 EDT
Modified files:
/phpdoc/en/reference/dir/functions chroot.xml
Log:
- Change wording a little
Index: phpdoc/en/reference/dir/functions/chroot.xml
diff -u phpdoc/en/reference/dir/functions/chroot.xml:1.3
phpdoc/en/referenc
+1 on using trigger_error() in examples, including in mysql_connect. In my
experience, it needs more exposure to newbies as it is a far more efficient
way of dealing with errors. (And it actually took me a couple years to
discover it! :)
And here is how I would do the code snippet
if (!$conn = my
We need to convince Marc Liyanage to write the mac
docs for the PHP manual :) This link can be found
on the sidebar of downloads.php so maybe it should
replace the stepwise link in the docs. Or ideally
the MacOS docs will be updated. I too know nothing
on the subject but believe the docs are o
I like the idea of trigger_error() and not using 'die'. Using
'die' in errors in unsexy and rather limiting but yes I remember
we discussed this before too but it was only part of a huge
discussion regarding the coding_standards RFC. I also feel
'or' for errors is unsexy and limiting. How about
ID: 20694
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Windows 2000 Server
PHP Version: 4.3.0RC2
New Comment:
IMO this should definitively be included in the docum
The only problem left is this means 404's will
remain.
During 'make test' it would be nice if it said
something like:
"Warning: file foo.xml is using a link from
legacy.ent, please update it to
reflect the en/ version"
Something like that, it would check more than
jus
I personally have no problem with using trigger_error instead of
die()... I just have an issue with not using mysql_error() because we
don't want to be flooding with SQL queries, or using some sort of
debugging logic in a reference manual
John
>-Original Message-
>From: Gabor Hojtsy [ma
ray Mon Dec 2 10:13:07 2002 EDT
Modified files:
/phpdoc/en/reference/ldap/functions ldap-connect.xml
Log:
Added 2 examples demonstrating ldap-connect.
Index: phpdoc/en/reference/ldap/functions/ldap-connect.xml
diff -u phpdoc/en/reference/ldap/functions/l
It reads:
"...created by shmop_open(), the function will return and int, which ..."
I do believe it's supposed to not be "and int" but rather "an int"
http://www.php.net/manual/en/function.shmop-size.php
--
Kind regards
Stig-Ørjan Smelror
Webmaster
http://www.susperianews.com/
PS.
I'm not sub
betzMon Dec 2 07:55:47 2002 EDT
Added files:
/phpdoc/en/reference/readline configure.xml
/phpdoc/en/reference/recode configure.xml
/phpdoc/en/reference/regex configure.xml
/phpdoc/en/reference/semconfigure.xml
/phpdoc/en/reference/
betzMon Dec 2 07:51:41 2002 EDT
Modified files:
/phpdoc/entitiesglobal.ent
Log:
links for libedit and mm
Index: phpdoc/entities/global.ent
diff -u phpdoc/entities/global.ent:1.62 phpdoc/entities/global.ent:1.63
--- phpdoc/entities/global.ent:1.62
ID: 20760
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: RedHat 8.0
PHP Version: 4.2.2
New Comment:
OK, but mark it in the documentation with a big red callsign. ;-)
ID: 20760
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Zend Engine 2 problem
+Bug Type: Documentation problem
Operating System: RedHat 8.0
PHP Version: 4.2.2
New Comment:
This is indeed intended
> All these links are 404. I removed them
> from here and the docs for a reason, please
> revert. If some links still exist in the
> docs, let's fix them.
> Also, stepwise doesn't support PHP anymore,
> we need a new macos resource.
I am not familiar with MacOS but this link was suggested a fe
> > removing dead links, and updating fr doc
>
> AHHH, my bad! Didn't take into account all
> the translations! :(
>
> I'm away from my CVS tree right now but if
> someone doesn't update them all I will
> eventually. I promise to keep this in mind
> in the future.
IMHO it would be good to mo
Please do s/PHP(3|4)/PHP \\1/g
In other words, please put a space between the PHP name and
the version number. We have this standard in the documentation,
and use it exclusively. If you can find any examples against this
rule, please also change it from PHP3 => PHP 3 and PHP4 => PHP 4
(unless you
> IMHO, I think it's the newbies' decision on how and when to use
> functionality available in PHP. I see no problem with the examples in
> the documentation reflecting the use of functionality. There are
> countless examples in the manual currently which don't use what could be
> considered "best
Khm, it would be nice to use the link as a parameter for mysql_error() in
examples, where the link is used in other function calls (like the one
quoted below, and in some others):
Index: phpdoc/en/reference/mysql/functions/mysql-field-name.xml
diff -u phpdoc/en/reference/mysql/functions/mysql-fiel
ID: 19453
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Closed
Bug Type: Documentation problem
Operating System: windows
PHP Version: 4.2.3
Assigned To: goba
New Comment:
Works for me n
41 matches
Mail list logo
