[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.