Slashdot Mirror
March To Be Month of PHP Bugs
PHP writes "Stefan Esser is the founder of both the Hardened-PHP Project and the PHP Security Response Team (which he recently left). During an interview with SecurityFocus he announced the upcoming Month of PHP bugs initiative in March." Quoting: "We will disclose different types of bugs, mainly buffer overflows or double free (/destruction) vulnerabilities, some only local, but some remotely triggerable... Additionally there are some trivial bypass vulnerabilities in PHP's own protection features... As a vulnerability reporter you feel kinda puzzled how people among the PHP Security Response Team can claim in public that they do not know about any security vulnerability in PHP, when you disclosed about 20 holes to them in the two weeks before. At this point you stop bothering whether anyone considers the disclosure of unreported vulnerabilities unethical. Additionally a few of the reported bugs have been known for years among the PHP developers and will most probably never be fixed. In total we have more than 31 bugs to disclose, and therefore there will be days when more than one vulnerability will be disclosed."
Public Holes Publication, isn't it ? ;)
-- Rastignac was here.
Looks like this will also be "Month-of-me-working-harder-to-make-sure-my-site-i s-patched- and-updated-and-not-exploited-by-script-kiddies"
Lindsay Blanton
RadioReference.com
I thought every month was PHP Bugs month?
...there are that much holes in PHP (which i don't doubt), mr. esser seems to be on a kind of crusade since he left the security response team.
month of PCP bugs. i see them all over my skin and i can't scratch them off! SOMEONE HELP ME
I really shouldn't be surprised at the PHP team's approach to security any more, but it really does still surprise me from time to time. It's amazing, but the PHP team are worse than Microsoft ever were with security. And they don't even learn from this - they've had this attitude for as long as I can remember (PHP 3 days), and they just aren't getting it. Or rather, if they get it, they just don't care.
I am actually glad to see one of these xxx month of bugs. Personally I have always thought PHP to be a steaming pile of poorly thought out garbage but there is no denying its popularity despite its flaws. Anything that actually helps the meme 'most php flaws are caused by poor programmers' actually become a reality by improving the core security of the language is therefore to be welcomed.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
I recently installed modsecurity http://www.modsecurity.org/ for apache along with the rules from http://www.gotroot.com/ and it's done a good job of blocking attacks on my server including a lot of the php mail() injection attempts, whilst it has shown up a few false positives like someone posting a message with sql keywords e.g. "select" "from", it is certainly worth installing even if you have to monitor the logs for a bit afterwards to watch for the false positives and alter the rules accordingly.
Whilst it probably won't solve a lot of the problems with php and security it does help protect the server especially when you don't have control over what your users are uploading to their web space.
Maybe you shouldn't bother with the patches. If you're running any of the well-known PHP software, there's a good change your server has already been compromised by one or more such script kiddies.
I actually persuaded my business partner to authorise a 2-month long project to reimplement all the features we need from phpBB from scratch, rather than use original code, just for this reason. It didn't take much work to convince him that we didn't want the hassle of having to deal with regular 0-day exploit scripts in the wild.
I always had the feeling that the bad security reputation with PHP had less to do with technical bugs and more to do with how easy it is to write insecure code(especially when using the mysql module). Also at fault is the general lack of programming understanding by the amatuers who find their way to PHP because it is so easy to go from having a static HTML page to a dynamic PHP page. Are there a lot of vulnerabilities in the interpreter?
It's amazing, but the PHP team are worse than Microsoft ever were with security.
This is very true. And also very unfortunate. When it comes to many managers, PHP has given the entire open source community a bad name. This is mainly because it has been repeatedly pushed as being part of the LAMP suite, when in fact Python and Perl are far better options for the 'P'. So when you recommend the use of Linux, Apache or MySQL, they automatically think of PHP, and recall how terrible its security is. And then they associate that lack of security with Linux, Apache and MySQL, even when that's not the case!
If there's one thing the open source community as a whole should do, it should be to disown PHP. Responsible open source developers and projects need to just stop using it for their web sites. It'd be good if more things like this Month of PHP Bugs were held, just to show the public that the OSS community knows that PHP is terrible, and wants to do something about it. The longer we continue to use PHP, the harder it will be to repair the reputation of even completely unrelated (and far more secure) open source projects.
Only a month?
Ha ha, yes, thank you, I'll be here all week, bringing predictable yet mildly amusing banter. In fact, I'll be here all year. The whole of my life, probably. *breaks down and cries*
Whence? Hence. Whither? Thither.
If he really wants to make a difference, he should fork PHP and really fix up the language and interpreter to his liking. Besides bug and security fixes, a standard naming convention for built-in functions would be quite nice. Maybe Esser could do for PHP what EGCS did for GCCS if he did that.
Most likely, you're correct.
Still, there are precautions to take when running a common PHP-based app. First off, use Xen. Set any filesystem to read only (through Xen) that you can get away with. When installing PHP, only install the modules the script actually uses. Second, install mod_security and enable every possible protection. Third, install Suhosin (hardened php, Debian Etch has it packaged). Fourth, edit the php.ini file and enable safe mode and disable every possible feature you can get away with. Fifth, for the DB create multiple accounts. Use the permissions properly. Set it so that the user the script has only can update the specific tables it has to, deny it from everything else.
Still, it will only be a matter of time before it's compromised but at least those steps help. Make sure to make regular database and file backups from the Dom0 so it will be easier to restore the site.
PHP really needs to enforce proper security. In 5.x it's OO is actually pretty nice and I like doing development with it, but I've dropped it for Java due to constant security issues.
With all the effort necessary to set up Xen, strip out unused modules, fuck around with configuration settings, test it all out, etc., etc., it's probably just easier, cheaper and safer to go with something other than PHP.
Not to start a little argument over PHP and Python, but you're comparing apples with oranges here. You are saying that PHP is insecure, its semantics are undesirable and so are its standard libraries, database interfacing, interpreter and performance, and then you come along saying how awesome Django is, disregarding that actually you're comparing a language with a framework.
There are a handful of decent PHP frameworks out there, with others coming along, which you can take and compare with Django, but please don't bash the language because you don't like its semantics, you have something personal with it or you didn't take the time to choose a decent framework.
Regarding the database interfacing support, I beg to differ, I believe PHP has been supporting a large number of databases for a longer while than most of the other web scripting languages out there today.
This is not your signature.
Do we need a month dedicated to every application that has bugs in it? Because I'm pretty sure our sun will have imploded by then.
The bright side, it seems to me, is that PHP's openness means even if the developers are slack, the bugs can still be disclosed without IP litigation threats.
Also, he's given the developers a week or two of warning before March. If there's anything *that* serious in there, actually known to the developers, the fix could conceivably be ready by the time the bug is announced.
I run PHP sites, and I'd rather see the bugs public and being patched, than known only to the developers (we hope).
You're absolutely correct.
However, you'll probably run into a situation where the customer demands a certain poorly written php app. In those cases you have to go through the extra effort and deal with the inevitable compromise.
PHP is a nice language, but it needs to enforce proper security. If that security breaks apps, tough shit. Fix the broken apps.
Disregard that post, I should have previewed and read it again before submitting. It actually makes it sound like PHP is the OpenBSD of scripting languages, which is obviously the opposite of the desired effect.
This stinks of self-promotion. Calling something a "Month of PHP Bugs" does nothing to improve PHP's reputation. It sounds spiteful, in fact.
Yep. Everything he writes on this topic is along the lines of:
-They all suck.
-I'm the greatest.
-They're all out to get me.
-The fools, the laughed at me at the institute.
-You aren't taking me seriously! I've fixed everything in my personal extension to PHP and you keep breaking it by changing the language!
etc... etc...
I don't know what he thinks he's going to accomplish - but he's made his name synonomous with "shit disturber" and while he claims to be trying to make PHP better, he's only poisoning things in the long run.
BlackNova Traders
On a side note, anyone know where I could find that Suhosin extension compiled as a binary (DLL) for windows ?
"Month of Shooting Fish In a Barrel"
At least the Month of Apple Bugs was a hard target to go after.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Scratch harder.
Well, I do not have a lot of experience with PHP (only some typical unsecure LAMP tests) but after looking what they did with mysql_real_escape_string() and mysql_escape_string() I agree with GP. What kind of programming language is that? what the heck does REAL is supposed to mean?
.NET was just out) and I can tell you that even there, the microsoft product was better than PHP. One of the things I dislike about PHP and I liked about the WebForms .NET approach is the separation of the interface with the functionality which allowed us to create a real multi tier application. I have not programmed "for real" web applications for some time but as far as I know it is not possible to do that sepparation with PHP.
I have programmed in PHP and C#/VB.NET for web forms (back when
Ubuntu is an African word meaning 'I can't configure Debian'
Do not let it execute inside web pages. X server pages is bad. Take PHP outside of web pages altogether. Good PHP programmers should be using Smarty templates anyways.
/. security image is the word "toasted". Haha nice!
One way of looking at PHP is that it is an extremely powerful templating language. That's the job it was designed to do in the first place, anyway. So why not write your back end in a more powerful language and just do a quick front end templating job in PHP that takes those results and slaps them into a web page.
Oh, right, the reason not to is that PHP is just about the only common denominator you'll find at nearly any web hosting company you might choose to go with. I think this is just about the only reason not to though.
(I say, begrudgingly, as a PHP programmer who uses the language only because of this popularity factor)
PHP has nice C/Perl syntax, it has the potential for a good general purpose language.
I don't think so. There is at least one major flaw with its language design (and it's a basic, fundamental flaw that most people don't realise): there is no distinction between strings and identifiers. Try this:
It's an interesting choice: '$' becomes an unary operator that returns a reference to the value of its argument. So why doesn't work? God knows. It should, but it doesn't. Probably the same reason that functionReturningAnObject()->field doesn't work: the language definition is screwed up. $v = "t"; echo $$v; works fine though.
Reference semantics are screwed up as well. Try this:
$a = array (1, 2, 3, 4);
foreach ($a as &$b) $b++;
foreach ($a as $b) $b++;
print_r ($a);
Now, explain to me why it is that the last item in $a is incremented twice, while all the others are only incremented once?
The more features are added to it, the more evidence there is that at its core, PHP is a badly designed language.
P.S The
Did you post AC just so you could make that joke?
Hmmm... The munged PHP code from my post was:
(lack of quotation marks deliberate)
and
(addition of quotation marks also deliberate)
after looking what they did with mysql_real_escape_string() and mysql_escape_string() I agree with GP. What kind of programming language is that? what the heck does REAL is supposed to mean?
It's a backwards compatibility hack. When they implement mysql_escape_string, the MySQL C API didn't need a connection object to the server to perform quoting, it just did it locally. Some advanced features were added in later MySQL versions, and a connection to the server is now needed in order to know what character set is in use in order for the quoting to be performed correctly. If you're just using us-ascii/iso-8859-1 like most MySQL developers, you can ignore the difference. If you're using UTF8 or some other charset, you need to make sure you use the "_real_" version.
The whole 'mysql_*' API ought to be deprecated anyway. mysqli is much better.
One more thing:
.NET approach is the separation of the interface with the functionality which allowed us to create a real multi tier application. I have not programmed "for real" web applications for some time but as far as I know it is not possible to do that sepparation with PHP.
One of the things I dislike about PHP and I liked about the WebForms
As somebody who has written a 3-tier web application in PHP for a well-known multinational company, I can assure you that tier separation is not only possible in PHP, it's actually fairly easy. Just don't try forwarding remote session IDs to the middle tier from the front tier and then running them on the same server. It won't work.
Here are a few simple precautions for PHP configuration:
- Do not(!) install cURL. I know it is useful, but has a lot of security problems!
- Disable register globals [default as of 4.2.0]
- Safemode is worthless and a little too restricting, use OpenBaseDir.
- disable_functions = exec,system,passthru,shell_exec,proc_open,proc_cl
o se,proc_terminate,proc_nice,proc_get_status (may be more, off the top of my head :-)
These are what I can think of off the top of my head. This allows full compatability with all major scripts [mostly due to not using SafeMode] but still holds a fair bit of protection from people executing scripts and pushing them to run in the background. Had this happen to me a few years ago. I was hosting someone as a favour, and I'm not sure if they did it, or they were running some crappy code and it was exploited. Either way, their account was suspended.Give people a day or two to respond to each exploit before he hands us another to go racing after.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
I hereby declare March 2007 the March that never ended, in spirit of September that never ended.
My personal opinion is that there are far too many people out there that call themselves Wep Applicaton/PHP security experts and write books/give talks about PHP Security
No, kidding?
I'm not a programmer and never will be, so "Code your own!" doesn't work for me. If PHP is really so insecure then what are realistic alternatives?
Right now, they're very few and very far between. You could look through sourceforge projects in the Internet/WWW category with the filter 'excluding programming language PHP' applied.
The problem is that so much stuff was implemented in PHP in the late 90s/early 2000's that just about every hosting service went out and installed it. This led to a positive feedback system where nearly everyone chose to develop for PHP, because that's what nearly every hosting service offers, etc. It's the same kind of situation that led to Windows dominance, only (IMO) without the product actually being anywhere near as good.
I'm going to need enough popcorn to last... March.
Game... blouses.
Have a back end program that doesn't produce any HTML output. Have it produce a data structure that describes the information to be embedded in the page, along with the name of the template to embed the data into. More complex schemes may be necessary for some apps, but this suffices for most. Serialize this data structure (you could use any appropriate data serialization format, I generally use simple XML schemes)
Write a front end program that takes the user's request parameters and parses them, selects an appropriate back end program and then includes its response via file ('http://whatever') (or cURL if you need to POST data). Then it can either do what I do, which is use a template engine to process that data into an HTML page, or if you're feeling too lazy to do it that way you can use PHP itself as the template engine: just include ("../templates/" . $templatename . ".inc") (after suitably validating $templatename of course). The code in the template is very simple, using PHP only for simple variable substitution and iteration over predefined data structures.
If you only need logical and not physical separation of the front and back ends, you can include a file with the implementation of the data-structure producing logic and call that, which should save the cost of serialization and deserialization.
Separation of code and presentation can be done by using a templating system. Smarty is a popular one, although it's often criticized, and there are a lot others around as well. FastTemplate, although old, is also a choice.
Most of the frameworks mentioned above are built fanatically on MVC, so this separation is imperative.
This is not your signature.
If you teach a man to fish with a rod, he won't immediately know a better way to catch more fish. The idea of using a mesh net to catch more fish at once will not be apparent to him -- it will take time. A man and his tools are departed only when he finds something better for the job.
So let's apply this concept to learning in the PHP community. For years, PHP developers (newbies, amateurs, and experts alike) have been handed down wisdom that reflected the current knowledge. Years ago, it was using registered globals. Then it became including pages via the query string. And so on... You can imagine for someone new to PHP how hard it would be (if not impossible) to distinguish right from wrong when everyone was telling you to do a certain thing. Articles, forums -- you name it, they preached it.
PHP has become more insecure due to the amount of bad advice spread, not because of PHP. What did we all learn about pointers? When abused or not taken care of, they can cause problems. The same goes for the tools PHP offers.
Slashdot will forever gouge PHP for being insecure, but I think it has everything to do with an immature community dishing out advice far too soon. PHP has matured, and so has much of the advice. Given more time, bad advice will be harder to find.
Blaming PHP for being insecure / providing insecure tools is like blaming auto manufacturers for attaching a steering wheel and a gas pedal to cars that cause accidents... think about it.
For he today that sheds his blood with me shall be my brother.
I've long argued that for as much as the pro-PHP group blames the coders, there is simply no excuse for some of the levels of vulnerability. So, while I'm loathe for the torrent of problems, I am glad to see someone finally calling PHP out in the open for some of the problems it created long before any kid touched a single line of code.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
You might want to try http://www.nyphp.org/content/presentations/3templa tes/ - it's a good explanation of how and why you should use templating. Which method you go for is entirely up to you but I recommend not using a template engine unless you're planning on building a large site and using PHPs native ability to template instead.
After learning PHP some years back by reading a couple of books I was satisfied with the level of information I got from it. I was able to write my own web-apps, hoorah! Over time though, common sense kicked in when I realised that merging PHP and a fair amount (not the whole lot) of HTML did nothing for readability and future maintenance. It's worth nothing here that I'd not much experience in formalised programming methods or style at the time.
Let me tell you, as a newcomer to PHP you see plenty of guides and books explaining how to create run-of-the-mill web apps but will never come across anything that tells the benefits of splitting up your code into different layers of logic (or funnily enough, how to use OOP). As I mentioned, common sense kicked in and I spent some time looking into it until I eventually found what I was looking for. This is a clear example of how emphasis is placed on firing out code rather than doing it right.
Still munged I'm afraid.
Actually, that bug is resolved in PHP 5.2.1
http://bugs.php.net/bug.php?id=35106
"At this point you stop bothering whether anyone considers the disclosure of unreported vulnerabilities unethical."
Maybe. But to take more than 31 bugs and disclose them a day at a time so that in effect major web-facing infrastructure for big business and home users alike will have no chance at all of being secured during this entire window, all for the purposes of publicity?
Really? Leaving aside the matter of using shared libraries, whenever I've had to add features to PHP it's gone like this:
The only actual downtime occurs during step 5, which lasts maybe a second at most. This is Linux after all -- you can run the old version while you're installing the new one.
Or am I misunderstanding your point?
I'm a PHP developer (amongst other things) and am looking forward to this. Stuff like this can only be good. And if it helps to find new or forgotten bugs - all the better.
We suffer more in our imagination than in reality. - Seneca
You will want to use an MVC (Model-View-Controller) paradigm. The Model contains your data work (accessing database, data manipulation, etc.). The Controller directs the application what to do, and the View is the final result (HTML).
The View can contain minimal PHP that's only used for display purposes. No data manipulation is done here (other than walking through records, for example). Alternatively you can use templates, but the point is moot because you're adding a layer of abstraction on top of what PHP already does -- templating.
I recommend CodeIgniter as a simple framework for any future applications you build. It's based around MVC, has a small footprint, and is very easy to learn and work with.
For he today that sheds his blood with me shall be my brother.
Good PHP programmers should be using Smarty templates anyways.
I was reading until that line. Yes, let's template a templating language thereby giving us less functionality and more overhead. The additional layers of abstraction and work is brilliant!
For he today that sheds his blood with me shall be my brother.
This is all in fun, it's his "brand". Didi your last marketing effort end up on CNN? Of course he's picked the low-hanging fruit first. Once it's 2008 and it's the "Month of COBOL on DEC Alpha Bugs" let's see if he can still stir up a media cluster f***. Go Stefan!
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
This works fine in PHP 5.1.4: - - - - - - - -
Now, explain to me why it is that the last item in $a is incremented twice, while all the others are only incremented once?
Sure (after some fiddling around). As you enter the second foreach loop, $b contains a reference to the last member of the array because that's how the previous foreach left things. Therefore, for each iteration, what you are saying is this: Make the last member of the array ($a[3] as referenced by $b) equal to the current member of the array, plus one.
If $b added 1 to itself (as might be expected) then the value would end up being 9. What seems to be happening in the second loop is: $a[3] = $a[n] + 1, not $a[3] += 1
I don't know if that behaviour is right or wrong in a formal sense.
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
Take a look and feel free: http://www.PieMenu.com
Are these exploits or "exploits"? After all, a lot of "exploits" are huff and bluff about what really should be called bugs or even just quirks.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
I've forgotten - how many lumps of sugar does a Scotsman take with his tea?
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
Take a look and feel free: http://www.PieMenu.com
I think I'll switch to brainfuck.
Anyone ever heard about a bug in brainfuck?
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
Take a look and feel free: http://www.PieMenu.com
You were modded "Insightful" for this flamebait? The mod system strikes again!
The only "idiots" I referred to are the ones who know just enough about their tools to get themselves into trouble. I don't see me dropping blame on _ANYONE_ whatsoever, could you point out the "blame" I've laid on others?
Flame on with your "Insightful" claims, your valuable input is appreciated.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
If you were such a great programmer, you would know better, and you wouldn't be using PHP in the first place.
You know, a lot of us PHP programmers don't use the language out of choice. We use it because either (a) the boss insists on it, or (b) we're programming for deployment to a choice of web hosting providers that is out of our control, and know that PHP is the only scripting environment that we can rely on the availability of.
Unless you see a workable solution for people in either of these situations, shut up.
If you're a programmer and you don't see huge problems with both the design of PHP itself and the standard library you should just quit now and find another hobby/profession.
I'm a programmer. I work with PHP. I see a hell of a lot of problems with its design and implementation. Am I ready to dump it and switch to something better? You bet. I've been waiting for the chance for the last 5 years or more.
Can I actually do this?
No. The marketplace is such that if I implement my solutions in any other environment, I'm cutting myself out of large chunks of the market simply because people might choose a hosting provider that doesn't support whatever alternative language I choose to use.
Why do you have to wait a month? Something with your setup must be wrong if you can't get the recent source from CVS or download the latest snapshot.
*facepalm* Made the same mistake twice in a row.
Meant to write:
$t = hello; echo $t;
and
echo $"t";
I don't know if that behaviour is right or wrong in a formal sense.
I'm not saying its wrong. I know that according to the language design it's complete correct. I *am* saying it's counterintuitive, and evidence that something is wrong with the design.
Again your confusion is due to your misunderstanding, not any fault with PHP.
My point is that it's difficult to understand. I do understand it, believe me, which is why I used it as an example. *But* I constantly see people getting confused by this behaviour. It doesn't match their internal model of theway they thought the language worked.
And if you weren't an idiot you would come up with real issues instead of replying to everyone who doesn't hate PHP. You see how easy it is to write something like this. I write it and it makes you an idiot - like you made everyone else an idiot. Or maybe you're just wrong and are wasting you're energy for the wrong things.
/usr/local/src/drupal-5.0-beta1/includes/session.i nc on line 46"
BTW why are you using Drupal? Any why don't you RTFM or use the recommended php.ini? Notices and display_error should be turned of:
"Notice: Trying to get property of non-object in
Seems like this makes you an idiot^2.
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
Take a look and feel free: http://www.PieMenu.com
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
Take a look and feel free: http://www.PieMenu.com
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
Take a look and feel free: http://www.PieMenu.com
The default behavior in case of database problems is to display the host, username and password in the browser? Good grief.
No, I did not read the f***ing article!
Java! And Applescript! And FORTRAN! And Cobol!
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
Take a look and feel free: http://www.PieMenu.com
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
Take a look and feel free: http://www.PieMenu.com
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.
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.
- Raynet --> .
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
Take a look and feel free: http://www.PieMenu.com
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
Take a look and feel free: http://www.PieMenu.com
You should not develop on your live server and try not to debug there either. But even if you need to you could turn display_errors on when you need it - even in a PHP script, because it's PHP_INI_ALL. error_reporting too. Maybe in an auto_prepend_file. RTM.
:: is always using the class it's defined in. Otherwise self:: or parent:: wouldn't work. However it will be fixed in PHP 6. If anyone would have mentioned it when PHP 5 was still in development (before 5.0) the internal structs could have been changed to allow such code. But it took until Ruby on Rails got famous for anyone to need such a feature. Maybe it's because the same thing can be done with an instance - see Zend_Db_Table.
... Sometimes you have "designers" write the templates and for them it's easier to learn Smarty.
Now your two posts. T_PAAMAYIM_NEKUDOTAYIM or
And Smarty. If you want to write your template with XML tools why don't you use TAL? Or output your data in XML and use XSLT to transform it to PHP. If you want to use PHP template engine then just do it! Or you could use Zend_View if you're into libs. But not everyone wants or needs every PHP feature in the view layer and not everyone working with templates should need to learn PHP - or XML and XSLT and XPath and XInclude and
I recently installed modsecurity http://www.modsecurity.org/ for apache along with the
rules from http://www.gotroot.com/ and it's done a good job of blocking attacks
on my server including a lot of the php mail() injection attempts.
ozgur uksal
How do you really feel, Don? Don't hold back for our sake.
Seriously, while I agree in spirit, what PHP has going for it isn't "irresponsible PHP fan-boys" as much as it is a good ol' network effect. Every host has it and deploying a PHP application is often just a matter of uploading the file and going. (In the immortal words of Jeff Goldblum, "There's no step three!") Contrast that with Ruby on Rails; you have to find a host that will host a Rails app, and as I'm learning, some of the ones that say they do have a lot of caveats on their basic plans (I'm looking at you, TextDrive, with shared hosting process size limits that make running Rails... problematic, shall we say). Assuming you manage to get things set up with Capistrano you're golden. Unless you gotta move providers for some reason. If you do, you're not just dumping your database file and zippin' up the application directory like you would with -- yes -- PHP. While I haven't used Django or Python-based apps, many of the concerns are, from what I've seen, similar.
Yes, yes, I know: none of these things make PHP any better as a language, all of them could be addressed through proper education, and so on. All true. But I'm gonna go out on a limb and guess that you're hostin' your own web site on Drupal rather than Django (or whatever) for reasons other than being convinced by droves of sloppy, uneducated programmers. And those reasons are the ones that need to be addressed. Until deploying Rails, Django, Seaside, or whatever else is as easy as deploying PHP, then PHP wins. The most repeatable (if oft depressing) lesson of modern technology is, arguably, convenience trumps all other considerations.
I work for a big web company (go ahead, guess which one). We use Smarty for several of our large sites. It is extremely convenient to not have production staff (who do stylesheets, graphics, etc) messing around with the actual site code. Overhead isn't really a big factor if you use an opcode cache. For 99% of the requests, Smarty serves a cached flat file anyway. It's very nice.
no longer working for cnet
That's just bullshit. It took Ruby on Rails (and ZRecords, *snicker*) for Zend to understand why that would be useful. Meanwhile, there are dozens of bug reports (predating PHP 5 development), dismissed and closed because its "not a bug."
PHP is full of half-assed and poorly implemented features... references, function parameters, core functionality, etc. Depending on which version you're using, http_build_query, for example, may take three parameters. Or maybe two. Or maybe the function doesn't even exist. Why do they bother polluting the namespace when you're going to have to rewrite the (5-line) function yourself?
Do you even lift?
These aren't the 'roids you're looking for.
If they are problems which are not being fixed then why not fork the PHP code base and apply your security fixes, no ones stopping them and this is the point of open source software.
If something isn't being done then you have to do it yourself.
It seems like you're thinking it needs Zend for any feature in PHP. But PHP is not written by Zend. So it also doesn't matter when and if Zend understands if a feature is needed.
:: that does not bind at compile time. It would be funny if i.e. parent:: changes just because it's a different instance. Also many languages don't have such a keyword and you have to write the classname explicitly - which also means it won't change. And all of them have ORM libs.
And it is not a bug. At least for self::. There is currently no keyword that can be combined with
But even in PHP6 it's not a bug that self:: is bound at compile time. What you want is a new keyword that is evaluated at run-time in static context. And that will be static:: IIRC.
I don't know what your problem is with functions with added parameters. That's done in every language and as long as the parameters are optional it's backward compatible. As long as you know under which version your code will run you know which parameters or even function you can use and which you should avoid. Again - like in every other language. If you think feature X of version Y is necessary you'd define that as your minimum version.
The global/single namespace, you seem to have a problem with, is not uncommon in procedural programming languages, which PHP still is. That's why prefixes are used. And you'd prefer the internal functions if performance is an issue.
Python (Monty).
GPL: Free as in will
I am not apologizing, perhaps I am just stupid or something, but I really don't see the problem with register_globals. Perhaps you could point me to some well written article on why it is so fundamentally bad design.
And I said, database handling is what in my opinion sucks the most in PHP. Some anonymous commented about Pear:DB and PDO, and PDO looks at a glance to be quite an improvement, so perhaps PHP6 gets it right...
- Raynet --> .
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
Take a look and feel free: http://www.PieMenu.com
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
Take a look and feel free: http://www.PieMenu.com
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
Take a look and feel free: http://www.PieMenu.com
Namespaces are not the same as modules. Modules is just loading a bunch of constructs in the global namespace. You could use PHP with only a minimal set of modules and load what you need at runtime. But that won't work very well in the web enviroment.
BTW how do you know ZActiveRecord was the idea of someone at Zend? There are many people working on the Zend Framework and many of them are not working for Zend.
Last but not least. If you want Python - use Python. It's that simple. PHP will never be Python - why should it?
You mean you have only one computer and that's also your server? Otherwise you could use your desktop for development. But if you want to develop on your server you can and may - it's just not something you should do if you're sane. Even if you have to you could change your config - but I've mentioned that in my previous post.
Next point. Static inheritance is not really an OOP thing. There are no school books about how it should exactly work, thus if it's a misunderstanding it means it doesn't work like in language X.
Still - self:: is bound at compile time. That's not an error and will never be. Also not in PHP6. It won't change. PHP6 will add a new keyword static:: that does late binding or at least it's planed. Again: self:: won't change and the way it behaves is not an error.
One thing I also mentioned before - PHP is not Zend's language. Zend is one of the companies working on PHP and providing tools and support for other companies working with PHP. Like Python is not Google's language even if Guido works for them.
BTW I don't believe you've really read the TAL source code. You remember. We're talking about PHP. Plone and Zope have nothing to do with PHP. Kid on the other hand is a much XML as PHP is. You said you hate Smarty because it doesn't work with XML editors. But they won't help you with Kid either, as hiding structure in PIs is not really XML. Maybe you were just looking for a random argument against Smarty.
Oh yeah I read Smarty. It's as complex as such an additional layer needs it to be. Never had a big problem. Never had our designers. Maybe it's because we write PHP code and dummy template and they write HTML dummies and than use our dummy templates to put things together. But I guess working with others is not something someone, who calls everyone an idiot out of the blue or compares him with a random jackass, would think of.
Stop using PHP or get over it. No one really forces you - you could start flipping burgers at McDonalds and never again hear of PHP.
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
Take a look and feel free: http://www.PieMenu.com
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:
Take a look and feel free: http://www.PieMenu.com
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
Take a look and feel free: http://www.PieMenu.com
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
Take a look and feel free: http://www.PieMenu.com
I thought of .so when talking about modules. I.e. DSOs in Apache are modules too. Namespaces are on the list of PHP6 IIRC, but I don't know if they've found a symbol for namespaces yet.
ActiveRecord is possible in PHP, just not with the same syntax as in Ruby. You've to create an instance before using it. See CakePHP or Zend Framework for examples.
BTW PHP uses COW. You don't need a reference to an array to avoid copying.
The other Month of Bugs are a little ***useful***! Exposing that things are less secure than they seem, and so forth. But everyone knows that PHP has more bugs that the worst hotel's mattress! If someone sees a point, tell me!
If you want a real pure XML template system it'll always be PITA. Otherwise no one would use XSLT or TAL, because there would be something easier. "Hiding" commands in PIs or cdata is the only way to make it easier.
Why bother implementing an extremely bad languge like Smarty in a very bad language like PHP? Just use the very bad langauge instead: it's faster!
That's what Smarty does. Templates are translated to PHP. Many people made benchmarks and Smarty is nearly as fast as plain unstructured PHP code as template language. That trade-off is because you get an organized view layer. It's the same with every other layer in the classic MVC model.
If you don't like SAX you should take a look at XMLReader. I did take a look at Kid. Something similar should be possible in PHP. Of course it woldn't be exactly the same, because it wouldn't be base on Python, so you'd bash it anyway. One problem I see in Kid is using it for output that's not XML.
Python's Kid template system is proof that you're wrong about XML template systems always being a pain in the ass. I've used it to write a whole lot of complex templates, and I'm very happy with it, and will continue using it. I've also used XSLT, TAL/METAL/TALES in Plone, and Smarty in PHP, and they are all total pains in the ass which I hope to avoid ever using in the future. If you had some perspective on other templating systems, you'd know that hiding commands in processing instructions or cdata is NOT the only way to make them easier. Designing clean simple consistent yet powerful XML based languages is the way to make them easier, and that's what Kid is. OpenLaszlo is another example of a well designed XML based programming language that is easy to use because it's well designed.
At least I'm criticizing and complementing systems that I've actually used. You're just making wild guesses about things you know nothing about, and your guesses are wrong.
I know Smarty translates templates into PHP -- I've read the source code and used it. Kid translates templates into Python, and I've read that source code and used it too. Kid's approach to XML processing is a much more elegent, efficient, better designed than Smarty's ad-hoc string parsing based approach, by a long shot. Go back and read the source code to both systems yourself, and use them for non-trivial projects like I have, before shooting your mouth off about them when you don't know what you're talking about.
Again: Why bother implementing an extremely bad languge like Smarty in a very bad language like PHP? You can't argue that Smarty's syntax is any better than PHP or XML. So why use Smarty at all? Why not just stick with pure PHP? There is no need for Smarty. It doesn't solve any problems that PHP doesn't already solve. It just introduced another fucked-up quirky syntax you have to learn, which makes PHP even harder to use.
And no your could not implement a system like Kid in PHP easily or efficiently, because it's based on XML event handling using Python's generators, which PHP does not support. Kid transformations are easy to write because they use generators with "yield" and "next" in co-routines running in parallel, to efficiently produce and consume XML events, so you can write straightforward procedural code with local variables, conditionals and loops, without writing SAX-like handlers and putting all temporary state into objects. Generators are a language feature that is extremely useful for efficiently processing XML, and they can't be implemented by a library: they have to be built into the language. PHP does not have generators, and I doubt it ever will.
Smarty is purely string based, and not at all XML compliant, and makes no guarantees about the validity of its input or output. XMLReader's detailed description is "This class can be used to parse XML documents and build an array with structure and data.
Take a look and feel free: http://www.PieMenu.com
Your statement "I don't know if they've found a symbol for namespaces yet" illustrates how some people think about languages in shallow terms of surface syntax, while others think in terms of deep semantics. Namespaces are a semantic issue. The syntax you use for them is not important. Unfortunately most of the PHP designers and programmer are shallow "syntax oriented" thinkers who can only visualize a concept if they know what characters to type to represent it, and they think that once they've designed a syntax (or imitated a syntax of an existing language, like PHP's references imitate C++, but don't share any of the semantics), they're done. They they spend the next 10 years fixing thousands of bugs and security holes that popped up because they didn't think the semantic issues through. That's why PHP is such a totally fucked up mess.
Forcing the programmer to create a dummy object, just to select for real objects of the same type, is a horrible kludge, which is wasteful and imposes unnecessary and obnoxious restrictions on the design and implementation of your objects, and clutters up the code and memory with unnecessary crap. Of course that would not occur to you if you were just trying to ape the surface syntax of ActiveRecord by putting a "Z" in front of it, giving a screencast promising it, and declaring yourself done with the design phase.
-Don
Take a look and feel free: http://www.PieMenu.com
If syntax is not an issue why is perl called a write only language? Both is important. You could use as namespace operator - people should get over it, because it's not the syntax that matters.
Know it gets funny. You're talking about how stupid I'm about not knowing what I'm talking about, but you can't even type http://php.net/xmlreader and read what it's really about.
BTW, QED: You won't accept any Kid like solution in PHP, because PHP is not Python and it won't be exactly the same. At least I'm sure _you_ couldn't implement it in PHP.
Now if you want me stop criticizing you and the stuff you write you should really learn and understand PHP.
Perl is a write-only language, because its designer believes it's OK for syntax to be extremely complex, subtly nuanced, haphazard and inconsistent, which I strongly disagree with.
Grammars "is" important, too.
Both syntax AND semantics are important. If you screw up either one of them, you've made a mistake. Smarty is so horribly bad because it totally screws up BOTH syntax and semantics. Kid is so wonderfully elegant because it has both excellent syntax and semantics.
Your words suggest that you (and the PHP designers you're talking about) are thinking in terms of syntax, and ignoring the semantics. Quibbling about what character to use to syntactically represent namespaces should not hold up such an important issue of language design. PHP should have had namespaces from day one, but now it's way too far down the road of "globalism," with millions of programs depending on thousands of global variables and functions, so adding namespaces to PHP now would just be closing the barn door years after the horse left the barn. It's laughable that they'd be so concerned about figuring out the perfect syntax of namespaces, and it has taken them so long to decide, that even after 13 years PHP still does not have namespaces!
My point is that when you THINK about programming, you should no be thinking about what characters you're going to have to type in order to enter the program into a text editor. If you are are thinking at such a low syntactic level, and not thinking about the semantics of your program, then you are a shallow programmer. But if all you have to do is write a program that barfs out some HTML and substitutes a few variables, then you can get away with being a shallow programmer, like most PHP programmers. And there's nothing wrong with that. But shallow programmers should not try to design their own languages, because the results are usually disasterous. Both PHP and Smarty exhibit the pathetic symptoms of having been designed by and for shallow programmers, more worried about syntax than semantics. Their attempts to make it simple on the surface result in deep and subtle complexity.
How about using "." for namespaces, like Java or Python? Oh, that's used for string concatination. Then how about "::" (four times as many dots). Oh that doesn't work for some obscure reason. How about ... PHP syntax is in a never-ending spiral of unintended consequences! It was never planned. It's just a lame immitation of a bunch of other poorly chosen languages' syntax, without understanding or implementing their semantics. For example, PHP's references aping C++, PHP's class system aping Java, etc.
It's hard to figure out how to put namespaces or any other syntax into PHP without breaking a lot of existing code and creating subtle nuanced special cases, because PHP's syntax is not consistent like Python, nor extensible like Lisp.
PHP's simplicity is only an illusion, because it gets extremely complex and convoluted under the surface, while Python has true simplicity that goes deep. Lua and Lisp are even simpler and deeper.
-Don
Take a look and feel free: http://www.PieMenu.com
You still don't get it. A pull parser is not the same thing as generators. Generators are a programming language construct which is extremely useful for implementing pull parsers, and modular telescoping XML processing pipelines, like the Kid templating system.
Go read the link about generators that I provided. Then please explain how you would implement generators in PHP. You can't, because it's a language feature that can't be implemented at the PHP script level. It required modifying how the PHP interpreter works. Let me say this again: it is impossible to implement generators in PHP code, no matter how good a PHP programmer you are -- you have to rewrite the PHP interpreter which is written in C, to implement generators. Generators enable your processing modules to run in parallel, each with its own return stack and local variables (i.e. co-routines). PHP absolutely cannot do that.
If you don't believe that, then you don't understand how generators work, so go back and read the article again. Then try to convince the PHP designers to add generators to PHP: good luck!
Python supports generators, because they are built into the interpreter. They are a fairly new feature from Python 2.3, described in PEP 255: Simple Generators. The Python interpreter C code had to be modified to support them, and it was done because generators are so useful (especially for processing XML).
Other more powerful languages like Scheme do not have to have their interpreters modified in order to support generators, because they already have more powerful programming constructs (like continuations) that can be easily and efficiently used to implement generators.
But since PHP does not support continuations or co-routines, it is absolutely impossible to implement generators (or Kid-like templating systems) in PHP, no matter how great a PHP programmer you are.
-Don
Take a look and feel free: http://www.PieMenu.com
Stop the Blah. If you don't want to answer my posts just don't. Your "an easy XML template engine can only be done with generators" makes you look very stupid. But that's nothing new.
Of course I'm answering your posts -- you're just ignoring my answers. What point did you make that I didn't address? Just because you don't understand what I'm saying doesn't mean it means "blah". Go read the article on generators. You implied that a good PHP programmer could implement generators in PHP, and you are totally wrong. You obviously don't know what generators are. I provided a reference. Did you read the article I refered you to about generators? Do you understand them now? Do you still maintain that a good PHP programmer could implement generators without hacking the PHP interpreter source code in C? Or do you concede my point?
And now you are misquoting me: I never said "an easy XML template engine can only be done with generators". I said templating languages should have well designed syntax and semantics, but Smarty has neither, while Kid has both. I also said that generators make it much easier to implement efficient elegent XML processing tools (note that implementing a templating language is very different than using it: graphical designers don't have to understand or use generators in order to use Kid), and you haven't been able to counter that argument because you don't even understand what generators are, even though I provided a reference. Are you too lazy to learn? Then concede my point. The ball's in your court and the burden of proof is on you.
Are you contesting my claim that generators are extremely useful for implementing efficient XML processing pipelines? Or do you accept my point? Are you arguing that syntax doesn't matter? That semantics doesn't matter? Or do you accept my point that both matter? Are you arguing that Smarty has good syntax and semantics, or do you accept my point that it sucks?
What templating languages have you implemented, and have you published any papers about them so I can read about your design? Have you read the paper about the HyperTIES markup language I implemented in 1987 and published with Ben Shneiderman in 1991? Have you ever read any other papers written by Dr. Shneiderman, or even heard of the field of human computer interaction, or read the ACM journal of Hypermedia? Have you even heard of ACM? Do you have any problems with the points that peer reviewed paper made about markup language design? I linked to the source code and documentation that I wrote, so you can look at that and make comments on it. So what are your comments on the points I made? Silence?
"If you don't want to answer my points just don't", but that "makes you look very stupid". I am addressing your arguments point by point, and you're totally ignoring every point I'm making. Why is that? Can you answer any of these questions I've asked, or are you just frustrated that you made a lot of stupid arguments about topics that you don't know much about, and you're trying to run away from the argument without answering any questions?
You accused me of not knowing what MVC was, and I told you when I first started using it, and refered you to some criticism I wrote about it. What are your comments on that? More silence? I addressed your incorrect accusation, and asked you when you learned MVC and if you had any criticism of it or just accept it blindly, but you refused to answer. More silence that makes you look stupid.
Face it: Smarty is a piece of shit, and you're trying to apologize for it by making ridiculous statements like "don't use math in templates". You are full of shit, and I refered you to papers I wrote years ago to answer your posts and rebut your points! Don't blame me if you're too lazy to read them or too ignorant to understand them.
You're wrong that I don't want to answer your posts. I have, but you just ignored me. Can't you defend your statments? Why can't you answer my questions point by point, instead of ignoring them all?
-Don
Take a look and feel free: http://www.PieMenu.com
First - like in you other post you're now starting that "look at my penis and how big it is" thing. That's boring.
The math was {math} in Smarty. It's also mentioned in the manual that it's not a good idea to use it.
And I did never say a good and easy template engine needs a language that support generators. That's your shit. What I said was that something similar to Kid could be done in PHP. Including being light on memory. You can't stop talking about generators and thus aren't answering my post.
At least I accept that Smarty isn't the right choice for you. I just don't understand why you invest so much time if you really hate it. You could just ignore it.
You're the one who accused me of not knowing about MVC or templating, so I gave you some references to my experience. You're the one who brought the subject up by making false accusations. Do you retract what you said about me not understanding MVC or templating?
If Smarty's {math} isn't a good idea to use, as documented by the Smarty manual, then why does it exist? Either Smarty is supporting "bad" features that you should not use, or your premise that "math is bad" is wrong.
Of course PHP is a horrible language because it's rife with stupid half-baked ideas that they threw into the language but that are a bad idea to actually use (register_globals, magic_quotes_gpc, addslashes, all the other half-assed attempts at quoting sql strings, etc.) But math is not one of those mistakes. Do you think it's OK for Smarty to have features that you claim are bad ideas, just because that's typical of the PHP culture?
My point is that you are dead wrong about math being bad in templates. You're just attempting to apologize for Smarty by repeating what you believe is the "conventional wisdom", and that conventional wisdom is dead wrong.
What references can you give me that prove your point that you should not use math in templates? Did Alan Kay ever stand up and said "I invented OOP and MVC, and I say that views should not use math"? I gave you a reference to a paper I wrote with Ben Shneiderman (who is a user interface and hypermedia researcher whose name you should recognize if you know anything about the subject), published in the peer reviewed ACM journal of Hypermedia, which clearly describes why it's useful to have math in templates (for calculating the condition for conditional text). What is your counter-argument, or do you prefer to avoid answering that question because you can't? Claiming your too bored is conceding my point.
You keep trying to avoid addressing the arguments, by claiming you're too bored to respond, or twisting my words. I never accused you of saying a good and easy template engine needs a language that supports generators, so why are you denying that you said it, if I never implied you did? You can't win an argument by repeating the other person's point as if it's your own, as if I accused you of claiming the point I was trying to make. That only works in Bugs Bunny cartoons.
What I do accuse you of implying is that a good PHP programmer could implement generators (by saying that I wasn't a good enough PHP programmer to implement Kid in PHP), which means you have no idea what generators are, even though I pointed you to a perfectly good explanation of what they are. Did you read the explanation? Do you still believe that a PHP programmer can implement generators in PHP, or not? Do you think you're such a great PHP programmer that you could implement a templating system as efficient and easy to program as Kid, with or without generators?
So how do you propose a PHP programmer implement a good templating system without generators? I previously listed the advantages that generators have over the SAX based even call-back method, which as you know, if you've ever tried using it, is a total pain in the ass and hard to program. I also listed the advantages that generators have over parsing the entire document into a DOM tree, which is a total waste of memory, and extremely inefficient. Generators enable you to 1) process arbitrarily sized XML documents efficiently, 2) write straightforward code that uses conditionals and loops 3) keep temporary state in local variables instead of having to store it in object fields between event handler invocations. So which programming techniques do you suggest PHP programmers use to get around the problems that generators solve so nicely?
Ignoring smarty is not an option for me. I know how bad it is because I'm working on a project that uses it, and I have read the source code to understand how it works. So I have every right to complain about it.
-Don
Take a look and feel free: http://www.PieMenu.com
"Stop the Blah", huh? So you've stuck your fingers in your ears and you're chanting "ya ya ya ya ya" because you refuse to listen to what I say, since you can't come up with any better arguments? Why can't you answer any of the questions I've asked you? If you incapable of answering any of the questions I've brought up, then you're conceding my points, thank you.
-Don
Take a look and feel free: http://www.PieMenu.com
That's a post lenght that's worth reading. Try to answer short and right to the point instead of instead of telling me what you did 20 years ago or posting information about things I already know (like what Generators are).
Maybe you should also understand that just because someone isn't against you that doesn't mean he is with you. So if I don't answer your question that could mean it's just not worth an answer or my time.
But let's use your opinion about conceding points. You had no argument against the XMLReader as found in newer PHP version or PECL. So that means it's a good solution and could help to write a better template language. Thank you very much for the discussion. I'll now stop feeding the troll.
The problem with using a pull parser like XMLReader from a language like PHP that doesn't support generators, is that it's difficult to write the rest of your XML processing stack using the efficient event-driven pull processing approach. The parser is only the first step of an XML processing pipeline, and while it's nice to have a pull parser, it's much nicer if you can write the rest of the templating system and XML processing pipeline in that style, as well. Which is extremely difficult to do in PHP, because it lacks generators. Why should only the parser be efficient, and not the rest of the program?
You claim you understand what generators are. Then do you think they could be implemented in PHP by a good programmer? How? Do you consider yourself a good PHP programmer, or will you pass on explaining on how to implementen generators in PHP?
Not having the attention span to understand the issues is not an excuse for being wrong -- it just means your opinions aren't valuable because you refuse to put the time into learning. If these issues bore you so much, then perhaps you shouldn't be programming computers, and just flip burgers instead?
-Don
Take a look and feel free: http://www.PieMenu.com
http://php.net/xmlwriter
... not ... possible ... no .. generators ... only .. holy ... generators ... can ... work. Like a robot. When do you invest some time and learn? Just because you did something useful in the 80ies or 90ies doesn't mean you can stop learning.
http://php.net/stream_wrapper_register
What you call extreme would others call a challenge.
You're making it yourself very easy with your generators argument. It's always the same