That is right, it's extremely difficult to use XML unless you have a tool, like a computer.
Technically, you can use XML with a pencil and paper, but it's difficult, and a pencil is a tool too.
You can also write XML in the sand with a stick, but sticks are also tools.
Another thing you can do is think about XML with your brain, but your brain is also a tool.
So yes, you do have to use tools in order to use XML, and if you don't have any tools like brains or sticks or pencils or computers, then no, you should not be using XML.
Oh man Smarty source code is just a hoot. Look at this stuff:
The rats-nest of regular expressions in Smarty_Compiler.class.php, and how they're used along with even more regular expressions scattered throughout the code.
File function.math.php, function smarty_function_math:
// make sure parenthesis are balanced
if (substr_count($equation,"(") != substr_count($equation,")")) {
$smarty->trigger_error("math: unbalanced parenthesis");
return;
}
That's the typical kind of seat-of-the-pants half-assed parsing that Smarty is rife with. In this case, it gleefully accepts "))((" as balanced parenthesis, and doesn't ignore parenthesis in strings! Why even bother checking, if the check's obviously not correct?
Smarty just heuristically interprets text in a bizarre, poorly documented, non-standard, arbitrary accidental syntax, by slinging around inscrutable regular expressions, parsing text bit-by-bit, making exceptions and special cases, guessing and fudging and cutting corners all along the way. It's so haphazard and mixed up, it's impossible to write a decent emacs text editing mode for it, let alone edit, validate and process your Smarty templates with standard off-the-shelf XML tools. That's why Smarty is such a vile, poorly designed templating language.
Your argument is based on misusing a PHP term for "modules" and trying to apply it to my sentence about Python modules. Python modules ARE namespaces, arranged in a tree. Python "extension" are plug-in code that may define modules and sub-modules. PHP makes no distinction between "module" and "extension" because it doesn't have namespaces. But Python's philosophy says namespaces (aka Python modules) are a very good thing. Too bad for PHP, because its designers chose to ignore that advice, and throw everything into one big messy global namespace.
I'm not saying PHP should try to morph itself into Python or any other language, just that people should not use PHP when given a choice in the matter. Look what happened when PHP tried to morph itself into Java, without understanding the basics of OOP: you get the horrible situation that exists today, where it's impossible to implement an ActiveRecord-like ORM. PHP also has "references" that it aped from Perl, which look just like C++ references on the surface, but they're actually totally unlike anything that C++ or Java or any other sane language: symbol table aliases. Most languages consider aliasing to be a danger that is to be avoided, not a cool feature that you have to use all over the place to work around a stupid design flaw in the original language (passing structures by copying instead of by reference).
There most certainly are a lot of school books and web pages written about object oriented programming, including static inheritance. OOP is not a monolithic agreed-upon definition, but there are certainly some best practices to apply and notorious mistakes to avoid. There are a lot of different things that go into "OOP", and anyone designing an object system should understand them all, so they can understand the trade-offs they're making. Unfortunately the PHP designers were just trying to ape the surface features of Java, but they didn't understand OOP well enough themselves to know why it was designed the way it was, or get their own OOP design right.
Here is an a la carte menu of features or properties that are related to these terms; I have heard OO defined to be many different subsets of this list.
1. Encapsulation - the ability to syntactically hide the implementation of a type. E.g. in C or Pascal you always know whether something is a struct or an array, but in CLU and Java you can hide the difference.
2. Protection - the inability of the client of a type to detect its implementation. This guarantees that a behavior-preserving change to an implementation will not break its clients, and also makes sure that things like passwords don't leak out.
3. Ad hoc polymorphism - functions and data structures with parameters that can take on values of many different types.
4. Parametric polymorphism - functions and data structures that parameterize over arbitrary values (e.g. list of anything). ML and Lisp both have this. Java doesn't quite because of its non-Object types.
5. Everything is an object - all values are objects. True in Smalltalk (?) but not in Java (because of int and friends).
6. All you can do is send a message (AYCDISAM) = Actors model - there is no direct manipulation of objects, only communication with (or invocation of) them. The presence of fields in Java violates this.
7. Specification inheritance = subtyping - there are distinct types known to the language with the property that a value of one type is as good as a value of another for the purposes of type correctness. (E.g. Java interface inheritance.)
8. Implementation inheritance/reuse - having written one pile of code, a similar pile (e.g. a superset) can be generated in a controlled manner, i.e. the code doesn't have to be copied and edited. A limited and peculiar kind of abstraction. (E.g. Java class inheritance.)
9. Sum-of-product-of-function pattern - objects are (in effect) restricted to be functions that take as first argument a distinguished method key argument that is drawn from a finite set of simple names.
So OO is not a well defined concept. Some people (eg. Abelson and Sussman?) say Lisp is OO, by which they mean {3,4,5,7} (with the proviso that all types are in the programmers' heads). Java is supposed to be OO because of {1,2,3,7,8,9}. E is supposed to be more OO than Java because it has {1,2,3,4,5,7,9} and almost has 6; 8 (subclassing) is seen as antagonistic to E's goals and not necessary for OO.
The conventional Simula 67-like pattern of class and instance will get you {1,3,7,9}, and I think many people take this as a definition of OO.
Because OO is a moving target, OO zealots will choose some subset of this menu by whim and then use it to try to convince you that you are a loser.
Perhaps part of the confusion - and you say this in a different way in your little memo - is that the C/C++ folks see OO as a liberation from a world that has nothing resembling a first-class functions, while Lisp folks see OO as a prison since it limits their use of functions/objects to the style of (9.). In that case, the only way OO can be defended is in the same manner as any other game or disci
If there isn't a problem with register_globals, then why are they finally taking it out of the language?
Of course the real questions are: why did it take so long to remove from the language, and why was it ever there in the first place? That is even more evidence of extremely bad judgement on the part of the PHP designers, that they mad such a bad mistake in the first place, and took so long to admit they made a mistake and correct it. They still try to blame it on "bad developers", but that's the only kind of developers they have left any more, because anyone with any sense or choice in the matter has moved on to better languages like Python and Ruby.
Doing a google search for register_globals site:www.us-cert.gov shows 112 references to security vulnerabilities having to do with register_globals. Is that enough evidence that register_globals is a bad idea?
The register_globals flag should not even be an option, backwards compatibility be damned. When you have security holes like "Unsafe termination of parse_str() may result in the register_globals directive turned back on, you're screwed even when you turn it off, because PHP turns it back on internally, then wets its pants before turning it back off, so it leaves it on for the rest of the lifetime of the web server.
That terrible bug was found AND FIXED by Stefan Esser (the person who this thread is about, in case you didn't bother to read the article), yet some piss-water-carrying PHP fan-boys are still attacking him as a "traitor".
Here is another article he wrote about PHP security problems having to do with register_globals and a lot of other stupid flaws that should have never existed in the first place: Zend_Hash_Del_Key_Or_Index Vulnerability. If you don't like it when people blame the Zend Corporation for so many of the problems in PHP, then maybe you should ask Zend to stop putting their company name into all those functions that are the root cause of so many security problems.
If you have heard of Unicode, and you know that PHP does not handle Unicode, then why do you have to ask if there's a charset issue? Of course there is! You should also know that is one of the issues, but not the only one. Another important issue is the particular database's quoting conventions, and every database has its own different quoting conventions (which sometimes change from version to version). PHP had shamefully made several attempts at providing functions to quote database strings, none of which work properly, yet are all still in the language. Aren't you aware of that??!
It's insecure because it exists, and so are all the other lame half-assed database quoting functions in PHP. There is no reason for a function that doesn't work to exist, other than to mislead ignorant programmers into using it, and give them a false sense of security. Are you actually trying to deny all the security bugs that have been caused thanks to addslashes, mysql_escape_string, mysql_real_escape_string, mysql_escape_string_not, mysql_really_o_truly_o_escape_string, mysql_no_now_I_really_mean_it_escape_string, mysql_I_was_just_joking_before_but_now_I_really_re ally_mean_it_escape_string, mysql_mother_may_I_escape_string, postgres_kicks_mysqls_ass_escape_string, and all that other crap that's in PHP but shouldn't be?
If you're a professional PHP programmer, then you should be able to recite all the problems with addslashes from memory, and all the half-assed yet incomplete attempts at solving them, as well as the problems with them, and not have to ask me. The problem is that most PHP programmers think they know what they are doing, but they are horribly wrong. Even the self-proclaimed "PHP expert wizards" at Zend got tripped up and blindsided by the ZActiveRecord Boondoggle bug that they previously had refused to fix because they thought it was a feature. If Zend doesn't understand their own darling PHP, then who can? Professional competent programmers know their limitations and areas of ignorance, but ametuer incompetent programmers don't think they have any limitations, and think they know it all.
How long have you been using the Internet, that you have to ask me what the problem with addslashes is (or that other guy who asked me what the problem with register_globals is), instead of using google to find out for yourself?
I'm all for capitalism: vote with your feet! Those hosting providers who only host old poorly configured versions of PHP, and refuse to host decent versions of Ruby and Python, totally deserve to go out of business. So stop sending them your money! It's not like it's hard to find a better one. And I'm sick and tired of all the spam and break-in attempts I get because there are so many security holes in PHP running on those cheap hosting providers' hijacked servers.
Somebody paid me to do some Drupal programming, so I decided to learn it by installing it on my development server, using it for my own blog, reading the source code, and writing my own module (which exports an OPML site map based on the Drupal taxonomy, which dovetailed with my Laszlo OPML Drupal Taxonomy Site Map Browser).
As PHP code goes, Drupal is pretty clean and well designed, because it refuses to use PHP's fucked up object system, and rolls its own instead. If course it's clumsy since its own object system is not directly supported by the language (and PHP isn't extensible like Lisp, whose macro system and CLOS lets you elegently roll your own object systems that are seamlessly integrated into the language). But Drupal's html generation facilities and user interface suck.
Sure I would love to try Django, but nobody's offered to pay me to learn it, and I have other stuff to do. I have spend a lot of time doing Zope and Plone development, and was trying to use it as a blog, but I was not satisfied with it (it's very frustrating and much too complex), so I moved over to Drupal because somebody wanted me to do some Drupal work. Ideally I'd write my own blog in TurboGears, which is currently my favorite Python web framework, but I don't have time for that either (and I'm not satisfied with any of the "Write a blog in 2 minutes" screencast example blogs, as cute and furry as they are). I'd rather spend my time developing software instead of writing about how I would be developing software if I weren't writing about it (like I'm doing right now, ironically).
You're certainly right about convenience trumping all other considerations. But building an elementary school out of radioactive wastes, asbestos insulation and lead flashing, exterminating bugs with DDT, hiring drunks to drive the school busses, and contracting McDonalds to run the cafeteria, may be convenient and expedient, but it's unwise and irresponsible.
Until people who understand the dangers start loudly and publicly warning other people about them, there is very little chance of changing those horrible yet convenient practices. That's what Stefan Esser and I and other people are doing, because it's important to discourage people who don't know better from choosing to use PHP when there are much better alternatives, and embarass the PHP developers who should know better into fixing their fucking long standing security problems and bugs (because nothing else has worked).
I did not post it verbatim: I linked to my previous post and summarized it. What is "verbatim" about that? (Do you misunderstand what the word "verbatim" means? Look it up before using it!) I certainly did give you a "god damned link". If you disagree with the facts on the ground, then state your arguments, instead of making up lies about "verbatim" postings and not giving you a "god damned link".
I will keep posting references to the ZActiveRecord Boondoggle until Zend finally gets their act together and fixes the problem. Or you can fix the problem yourself, and try to get them to integrate your changes! That will make me shut up about it. But telling me not to "post this polemic verbatim every time" and "give us a god damned link", after I go to the effort of summarizing my previous post and linking to it, isn't going to make me shut up. That's just white-washing and censorship, and a lame attempt to rewrite history, fan-boy.
If the people at Zend don't understand the nuances of PHP's object system, then why should anyone else be expected to understand it? You must concede the point that the bug that caused them to cancel their ZActiveRecord plans was a stupid mistake caused by a misunderstanding of OOP, because Zend themselves got unexpectedly bitten by it, even after making excuses for the flawed behavior and claiming they would never fix that bug. Unless your name is John McCain, choose one side of the argument and stick to it. Either it's not a bug and it should not be fixed (and you should expect it to work that way and not make the mistake Zend did), or it is a bug and should be fixed (like all the PHP programmers have been clamoring for, which you will see if you read the comments on the bug). You can't have it both ways, Mr. Straight Talk Express.
Stop making excuses for PHP's horrible global namespace. There's nothing about "procedural languages" that requires global namespaces and all the problems inherent with them. Haven't you ever heard of "modules"? You must be totally ignorant of other languages, to make a statement like that. But then again, that's probably why you choose to use PHP, and foolishly leap to the defense of its flaws: because you don't know any better.
Your homework is to go read PEP 20, The Zen of Python. Python was designed and written by people who actually understand language design, but PHP wasn't. It actually makes a difference! Here is The Zen of Python for you to read right now -- every one of the principles flies in the face of PHP's foolish design. Pay special attention to the last one:
The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
You should not develop on your live server and try not to debug there either.
Who are you to tell me which server I should or should not develop code on? Until you paypal me enough money to rent another server for a year, and donate your time to setting up and maintaining all the software I require on the extra server, I will develop on any server I need to.
Stop making excuses for design flaws in PHP caused by the developer's misunderstanding of object oriented programming. The fact that PHP uses a hebrew word in its error messages doesn't make it easy to understand why PHP's fucked up object system is annoyingly and brokenly different than well designed object systems of other languages. As Wikipedia article on Paamayim Nekudotayim says, "Although it has been confusing to many developers, it is still being used in PHP 5, as in this sample error message:
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in... on line...". Is that supposed to explain why PHP's design flaw is not a design flaw? If it weren't a design flaw, then why did it broadside the Zend developers who foolishly assumed their language had as well designed an object system as Ruby? Shouldn't they understand their own object system well enough to know it was impossible to implement ZActiveRecord, before trying it, announcing it in public, and being busted by a blogger who knew their own language better than they did? Why did they fight against fixing the bug for so long? If it's a design feature and not a bug, then why have they finally agreed to fix it in PHP 6, only after they've been publically humiliated by the ZActiveRecord Boondoggle.
You PHP apologists are just like the Bush administration's right wing water carriers. You will argue the wrong side of the issue even though you know you're wrong, because politic trumps truth. Just as bad as McCain respecting and thanking Rumsfeld: "While Secretary Rumsfeld and I have had our differences, he deserves Americans' respect and gratitude for his many years of public service", then flip-flopping and criticizing him: "I think that Donald Rumsfeld will go down in history as one of the worst secretaries of defense in history."
I have used TAL quite a lot, thank you. I've developed large compex sites in Plone, written many TAL templates and Metal macros, and I absolutely hate TAL templates, Metal macros, TALES expression language, and "restricted Python". I've read many TAL templates and Metal macros written by other people (Plone is full of them), and the TAL source code itself (which was rewritten by none other than Guide during his time at Zope Corporation). It's a great implementation of a horrible idea, that has been taken to extremes. That's why I like the Kid template system so much: it elegently addresses all the horrible problems of TAL.
But now I have to deal with PHP code that uses Smarty templates, so I read the Smarty source code. Have you? Do you have any idea how it works or what it's doing behind your back? Shut up with your PHP apologizing and sit down and read Smarty head to toe before you go claiming it's easy for designers to learn Smarty. If you had any understanding or appreciation for language design or parser implemention, you would throw up in your mouth at the heuristic regular expression guessing games it plays, and the undocumented, ridiculously obscure and inconsistent nuances of its syntax.
For beginners register_globals can create nasty suprises, but for those who know that it is on and write the code accordingly, I don't see what is the problem with register_globals being enabled.
Most PHP programmers ARE beginners, so it creates many many unnecessary nasty surprizes. And for experts, it does not give you anything that you can't already do another way. It adds no real value to the language for experts (of which there are few), and totally screws beginners (of which there are many). Now please explain why you're apologizing for PHP and making excuses for why register_globals is still part of the language after all these years everyone knew it was wrong? I ask again: why did they make such a horrible mistake in the first place?
One of the biggest problems currently with PHP is the lack of good database module with support for multiple different database engines with things like prepared statements.
That's ironic, because people often repeat the myth that PHP makes it easy to interface with the database. Easy but deadly. The reality that PHP has horrible database handling is what's causing PHP programmers to defect to Ruby on Rails (which has ActiveRecord) in droves. Zend tried to imitate ActiveRecord but that resulted in the ZActiveRecord Boondoggle. Python has some excellent database interfaces and object-relation mappers, like SQLObject and SQLAlchemy, which beat the pants of anything PHP has to offer.
Why do you think I have such a distaste for PHP? Because I have to use things like Drupal and Smarty out of necessity, because someone paid me to. If I never used PHP myself, then I would have no right to complain about it. The reason I have display_errors turned on is because I use my web server to develop and debug PHP code, and I like to see all the errors, so I know they're there and can fix them. You ought to try it some time. But fixing bugs in my drupal blog isn't high on my priority list, because there are other more important PHP bugs to fix.
If PHP is so great at supporting databases, then why did Zend give up on their ZActiveRecord Boondoggle, which wouldn't work as they falsely advertised because of a stupid PHP bug they refused to fix? Why isn't there anything like ActiveRecord for PHP? Because it's impossible, because of a bug that came about because the PHP developers didn't understand object oriented programming when they tried to imitate Java's class system.
Python has no trouble implementing ActiveRecord-like ORMs, and even has much more advanced SQL database toolkits than ActiveRecord.
What does PHP have that compares with Python's SQLAlchemy?
It was highly unethical for the PHP development team to sweep all those bugs under the rug. The cat is already out of the bag. They are already public. Making an public issue of the PHP developer's horrible behavior and careless attitude is the only ethical thing to do. Don't blame the messenger. Blame the incompetent people who refused to fix the bugs, not the diligent person who fixed them, but had his changes ignored by the incompetent people.
Oh, please. Smarty is a piece of shit. You are hereby sentenced to go read the Smarty source code, and don't come back or post anything else about PHP to slashdot until you are done, and have washed the puke taste out of your mouth. Then you will be so embarassed you mentioned Smarty. It's one of the most truly horrible pieces of PHP code I have ever seen and had the misfortune of having to use. The whole idea is ill-concieved. PHP is ALREADY a templating language: why use it to implement another half-baked watered-down ill-defined templating language, that doesn't even support all the functions or syntax of PHP? I mean, it's not like Smarty keeps you from having to learn PHP, and then you still have to learn its horrible quirky half-assed syntax, which is even worse and messier than PHP! And you certainly can't edit in an XML editor, since it's flagrantly XML non-compliant, or even a PHP editor, since it's not PHP syntax either.
Templating languages should be clean, elegant, well integrated with the native scripting language, not trying to fight against it. And they should be 100% XML compliant, so you can edit and integrate them with all your other XML tools. Python's Kid templating language is a wonderful example of how to do it right.
Kid is a simple template language for XML based vocabularies written in Python. It was spawned as a result of a kinky love triangle between XSLT, TAL, and PHP. We believe many of the best features of these languages live on in Kid with much of the limitations and complexity stamped out (see WhatsBorrowed and WhatsDifferent). For more info on current and planned features and licensing information, see AboutKid.
Why use Kid?
Kid was designed to simplify the process of generating and transforming dynamic well-formed XML documents using Python. While there are a myriad of tools for working with XML documents in Python, generating XML is generally tedious, error prone, or both:
* APIs like SAX, DOM, or ElementTree can guarantee well-formed output but require that output documents be created entirely in Python.
* Template languages like Cheetah or PTL make generating text content easy but offer little to help ensure the output is correct/well-formed. Using text based tools to generate XML can result in bad data as there are many issues with basic XML syntax and encoding that need to be understood and coded for by the programmer.
* XSLT provides much of the functionality required to generate good XML content but requires all input to be in the form of an XML document. This brings us back to the original problem of not being able to generate XML content safely and easily.
Kid is an attempt to bring the benefits of these technologies together into a single cohesive package.
Kid also allows the programmer to exploit the structured nature of XML by writing filters and transformations that work at the XML infoset level. Kid templates use generators to produce infoset items. This allows pipelines to be created that filter and modify content as needed.
How about putting all the PHP developers on a month long reality show, where if they can't fix all their bugs in a month, they have to cancel PHP!
But there would be so many bugs, soap operas, security holes, personality conflicts, segmentation violations, and hissy fits, that the network executives would extend the PHP Reality Show again and again, and it would end up running longer than The Simpsons. They could keep it going forever, by fixing one bug a day, while adding two more bugs.
I don't really want to make excuses for poor responses to bug reports, but...
Whenever somebody uses the sentence pattern: "I don't really bla bla bla, but bla bla bla." it means that they don't really mean the thing before the "but", and they're just saying it because they know the thing they're going to say after the "but" is totally full of shit. Like "I don't really hate gays, but I don't believe they deserve to get married, because the bible says so, and it's a horrible threat to my own marriage."
Would you please stop apologizing for PHP? You are part of the problem if you're apologizing instead of fixing security bugs. And you're hurting the internet, if you think you're sticking up for PHP by attacking somebody who actually is fixing security bugs. So stop it. PHP doesn't need you to leap to its defense: it needs to be fixed, or people need to stop using it.
Not only is the PHP development team negligent when it comes to dealing with security bugs, but they're incompetent when it comes to understanding the limitations of their own language, the tenants of object oriented programming, and database object-relational mapper design.
The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".
To summarize:
[Criticism of PHP "references".] [Criticism of PHP "object system".] [Description of "static methods".] [Description of Ruby on Rail's ActiveRecord.] [Description of "ZActiveRecord", Zend's lame half-baked cargo cult attempt to ape ActiveRecord.] [Zend busted for misleading screencast.] [Blog posting that proves: ZActiveRecord Can't Work.] [Zend misunderstood their own language's object system, showed fake code in a screencast that could not possibly work (because of a PHP bug), and made promises of ZActiveRecord they couldn't keep, because of that stupid bug they refused to fix.] [Longstanding bug that PHP static methods that the developers refuse to fix.] [Summary of comments on the bug that prevents anyone from writing an ActiveRecord-like ORM in PHP.] [Final word from andi, calls it expected behavior, demonstrating how he misunderstands object oriented programming, and casually dismisses all the bug report's valid comments.] [Zend gets hoisted on their own pitard by this very bug.]
And here's the final word from andi: "Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ [php.net] and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [php.net] This is expected behavior. self:: binds statically to its class (to the best of my knowledge other languages like C++ don't support this either as they require to explicitly use the class name). There are actually advantages also to this approach as they allow you to protect and encapsulate functinality."
Since Zend's dishonest and embarassing public-relations disaster with the ZActiveRecord Boondoggle, Zend has quietly withdrawn their plans for ZActiveRecord, instead of fixing the stupid bug that made it impossible to implement and ORM like ActiveRecord in PHP.
It's not just security that the PHP developers and Zend don't care about. They also don't care about nor understand object oriented programming, nor database object-relational mapping.
There is absolutely no reason to use PHP, when there are great languages like Python with extremely powerful, easy to use, safe and secure, database independent, object-relational mappers like SQLObject , and intelligent scalable SQL toolkits with multiple modular ORMs like SQLAlchemy. That stuff so blows away PHP's horribly insecure string-concatination approach to SQL, and all of the kludgy PHP database libraries people have cobbled together over the years.
If you're not fearful, uncertain and doubtful about PHP, then you're head is stuck in the ground and you do not know what you're talking about. PHP should most certainly be feared, doubted and not trusted. Stop being such an apologist fan-boy, and trying to attack the messenger instead of the cause of the problem: the PHP development team's negligent attitude.
It's the ignorant PHP apologists like you who are damaging the internet and causing much more trouble than anyone who's trying to expose PHP's bugs and embarass the PHP development team into finally fixing all of their long-standing security problems that they have refused to address.
The hackers and script kiddies ALREADY KNOW all of the vulnerabilities. It's ignorant PHP fan-boys like you who are in the dark and spreading bullshit, if you're not aware of what a truly horrible and insecure disaster PHP really is. The security holes already exist, and covering them up and making excuses for them isn't going to fix them. But exposing them to the light of day will force the idiots on the PHP development team to finally address them, and hopefully warn people away from using or trusting PHP. They had their chance to fix the problem before, and they chose not to. Stop trying to rewrite history to justify your misplaced finger-pointing. You fan-boys making excuses for the PHP development team's negligence are contributing to the problem, and just making it worse -- it's not the fault of the courageous whistle-blower who you're attacking. Stop damaging the internet, fan-boy.
The root cause of the problem of PHP's popularity are the minions of ignorant, irresponsible PHP fan-boys, evangelists and apologists who are always shooting their mouths off trying to convince droves of other sloppy uneducated programmers to use PHP.
STOP EVANGELIZING PHP! YOU ARE HARMING THE INTERNET!
There are many reasons that add_slashes is insecure, and if you think about it, you should be able to come up with a few yourself. Have you ever heard of Unicode? Do you really know what the quoting conventions of your database are, or are you just assuming that add_slashes somehow magically does? Have you even bothered to use google or read any of the many security articles about PHP? Obviously not. And the same goes for so many other PHP developers. They need training wheels and adult supervision, otherwise they wouldn't have made such a horrible decision to use PHP in the first place.
The issue is that PHP has many functions and mis-features like magic_quotes_gps that pretend to give you some level of security but ACTUALLY DON'T, combined with the fact that there are a lot of naive and sloppy programmers out there like you, who have no idea what the issues are, and have never bothered to think about them or even look them up on the internet. The problems are WELL DOCUMENTED AND WIDELY DISCUSSED. You have no excuse for not knowing them. You can use google as well as anybody, and educate yourself, but you choose not to.
But it's wrong to blame the ignorant sloppy application developers, when the language actually offers them up so many false non-solutions and dangerous pitfalls. It ENCOURAGES ignorant developers to make mistakes. Why didn't they remove add_slashes, magic_quotes_gpc, and all those other horrible bugs a long time ago, instead of leaving them in there to temp ignorant people into use them? The design of the PHP language and libraries and the attitude of the PHP development team is the core of the problem that causes sloppy application developers to make so many mistakes.
And you're surprized? You made your bed, now sleep in it. Or rather, stop sleeping until you've un-installed PHP on all your servers, because it will never be secure, thanks to the PHP team's attitude.
Can you please explain why register_globals was there in the first place? The reason is that PHP was designed by idiots, pure and simple. It should have never existed, not as an option, and especially not as a default setting. The same goes for magic_quotes_gpc and its ilk.
Face it: PHP is a horribly designed language from the core to its extremities, and you can't knickle-and-dime security issues as you discover them. The PHP development team's attitude just makes it much much much much worse. You're an idiot to trust them, and a danger to the Internet if you apologize for PHP, make excuses, and continue to evangelize and recruite naive developers.
You wouldn't be using PHP if you weren't an idiot yourself, so shut up with calling other PHP developers idiots, and blaming them for the problem. If you were such a great programmer, you would know better, and you wouldn't be using PHP in the first place.
Slashdot Mirror
That is right, it's extremely difficult to use XML unless you have a tool, like a computer. Technically, you can use XML with a pencil and paper, but it's difficult, and a pencil is a tool too. You can also write XML in the sand with a stick, but sticks are also tools. Another thing you can do is think about XML with your brain, but your brain is also a tool. So yes, you do have to use tools in order to use XML, and if you don't have any tools like brains or sticks or pencils or computers, then no, you should not be using XML.
-Don
Oh man Smarty source code is just a hoot. Look at this stuff:
The rats-nest of regular expressions in Smarty_Compiler.class.php, and how they're used along with even more regular expressions scattered throughout the code.
That's the typical kind of seat-of-the-pants half-assed parsing that Smarty is rife with. In this case, it gleefully accepts "))((" as balanced parenthesis, and doesn't ignore parenthesis in strings! Why even bother checking, if the check's obviously not correct?
Smarty just heuristically interprets text in a bizarre, poorly documented, non-standard, arbitrary accidental syntax, by slinging around inscrutable regular expressions, parsing text bit-by-bit, making exceptions and special cases, guessing and fudging and cutting corners all along the way. It's so haphazard and mixed up, it's impossible to write a decent emacs text editing mode for it, let alone edit, validate and process your Smarty templates with standard off-the-shelf XML tools. That's why Smarty is such a vile, poorly designed templating language.
-Don
Your argument is based on misusing a PHP term for "modules" and trying to apply it to my sentence about Python modules. Python modules ARE namespaces, arranged in a tree. Python "extension" are plug-in code that may define modules and sub-modules. PHP makes no distinction between "module" and "extension" because it doesn't have namespaces. But Python's philosophy says namespaces (aka Python modules) are a very good thing. Too bad for PHP, because its designers chose to ignore that advice, and throw everything into one big messy global namespace.
I'm not saying PHP should try to morph itself into Python or any other language, just that people should not use PHP when given a choice in the matter. Look what happened when PHP tried to morph itself into Java, without understanding the basics of OOP: you get the horrible situation that exists today, where it's impossible to implement an ActiveRecord-like ORM. PHP also has "references" that it aped from Perl, which look just like C++ references on the surface, but they're actually totally unlike anything that C++ or Java or any other sane language: symbol table aliases. Most languages consider aliasing to be a danger that is to be avoided, not a cool feature that you have to use all over the place to work around a stupid design flaw in the original language (passing structures by copying instead of by reference).
-Don
There most certainly are a lot of school books and web pages written about object oriented programming, including static inheritance. OOP is not a monolithic agreed-upon definition, but there are certainly some best practices to apply and notorious mistakes to avoid. There are a lot of different things that go into "OOP", and anyone designing an object system should understand them all, so they can understand the trade-offs they're making. Unfortunately the PHP designers were just trying to ape the surface features of Java, but they didn't understand OOP well enough themselves to know why it was designed the way it was, or get their own OOP design right.
Paul Graham quotes Jonathan Rees's la carte menu of features or properties that are related to object oriented programming:
If there isn't a problem with register_globals, then why are they finally taking it out of the language? Of course the real questions are: why did it take so long to remove from the language, and why was it ever there in the first place? That is even more evidence of extremely bad judgement on the part of the PHP designers, that they mad such a bad mistake in the first place, and took so long to admit they made a mistake and correct it. They still try to blame it on "bad developers", but that's the only kind of developers they have left any more, because anyone with any sense or choice in the matter has moved on to better languages like Python and Ruby.
Doing a google search for register_globals site:www.us-cert.gov shows 112 references to security vulnerabilities having to do with register_globals. Is that enough evidence that register_globals is a bad idea?
The register_globals flag should not even be an option, backwards compatibility be damned. When you have security holes like "Unsafe termination of parse_str() may result in the register_globals directive turned back on, you're screwed even when you turn it off, because PHP turns it back on internally, then wets its pants before turning it back off, so it leaves it on for the rest of the lifetime of the web server.
That terrible bug was found AND FIXED by Stefan Esser (the person who this thread is about, in case you didn't bother to read the article), yet some piss-water-carrying PHP fan-boys are still attacking him as a "traitor".
Here is another article he wrote about PHP security problems having to do with register_globals and a lot of other stupid flaws that should have never existed in the first place: Zend_Hash_Del_Key_Or_Index Vulnerability. If you don't like it when people blame the Zend Corporation for so many of the problems in PHP, then maybe you should ask Zend to stop putting their company name into all those functions that are the root cause of so many security problems.
-Don
If you have heard of Unicode, and you know that PHP does not handle Unicode, then why do you have to ask if there's a charset issue? Of course there is! You should also know that is one of the issues, but not the only one. Another important issue is the particular database's quoting conventions, and every database has its own different quoting conventions (which sometimes change from version to version). PHP had shamefully made several attempts at providing functions to quote database strings, none of which work properly, yet are all still in the language. Aren't you aware of that??!
It's insecure because it exists, and so are all the other lame half-assed database quoting functions in PHP. There is no reason for a function that doesn't work to exist, other than to mislead ignorant programmers into using it, and give them a false sense of security. Are you actually trying to deny all the security bugs that have been caused thanks to addslashes, mysql_escape_string, mysql_real_escape_string, mysql_escape_string_not, mysql_really_o_truly_o_escape_string, mysql_no_now_I_really_mean_it_escape_string, mysql_I_was_just_joking_before_but_now_I_really_re ally_mean_it_escape_string, mysql_mother_may_I_escape_string, postgres_kicks_mysqls_ass_escape_string, and all that other crap that's in PHP but shouldn't be?
If you're a professional PHP programmer, then you should be able to recite all the problems with addslashes from memory, and all the half-assed yet incomplete attempts at solving them, as well as the problems with them, and not have to ask me. The problem is that most PHP programmers think they know what they are doing, but they are horribly wrong. Even the self-proclaimed "PHP expert wizards" at Zend got tripped up and blindsided by the ZActiveRecord Boondoggle bug that they previously had refused to fix because they thought it was a feature. If Zend doesn't understand their own darling PHP, then who can? Professional competent programmers know their limitations and areas of ignorance, but ametuer incompetent programmers don't think they have any limitations, and think they know it all.
How long have you been using the Internet, that you have to ask me what the problem with addslashes is (or that other guy who asked me what the problem with register_globals is), instead of using google to find out for yourself?
-Don
I'm all for capitalism: vote with your feet! Those hosting providers who only host old poorly configured versions of PHP, and refuse to host decent versions of Ruby and Python, totally deserve to go out of business. So stop sending them your money! It's not like it's hard to find a better one. And I'm sick and tired of all the spam and break-in attempts I get because there are so many security holes in PHP running on those cheap hosting providers' hijacked servers.
Somebody paid me to do some Drupal programming, so I decided to learn it by installing it on my development server, using it for my own blog, reading the source code, and writing my own module (which exports an OPML site map based on the Drupal taxonomy, which dovetailed with my Laszlo OPML Drupal Taxonomy Site Map Browser). As PHP code goes, Drupal is pretty clean and well designed, because it refuses to use PHP's fucked up object system, and rolls its own instead. If course it's clumsy since its own object system is not directly supported by the language (and PHP isn't extensible like Lisp, whose macro system and CLOS lets you elegently roll your own object systems that are seamlessly integrated into the language). But Drupal's html generation facilities and user interface suck.
Sure I would love to try Django, but nobody's offered to pay me to learn it, and I have other stuff to do. I have spend a lot of time doing Zope and Plone development, and was trying to use it as a blog, but I was not satisfied with it (it's very frustrating and much too complex), so I moved over to Drupal because somebody wanted me to do some Drupal work. Ideally I'd write my own blog in TurboGears, which is currently my favorite Python web framework, but I don't have time for that either (and I'm not satisfied with any of the "Write a blog in 2 minutes" screencast example blogs, as cute and furry as they are). I'd rather spend my time developing software instead of writing about how I would be developing software if I weren't writing about it (like I'm doing right now, ironically).
You're certainly right about convenience trumping all other considerations. But building an elementary school out of radioactive wastes, asbestos insulation and lead flashing, exterminating bugs with DDT, hiring drunks to drive the school busses, and contracting McDonalds to run the cafeteria, may be convenient and expedient, but it's unwise and irresponsible.
Until people who understand the dangers start loudly and publicly warning other people about them, there is very little chance of changing those horrible yet convenient practices. That's what Stefan Esser and I and other people are doing, because it's important to discourage people who don't know better from choosing to use PHP when there are much better alternatives, and embarass the PHP developers who should know better into fixing their fucking long standing security problems and bugs (because nothing else has worked).
-Don
I did not post it verbatim: I linked to my previous post and summarized it. What is "verbatim" about that? (Do you misunderstand what the word "verbatim" means? Look it up before using it!) I certainly did give you a "god damned link". If you disagree with the facts on the ground, then state your arguments, instead of making up lies about "verbatim" postings and not giving you a "god damned link".
I will keep posting references to the ZActiveRecord Boondoggle until Zend finally gets their act together and fixes the problem. Or you can fix the problem yourself, and try to get them to integrate your changes! That will make me shut up about it. But telling me not to "post this polemic verbatim every time" and "give us a god damned link", after I go to the effort of summarizing my previous post and linking to it, isn't going to make me shut up. That's just white-washing and censorship, and a lame attempt to rewrite history, fan-boy.
If you don't like the heat, get out of the fire.
-Don
If the people at Zend don't understand the nuances of PHP's object system, then why should anyone else be expected to understand it? You must concede the point that the bug that caused them to cancel their ZActiveRecord plans was a stupid mistake caused by a misunderstanding of OOP, because Zend themselves got unexpectedly bitten by it, even after making excuses for the flawed behavior and claiming they would never fix that bug. Unless your name is John McCain, choose one side of the argument and stick to it. Either it's not a bug and it should not be fixed (and you should expect it to work that way and not make the mistake Zend did), or it is a bug and should be fixed (like all the PHP programmers have been clamoring for, which you will see if you read the comments on the bug). You can't have it both ways, Mr. Straight Talk Express.
Stop making excuses for PHP's horrible global namespace. There's nothing about "procedural languages" that requires global namespaces and all the problems inherent with them. Haven't you ever heard of "modules"? You must be totally ignorant of other languages, to make a statement like that. But then again, that's probably why you choose to use PHP, and foolishly leap to the defense of its flaws: because you don't know any better.
Your homework is to go read PEP 20, The Zen of Python. Python was designed and written by people who actually understand language design, but PHP wasn't. It actually makes a difference! Here is The Zen of Python for you to read right now -- every one of the principles flies in the face of PHP's foolish design. Pay special attention to the last one:
The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
-Don
Who are you to tell me which server I should or should not develop code on? Until you paypal me enough money to rent another server for a year, and donate your time to setting up and maintaining all the software I require on the extra server, I will develop on any server I need to.
Stop making excuses for design flaws in PHP caused by the developer's misunderstanding of object oriented programming. The fact that PHP uses a hebrew word in its error messages doesn't make it easy to understand why PHP's fucked up object system is annoyingly and brokenly different than well designed object systems of other languages. As Wikipedia article on Paamayim Nekudotayim says, "Although it has been confusing to many developers, it is still being used in PHP 5, as in this sample error message: Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in... on line...". Is that supposed to explain why PHP's design flaw is not a design flaw? If it weren't a design flaw, then why did it broadside the Zend developers who foolishly assumed their language had as well designed an object system as Ruby? Shouldn't they understand their own object system well enough to know it was impossible to implement ZActiveRecord, before trying it, announcing it in public, and being busted by a blogger who knew their own language better than they did? Why did they fight against fixing the bug for so long? If it's a design feature and not a bug, then why have they finally agreed to fix it in PHP 6, only after they've been publically humiliated by the ZActiveRecord Boondoggle.
You PHP apologists are just like the Bush administration's right wing water carriers. You will argue the wrong side of the issue even though you know you're wrong, because politic trumps truth. Just as bad as McCain respecting and thanking Rumsfeld: "While Secretary Rumsfeld and I have had our differences, he deserves Americans' respect and gratitude for his many years of public service", then flip-flopping and criticizing him: "I think that Donald Rumsfeld will go down in history as one of the worst secretaries of defense in history."
I have used TAL quite a lot, thank you. I've developed large compex sites in Plone, written many TAL templates and Metal macros, and I absolutely hate TAL templates, Metal macros, TALES expression language, and "restricted Python". I've read many TAL templates and Metal macros written by other people (Plone is full of them), and the TAL source code itself (which was rewritten by none other than Guide during his time at Zope Corporation). It's a great implementation of a horrible idea, that has been taken to extremes. That's why I like the Kid template system so much: it elegently addresses all the horrible problems of TAL.
But now I have to deal with PHP code that uses Smarty templates, so I read the Smarty source code. Have you? Do you have any idea how it works or what it's doing behind your back? Shut up with your PHP apologizing and sit down and read Smarty head to toe before you go claiming it's easy for designers to learn Smarty. If you had any understanding or appreciation for language design or parser implemention, you would throw up in your mouth at the heuristic regular expression guessing games it plays, and the undocumented, ridiculously obscure and inconsistent nuances of its syntax.
-Don
Most PHP programmers ARE beginners, so it creates many many unnecessary nasty surprizes. And for experts, it does not give you anything that you can't already do another way. It adds no real value to the language for experts (of which there are few), and totally screws beginners (of which there are many). Now please explain why you're apologizing for PHP and making excuses for why register_globals is still part of the language after all these years everyone knew it was wrong? I ask again: why did they make such a horrible mistake in the first place?
That's ironic, because people often repeat the myth that PHP makes it easy to interface with the database. Easy but deadly. The reality that PHP has horrible database handling is what's causing PHP programmers to defect to Ruby on Rails (which has ActiveRecord) in droves. Zend tried to imitate ActiveRecord but that resulted in the ZActiveRecord Boondoggle. Python has some excellent database interfaces and object-relation mappers, like SQLObject and SQLAlchemy, which beat the pants of anything PHP has to offer.
-Don
Want to talk about real issues? Post a reply to ZActiveRecord Boondoggle or Smarty is a piece of shit!. What's you excuse for that? Will you keep apologizing for PHP, no matter how bad it is?
Why do you think I have such a distaste for PHP? Because I have to use things like Drupal and Smarty out of necessity, because someone paid me to. If I never used PHP myself, then I would have no right to complain about it. The reason I have display_errors turned on is because I use my web server to develop and debug PHP code, and I like to see all the errors, so I know they're there and can fix them. You ought to try it some time. But fixing bugs in my drupal blog isn't high on my priority list, because there are other more important PHP bugs to fix.
-Don
If PHP is so great at supporting databases, then why did Zend give up on their ZActiveRecord Boondoggle, which wouldn't work as they falsely advertised because of a stupid PHP bug they refused to fix? Why isn't there anything like ActiveRecord for PHP? Because it's impossible, because of a bug that came about because the PHP developers didn't understand object oriented programming when they tried to imitate Java's class system.
Python has no trouble implementing ActiveRecord-like ORMs, and even has much more advanced SQL database toolkits than ActiveRecord. What does PHP have that compares with Python's SQLAlchemy?
-Don
It was highly unethical for the PHP development team to sweep all those bugs under the rug. The cat is already out of the bag. They are already public. Making an public issue of the PHP developer's horrible behavior and careless attitude is the only ethical thing to do. Don't blame the messenger. Blame the incompetent people who refused to fix the bugs, not the diligent person who fixed them, but had his changes ignored by the incompetent people.
-Don
Oh, please. Smarty is a piece of shit. You are hereby sentenced to go read the Smarty source code, and don't come back or post anything else about PHP to slashdot until you are done, and have washed the puke taste out of your mouth. Then you will be so embarassed you mentioned Smarty. It's one of the most truly horrible pieces of PHP code I have ever seen and had the misfortune of having to use. The whole idea is ill-concieved. PHP is ALREADY a templating language: why use it to implement another half-baked watered-down ill-defined templating language, that doesn't even support all the functions or syntax of PHP? I mean, it's not like Smarty keeps you from having to learn PHP, and then you still have to learn its horrible quirky half-assed syntax, which is even worse and messier than PHP! And you certainly can't edit in an XML editor, since it's flagrantly XML non-compliant, or even a PHP editor, since it's not PHP syntax either.
Templating languages should be clean, elegant, well integrated with the native scripting language, not trying to fight against it. And they should be 100% XML compliant, so you can edit and integrate them with all your other XML tools. Python's Kid templating language is a wonderful example of how to do it right.
-Don
How about putting all the PHP developers on a month long reality show, where if they can't fix all their bugs in a month, they have to cancel PHP!
But there would be so many bugs, soap operas, security holes, personality conflicts, segmentation violations, and hissy fits, that the network executives would extend the PHP Reality Show again and again, and it would end up running longer than The Simpsons. They could keep it going forever, by fixing one bug a day, while adding two more bugs.
-Don
Whenever somebody uses the sentence pattern: "I don't really bla bla bla, but bla bla bla." it means that they don't really mean the thing before the "but", and they're just saying it because they know the thing they're going to say after the "but" is totally full of shit. Like "I don't really hate gays, but I don't believe they deserve to get married, because the bible says so, and it's a horrible threat to my own marriage."
Would you please stop apologizing for PHP? You are part of the problem if you're apologizing instead of fixing security bugs. And you're hurting the internet, if you think you're sticking up for PHP by attacking somebody who actually is fixing security bugs. So stop it. PHP doesn't need you to leap to its defense: it needs to be fixed, or people need to stop using it.
-Don
Not only is the PHP development team negligent when it comes to dealing with security bugs, but they're incompetent when it comes to understanding the limitations of their own language, the tenants of object oriented programming, and database object-relational mapper design.
Here is quick summary of my previous post about Zend's ZActiveRecord Boondoggle:
The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".
To summarize: [Criticism of PHP "references".] [Criticism of PHP "object system".] [Description of "static methods".] [Description of Ruby on Rail's ActiveRecord.] [Description of "ZActiveRecord", Zend's lame half-baked cargo cult attempt to ape ActiveRecord.] [Zend busted for misleading screencast.] [Blog posting that proves: ZActiveRecord Can't Work.] [Zend misunderstood their own language's object system, showed fake code in a screencast that could not possibly work (because of a PHP bug), and made promises of ZActiveRecord they couldn't keep, because of that stupid bug they refused to fix.] [Longstanding bug that PHP static methods that the developers refuse to fix.] [Summary of comments on the bug that prevents anyone from writing an ActiveRecord-like ORM in PHP.] [Final word from andi, calls it expected behavior, demonstrating how he misunderstands object oriented programming, and casually dismisses all the bug report's valid comments.] [Zend gets hoisted on their own pitard by this very bug.]
And here's the final word from andi: "Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ [php.net] and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [php.net] This is expected behavior. self:: binds statically to its class (to the best of my knowledge other languages like C++ don't support this either as they require to explicitly use the class name). There are actually advantages also to this approach as they allow you to protect and encapsulate functinality."
Since Zend's dishonest and embarassing public-relations disaster with the ZActiveRecord Boondoggle, Zend has quietly withdrawn their plans for ZActiveRecord, instead of fixing the stupid bug that made it impossible to implement and ORM like ActiveRecord in PHP.
It's not just security that the PHP developers and Zend don't care about. They also don't care about nor understand object oriented programming, nor database object-relational mapping.
There is absolutely no reason to use PHP, when there are great languages like Python with extremely powerful, easy to use, safe and secure, database independent, object-relational mappers like SQLObject , and intelligent scalable SQL toolkits with multiple modular ORMs like SQLAlchemy. That stuff so blows away PHP's horribly insecure string-concatination approach to SQL, and all of the kludgy PHP database libraries people have cobbled together over the years.
-Don
If you're not fearful, uncertain and doubtful about PHP, then you're head is stuck in the ground and you do not know what you're talking about. PHP should most certainly be feared, doubted and not trusted. Stop being such an apologist fan-boy, and trying to attack the messenger instead of the cause of the problem: the PHP development team's negligent attitude.
-Don
It's the ignorant PHP apologists like you who are damaging the internet and causing much more trouble than anyone who's trying to expose PHP's bugs and embarass the PHP development team into finally fixing all of their long-standing security problems that they have refused to address.
The hackers and script kiddies ALREADY KNOW all of the vulnerabilities. It's ignorant PHP fan-boys like you who are in the dark and spreading bullshit, if you're not aware of what a truly horrible and insecure disaster PHP really is. The security holes already exist, and covering them up and making excuses for them isn't going to fix them. But exposing them to the light of day will force the idiots on the PHP development team to finally address them, and hopefully warn people away from using or trusting PHP. They had their chance to fix the problem before, and they chose not to. Stop trying to rewrite history to justify your misplaced finger-pointing. You fan-boys making excuses for the PHP development team's negligence are contributing to the problem, and just making it worse -- it's not the fault of the courageous whistle-blower who you're attacking. Stop damaging the internet, fan-boy.
-Don
The root cause of the problem of PHP's popularity are the minions of ignorant, irresponsible PHP fan-boys, evangelists and apologists who are always shooting their mouths off trying to convince droves of other sloppy uneducated programmers to use PHP.
STOP EVANGELIZING PHP! YOU ARE HARMING THE INTERNET!
-Don
There are many reasons that add_slashes is insecure, and if you think about it, you should be able to come up with a few yourself. Have you ever heard of Unicode? Do you really know what the quoting conventions of your database are, or are you just assuming that add_slashes somehow magically does? Have you even bothered to use google or read any of the many security articles about PHP? Obviously not. And the same goes for so many other PHP developers. They need training wheels and adult supervision, otherwise they wouldn't have made such a horrible decision to use PHP in the first place.
The issue is that PHP has many functions and mis-features like magic_quotes_gps that pretend to give you some level of security but ACTUALLY DON'T, combined with the fact that there are a lot of naive and sloppy programmers out there like you, who have no idea what the issues are, and have never bothered to think about them or even look them up on the internet. The problems are WELL DOCUMENTED AND WIDELY DISCUSSED. You have no excuse for not knowing them. You can use google as well as anybody, and educate yourself, but you choose not to.
But it's wrong to blame the ignorant sloppy application developers, when the language actually offers them up so many false non-solutions and dangerous pitfalls. It ENCOURAGES ignorant developers to make mistakes. Why didn't they remove add_slashes, magic_quotes_gpc, and all those other horrible bugs a long time ago, instead of leaving them in there to temp ignorant people into use them? The design of the PHP language and libraries and the attitude of the PHP development team is the core of the problem that causes sloppy application developers to make so many mistakes.
-Don
And you're surprized? You made your bed, now sleep in it. Or rather, stop sleeping until you've un-installed PHP on all your servers, because it will never be secure, thanks to the PHP team's attitude.
-Don
Can you please explain why register_globals was there in the first place? The reason is that PHP was designed by idiots, pure and simple. It should have never existed, not as an option, and especially not as a default setting. The same goes for magic_quotes_gpc and its ilk.
Face it: PHP is a horribly designed language from the core to its extremities, and you can't knickle-and-dime security issues as you discover them. The PHP development team's attitude just makes it much much much much worse. You're an idiot to trust them, and a danger to the Internet if you apologize for PHP, make excuses, and continue to evangelize and recruite naive developers.
-Don
You wouldn't be using PHP if you weren't an idiot yourself, so shut up with calling other PHP developers idiots, and blaming them for the problem. If you were such a great programmer, you would know better, and you wouldn't be using PHP in the first place.
-Don