Harry Fuecks has posted his brief opinion on the comments that Tim Bray made recently about PHP over on the SitePoint PHP blog.

Tim Bray kicked off a big blog debate on the pros and cons of PHP (see links in his post to everyone who commented). If you've been around PHP for a while, there's basically nothing new here but you might find cause for optimism in how things are being said'"there's far more informed discussion happening than you might have found even two years ago.

Harry also mentions that there's not much more he wants to add other than a comment on the "PHP is too easy" comment Tim made. Be sure to check out the comments on this post for some great opinions.

Ilia Alshanetsky also has hos own look today at the "mysql_real_escape_string versus addslashes" debate that's going on, looking more at why there's even an issue here (with addslashes).

Chris has written a compelling piece about how the use of addslashes() for string escaping in MySQL queries can lead to SQL injection through the abuse of multibyte character sets. In his example he relies on addslashes() to convert an invalid multibyte sequence into a valid one, which also has an embedded ' that is not escaped. And in an ironic twist, the function intended to protect against SQL injection is used to actually trigger it.

The problem demonstrated, actually goes a bit further, which even makes the prescribed escaping mechanism, mysql_real_escape_string() prone to the same kind of issues affecting addslashes().

He shows code examples, creating a simple SQL injection that uses mysql_real_escape_string to cause the same issue - all based around the default characterset that the MySQL server uses. His suggested solution? Prepared statements... (like what things such as PDO offer)

In his latest blog entry, Chris Shiflett looks at a debate that's been going for a while now - addslashes() versus mysql_real_escape_string().

Last month, I discussed Google's XSS Vulnerability and provided an example that demonstrates it. I was hoping to highlight why character encoding consistency is important, but apparently the addslashes() versus mysql_real_escape_string() debate continues. Demonstrating Google's XSS vulnerability was pretty easy. Demonstrating an SQL injection attack that is immune to addslashes() is a bit more involved, but still pretty straightforward.

The reminder of the post explains the difference, how how protects you when the other doesn't (addslashes), and a simple example of how something like that could be accomplished, including code...

From Heigl's blog today, there's his look at some of the issues that surrounded the release of PHP 5.1.0 (and the quick following of PHP 5.1.1).

As many have noticed 5.1.0 had some issue when it was released, like for starters it introduced a empty date class by default which effectively killed scripts that used PEAR::Date.

As one can see in this excellent rant by Ilia there are different views on how this should have been handled (also read the internals ML if you need even more reading material), namely why PEAR was polluting generic names and why they didn't fix it right away so PHP could get the glorious name of Date.

Heigl takes the side of the internals developers, that internal PHP should win out over PEAR on this issue. There's been a pretty large debate raging on about this one - and, even with the (pullback) release of PHP 5.1.1, it goes on as an issue to address in, say, PHP 5.2? (Or maybe they'll just wait until 6 and lump it all in...)