Wikipedia:Peer review/PHP/archive2

PHP

Article (edit | visual edit | history) · Article talk (edit | history) · Watch • Watch peer review

This peer review discussion has been closed.
Feel free to edit the article instead of mentioning any copyedit changes here, if you feel it is a minor change.

I've listed this article for peer review because I want it to be a WP:FA some day.

Thanks, Gary King (talk) 20:30, 16 March 2008 (UTC)[reply]

In my opinion, this article is too technical. I'd appreciate it if anyone who has the time could help out and make it less technical by removing information that an average reader would either not understand or not care about. Also, please feel free to include information about PHP that would interest a typical reader; I would imagine this would include information regarding its popularity (a lot of people see URLs end in .php but wonder why PHP is so popular), and information such as how PHP can be vulnerable and its downsides and openness to hackers, since people generally understand that programming languages are never immune to hackers. And etc. Gary King (talk) 21:28, 16 March 2008 (UTC)[reply]

A script has been used to generate a semi-automated review of the article for issues relating to grammar and house style. If you would find such a review helpful, please click here. Thanks, APR _t 02:55, 17 March 2008 (UTC)[reply]

Comments by PeterSymonds (talk · contribs)

Addressed

Resolved comments by PeterSymonds (talk · contribs)

"A paradoxical indicator of PHP's popularity is the amount of software vulnerabilities related to PHP applications and identified by a CVE (Common Vulnerabilities and Exposures) on the National Vulnerability Database, which amounted to 12% in 2003, 20% in 2004, 28% in 2005, 43% in 2006, 36% in 2007, 38% for the first two months of 2008." Wow, a long sentence! Could you break it down a bit? It's gramatically correct, yes, but it's length distracted me. Skimreaders might not bother.
"More than one-quarter of all-time listed software vulnerabilities are related to PHP." All-time – does that mean every software vulnerabilities in history? If it does, I think it should be changed; while I respect that it's a more American article, all-time is a bit colloquial.
"...even more than one-third in recent years, and most of these defects can be exploited remotely." I don't understand. I think you should add more about specific defects. Also, "even more than one-third" might be a bit non-neutral.
Sentence juggling and rephrasing. These defects, followed by These vulnerabilities in the next sentence.

The general rule is to have a reference at the end of paragraphs. In the first paragraph in the "Usage" section, only the first sentence is referenced. If the same reference covers all sentences, put it at the end.
"The number of installations is different from the number of sites actually using those installations, but this statistic does reflect the popularity of PHP." Is this sentence really necessary? For me, it seems simply to reitorate what was said earlier.
"The static method and class variable features in Zend Engine 2 do not work the way some would expect." Who and why would they want it to work differently?

"it can raise issues with security and performance". What issues in particular?
"Code optimizers..." Are there any examples?

"The most commonly used packages for source code protection are from Zend Technologies and ionCube Ltd." Needs a citation.
"The nature of the PHP compiler is such that there are often many opportunities for code optimization." Needs a citation.
"Both commercial (e.g. Zend Platform) and open source accelerators (e.g. xcache, eAccelerator, APC) are available." Needs a citation.

"However, critical security updates for PHP 4 will be provided until August 8, 2008." I take it that's meant to be "will not be"?

"These vulnerabilities are triggered by bad programming habits (especially a lack of input sanitization) and doubtful features of the language (e.g. now deprecated register globals) which result in code injection, cross-site scripting and other application security issues." I'm not clear on "bad programming habits" and "input sanitization". I assume it's the incorrect input that causes the program to run badly? That needs to be more clear. I'm also not clear on "doubtful features of the language" or "register globals". What features were doubtful?

"The disadvantage of this latter approach is that a special extension has to be installed on the server in order to run encoded scripts; however, the approach of encoding compiled code and use of an extension offers typically the best performance, security and opportunity for additional features that may be useful for developers." Does it? Who says so?
I think the lead needs to be longer; at least 3 or 4 paragraphs, breaking down summaries of all the info that follows.

Great work on addressing those comments! ~~I do have a few more~~(now addressed; see above):

Reliability of sources. You link to PHP security blog to verify a claim, which isn't a reliable source because anyone can edit them. You should generally stick to reliable and well-reputed sources (either book or web) to avoid scrutiny at GA/FAC.
- fixed Gary King (talk) 03:42, 24 March 2008 (UTC)[reply]
Also, images; can more be added? Even a technical image of PHP script or something would do the trick. There are two at the start, but I don't want to move them around because they're appropriate for that section.
- added Gary King (talk) 03:52, 24 March 2008 (UTC)[reply]

PeterSymonds | talk 22:07, 16 March 2008 (UTC)[reply]

That's about it, and afterwards it should be ready for a second GA review. By the way, has this article had a copyedit? I think it needs one before you ask it to be reviewed again, just for minor grammatical/MOS issues. PeterSymonds | talk 20:24, 16 March 2008 (UTC)[reply]

PeterSymonds | talk 21:18, 16 March 2008 (UTC)[reply]

Unaddressed

A script has been used to generate a semi-automated review of the article for issues relating to grammar and house style. If you would find such a review helpful, please click here. Thanks, APR _t 02:55, 17 March 2008 (UTC)[reply]

Comments from MusicalConnoisseur (talk · contribs)

All MC's comments have been addressed

Ditto Peter on long sentences. ("Lerdorf initially created these Personal Home Page Tools to replace a small set of Perl scripts he had been using to maintain his personal homepage, such as display his résumé, and record data such as how much traffic his page was receiving.") Also, some sentences may be a bit too blunt. (You might want to specify the reasons for development here: "PHP 6 is currently under development.")
- done Gary King (talk) 04:25, 24 March 2008 (UTC)[reply]
Commas may have to come after the second-to-last unit in a list. ("The syntax was similar to Perl but was more limited, simpler and less consistent.")
- done Gary King (talk) 04:26, 24 March 2008 (UTC)[reply]
Again, rewording. ("Public testing of PHP 3 began and the official launch came in June 1998." could be "Public testing of PHP 3 began it was launched in June 1998.")
- done Gary King (talk) 04:27, 24 March 2008 (UTC)[reply]
There cannot be a comma between the subject and its verb. ("The most recent update released by The PHP Group, is for the older PHP version 4 code...")
- done Gary King (talk) 04:28, 24 March 2008 (UTC)[reply]
There is uneven punctuation in the table (If you would like to use periods, use them consistently; conversely, do not use them throughout if you choose not to.)
- done Gary King (talk) 04:36, 24 March 2008 (UTC)[reply]

Many thanks, Gary, for addressing my comments. :)--~~MusicalConnoisseur~~ Got Classical? 00:02, 25 March 2008 (UTC)[reply]

Comments from Alastair Haines (talk · contribs)

The overall impression I gained of this entry was very positive -- content verifiable, expression clear and NPOV. It "looks" like a GA already (I, for one, would class it so).

For FA status we probably need some kind of consensus regarding an appropriate level of content development. This matter has been raised already, but not resolved. My taste differs with the previous comments, in that I think the entry is currently aimed "just about right". I think this is reinforced by its structure. The lead and early sections address wider and simpler issues, later sections address more technical aspects of PHP.

Yes, there is some jargon in the entry, right from the word go. However, where jargon is unfamiliar to a reader, it is wikified. Personally, I find this preferable in many cases (certainly in the case of this entry), than "reinventing the wheel" and explaining jargon in every article that uses such terms.

I am sure an element of my assessment, in this case, is due to personal experience in commercial programming. I know enough not to get lost quickly, but am sufficiently out-of-date that I enjoyed learning new terms while being brought up-to-date.

The Wiki entry on PHP ought to be FA. Many students study PHP, and potential students -- likely decidedly internet aware, for obvious reasons -- may research this language at Wiki before opting for a course. In fact, a Wiki article can be an excellent community service, due to its independence from the economics of education and software marketing.

The entry needs to lie somewhere between a PHP textbook and a computer magazine advertorial. I'm happy it lies at about the right point. Change, imo, would need to tend more towards the textbook than the advertorial, since readers do not have to read the whole entry. In other words, I think the article could do with more info, not less.

I would suggest the "upper bound" for content detail be left to those who know more about the full extent of content that could be included. For the rest of us, I think we should be asking, Do I have questions this entry didn't answer? or Did it raise questions for me, without providing answers (or links to answers)?

Finally, there are a number of outstanding minor copyedit issues. I will smooth a little text here and there. However, copyedit is independent of content issues, which are the main concern for FA.

Hope my comments progress discussion and progress this entry towards FA. Congratulations to all those who have contributed so far, having brought it very close already.