[andjones]

The fact that many PHP projects end up in unmaintainable spaghetti code is a mark against the programmer and not the language.

Take your average PHP programmer and force him/her to code in Ruby and the same mess will result.

The fact that PHP has so many "noob" programmer is indicative of its success in creating so many great projects and websites. We have made PHP so easy that even your grandmother can do it.

From the article:

If you are capable of making wise software design decisions, PHP is a great choice to build your web application with.

[damncabbage]

> We have made PHP so easy that even your grandmother can do it.

I'd wager it's so easy that even your grandmother can do it /badly/, while putting her business or data at risk.

More seriously:

Frameworks or languages that make it easy to be secure by default are a lot better, both for newbies who don't know better, or for old hands who slip up once or twice.

The simplest example I can think of to illustrate the difference:

    <h1>Hi, <?php echo $name; ?></h1>

    vs

    <h1><%= name %></h1>

(Say "name" is "<script src=xss.js></script>". The former is vulnerable, the latter is not. Both are just as easy to write.)

[pilif]

In all fairness, the XSS protection in ERB expressions is a new feature of rails 3.0 which isn't out for that long. Before that you had to use the h helper (which of course is much easier to type than htmlentities)

[bad_user]

Also in all fairness, large parts of code written for Rails 2.x can be ported to Rails 3.0 painlessly, enjoying the new security benefits without breaking a sweat.

You simply won't be able to upgrade PHP to make <? echo $something ?> behave properly. That's the problem with languages that were designed to be frameworks in themselves -- languages have to maintain backwards compatibility.

[pilif]

well. If you were intentionally allowing certain replacements to be in HTML (because they come from a trusted source or because you sanitized them before) and so you weren't using the h helper in rails, when you move to 3.0, you will see escaped code just the same as if PHP changed echo to escape its parameters.

Both the update to rails 3.0 or to a hypothetical new release of PHP which escapes parameters to echo would cause the same amount of work.

What you could say is that rails is less afraid to force change on people and that conversely, PHP puts more emphasis on backwards compatibility.

Both have their advantages and their disadvantages, so this particular issue, I feel, really can't be used to show the inferiority of PHP. Parameter order of functions? Crude syntax? Strange case sensitivity rules? Awful, counterintuitive == operator? Sure. Emphasis on backwards compatibility? IMHO not really.

[bad_user]

     Emphasis on backwards compatibility? IMHO not really.

It's not that -- I like frameworks precisely because there's a layer of abstraction between my code and the final output.

Using PHP as a web framework, without a higher-level of abstraction (like a PHP framework) is dangerous because backwards compatibility has to be preserved.

"echo" in PHP is like "print" in Python. It wouldn't make sense in either case to force escaping of HTML tags for such a low-level instruction. But people have been using it to output HTML content for years.

[pilif]

Same goes for <%= which has been used by people for years to output HTML content.

Changing echo; to encode entities when used from within a web server SAPI (so not on the command line) would not cause more or less hassle per app than changing <%= to encode entities by default.

Of course the overall PHP code base is much bigger than the rails code base, so there would be more people affected. But for the individual application developer, there's no difference in amount of work whether <%= suddenly starts escaping or echo; does.