Talk:PHP/Archive 1

message: 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)
replies: text: 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)
thread_title: Criticisms section

message: ... 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)
thread_title: PHP extension

message: ====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)
thread_title: PHP Library/extension list

message: 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)
thread_title: Date

message: 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 . My favorite is PHPEdit  (now not free), PHP Coder, devPHP and Komodo (All on XP). --Rrjanbiah 05:39, 25 Aug 2004 (UTC)
replies: text: 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)
thread_title:  IDE explanations please 

message: 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)
replies: text: Still even speculation for Rasmus TBH - certainly I've not read anything 'official' on the matter --Streaky 01:31, 27 February 2006 (UTC)
thread_title:  Parrot (future of php) 

message: 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)
thread_title:  PHP development 

message: 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)
thread_title:  New criticisms? 

message: 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)
replies: text: 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)
thread_title:  Incorrect link to newt 

message: 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)
replies: text: I can't say I disagree.  As far as I'm concerned, feel free to improve. --Stevietheman 16:03, 28 Dec 2004 (UTC)

text: 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)
thread_title:  Mediawiki famous? 

message: 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)
thread_title: Frameworks