Re: [PHP-DOC] proposal: documenting trunk

On May 25, 2010, at 4:44 AM, Ford, Mike wrote: >> -Original Message- >> From: Philip Olson [mailto:phi...@roshambo.org] >> Sent: 19 May 2010 05:44 >> To: PHP Documentation ML > > >> Two new entities being proposed: >> - version.trunk.after.53 >> "This is in Subversion trunk only, and

RE: [PHP-DOC] proposal: documenting trunk

> -Original Message- > From: Philip Olson [mailto:phi...@roshambo.org] > Sent: 19 May 2010 05:44 > To: PHP Documentation ML > Two new entities being proposed: > - version.trunk.after.53 >"This is in Subversion trunk only, and will probably exist as of > PHP 5.4 or 6.0." Brilliant id

Re: [PHP-DOC] proposal: documenting trunk

On Wed, May 19, 2010 at 06:44, Philip Olson wrote: > Two new entities being proposed: >  - version.trunk.after.53 >   "This is in Subversion trunk only, and will probably exist as of PHP 5.4 or > 6.0." >  - version.trunk.changelog >   "Future" Do we need both? The changelogs only list the versi

Re: [PHP-DOC] proposal: documenting trunk

On 05/19/2010 06:45 AM, Daniel Convissor wrote: Hi Philip: Nobody knows if/when PHP 5.4 or PHP 6 will exist, yet commits are happening in php-src/ trunk. We need to figure out how to document this stuff in such a way that we: ... Here's a proposal that may work, please critique: Looks g

Re: [PHP-DOC] proposal: documenting trunk

Hi Philip: > Nobody knows if/when PHP 5.4 or PHP 6 will exist, yet commits are happening > in php-src/ trunk. We need to figure out how to document this stuff in such a > way that we: ... > Here's a proposal that may work, please critique: Looks good. Thanks for thinking about this stuff. --D

[PHP-DOC] proposal: documenting trunk

Nobody knows if/when PHP 5.4 or PHP 6 will exist, yet commits are happening in php-src/ trunk. We need to figure out how to document this stuff in such a way that we: - will inform users - won't confuse users - utilize our changelogs - won't repeat the PHP 6 fiasco Here's a proposal that ma

Re: [PHP-DOC] Proposal

Hi Hannes, Thank you for your quickly response! Actually, the proposal made by Jesus Cova is focused as you say, like a PHP user group, and I think he is reffering to have a stand alone infrastructure to run the website, the webhosting and domain by appart. Anyway Hannes, thank you for the start

Re: [PHP-DOC] Proposal

You guys don't need PHP.net approval for this. Anyone can create a user group or portals around and for PHP, so by all means; go for it! If however you are asking if the infrastructure and systems should be hosted by php.net.. then things get complicated and I don't know what to say. -Hannes On

Re: [PHP-DOC] Proposal

Hello everyone, I am agree with Jesus Cova's proposal, to launch a website or portal in spanish. What do you think if we (the hispanic and spanish contributors) can get informed, up to dated, to all the hispanic talking community regarding to activities, our own forums, official PHP news and its d

[PHP-DOC] Proposal

Good nigth, i'm writting to you because i have a dude and something that i want to do and i need the aprove of you, i have seen that the persons that speak spanish depend directly from php.net in english and for that reason we will not have a index page or something like php.net.es and i want if yo

Re: [PHP-DOC] Proposal: Removing the PHP 3 Documentation

On 22.07.2007 03:38, Philip Olson wrote: If there are concerns or other suggestions for doing this then please express them now. I'd like to finish this up before the end of the month. I don't think anybody sane would object =) The docs should be up to date, it's no museum after all. -- Wbr

[PHP-DOC] Proposal: Removing the PHP 3 Documentation

Now, don't laugh, but this is a proposal to remove PHP 3 documentation from the PHP manual. It remains now because history is good, but it's been a long time (~7 years). Here's the proposal: * Remove all non-historical PHP 3 information from the manual. There are a few places it makes sen

[PHP-DOC] Proposal for mail introduction

Runtime Configuration sendmail_path string Where the sendmail program can be found, usually /usr/sbin/sendmail or /usr/lib/sendmail. configure does an honest attempt of locating this one for you and set a default, but if it fails, you can set it here. Systems not using sendmail should set th

Re: [PHP-DOC] Proposal to remove void from protos

Hi Jakub, Jakub Vrana wrote: Poll results: [...] Thank you for the opinions, I've added void to Pseudo-types. Thanks for adding ;-) Friedhelm

Re: [PHP-DOC] Proposal to remove void from protos

Poll results: Null return type instead of void: +2 jakub, richard: true return type -3 tony, derick, friedhelm: isn't so explicit as void +0 etienne: differentiate between really void in echo and null in other functions -3 dave, hartmut, friedhelm, nuno: add void to Pseudo-types instead Remove v

Re: [PHP-DOC] Proposal to remove void from protos

Hartmut Holzgraefe wrote: > () has different meanings depending on which language you look at, > in C++ () is like (void) while in C it is like (...), so lets > stick with the explicit (void) to avoid misunderstandings BTW Livedocs use () instead of (void). Jakub Vrana

Re: [PHP-DOC] Proposal to remove void from protos

Jakub Vrana wrote: Hello! Would you agree with removal of the word "void" in methodsynpsis both from return type and parameters list? I propose to change the return type to "null" which it really is and remove it completely from parameters list as it is the way to declare that function doesn't

Re: [PHP-DOC] Proposal to remove void from protos

Friedhelm Betz wrote: Dave Barr wrote: Can't we add "void" to http://php.net/language.pseudo-types instead? +1 from me another +1 -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com

Re: [PHP-DOC] Proposal to remove void from protos

Dave Barr wrote: Jakub Vrana wrote: Hello! Would you agree with removal of the word "void" in methodsynpsis both from return type and parameters list? I propose to change the return type to "null" which it really is and remove it completely from parameters list as it is the way to declare tha

Re: [PHP-DOC] Proposal to remove void from protos

Jakub Vrana wrote: Hello! Would you agree with removal of the word "void" in methodsynpsis both from return type and parameters list? I propose to change the return type to "null" which it really is and remove it completely from parameters list as it is the way to declare that function doesn't

[PHP-DOC] proposal control-structures.for.php

Hi list, could someone add a paragraph to the end of 'control-structures.for.php' that it's not recommended to use count() in arg2 especially when the for loop is used to unset elements of an array, because the function will be executed every loop. I mean: for($i=0; $ihttp://www.nak-nrw.de/p_

Re: [PHP-DOC] Proposal

Sean Coates wrote: > Oliver Block wrote: > >>I don't know, if you discussed on that lately/in the past but wouldn't it be >>a >>good idea, if pages that give an overview over the functions of an extension >>would be sorted differently? > > I like the output, but this listing is currently gener

Re: [PHP-DOC] Proposal

Oliver Block wrote: > I don't know, if you discussed on that lately/in the past but wouldn't it be > a > good idea, if pages that give an overview over the functions of an extension > would be sorted differently? I like the output, but this listing is currently generated by scripts, so in order

[PHP-DOC] Proposal

Hello, I don't know, if you discussed on that lately/in the past but wouldn't it be a good idea, if pages that give an overview over the functions of an extension would be sorted differently? E.g. the function part of this page: could be reordered l

Re[2]: [PHP-DOC] proposal system

||*()*|| Hi, Sean. ... SC> I look at the proposal system as a way to work ideas into a solution SC> that the majority (and sure, ideally everyone) can be happy with. SC> For example, I have a pseudo-proposal that I've been stalling on, SC> waiting for the RFC system. Philip also has one (that m

Re: [PHP-DOC] proposal system

I don't know who invented proposal system, but I dislike it. Proposals votings and so-called "democratic system" is evil. If we can't find a consensus then we are very bad team. I personally enjoy solving phpdoc tasks and act on my own, but programming proposal for my chaotic nature is not dif

[PHP-DOC] proposal system

Hello, phpdoc@lists.php.net I don't know who invented proposal system, but I dislike it. Proposals votings and so-called "democratic system" is evil. If we can't find a consensus then we are very bad team. I personally enjoy solving phpdoc tasks and act on my own, but programming proposal for

Re: [PHP-DOC] Proposal - magic quotes

A few topics for this section: Yes, very good list Phillip, though I'm not sure the content lends itself to the security section. Perhaps features, perhaps tutorial? A tutorial section would be nice, however, we dont apparantly have any such section :) The only thing we need to do is decide where

Re: [PHP-DOC] Proposal - magic quotes

> > > A few topics for this section: > > > > Yes, very good list Phillip, though I'm not sure the content lends itself to > > the security section. Perhaps features, perhaps tutorial? > > A tutorial section would be nice, however, we dont apparantly have > any such section :) > > > > > The on

Re: [PHP-DOC] Proposal - magic quotes

* Thus wrote Aidan Lister: > > A few topics for this section: > > Yes, very good list Phillip, though I'm not sure the content lends itself to > the security section. Perhaps features, perhaps tutorial? A tutorial section would be nice, however, we dont apparantly have any such section :) > >

Re: [PHP-DOC] Proposal - magic quotes

> A few topics for this section: Yes, very good list Phillip, though I'm not sure the content lends itself to the security section. Perhaps features, perhaps tutorial? I've documented the "official" way to disable it, now. See http://au.php.net/manual/en/function.get-magic-quotes-gpc.php http://l

Re: [PHP-DOC] Proposal - magic quotes

On Monday 30 August 2004 09:46, Aidan Lister wrote: > "Derick Rethans" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > On Sun, 29 Aug 2004, Gabor Hojtsy wrote: > > > > I think we need to create a section in the manual, similar to > > "References > > > > > Explained" with all the

Re: [PHP-DOC] Proposal - magic quotes

"Derick Rethans" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Sun, 29 Aug 2004, Gabor Hojtsy wrote: > > > > I think we need to create a section in the manual, similar to "References > > > Explained" with all the information about magic quotes. > > > > > > What do you think? > >

Re: [PHP-DOC] Proposal - magic quotes

On Sun, 29 Aug 2004, Gabor Hojtsy wrote: > > I think we need to create a section in the manual, similar to "References > > Explained" with all the information about magic quotes. > > > > What do you think? > > Would be nice. Three of the cornerstones are: register_globals, > references and magic_q

Re: [PHP-DOC] Proposal - magic quotes

I think we need to create a section in the manual, similar to "References Explained" with all the information about magic quotes. What do you think? Would be nice. Three of the cornerstones are: register_globals, references and magic_quotes :) Goba

[PHP-DOC] Proposal - magic quotes

I think we need to create a section in the manual, similar to "References Explained" with all the information about magic quotes. What do you think?

Re: [PHP-DOC] Proposal: CHANGELOG

On August 18, 2004 03:52 pm, Gabor Hojtsy wrote: > >>We may need a livedocs person to tackle this as the structure is already > >>in place. Using the same example we have the following in the > >>methodsynopsis (split from one line to fit in this email): > >> > >> > >> intwidth > >> > > > >

Re: [PHP-DOC] Proposal: CHANGELOG

We may need a livedocs person to tackle this as the structure is already in place. Using the same example we have the following in the methodsynopsis (split from one line to fit in this email): intwidth I added a patch to do this. http://www.powertrip.co.za/livedocs/ Please notice Ilia

Re: [PHP-DOC] Proposal: CHANGELOG

* Thus wrote Philip Olson: > > > >> integer > >> choice="opt">width > > >> > > >> VS > > >> > > >> width > > > > > > Parameter has no type attribute, so only the former is possible. > > > > Ups, parameter also has no choice attribute, it is of paramdef. Which in > > turn can only be added

Re: [PHP-DOC] Proposal: CHANGELOG

> >> integer >> choice="opt">width > >> > >> VS > >> > >> width > > > > Parameter has no type attribute, so only the former is possible. > > Ups, parameter also has no choice attribute, it is of paramdef. Which in > turn can only be added inside a funcprototype according to the DocBook >

Re: [PHP-DOC] Proposal: CHANGELOG

width But anyway Goba what tags (if any) do you suggest for this? This last option seems to be fine with me. Should go as far as adding the type here too? integer width VS width Parameter has no type attribute, so only the former is possible. Ups, parameter also has no choice attribute, it is

Re: [PHP-DOC] Proposal: CHANGELOG

width But anyway Goba what tags (if any) do you suggest for this? This last option seems to be fine with me. Should go as far as adding the type here too? integer width VS width Parameter has no type attribute, so only the former is possible. Goba

Re: [PHP-DOC] Proposal: CHANGELOG

> > http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail > > > > As far as rendering, right now & and [] are typed into the parameter > > listing and this feels dirty. If we could use a role with the parameter > > tag (Curt suggested this in irc) it might solve this. For example:

Re: [PHP-DOC] Proposal: CHANGELOG

Done. But if this information is shown it seems we'd also have to include all parameter information, like if it's optional. Look again at the exif_thumbnail() docs for how this might look: http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail As far as rendering, right now & and [

Re: [PHP-DOC] Proposal: CHANGELOG

> >>Type information and by reference passing should be included IMHO too. > >>BTW the names of the parameters are missing from > >> > >> http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail > > > > Livedocs does not handle parameters with & correctly, they show > > up blank. I'l

Re: [PHP-DOC] Proposal: CHANGELOG

Type information and by reference passing should be included IMHO too. BTW the names of the parameters are missing from http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail Livedocs does not handle parameters with & correctly, they show up blank. I'll clean exif up, and add the typ

Re: [PHP-DOC] Proposal: CHANGELOG

> > (ii) Parameter List: I'd like to see this kept as compact as > > possible, so I'd prefer to do without the vertical spacing > > between the parameter name and its description. (Also, if it > > were possible to merge the top and bottom dashed borders, that > > would be great!)

Re: [PHP-DOC] Proposal: CHANGELOG

* Thus wrote Gabor Hojtsy: > > BTW the names of the parameters are missing from > > http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail livedocs doesnt seem to like: &width And is very picky with whitespace between as well. Curt -- First, let me assure you that this is no

Re: [PHP-DOC] Proposal: CHANGELOG

(ii) Parameter List: I'd like to see this kept as compact as possible, so I'd prefer to do without the vertical spacing between the parameter name and its description. (Also, if it were possible to merge the top and bottom dashed borders, that would be great!) However, I would lik

Re: [PHP-DOC] Proposal: CHANGELOG

Philip Olson wrote: I thought about this but here's why I went with one description. First, the short definition (purpose) is already in the refpurpose of the function. Also, writing a summary for each would be a bit too difficult. As far as using just the first para, I think it'd be confusing ha

Re: [PHP-DOC] Proposal: CHANGELOG

> >> I thought about this but here's why I went with one description. > >> First, the short definition (purpose) is already in the refpurpose > >> of the function. Also, writing a summary for each would be a bit > >> too difficult. As far as using just the first para, I think it'd > >> be confusi

Re: [PHP-DOC] Proposal: CHANGELOG

Gabor Hojtsy wrote: I thought about this but here's why I went with one description. First, the short definition (purpose) is already in the refpurpose of the function. Also, writing a summary for each would be a bit too difficult. As far as using just the first para, I think it'd be confusing ha

Re: [PHP-DOC] Proposal: CHANGELOG

I thought about this but here's why I went with one description. First, the short definition (purpose) is already in the refpurpose of the function. Also, writing a summary for each would be a bit too difficult. As far as using just the first para, I think it'd be confusing having it so far apart

RE: [PHP-DOC] Proposal: CHANGELOG

> > Oh, I like these! I have a few comments that I'd like to cast into > > the pool for discussion: > > > > (i) Personally, I'd like to see the Parameter Information and Change > > Log before the full description, so I'd go for something like: > > > > Definition(proto + *short* descr

RE: [PHP-DOC] Proposal: CHANGELOG

On Wed, 11 Aug 2004, Ford, Mike [LSS] wrote: > Oh, I like these! I have a few comments that I'd like to cast into > the pool for discussion: > > (i) Personally, I'd like to see the Parameter Information and Change > Log before the full description, so I'd go for something like:

RE: [PHP-DOC] Proposal: CHANGELOG

On 10 August 2004 23:53, Philip Olson wrote: > > I'll work on some examples, this is going to be good. > > Here's an example where: > > * Two new sections: Parameter listing and CHANGELOG > * The parameter listing is a variablelist > * The CHANGELOG is a table > > http://livedocs.phpp.o

Re: [PHP-DOC] Proposal: CHANGELOG

> I'll work on some examples, this is going to be good. Here's an example where: * Two new sections: Parameter listing and CHANGELOG * The parameter listing is a variablelist * The CHANGELOG is a table http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail This looks pretty

Re: [PHP-DOC] Proposal: CHANGELOG

If you expect a table layout, why overload simple paragraphs with attributes? If it is going to be a table, then para is not right for the markup IMHO. It does not fit semantically and does not fit into DocBook either. BTW I have not checked, but I don't think docbook has a version attribute wh

Re: [PHP-DOC] Proposal: CHANGELOG

> > The above would output something similar to: > > > > CHANGELOG > > > > --- > > |Version | Role | Description | > > --- > > |4.3.0| |foo() is binary sa

Re: [PHP-DOC] Proposal: CHANGELOG

Okay this sounds good, let's do it! The following would go right along with our new refsect1 style, does it appear doable? &reftitle.changelog; foo() is binary safe. The length parameter is optional with a default value of 1024. length The above would output something simil

Re: [PHP-DOC] Proposal: CHANGELOG

> > > > > > length > > 4.2.0 > > > >Became optional with a default value of 1024. > > > > > > ... > > > > > > Maybe it's not generic enough, could we cover every condition? > > , , etc. Thoughts? > > As the TODO suggests we planned to introduce roles, and not new tags. In >

Re: [PHP-DOC] Proposal: CHANGELOG

What it will contain: 1) Parameter changes (new, modified, ...) 2) Function changes (new features, new behaviors, ...) 3) PHP Version info for each change From TODO: new roles: seealso, newparameter, and changedparameter. That idea is similar and here's one of the threads on the topic: http://m

Re: [PHP-DOC] Proposal: CHANGELOG

Now as to the CHANGELOG, I am guessing nobody will implement it in DSSSL (I know I won't) so focusing on livedocs may end up happening. Livedocs or bust, 2004! Or 2005, 2006, 2007,. I don't mind focusing on livedocs, because I have some free time now. But I would like to have the oficial websi

Re: [PHP-DOC] Proposal: CHANGELOG

> > > This would be great and it's a perfect time to implement because > > > when people update old docs to the new refsect1 style we would > > > also implement these changelog entries! Woohoo!!! > > > > What is the new refsext1 style? The credits tag?... > > Each manual page is split up in sectio

Re: [PHP-DOC] Proposal: CHANGELOG

> > A partial proposal: CHANGELOG refsect1 > > > > What it will contain: > > 1) Parameter changes (new, modified, ...) > > 2) Function changes (new features, new behaviors, ...) > > 3) PHP Version info for each change > > > > From TODO: > > new roles: seealso, newparameter, and changedparameter.

Re: [PHP-DOC] Proposal: CHANGELOG

> A partial proposal: CHANGELOG refsect1 > > What it will contain: > 1) Parameter changes (new, modified, ...) > 2) Function changes (new features, new behaviors, ...) > 3) PHP Version info for each change > > From TODO: > new roles: seealso, newparameter, and changedparameter. Of course this is

Re: [PHP-DOC] Proposal: CHANGELOG

I like the theory, its always handy to tell what has changed between version x and version y. The implementation on the other hand, will be a bit more interesting i think. Nathan. On Wednesday 28 July 2004 12:25, Philip Olson wrote: > A partial proposal: CHANGELOG refsect1 > > What it will cont

[PHP-DOC] Proposal: CHANGELOG

A partial proposal: CHANGELOG refsect1 What it will contain: 1) Parameter changes (new, modified, ...) 2) Function changes (new features, new behaviors, ...) 3) PHP Version info for each change >From TODO: new roles: seealso, newparameter, and changedparameter. That idea is similar and here's

Re: [PHP-DOC] proposal: changes to the style definition

> Gabor: obviously I could change it and then build it locally, but what i am > trying to ask is how that would affect www.php.net - where I wanted to replace > the current definition. :) > > It may be that i am not making any sense, or not understanding you, for which > i apologise, and we can tr

Re: [PHP-DOC] proposal: changes to the style definition

> > The language it was written in is DSSSL, a LISP dialect. I was unable to > > understand most of it :(( > > well, for me it still works better than the other LISP dialect that > doesn't even look like LISP (XSLT) ;) XSLT is at least readable for me. Maybe I'll get into some more DSSSL, as I w

RE: [PHP-DOC] proposal: changes to the style definition

hmm, I am sure there must be some way of learning / getting into it. :) James > -Original Message- > From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 08, 2002 10:39 AM > To: Gabor Hojtsy > Cc: James Cox; phpdoc > Subject: Re:

Re: [PHP-DOC] proposal: changes to the style definition

Gabor Hojtsy wrote: > The language it was written in is DSSSL, a LISP dialect. I was unable to > understand most of it :(( well, for me it still works better than the other LISP dialect that doesn't even look like LISP (XSLT) ;) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-

RE: [PHP-DOC] proposal: changes to the style definition

Hi, Gabor: obviously I could change it and then build it locally, but what i am trying to ask is how that would affect www.php.net - where I wanted to replace the current definition. :) It may be that i am not making any sense, or not understanding you, for which i apologise, and we can t

Re: [PHP-DOC] proposal: changes to the style definition

> Right now, we use the style as seen here : http://www.php.net/manual/en/install.windows.php and it's really not very clear that we are trying to highlight it as something that _must_ be read, since it's really important. (in theory :)). > > I propose something much lighter (not having that ugly

[PHP-DOC] proposal: changes to the style definition

hey guys, I wonder what you would think of a slight change to the style for the tags. Right now, we use the style as seen here : http://www.php.net/manual/en/install.windows.php and it's really not very clear that we are trying to highlight it as something that _must_ be read, since it's

Re: [PHP-DOC] [PROPOSAL] database security issue

> I'd love to know your position on writing a short section > about "SQL injection and others" in security.xml, something > similar has already done for filesystem security. > > It aims to be an introduction into the very basics of PHP > related database security and vulnerability, because: >

[PHP-DOC] [PROPOSAL] database security issue

Hello, while surfing on the net I've found a few articles about web based appliction security and a dedicated site: Open Web Application Security Project where I read this article: http://www.owasp.org/projects/asac/iv-sqlinjection.shtml I'd love to know your position on writing a