When I say "make sure it is worth it" I mean, don't just switch your arrays from array() to [] just because it looks cool. That was the extent of my original tweet, because I've seen a few packages doing that and it annoyed me immensely. [...] Suffice it to say, if you require a user to upgrade their version of PHP simply so you can use some syntactical sugar inside a package that nobody else is even going to be looking at, then you're an idiot. Beyond that, you're actually hurting the community.

He notes that, by requiring users that are currently only at 3.1% of PHP installs to upgrade to 5.4 just to use your library is a quick way to not have your library used. He points out that PHP 5.4 is "more than just []" for arrays and includes a reminder that several projects are still in PHP 5.3-compatibility mode just because that's the widest audience. He also briefly touches on the "push it forward" comments that people have used to justify 5.4-only packages, but notes that it's still not as much up to the developer as it is the web host.

This article uses the pecl_oauth extension and builds on Rasmus' OAuth Provider post. [...] OAuth has a little more baggage with it than just passing a username and password to an API.

She lists the five things you'll need for your service and talks a bit about the registration process and how the consumer key/consumer secret keys are generated. There's no strict definition on them, so her example uses a combination of sha1, mt_rand and substr to get the job done. She also includes a sample "consumers" table for your reference.

How about creating a PHP code validator? Got this idea by looking at tokenizer and reflection extensions. I doubt I will find the time to work on this myself but then someone else might be interested to pick it up. From user's point of view there will be a form made of a large textarea box and a single file upload input. One could paste code snippet on that textarea or upload a ZIP'ed source code archive (or a single .php file) for validation.

His proposed result would show a list of "Required Extensions", PHP versions, E_STRICT compatibility and possibly total lines of code in the project. He points out a few issues that might pop up in writing such a tool such as the requirement for it to be able to use the tokenizer extension itself (a sort of catch-22 since it's not always installed).

At the moment, Wikipedia's list of content management systems features 137 unique CMS products. 59 of these are written in PHP. And that's only the ones that Wikipedia finds 'notable', which means these are the ones that have significant usage or large enough communities to be mentioned. [...] The sheer size of the CMS market is interesting when you consider that one of the most frequent questions we get at Ibuildings is: "What CMS do you recommend we use?"

In an experiment in his recent talk (at the IMS conference) he asked the audience which car he should purchase from his list of four. Of course, their answers were wrong because of one fact - no one asked about his requirements.

This is a definite first step to anyone looking for a CMS to fit their needs (or really any kind of software). He also mentions other criteria to consider like cost of ownership, technology required, features and functional requirements.

In the first installment of this series on Dependency Injection, I have tried to give concrete web examples of Dependency Injection in action. Today, I will talk about Dependency Injection Containers. First, let's start with a bold statement: Most of the time, you don't need a Dependency Injection Container to benefit from Dependency Injection.

A dependency injection container is a wrapper around classes/libraries that need certain types of objects and settings to make them work correctly. This wrapper gathers together the information the object inside needs automatically without the user of the library having to worry they've missed something. Several code examples are included showing an application both with and without the container.

Please read the following document and post your comments on the wiki using the discussion page. Comments are opened for a period of two weeks. It is very important that you comment as these standards will define PEAR2.

The standards can be found here and include everything from the base requirements and package approach down to specific package-related rules (for things like directory structure, class-to-file conventions and handling dependencies).