The SitePoint PHP blog has a new post by Jeroen Meeus that wonders if MVC is a solution or a problem when it comes to developing web applications.

Repositories, Adapters, MVC with all it cousins, SOLID, RTFM… As a (PHP) developer, those words are thrown at you from every corner of the web. And I hate it, I’ve had enough. Stop telling me what to do and show me those kittens instead. [...] When solving the web-application problem, we are forced to use MVC. The dev community often frowns upon those who don’t use it, but seldom lets those they’re frowning upon ask why. [...] MVC doesn’t solve the Code complexity problem. It doesn’t solve the code reuse or no-flexibility problem either. And it doesn’t guarantee decoupled code.

He goes on to talk about how design patterns don't "solve problems". Rather they help us as developers by providing a best practice we can follow to get the job done. He suggests, though, that MVC has become "the new Singleton" but it has been used so much in so many different ways, it's boarding on the point of being abused.

Depending on the situation, and the problem at hand, different patterns can help you write robust, secure and understandable code. Just be careful using them – if you catch yourself using the MVC pattern for a 1-pager, ctrl+a del.

With the first stable release of PHP 5.4 not too far off, it's important to understand the new features it offers and how to use them effectively. In this new post to DZone.com Giorgio Sironi shows how to "write clean code" with these new features, including a few snippets of code to illustrate.

After seven release candidates, it's clear PHP 5.4 is coming: as always the improvements from the previous minor version are many. [...] Let's look at the new features and score them on two metrics: usefulness, and potential for abuse. I'll try to avoid discussing non-language related matters.

He starts by pointing out some of the "gotchas" that can happen with traits (like errors thrown when more than one method is named the same and that they are a separate hierarchy), the short syntax and dereferencing support for arrays, closure binding, upload progress and more. For each of them he gives two measurements - the usefulness of the feature and the potential for abuse.

On DevShed today there's a new tutorial looking at a method for protecting your application (your MySQL/PHP application) forms from malicious attacks like SQL injections.

It has been known for a while that if a form is unsecured, malicious code in the form of MySQL injection will be initiated to attack the site. HTML forms such as drop down menus, search box, check boxes are all susceptible entry points of this type of abuse. This article will explain what happens in this kind of attack, and how to prevent it.

They compare unvalidated input with a validated method that uses some simple checks to ensure that the given content is numeric and regular expressions to match text.

In response to this previous post from Felix Geisendorfer, Sara Golemon shares a few thoughts on why she thinks it's just the other way around - create_function is not your friend.

In the short post she lists just a few of the issues surrounding the use of the function including that it:

• is prone to critical abuse by user-supplied code
• skips opcode cache optimizations
• encourages not using comments (evil)
• 100% blind to reflection or PHPDoc style documentation generation

In response to this previous post from Felix Geisendorfer, Sara Golemon shares a few thoughts on why she thinks it's just the other way around - create_function is not your friend.

In the short post she lists just a few of the issues surrounding the use of the function including that it:

• is prone to critical abuse by user-supplied code
• skips opcode cache optimizations
• encourages not using comments (evil)
• 100% blind to reflection or PHPDoc style documentation generation

In a new entry on his blog today, Marco Tabini introduces us to 5 PHP Performance Tips that we "probably don't want to hear".

I thought it might be interesting to write an article about the performance-enhancing tips you probably don't want to hear about - that is, those that are most likely to produce measurable (and durable) results but do require some effort on your part.

His list consists of:

• You Don't Need To Plan Ahead In Order To Have A Plan
• Combat Database Abuse
• Do You Really Need A Database Anyway?
• Scale Horizontally
• Refactor To Scale Vertically

For each, he explains the title and gives a bit of validation to the point. There's some great mentions of tools that you can use to help accomplish them too - a profiler, the Lucene and Xapian full-text databases, and Lustre.

In a new entry on his blog today, Marco Tabini introduces us to 5 PHP Performance Tips that we "probably don't want to hear".

I thought it might be interesting to write an article about the performance-enhancing tips you probably don't want to hear about - that is, those that are most likely to produce measurable (and durable) results but do require some effort on your part.

His list consists of:

• You Don't Need To Plan Ahead In Order To Have A Plan
• Combat Database Abuse
• Do You Really Need A Database Anyway?
• Scale Horizontally
• Refactor To Scale Vertically

For each, he explains the title and gives a bit of validation to the point. There's some great mentions of tools that you can use to help accomplish them too - a profiler, the Lucene and Xapian full-text databases, and Lustre.

With yet another reason not to trust the users of your application (mainly the data they send you), Ilia Alshanetsky has details on an issue that could be caused by the unserialize() function in PHP.

While talking with PHP developers this morning I thought of another way unverified serialized strings could be abused. This exploit can only affect PHP 5 installs though, but given the growing market share of PHP 5 it is certainly something worth noting.

As you may know classes in PHP are allowed to implement a magic method called __wakeup() that contains operation that are to be performed when a class is deserialized. Some native classes like PDO implement this function with a goal of preventing database serialization and throw an error when it is used.

He uses an example with PDO and a string of a serialized "supposed PDO object" to illustrate how, without the proper handling, it could lead to a fatal error in the script. The end result of the fatal error, if displaying errors is still on, could be that somewhat sensitive information could be displayed to the viewer.

With yet another reason not to trust the users of your application (mainly the data they send you), Ilia Alshanetsky has details on an issue that could be caused by the unserialize() function in PHP.

While talking with PHP developers this morning I thought of another way unverified serialized strings could be abused. This exploit can only affect PHP 5 installs though, but given the growing market share of PHP 5 it is certainly something worth noting.

As you may know classes in PHP are allowed to implement a magic method called __wakeup() that contains operation that are to be performed when a class is deserialized. Some native classes like PDO implement this function with a goal of preventing database serialization and throw an error when it is used.

He uses an example with PDO and a string of a serialized "supposed PDO object" to illustrate how, without the proper handling, it could lead to a fatal error in the script. The end result of the fatal error, if displaying errors is still on, could be that somewhat sensitive information could be displayed to the viewer.

From PHPEverywhere today, there's a new post from John Lim that asks the question, "Is PHP4 the new Perl?"

Tim Bray, one of authors of XML, voices concern about PHP: "So here's my problem, based on my limited experience with PHP (deploying a couple of free apps to do this and that, and debugging a site for a non-technical friend here and there): all the PHP code I've seen in that experience has been messy, unmaintainable crap. Spaghetti SQL wrapped in spaghetti PHP wrapped in spaghetti HTML, replicated in slightly-varying form in dozens of places.

But in the big picture, it feels vulnerable to me."

John argues that it's not the language's fault if the code that's written is bad (more coders need this). He also suggests that maybe PHP4 is perl for the web - simply because of the one of the reasons it's popular - it's potential for abuse from badly written code.