Talk:PHP/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

Old text from before September 2002

What does the first P in PHP stands for?

I assume the H is hypertext, the last P is preprocessor.

The 'P' in PHP stands for PHP. Yes, it's one of those recursive acronyms, like "GNU's not unix". -- DrBob

---

I could understand the origin of GNU because gnu itself is a real word, so the word play at least make sense.

The G is chosen so that the acronym makes a real word.

PHP is totally out of the blue.

Why not XHP where X is recursive?

Why the P?

It is traditional for publication to expand on what an acronym stands for when it is referenced for the first time.

From all the reference I have read, PHP is used as a word instead of an acronym.

I read some history of PHP that it was the original author's "Personal Home Page" tool.

Perhaps the acronym starts out as "Personal Home Page".

But since it does not match what it actually is, the meaning is dropped and replaced with a faddish recursive arconym with no explanation on where the first P come from.

Anyone know the real origin of the name?

---

All your doubts and inquiries are easily solved if you take the time to read the PHP manual:

http://www.php.net/manual/en/intro-history.php

The historical reasons are there for all to see, just a little search and reading will always make you avoid misunderstandings.

OK

---

The page is now http://www.php.net/manual/en/history.php and there's a note by its inventor in some old archive but I can't find it now.

---

This is a Wiki: you can go ahead and put as much of this as seems appropriate in the article itself. Someone who already knows about a subject--that's you--will explain it better than someone who doesn't. Vicki Rosenzweig

Criticisms section

What happened to the "List of PHP Applications" page? That was a really useful resource.

I wish there were a consistent "voice" employed in the Criticisms section of this page. I wish there were a simple table editor available in WYSIWIG mode employed throughout this Wiki. I wish there were a non-techy-oriented version alongside, or somehow more prominently displayed/call-attention-to throughout the article. Anyoo, I made the last sentence first in the criticisms section. Hope that's ok.

)olc

I wish the whole Criticisms section would consist of anything else than propaganda...

I also wonder if the criticisms section can be called objective. The mention of ASP.NET might not be thought as an ad, but it comes across as an recomendation: "Don't take PHP, take ASP.NET."

It's a statement of fact.. feel free to add other web app systems which aren't as vulnerable to cross-site scripting attacks as PHP. Rhobite 22:54, Dec 26, 2004 (UTC)

I love PHP to death, and while I use ASP.NET at work I very much dislike many of the things it imposes and ways it forces you to do things. However, I was the one who added the criticism, and indeed the "ad" for ASP.NET. Being able to point out the faults in a language and not be afraid to mention other, inferior (in your opinion) languages is called confidence. And if people see the "ad" for ASP.NET, and like it better... that's great! There's no reason everyone has to use PHP; just reasons why PHP is better (but, that's just my opinion, not theirs.) -[Unknown] 10:30, Dec 27, 2004 (UTC)

I'm not the one disputing the neutrality of this article, however, I consent. Should that really be in a Wikipedia article?

I think it would be sufficient for solving this particular issue only to refer to "other languages" and change the wording from "PHP does not" to "PHP leaves it to the programmer".

Furthermore the whole criticisms section should be reworked.

I don't really see the point of the comparison with ASP.NET. The issue at hand, is the lack of input sanitation, and that is what the sentence should focus on, not weather ASP.NET has it or not, which strictly speaking, is immaterial in an PHP-article.Jerazol 09:47, 8 May 2006 (UTC)

I don't mind comparisons to other languages and platforms. However, goose, gander. Feel free to go into the ASP.net article and compare it to PHP unfavorably. --Stevietheman 16:32, 27 Dec 2004 (UTC)

PHP extension

... other sites (like Wikipedia) tend to dispense with the .php extension. This is (I assume) true, but the odd ".phtml" extension does sneak out from under the covers: this AFAIK is an HTML page with PHP content. Would it be fairer to say that Mediawiki (I assume rather than just Wikipedia) tends to hide most PHP-related extensions? Phil 14:54, Dec 17, 2003 (UTC)

The 'other' extensions, such as .php3, .phtml, etc. are all going out, especially because many servers don't parse them. The most universal one is .php, and it is by far the most often used. When you see this in MediaWiki, it's because you're following a "direct" link that isn't being redirected through a rewrite or path info.

It is a common thing to avoid use of the .php extension, and more significantly of query strings, when possible because Google tends to treat sites it can flag as "generated content" much worse than those that are static (or generated ones that pretend.) However, this is okay if you don't want the page on Google - for example, this edit page is wiki.phtml?... and no one searches for edit pages, so this is perfect.

My point is, it's not that MediaWiki is hiding .php and failing to hide .phtml, but rather that it is just not *always* hiding the .phtml. I would suggest the text is fine as-is. -[Unknown] 21:05, Nov 9, 2004 (UTC)

It's not Mediawiki hiding the .php extension at all, its the webserver (Apache). In that case it is fairer to say that it is this website, not mediawiki, that hides the extensions. Borb 20:41, 12 Jun 2005 (UTC)

Advocacy

The article currently seems quite to advocate PHP a little too much. Pete/Pcb21 (talk) (Python programmer).

You first correct Python programming language and come back. I don't find any advocacy here. You should learn PHP to know what is true and what is hype.--Rrjanbiah 07:49, 4 Mar 2004 (UTC)

I agree entirely.

• "The error messages generated by PHP are easier to comprehend than those of Perl." is POV nonsense - the source cited is not at all notable or correct.
• There is no criticism of PHP5's added features as being irrelevent to most developers - take a look at each of "Applications built with PHP" and see that maybe 10 percent use even PHP4's OOP features.
• There is no criticism that PHP5 is not threadsafe - meaning Apache 2's multithreaded MPM is useless for servers running PHP.
• Finally there is no mention of PHP and applications written with PHP having a notorious security record - at a glance I'd say 90% of the applications in "Applications built with PHP" have at some point had a serious security vulnerability in the past year. You may argue that this is not relevent to the language itself, but it really is when you consider PHP works to make it easy to write unsafe code (as currently touched upon in the Criticisms section) and does not contain sorely needed features such as variable tainting and deprecation of old, unsafe functions.

--Ctz 23:13, 25 Mar 2005 (UTC)

Agree with the first one, or at least it's not worthwhile to even bring up in the article. The second one is your own POV, but it might be worthwhile to add info about the degree of OOP implementation in PHP apps. The third one sounds like a good criticism. The fourth one is your POV... "notorious"? Please. — Stevie is the man! ^{Talk | Work} 17:20, 26 Mar 2005 (UTC)

I concur on point 2 et 4 being POV

Point 3 is untrue, all of the php ``core is threadsafe, what happens is that many non-core modules are not threadsafe. Making point 3 land under the same POV category as point 4, it's simply not under their control. It is worth mentioning, just not the way you put it. However it is an expected flaw with such a major change, and the same will likely occur with php6. No contest on point 1 though. A final point on point 4. It is true that php does not implement a lot of ``safety features, but that does not make it hard to write safe code. All of those features can be written in php and reused 90% of the time. It's the fact that the community does not advocate or teach security enough that people don't correctly use the tools. I will agree that php generally has a bad name in security, but that doesn't mean security is hard. It's just not a common conern amoung php programmers.

Advocacy II

The following statements sound awfully "POV" to me:

Many PHP programmers have reported having had trouble trying to learn other languages in the past and ultimately giving up after each attempt until attempting to learn PHP. The ease of programming in PHP has made it so these programmers are able to learn the basics of programming and are then able to continue on to other languages suchs as C/C++ or Perl/Python/Java and then finding themselves back programming in PHP for its speed of development in comparison to other languages.

I'd use a stronger word than "POV", but this is a family encyclopedia. :-)

Comments? Does anyone have any hard data to support the claims in this 'graph?

Atlant 17:20, 28 Mar 2005 (UTC)

Boy is that total BS or what - I recenty learned Python, I had NO problem with it. Please remove!

--213.89.140.71 13:45, 28 February 2006 (UTC)

PHP Library/extension list

Listings

PHP is slowly moving ALL extensions into [PECL] meaning all the listed extensions will be mixed in with various "not-so-popular" extensions like [Net_Gopher] so eventually this list will be enormous. Also, all these PECL extensions will be documented at php.net/manual so this is something to discuss. Eventually there will be 100's to one day 1000's of extensions all of which can't be listed in this Wiki. philip

Date

Could somebody provide a date for the complete list of libraries? In other words "This is a complete list of libraries as of <insert date here>." 216.74.222.174 05:37, 27 Mar 2004 (UTC)

Introduction

I think the parenthetical list of possible expansions of the abbreviation detracts from the introductory paragraph. I think it should be reduced to:

PHP (PHP Hypertext Preprocessor) is a widely used open-source programming language...

The other names should be moved somewhere else in the article. Possibly to the history section? --Rory ☺ 14:31, Jun 16, 2004 (UTC)

Sounds good to me. As far as I'm concerned, go ahead and make the changes. -- Stevietheman 14:55, 16 Jun 2004 (UTC)

I forgot to mention earlier that I went ahead and made the changes.  :) -- Stevietheman 14:51, 7 Aug 2004 (UTC)

I didn't see this remark until just now, but earlier today, I made another change along these lines. Of course, since then the page has been vandalized a bunch of times (sigh)! Assuming the page isn't currently vandalized, read it and see what you think...

Atlant 18:51, 3 Mar 2005 (UTC)

Looks good to me. Thanks. — Stevie is the man! ^{Talk | Contrib} 23:05, 3 Mar 2005 (UTC)

Pros and cons

I am definitely a major supporter of PHP, but this article could use a "Pros and cons" section like that in the Delphi article. It's a good way to help people better understand if this is the language/platform they should use for their project, and have the ability to compare/contrast to other languages' capabilities. I probably won't have the time to write this in the near future, but if anyone is so inclined, please go ahead and do it. -- Stevietheman 14:50, 7 Aug 2004 (UTC)

I am both a fan AND detractor of PHP. I hope my addition of a criticism section meets with everyone's approval. AdmN 19:59, 24 Aug 2004 (UTC)

Looks like a good writeup or at least a start. I cleaned it up a little. -- Stevietheman 20:41, 24 Aug 2004 (UTC)

Unfortunately, some of the criticisms are funny and looks like intentionally found/written. Just curious, where else such criticism is available? --Rrjanbiah 05:33, 25 Aug 2004 (UTC)

I'm not sure what you mean by "intentionally found," though I assume you are implying a non-neutral point of view. I use PHP on a semi-regular basis. Like any language on Earth, it is great at some things, and not so great at others. All in all, I enjoy PHP. It allows me to do things that would be nearly impossible, (or at least really hard), without it. It is, in fact, the only server-side technology that I have ever really gotten into.

This page: [1] both provides criticism and the following links: [2], [3], [4], [5].

AdmN 06:46, 25 Aug 2004 (UTC)

PHP is now 5 and many of the criticisms are now not valid. Like many other languages, PHP is also inspired by C's function names (like strcmp, stricmp, etc). I see, much of the criticism are like complaining C's syntax by an assembler diehard who is confined to only one way of thinking and syntax. --Rrjanbiah 10:17, 25 Aug 2004 (UTC)

We shouldn't be afraid of criticism. The listed criticisms of PHP 4 are based on facts (otherwise, I would have edited them out). We should also realize that many of us will be using PHP 4 for a long time before migrating to PHP 5. Even if PHP 5 has fixed some of the problems, most PHP developers have to deal with web hosting providers that haven't upgraded for months (or maybe even years) to come. -- Stevietheman 13:56, 25 Aug 2004 (UTC)

Fair enough, but criticising old version (which is fixed and improved now) is not pleasing. Also, _criticising PHP because it is PHP_ is not interesting, IMHO; otherwise the computing world is only with 1s and 0s without C, PHP, etc. --Rrjanbiah 06:23, 26 Aug 2004 (UTC)

Not pleasing to whom? It's pleasing to me to know facts about any language I might choose for a project. Further, PHP is not being singled out here. Delphi has a "Pros and cons" section, and other languages includes criticisms as well. Let's not get worked up over this. -- Stevietheman 14:45, 26 Aug 2004 (UTC)

IDE explanations please

The IDE section could do with being more than just a list of links. I for one could do with some sort of explanations as to the relative strengths/weaknesses of the various IDEs, together with which OS they work on. --Phil | Talk 10:24, Aug 20, 2004 (UTC)

There is a wonderful site dedicated to this [6]. My favorite is PHPEdit [7] (now not free), PHP Coder, devPHP and Komodo (All on XP). --Rrjanbiah 05:39, 25 Aug 2004 (UTC)

None of those are IDEs though, if you're talking about IDEs you're talking ZDE and TruStudio tbh.. Ambigus titling there?? IDE implies debugging and things to me.. --Streaky 01:29, 27 February 2006 (UTC)

Library list links

The library list contains some links to completely irrelevant articles like stream (chiefly about moving water) and token (a disambiguation page) that should be renamed to their appropriate computer counterparts. Livajo 19:49, 24 Aug 2004 (UTC)

I had updated about 1 third of the list (with links to manual and checking all wiki-links), saved it, to continue a day or two later. But my changes was reverted by Stevietheman. Why? Because it was partial, or because my work is unwanted? I don't want to finish it, if it is just going to be reverted again. -- Myplacedk 22:07, 2004 Sep 2 (UTC)

I think it would be fair to re-revert Stevietheman's edits if he doesn't give a reason for his reversion. I glanced at the history and I can't see any clear reason to revert.—Rory ☺ 23:01, Sep 2, 2004 (UTC)

Reason: There's no point in providing external links there--it's clutter. The wikilinks should point to articles that provide the external links. It's better to trust that the wikilinked articles will provide that info, and if they don't, they will/should eventually. -- Stevietheman 23:22, 2 Sep 2004 (UTC)

It hink there is a point. For example, the current list mentions the COM-extention, which of course linked to Component object model (AFTER my update). But that article does not mention PHP's implementation of it, of course. The "Direct IO" extention linked to an article about what I/O is, in computer terms. This is also great, but of course, again, the article says nothing about the PHP implementation of it. I think these external links are quite useful, but if I'm the only one... -- Myplacedk 05:13, 2004 Sep 3 (UTC)

This is an encyclopedia article, not the complete unabridged PHP reference. -- Stevietheman 05:30, 3 Sep 2004 (UTC)

Okay, I agree about clutter but didn't the edits also remove ambiguous links? I would recommend the same edits but without the external links for the reasons given by Stevietheman.—Rory ☺ 00:44, Sep 3, 2004 (UTC)

Yes, the external links was the easy part. The time consuming part of my work was updating the wiki links. I'll re-revert... -- Myplacedk 05:13, 2004 Sep 3 (UTC)

I will agree to any fixes of ambiguous links. I realize that I may have swept away a small degree of goodness in the revert I made. Just don't bring back the external links, please. -- Stevietheman 02:53, 3 Sep 2004 (UTC)

If the wiki links really isn't more worth to you, it might as just remove all af them, then it shouldn't take more than a couple of minutes to make the complete update. :-/ -- Myplacedk 05:13, 2004 Sep 3 (UTC)

And I'll revert any such changes that don't make sense. -- Stevietheman 05:30, 3 Sep 2004 (UTC)

Code Example

The article features a poor code example. Control structures are not pointed out, the // comment method could be better placed to show its features. Print and echo do not do the same thing--echo dumps data out immediately to the browser, whereas I think print dumps it when it's finished processing the script. Using echo lots of times is thus not very efficient. Yes, this is an encyclopedia article, not a php reference, but a code example that showed more features of the language would be better appreciated by readers checking out different languages. --User:66.226.249.19

Feel free to enhance and expand the example. -- Stevietheman 20:02, 9 Sep 2004 (UTC)

I turned it into a 99 bottles of beer -example, trying to demonstrate various structures in it. What do you think? --ZeroOne 21:49, 9 Sep 2004 (UTC)

Looks pretty good, although it could be made to require less width (too much word wrapping) and fix a few errors. I'm too tired to tackle it tonite though. -- Stevietheman 06:14, 10 Sep 2004 (UTC)

I can't believe some people don't read the manual before reverting changes that are specifically noted not only in the comment for the change but within the product's own documentation. For example, print is not a function it is considered a language construct and as such as do not require ( ) to enclose it's contents and doing so only confuses how the construct actually works -- it doesn't return anything. You can't go $var = echo 'hello world'; can you? This simply adds needless complexity, btw, this could make a good mention in the Criticisms section. Quadra23 Sep 7, 2005.

I'm sorry, I'm using 1600x1200 resolution so I really don't know how the lines will wrap with lower resolutions. I tried to account for this but apparently didn't do it well enough. The code sure runs (PHP 4.3.something) so there are no syntactical errors. :p --ZeroOne 10:49, 10 Sep 2004 (UTC)

Sorry. I didn't necessarily mean syntax errors. -- Stevietheman 16:55, 10 Sep 2004 (UTC)

The differences between echo and print are often not well understood, because they are so similar. I often here people say they think there's a specific difference.. that doesn't actually exist. Please see the following, from php.net's page on print():

http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40

In other words, the difference is that echo can take multiple parameters. This is noticably faster, in my benchmarks, than single quotes concatenated together *OR* double quote interpolation. Regardless, that's not the point... I just wanted to note that there is no such difference.

I've also slightly updated the code example with some minor conventional issues, because most people will agree it looks nicer to put spaces around operators. Additionally, I tweaked the wrapping to look nicer in 800x600, because it was so close. If you disagree, I'm sorry... it can easily be changed back.

99 bottles shouldn't work. The multi-line comment is terminated too early, on the second line:

/*
*  /* ... */ is a comment that can span one or many lines.
*  This kind of comment does not need stars (*) in the beginning of each line,
*  but including them is a common practice. // and # are also comments.
*  They only comment the text that are after them in the same line. They have 
*  no special ending character.
*
*/

Has anyone actually tried these examples out to see if they work? -- Phyzome is Tim McCormack 21:32, 2005 Mar 18 (UTC)

How about coloring the code examples :) it would make article more user friendly :) --sverde1 18:52, 6 April 2006 (UTC)

Parrot (future of php)

I'd put a reference somewhere to possible future directions for the project. For example Lerdorf has declared in an interview they could take in account Parrot as a possible basis for future releases.

Also the licence type is not even indicated, nor the disputes about it. And history part, besides being a bit poor in my opinion, seems to overstate the role of Zend contribution. It's sure relevant but after all is a collaborative effort. ciao --Balubino 18:07, 14 Sep 2004 (UTC)

Here's some reference. Rasmus interview at Linux Bangalore meeting where he cites the convenience of using the parrot engine and why they are thinking about it. Then an article again by Rasmus which describes the beginning of the project and also the plans for the future. Finally php.net's history page in user manual. ciao --Balubino 18:31, 14 Sep 2004 (UTC)

Still even speculation for Rasmus TBH - certainly I've not read anything 'official' on the matter --Streaky 01:31, 27 February 2006 (UTC)

Coding standard?

Personally, I think the link just added, named "PHP Coding Standard", to be... not neccessarily so official. If I were new to PHP, I might think that was official with its name. I don't know what to name it otherwise, but I just wanted to ask... are things like that allowed? Could I write up a quick guide to PHP (I actually have, a decently-used tutorial on how to install the latest versions of PHP, MySQL, and Apache without the help of packages..) and just stick it on there, with a name like The Ultimate Guide to Life, the Universe, and Installation :P?

-[Unknown] 19:49, Oct 16, 2004 (UTC)

You might seriously consider contributing it to Wikibooks. --Phil | Talk 10:02, Oct 18, 2004 (UTC)

Perhaps so... but, my primary concern here is simply that I'm not so sure this article (PHP) is meant to be a respository of "unofficial" documents like one proclaiming itself to be the "PHP Coding Standard". Indeed, many of the function names built into PHP "violate" this supposed standard... -[Unknown] 16:30, Oct 18, 2004 (UTC)

So... I guess it's staying? Can it at least be given a different name, such as "Unofficial..." or "A common..."? -[Unknown] 09:49, Oct 27, 2004 (UTC)

PHP development

Following the recent "tidying" exercise, would it be an idea to move the sections on frameworks and IDEs to a new PHP development article? --Phil | Talk 14:08, Oct 20, 2004 (UTC)

Why? --Streaky 02:49, 1 March 2006 (UTC)

New criticisms?

Global variables such as $_GET, for retrieving information from the URL, could cause problems as users could
manipulate poorly written code to make the website not function as intended by the author.

And why is this? Did you know that I could manipulate argv such that poorly written C programs would fail? I could also manipulate the input variables for Perl programs on the query string or in POST data such that poorly written Perl programs would fail. And, why does global make them more fallable? Simply because you were taught global is bad in school?

Sorry, but I just don't see how that is a concern at all. The register_globals one is indeed a concern, and so is the fact that by default, users are not "jailed" into a certain directory. Another concern is that, on most systems, PHP runs as nobody, often meaning that files have to be writable by everyone for things to function properly.

But... superglobals such as $_GET? Security holes? How?

-[Unknown] 09:48, Oct 27, 2004 (UTC)

As of PHP version 4.2.0 register_globals defaults to off (including version 5.x). I think the point is an old one and should be removed.

I still think this criticism is about as worthwhile on the page as any "glowing terms" are, or any of the horde of external links. They should all three be gone, and only the correct stuff left. Sigh.

However, the register_globals issue is a huge thing. I began work on YaBB SE back two years ago on Christmas, and not long after they had a huge cross-site scripting security vulnerability. It only worked, of course, on register_globals servers... and 4.3.0 either had just come out or came out soon after... but, well, it was still a problem for 99% of the people using YaBB SE. It was also in previous versions, not just the new release, and caused quite a scare. I remember writing up packages to easily fix the bug... but, the damage was done and many many people were hacked.

The point of my dumb little story is that it's still a problem, and I expect it will be for some time. Last time I used osCommerce, it didn't work without register_globals on... and, there are even more less professional scripts out there, and tutorials on scripting, that all pretend register_globals is always on, and is a part of PHP. Because of this... hosts oblige; it is a standard feature of PHP now, simply because nearly every server on the Internet that has PHP installed also has register_globals enabled. And error_reporting set to E_ALL ^ E_NOTICE. And short_open_tag on. These are constants now. Which means, yes, it's still a problem... as much as I hate to say it is, as much as I wish PHP 5 could fix it. -[Unknown] 01:05, Dec 15, 2004 (UTC)

In response to: "And why is this? Did you know that I could manipulate argv such that poorly written C programs would fail? ( . . . ) Simply because you were taught global is bad in school?": Just because the same vulnerability exists in other languages does not mean we should not mention it in here. This is an encyclopedia article; I think that it should include as much information as it can. Though, I think it can be re-worded a bit, as what you say is still somewhat true. --qrc 03:50, Dec 19, 2004 (UTC)

The wording is totally rediculous. You're making it sound like if $_GET was not used (so I assume register_globals is better?) it would allieviate the problem. You're also ignoring $_POST, which is much more often the problematic one... not to mention $_COOKIE which so many people think is innocent.

However, those problems are NOT problems in PHP. They exist in every language, and can be said of any variable or data input from the user. I replaced your criticism with a more valid one; that PHP does not do any checking on the input by default. That actually makes sense for it to do - there's nothing for PHP to do to stop you from misusing $_GET.

And, if you mean using /etc/passwd in the query string, this is something PHP can protect by use of open_basedir. In other words, the criticism sounds more like a general one of newbie programmers than of PHP specifically. And the fact that it is not a criticism of PHP means it shouldn't be in the section for them!

Sorry, I just don't get why this would make any sense. -[Unknown] 08:21, Dec 19, 2004 (UTC)

Agreed, the above criticism about $_GET makes no sense unless you feel "The ability to read HTTP headers" is a bad thing and that's ridiculous. At any rate, regarding checking user input, isn't this a developers job? See also strip_tags(). --philip

reg globals is going bye-bye in PHP 6 - see http://www.php.net/~derick/meeting-notes.html#register-globals --Streaky 01:36, 27 February 2006 (UTC)

Incorrect link to newt

The link to newt is wrong but I can't find a corect link, should it be removed?

I would personally remove it... or, that is, not link it. -[Unknown] 21:02, Nov 15, 2004 (UTC)

Do something about it. I cant even find any documantation on google with "newt gui" about newt. Is it a real product?Patcat88 04:49, 9 Jan 2005 (UTC)

I de-linked it, as the article linked was about the animal version. However, there does appear to be a Newt text-based UI. --Stevietheman 04:58, 9 Jan 2005 (UTC)

No links at all?

Tregoweth, while I strongly support your motivations and intents... was removing ALL but one of the links really necessary? Sure, many of the links being added (mostly by unregistered users) were not needed, and there were far too many (perhaps a list of PHP development tools or something would be better?)... but removing all of them? -[Unknown] 09:16, Dec 9, 2004 (UTC)

I restored the links. I agree that there's probably some spam in there, but the removals should be more surgical rather than like a rape.  :) There were too many useful links for PHP developers there. -- Stevietheman 16:55, 9 Dec 2004 (UTC)

I'm not saying there shouldn't be any; just keep in mind who will be reading the article. Someone looking up PHP here probably doesn't know anything about it and is just looking for basic information, so links to development tools, etc., seem excessive. And shouldn't PHP developers have better places to look for links than here? :) —tregoweth 17:02, Dec 9, 2004 (UTC)

Perhaps this calls for a reorganization of the article or a split into separate articles. There are indeed many experienced PHP developers or experienced programmers in general who may want more extensive information about PHP, esp. about how it can be extended to do enterprise web application development. -- Stevietheman 16:44, 15 Dec 2004 (UTC)

Indeed... many of the links aren't useful, imho. For example, I am not going to even look through 22 "frameworks". To my experience they aren't that popular, really, and these aren't really articles that contribute to "PHP". If they are needed, they should be in Wikibooks or in their own article... at least in my opinion.

And, while tutorials are nice... we have the PHP wikibook which should include, theoretically, any tutorial material needed. (I know I've read somewhere that links should only be used for external information that cannot be brought into the article.) As it is, this article is getting spammed by low-grade tutorials with plenty of advertising on them. And, indeed, ones that cannot be edited and are not FDL... which is not, imho, the spirit of Wikipedia.

I don't necessarily disagree, but I'd like to see an intelligent paring down and moving into other spaces that are linked to, such as the PHP wikibook. -- Stevietheman 16:44, 15 Dec 2004 (UTC)

For example, the Mozilla Firefox article is very popular. There is a lot of development work on it, extensions (XUL), and etc... and it has eight external links. I think less than ten is a wonderful goal.... but definitely less than twenty five! -[Unknown] 00:40, Dec 10, 2004 (UTC)

Firefox probably has too few links. At any rate, this comparison is unconvincing because we're talking about a complex programming language, not unlike other complex programming languages. However, I certainly support the weeding out of light or superfluous links, as I always do. -- Stevietheman 16:44, 15 Dec 2004 (UTC)

Glowing terms

This article frequently speaks of PHP in glowing, exaggerative terms. I'll try to go through and change what needs to change but I am putting on an NPOV notice with the hope that people will help out. Examples: "thanks to its modular design", "easy interaction with a large number of relational database systems" (note the exclusion of MSSQL), "extensive documentation", "many contributors", "All of this "looseness" makes it very easy to do many things", "major step for PHP, because it represents its beginning adoption as a genuine programming language", "PHP, unlike ASP, has some of the largest free and open-source libraries", "PHP's object-oriented functionality has been very much enhanced", "There are many excellent help resources available".

It's also interesting that the criticism section is weasel-compliant, with much use of words like "alleged", "said to be", etc. No other section has this treatment. Rhobite 04:24, Dec 12, 2004 (UTC)

I totally agree. This is about as bad as Mariah Carey. Fixing it all would be an effort though. Deco 23:03, 13 Dec 2004 (UTC)

The exclusion of MSSQL was most likely an oversight, although its exclusion from a list of examples isn't a POV issue. Also, I agree that some marketing terms are used therein, but to brand the article with the NPOV notice seems a tad extreme, especially since these "glowing" terms are reasonable assessments. -- Stevietheman 16:38, 15 Dec 2004 (UTC)

Maybe it was a little extreme, but the article reads like an album review. NPOV disputes aren't just for political pages. And remember, truth isn't a defense to POV statements. Wikipedia does have a pro-open source bias and it's important to try and reduce this bias. Rhobite 22:34, Dec 15, 2004 (UTC)

External links proposal

How about we point to DMOZ instead of showing many of the links we're now using? Specifics:

• Frameworks links -> this link
• Tutorials links (leaving articles in place) -> this link
• IDEs and debuggers -> this link

In the cases where links we have aren't in the DMOZ lists, then go to the corresponding DMOZ page and request they be added.

Re: Frameworks, we should then add a blurb regarding "what is a PHP framework?" and its importance to enterprise web application development (or something to this effect). -- Stevietheman 20:46, 15 Dec 2004 (UTC)

Generally... I like it. It's much better to ask people to add their tutorials, toolkits, and etc. to DMOZ (which is a site for links) than here or another article. It also moves out the content that's supposed to not be duplicated in this article (imho, and according to my understanding of what Wikipedia is not.)

I still think you're giving to much credit to frameworks, but that's a moot point and definitely only my point of view. So if no one else disagrees, I say go for it. -[Unknown] 05:28, Dec 16, 2004 (UTC)

OK... I'll hold off on the frameworks blurb for now so that it can be discussed first. Otherwise, without objection, I'll make the changes I described. -- Stevietheman 17:45, 16 Dec 2004 (UTC)

Mediawiki famous?

Although we certainly have a pro-Wikipedia bias here, is "MediaWiki, the software behind Wikipedia" really deserving of in-the-intro labelling as a "famous" PHP product, without mentioning dozens of more widely-known ones? Deco 11:39, 28 Dec 2004 (UTC)

I can't say I disagree. As far as I'm concerned, feel free to improve. --Stevietheman 16:03, 28 Dec 2004 (UTC)

Can't list everything TBH, lets list all the content managemnt systems and blog systems and photo galleries too - fact of the matter is wikipedia (and thus mediawiki inherrently) *is* a notable site built on PHP --Streaky 01:59, 27 February 2006 (UTC)

Frameworks

I just wanted to report that the Open Directory Project is now listing most of the PHP frameworks that used to be listed in this article. Enjoy! --Stevietheman 21:42, 10 Jan 2005 (UTC)

Vandals

What's with these vandals as of late? Anything we can do to stop this? — Stevie is the man! ^{Talk | Contrib} 11:26, 8 Feb 2005 (UTC)

It appears to be a runaway spambot. Since it always posts a link to the same few domains, I asked on Wikitech-L for these domains to be added to the spam filter. The other option is to block the vandals on sight, which we've also been doing. Many of them are already in spam blocklists, indicating they're used to send e-mail spam as well. I guess Wikipedia could start checking IP addresses against a DNS blocklist but that would be a big change. Rhobite 15:04, Feb 8, 2005 (UTC)

Unfortunately, it's not the same few domains. There are several dozen, and I suspect he registers new ones on a continual basis (as long as each domain earns more than the $6 or so it costs to register them in bulk, he can afford to keep doing that indefinitely). An admin added the complete list of domains used so far to the spam filter, but I'm not sure it'll help, for the reasons mentioned.

Blocking the anon IP addresses on sight doesn't work because they are hit and run and he keeps coming up dozens of new ones every day. A few of the anonymous IPs were AOL addresses, so we know these are not open proxies... I suspect these are hacked zombie machines that have been "owned". There are literally millions of insecure home PCs out there that aren't properly updated with the latest security fixes.

So blocking linkspam on a per-domain basis doesn't really work and blocking anon IP addresses doesn't really work either. We are reverting on a timely basis, but the page histories still grow by dozens of edits every day, because the spambot hammers the same page a dozen times in a row even if the last edit was its own. So the only real solution for the time being is to vprotect.

But even vprotect is a problem, because the bot follows links. Some of the pages linked to from PHP have also been hit, as well as their talk pages. So we might come back tomorrow and find new pages under attack.

I'm not sure what the solution is if the spambot keeps it up. Checking IP addresses against one of the publicly available "blackhole" lists? Implementing a form of protection that only allows a page to be edited by logged-in users, as an alternative to choosing between wide open and completely protected?

The best thing would be if the spambot operator realized the whole thing is pointless, because the "nofollow" on Wikipedia links means he won't improve his Google ranking by doing this. He's doing damage with nothing much to gain.

-- Curps 03:59, 10 Feb 2005 (UTC)

Actually most of them appear to be from a free subdomain provider, 6x.to. I didn't know that other pages have been hit, that's unfortunate. I don't think there's any technical solution which will work on a long-term basis. Subscribing to a blacklist would have severe ramifications, it's something to be approached slowly if it's approached at all. The best approach is to continue dealing with it on a case-by-case basis, blocking spam sources (I agree they're probably trojanned), and adding spammed web sites to the filter. But beware of joejobs. Rhobite 04:33, Feb 10, 2005 (UTC)

The point is, every new time the spambot hit a page I saw a different linkspam URL and a different anon IP. So case-by-case won't work. We have filtered out all the domains seen so far and temporarily blocked all the IPs seen so far, but we'll just see new ones as soon as we un-vprotect. And we don't dare do that because last time we got 67 spam edits in 10 hours (and the reverts weren't done cleanly, so a spam URL stayed in the article for several hours).

The reality is that a popular topic like PHP is going to have to remain protected indefinitely (weeks or months?). I don't think there's general awareness of how serious this could potentially be. The other pages are all vprotected too, although the rate of hammering is lower for most of them; many of them are just longtime redlinks, so it's not a great loss if they stay vprotected. But who knows when/if other popular-topic pages will be targeted?

The spambot URLs are a bunch of subdomains of 6x.to and also uni.cc, and also some .ru and .su domains. Google shows two or three legitimate 6x.to and uni.cc external links within Wikipedia... could these be sacrificed? It would be nice to be able to say "block all of 6x.to except for the following domains", but apparently the spam filter can't do that yet.

-- Curps 07:45, 10 Feb 2005 (UTC)

The attack has now spread to PHP-Nuke and PL/I. Both of these pages will probably have to remain protected indefinitely. Again, I don't think there's general awareness of how serious this is. -- Curps 07:51, 10 Feb 2005 (UTC)

You're right that this is a serious problem. And even if blocking 6x.to would solve this problem, it's not a permanent solution. My point is there is no permanent solution. But long-term protection, especially for nonexistent articles, is not feasible.. it's unwiki, as they say. Rhobite 22:10, Feb 10, 2005 (UTC)

Yes, we have a dilemma with no easy solutions... the very definition of a "serious problem". We need better technical means for detecting and dealing with bots... no human would edit the same article a dozen times per minute. We probably need a throttling mechanism to limit the rate of edits by the same IP... this would also help with the Willy on Wheels vandalism as well. Perhaps an intermediate level of protection for a page, allowing only edits by logged-in users who have been registered for more than a few days, would be an alternative between fully protected and completely unprotected (we'd need to implement captcha to prevent bots from registering accounts). Traditional means aren't adequate here, and I hope the developers have some awareness of the issues faced by admins. -- Curps 23:28, 10 Feb 2005 (UTC)

Alternatively, one could create a spam-protected flag (akin to the protected flag) that requires users to solve a captcha to edit the page. jdb ❋ (talk) 04:36, 23 Mar 2005 (UTC)

Captchas are not a good solution because they are now easily defeated - not by computers, but by people who are willing to defeat them for a reward. Apparently, some spammers will run sites (notably porn) that require their visitors to solve a captcha, but rather than generate one on the fly, it will simply relay the captcha image from a target site that the spammer wants to attack (wikipedia, free emails services, etc.), then relay the visitor's response to the target site. Also, they're annoying :D Courtarro 19:12, 17 March 2006 (UTC)

Popularity

Just because a web server says it has PHP installed doesn't mean that PHP is really used on that domain.