Lorna Mitchell has a quick post related to some of the OAuth work she's done on both sides, consumer and provider. This latest post relates to the OAuth pages and endpoints that are needed as a part of the authentication process.

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.

Simas Toleikis has posted an interesting idea for a validator that would look at the incoming source of an application/script and determine what the requirements for it might be.

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).

In this new post from the IBuildings blog today Ivo Jansch looks at content management systems and how you can start to find that right fit for your and your company/organization.

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.

Following up on the previous part of his dependency injection series (the first part), Fabien Potencier has come back with this second look at the development technique asking if you really need a dependency injection container in your scripts.

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.

On the PEAR blog today, they're asking for thoughts on some of the standards for the coming PEAR2 development environment:

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).