In this new post to his blog Adam Harvey shares his opinion on unmoderated notes dropped directly into the PHP manual - "they're bad, mkay?"

I've had a couple of whinges on IRC lately about why I'm not thrilled with having user notes in their current form in the PHP manual; we get entirely too many questions in ##php from people who've copied code out of a note and are then annoyed when it turns out the code is wrong, broken, horrible, or all of the above.

His gives an example (one of many currently in the manual) that shows a round-about way of getting a date string that could be done better in a single "format()" function call on a DateTime object.

I don't know what the answer is - moderation has its own problems to do with workload, as PEAR can attest - but a system that's letting that go up as recommended practice (and stay up for a month) has to be looked at.

In a new post to his PHP in Action blog Dagfinn asks the question "is bad code good for you?" He wonders if bad code really is a good thing and how it can be split out from the good parts of your application.

This is an interesting idea that struck me as novel. But after thinking more about it, I believe it's not a radical departure from what we're all implicitly accepting, no matter how fanatical we might be about clean code.

He includes a quote from Luke Welling on the subject talking about how bad code, despite the headaches it may cause for maintenance and future development, can be a good thing if it does good for the project.

Following the release of the Zend Simple Cloud API for their Zend Framework, Clay Lovess has pointed out that sometimes a simple cloud could be a "dark cloud" for your application.

Developing "cloud-native" applications? Soon there'll be an abstraction layer for that too. [...] Sounds great, right? Not so much. As Chief Architect of a PHP-based "cloud-native" application that's handling hundreds of millions of requests per month, there's no way I'd consider using Simple Cloud. Here are five reasons why you shouldn't either.

His reasons are pretty simple ones - leaky abstractions, lowest common denominator calls the shots, the important groups (leaders) don't always get involved, creating a native option isn't that hard and, face it, you'll never make the move over because of the work level and uncertainty involved.

If you'd like to find out more about what he's talking about, check out this site for more information on Simple Cloud.

Samuel Folkes has posted a few practices (seventeen, to be exact) that PHP developers should "banish forever" from their development habits.

The following is a list of 17 PHP programming practices that in my opinion should be banished into oblivion. Forever and ever. Amen. Please note that this list is in no particular order.

Some of the practices include:

• Relying on Magic Quotes
• Mixing HTML, PHP, SQL, JS, CSS, Etc, Etc
• Not Documenting Code
• Using Regex Functions for Basic String Manipulation.
• Unquoted Array Keys
• Using Uninitialized Variables

There's lots more where those came from so check out the rest of the list here.

Jeremy Zawodny has shared his opinion on database abstraction layers in PHP applications - they need to die.

Beware of men preaching of false hope. Take, for example, the way some folks feel like they need a database abstraction layer in their applications. [...] So why do folks do it? Because PHP is also a programming language and they feel the need to "dumb it down" or insulate themselves (or others) from the "complexity" of PHP.

He goes on to say that, despite the claims that people make about portability ("it's never that easy") and ease of use, the only real answer is to strip out this layer and use good programming practices to take the database access code out into a separate library that can be replaced quickly and easily.

On the SitePoint PHP blog today Troels Knak-Nielsen has posted some of his own thoughts about the performance tips that Google recently published for PHP.

The project includes an article on "PHP performance tips", which is bordering on being ridiculous. There are of course lots of blog posts with similar nonsense around the web, but since this is being endorsed by Google, it's fair to assume that people might take it at face value. That's unfortunate, as almost none of it is true. The PHP Team responded back with this message, wherein they refute the unfounded nonsense.

He notes that these practices aren't the best road to optimization and, depending on when they might be used, could be harmful to the development of the application. He also recommends XDebug if you really want to get to know where your application is struggling.

Chance Garcia has posted about an exception he's come across several times in using the Zend_Log component of the Zend Framework but hasn't been able to figure out - until now (with the help of part of the Zend Framework manual).

There are a few times I've gotten this particular exception and then look at the trace and can't figure out what's wrong. More often than not, I'll get to the line in the trace and be like, "wtf! there's no priority here. It's a method call not a constant". [...] So to save myself and others some time and aggrevation, I'm going to go into a bit of detail as to why you may be getting this exception.

As it turns out, the Zend_Log exception was caused by the components overloading of the __call function to allow for some custom handling. Chance sees this issues as an example of "flexibility leading to complications that require complex understanding".

A little while back Scott MacVicar wrote some thank yous to some of the larger and corporate groups involved with PHP and enhancing it as much as they can, both on their own hardware and for the community in general. Unfortunately, there seems to be one company that doesn't want to pay nice - Apple.

So if you've ever tried to compile PHP on OS X, you'll most likely have problems using the default system libraries and in the end you'll use macports to install libxml and iconv. If you're not trying to compile your own versions of PHP and want to use a PECL extension then you'll find that the binary has had all the symbols stripped. Mid last year I tried to get some of these resolved, and filed a bug report with Apple but was informed these weren't bugs.

He goes on to talk about the reception he got from the Apple Developer Connection and the brush-off he seemed to get when he tried with the same questions a few months later.

What was essentially asked for was help to improve PHP on OS X, but this has fallen on deaf ears. Apple are happy to take PHP but don't seem as keen to contribute anything back to the project. Yes they are perfectly entitled to do this, PHP is open source after all. But is waiving a $499 charge too much to ask?

With the recent release of the Zend Server CE (Community Edition) software from Zend, several PHPers around the community have been trying it out and posting some of their experiences. Brandon Savage has posted some of his thoughts on the release as he tried out the Mac OS X version.

There are many good things in this product. Among them, is the ability to easily activate and deactivate most of the plugins and extensions that come bundled with PHP by default. [...] Unfortunately, the problem also contains many what I would call "bugs" or usability enhancements that are simply not there.

A few of the things that made his bad list included: a lacking install process (too long?), the lack of an obvious logging tool and a different sort of checking for setting directives (a check against a regular expression?)

He found some good in the release too - the easy to install extensions, the number of extensions it comes bundled with and the inclusion of MySQL with the stack. He notes he won't be abandoning his typical install (like MAMP/XAMPP) over this tool - at least not for right now.

One of the things that's been hanging around PHP's neck since its early days is the magic_quotes setting that was introduces to try to make things easier. In this interesting post Arpad Ray takes a look at this setting and why its a bad thing for PHP to have around.

Like register_globals, it helped lower the barrier of entry to building a dynamic website by removing some of the complexity. However it certainly wasn't without sacrifice, problems with the implementation quickly appeared and continued to abound for the next ten years. Finally in PHP 5.2.2 we got an implementation which (as far as its intentions went) seemed to be bug free, but of course by then it was turned off by default and was already slated to be dropped in PHP 6.

He looks at a few reasons they're bad (not good enough for escaping, inconsistent, performance issues) and some methods - code snippets - on how to deal with it being turned on on your server.