The ByMyCTO.com blog has a recent post that makes the suggestion that the Doctrine ORM isn't suited for PHP...or to put it another way why they think it's not a good option for database integration.

I know, this title sounds like a troll. But it’s not, it’s a fact. I’m not saying Doctrine is a bad technology or shouldn’t be used. I’m just saying it’s not suited for PHP and this can lead to critical problems if misused.

He covers a few different topics including:

• Differences between Java and PHP (and the fact that Doctrine's inspiration was Hibernate)
• The "session problem" (entity serialization)
• Identity Map, useless in a stateless environment
• UnitOfWork, far too complex
• EntityManager, too magical

Despite all of these points, he does remind the reader that Doctrine isn't useless or inherently bad, it's just that he sees it as reinforcing bad behaviors and suggests using something else.

The SitePoint PHP blog has a new post today sharing what they (well the author, George Fekete) see as the top 18 critical oversights common to web development in recent years. While the examples are in PHP, the principles could apply across multiple other languages.

Over the past years I had the opportunity to work on some interesting projects, complex in nature with an ongoing development, constantly upgrading, refactoring and adding new features to them. This article will cover the biggest coding oversights most PHP developers make, when dealing with medium and large projects. Oversights such as not differentiating between development environments or not implementing caching and backup. [...] The root of these problems lies mainly in developers’ knowledge and experience, especially the lack of it.

He's broken them up into three different overall types: design, application and database levels. Included in his list are things like:

• Developing with error reporting off
• Not implementing caching
• Not using automated tests
• Not differentiating between read / write queries
• Not using transactions
• No backup
• No monitoring

Check out the full post for the rest of the items on the list, all including examples and explanations.

On the main PHP site there's a new announcement about a critical update in a new version to both the PHP 5.2.x and 5.3.x series of releases to correct a problem that could cause a hang or crash from user input - 5.3.5 and 5.2.17.

The PHP development team would like to announce the immediate availability of PHP 5.3.5 and 5.2.17. This release resolves a critical issue, reported as PHP bug #53632 and CVE-2010-4645, where conversions from string to double might cause the PHP interpreter to hang on systems using x87 FPU registers. The problem is known to only affect x86 32-bit PHP processes, regardless of whether the system hosting PHP is 32-bit or 64-bit. You can test whether your system is affected by running this script from the command line.

All users are strongly encouraged to update their releases. While the problem only happens in certain circumstances, it can still be a huge problem since the data comes directly from the user. For more information about the issue see this post.

On his IIS.net blog Don Raman is asking for help in testing Microsoft's WinCache caching tool because of a critical fix they had to make to the current version.

There has been several instances where people using WINCACHE have reported problem while running it on the actual production server. They have complained that WINCACHE works very well on development server but the users can see a crash (or different symptoms of it) while actually deploying it on a live production server.

There have been several reports of the issue where the site visitor gets an empty page back and WinCache will crash. For those wanting to get into the technical details, the post includes them or, if you just want to find out more about the bug, there's a few email addresses you can contact the WinCache team at.

In response to this recent post on four reasons to hate CakePHP, Matt Curry has posted some of his thoughts over on his pseudocoder.com blog to refute the comments made.

I'm still bored and lacking posting ideas, so I figured I'd give a hyper-critical breakdown of "Four reasons to hate CakePHP" by A.J. Brown. Let's get right into it.

He responds to comments on: CakePHP's "heaviness", the (in)flexibility the framework allows, alpha releases, changes between versions, no namespace considerations and its use of global functions.

You can see the original post here: Four reasons to hate CakePHP as well as his AJ's own response to comments he recieved - Maybe I was too hard on CakePHP.

According to this new advisory on the Secunia website, rPath has updated more of their PHP packages and has marked the update as "moderately critical" to keeping your systems safe.

rPath has issued an update for multiple php packages. This fixes some vulnerabilities, where some have unknown impacts and others can be exploited by malicious, local users and malicious users to bypass certain security restrictions.

The original advisory has links to the updated versions and to references as to what has changed.

In its default configuration, rPath Linux 1 does not install php5 and is thus not vulnerable to these attacks; however, systems to which php5 has been added may be vulnerable to one or more of these attacks.

According to this new advisory on the Secunia website, rPath has updated more of their PHP packages and has marked the update as "moderately critical" to keeping your systems safe.

rPath has issued an update for multiple php packages. This fixes some vulnerabilities, where some have unknown impacts and others can be exploited by malicious, local users and malicious users to bypass certain security restrictions.

The original advisory has links to the updated versions and to references as to what has changed.

In its default configuration, rPath Linux 1 does not install php5 and is thus not vulnerable to these attacks; however, systems to which php5 has been added may be vulnerable to one or more of these attacks.

Following right on the heels of a different PEAR problem, Greg Beaver has posted about a similar PEAR-related issue that could cause some serious problems for you and your installation.

After investigating (which in my case meant briefly recalling from memory how PEAR actually validates dependencies), I remembered that PEAR validates dependencies twice, once prior to download, and once prior to installation. By the time the dependencies are sorted, PEAR assumes that the sort algorithm properly sorts things.

This is actually a pretty reasonable assumption considering the unit tests that are in place to test this. However, like all regression testing, the unit tests test boundaries and likely cases, but not all possible inputs.

So, to try to figure out where things might have gone wrong, Greg does a little research to find the problem. He discovers that it has to do with the order that the "subpackages" for the dependencies are installed, where the contents of those files are not removed correctly before installation, resulting in a file conflict.

Following right on the heels of a different PEAR problem, Greg Beaver has posted about a similar PEAR-related issue that could cause some serious problems for you and your installation.

After investigating (which in my case meant briefly recalling from memory how PEAR actually validates dependencies), I remembered that PEAR validates dependencies twice, once prior to download, and once prior to installation. By the time the dependencies are sorted, PEAR assumes that the sort algorithm properly sorts things.

This is actually a pretty reasonable assumption considering the unit tests that are in place to test this. However, like all regression testing, the unit tests test boundaries and likely cases, but not all possible inputs.

So, to try to figure out where things might have gone wrong, Greg does a little research to find the problem. He discovers that it has to do with the order that the "subpackages" for the dependencies are installed, where the contents of those files are not removed correctly before installation, resulting in a file conflict.

On the PHP Security Blog today, this note has been posted, a notification that a critical vulnerability has finally been fixed - the unset() issue.

Because there are meanwhile a lot of rumours about this vulnerability in the underground and because the PHP 4.4.3 release announcement does not mention this critical hole at all I wrote up a little article about it, which you can read here.

The article (from Hardened PHP) describes the issue - a problem in the hash tables of the Zend Engine, specifically the zend_hash_del_key_or_index function. The logic contained inside the function can find the wrong "bucket" of information and remove it. He also includes PHP code examples that show the issue in action.

To be protected, it's recommended to update to the latest versions of PHP that have been released - 4.4.3 and 5.1.4.