On the /r/php subreddit on Reddit.com, TheSkilletHead wonders if ORMs are inherently limiting in PHP development. Their main point is that, in abstracting and simplifying the interface the developer has to work with, some of the power of the complex database handling is lost.

I don't feel like I'm asking too much from an ORM. I'm not asking for the ORM to manage database-side functions. I'm not asking it to manage database-side variables. I'm not asking it support every type of INSERT (like INSERT DELAYED). I'm OK that it doesn't support LOAD DATA INFILE. I'm even OK with the overhead. However, when I look up why Doctrine doesn't support UPDATE ... JOIN and the response is "it's too different across database engines", then I'm a bit disappointed because that seems to be why one would use an ORM in the first place. [...] Can an ORM be a useful tool to abstract the database or is it just a crutch for people who can't be bothered to learn SQL?

There's quite a few comments on the post already, most confirming his opinion that ORMs are limiting. Some, however, note that they don't have to be. There are some (like the CakePHP 3 ORM) that do have some more advanced features and are still easy to use. Despite this, most of the comments are about developers moving away from ORM use towards more specific, customized solutions that are a better fit for their needs and database systems.

In this new tutorial on NetTuts.com, Jeff Reifman shows you how to build rate limiting into your application to help with issues on your login caused by possible brute force attacks.

Since one of the wealthiest corporations in the world [Apple] didn't allocate the resources to rate limit all of their authentication points, it's likely that some of your web apps don't include rate limiting. In this tutorial, I'll walk through some of the basic concepts of rate limiting and a simple implementation for your PHP-based web application.

He starts with a brief look at how (brute force) login attacks actually work and how that relates to the most common passwords used. He splits out the two main approaches to rate limiting in applications: limit based on failures by username or limiting by IP address. He then gets into the actual code examples, choosing a Yii framework-based application for his illustration. He creates a simple "failed login" database table, shows how to log the attempts and includes a snippet to purge items older than (by default) 120 minutes ago. Finally, he includes the code to check the table and see if the username has too many failures listen and, if so, denies them access.