The password features in PHP aren't exactly new, but I see lots of applications from "before" which aren't being migrated to better practices. I have some strategies for doing these migrations so I thought I'd share my main approach, plus a similar-but-different one I saw in the wild (OK it was in CakePHP, so not too wild!).

She offers a few steps to follow to upgrade your application to use the bcrypt solution instead of your current format:

Update Login Code (change SQL to just fetch the password, not evaluate it)

Hash existing passwords

Update registration code (for new passwords to use the new method)

Migrate users with old passwords hashes once they've verified their current login

She also mentions alternatives to these approaches including forcing the user to change their password on login.

The MongoDB blog has a new post asking for feedback on what the user community thinks of their approach to supporting MongoDB functionality in PHP 5.x, HHVM and even out to PHP7.

Since the PHP driver first appeared on the scene, MongoDB has gone through many changes. [...] Beyond MongoDB's features, our ecosystem has also changed. [...] During the spring of 2014, we worked with a team of students from Facebook's Open Academy program to prototype an HHVM driver modeled after the 1.x API.

[...] Although the final result was not feature complete, the project was a valuable learning experience. The C driver proved quite up to the task, and HNI, which allows an HHVM extension to be written with a combination of PHP and C++, highlighted critical areas of the driver for which we'd want to use C. This all leads up to the question of how best to support PHP 5.x, HHVM, and PHP 7.0 with our next-generation driver.

They've shared the overview of the new driver structure including three layers: the system level functionality, the extensions themselves and a MongoDB userland library. They walk through the thinking on each of the pieces of the puzzle and how they all couple together to make for a more robust, flexible system that's also easy to use.

The initial introduction and rfc for these functions made me uneasy, and I felt like a lone voice against many in that I thought something bad was happening. I felt that they should not be added to the PHP engine. I think that we should not extend the PHP engine, when it's possible to write the same API in userland, or there are significant benefits to do it in PHP, such as performance. Since the heavy lifting of the password functions is done by underlying libraries that are already exposed to userland-PHP, it didn't make sense to me to expose it as well in the core.

He includes a list of things he sees as drawbacks for new C-based functionality in PHP including the fact that it extends the "PHP specification" and forces other projects to implement it (like HHVM). He does include a few positives, though, such as the increased visibility and legitimacy, but still thinks they don't outweigh the negatives.

For those that may not be able to update to PHP 5.5 anytime soon but still want some of the cool features that come with it, there's one more option for adding that to your current PHP install. Ben Ramsey has released a userland-version of array_column, the function that returns the values from one column for all values in an array.

Many still use earlier versions of PHP, though. While the functionality of array_column() is simple enough to implement on your own in userland code, I’ve released a small library that implements it in userland code exactly as it’s implemented in the core, complete with the same PHP error messages and warnings.

The library has no dependencies and can be dropped into an existing application easily - just grab the source and include the needed file when you want to use the function (or it can be installed via Composer too).

In the theme of other recent posts mentioning the scalar type hinting that has been included in the main line of code that is headed towards the next PHP release, Sebastian Bergmannhas a new post about their inclusion in PHP 5.3.99 (yes, that's PHP 5.4) and the new syntax it introduces.

In a nutshell, this means that PHP 5.3.99 introduces new syntax -- scalar type hints -- but no new semantics. The latter can either be implemented as an extension written in C/C++, in userland PHP code, or in a tool that statically analyzes the code.

He includes an example fro userland with a "php_check_parameters" function that looks at the arguments of the current method and uses Reflection to check against the type hints for the correct value type.

Johannes Schluter has posted about another update to be included in PHP 5.3 - an improved getopt function:

So PHP 5.3 has lots of new stuff offer, so let's take a look at one change: Added long-option feature to getopt() and made getopt() available also on win32 systems by adding a common getopt implementation into core. (David Soria Parra, Jani)

This gives Windows users a function they haven't had before in both web-based applications and on the command line. You can get more information about the use of the function from its page in the manual.

In this new postJeremy Johnstone looks at creating a class to add that's missing from the basic datatype set of the language - enums.

I stumbled across a blog post on how to implement Enums in PHP via userland code written by Jonathan Hohle. I liked the concept he had, but the implementation was a bit unappealing because it used eval() among other more minor issues. You shouldn't need to generate Enums at runtime, so I took that as a challenge to find a way to do it at compile time, thus making the code much more efficient.

His enums would support type hinting and would, ideally, be iterable. He gives the code he's worked up - a base class, another than extends it to make a basic enum structure and some handy changes to support comparisons. A few more changes (and a few other extended classes later) he has some pretty well functioning enums that can even bee iterated through.

On the PHP Addiction blog today, there's a new post where Doug Hill asks a question of his fellow developers - are there advantages to having a standard container library for PHP?

Most compiled languages that I have used have some kind of container implementation, Lists, Maps, Trees, Stacks and all their many variations. PHP has arrays and the SPL.

The only problem he's noted so far is that containers made in userland would be slower than ones created natively. A comment from Antony Dovgal points out a project similar to what he's looking for that's already in the works.

On the PHP Addiction blog today, there's a new post where Doug Hill asks a question of his fellow developers - are there advantages to having a standard container library for PHP?

Most compiled languages that I have used have some kind of container implementation, Lists, Maps, Trees, Stacks and all their many variations. PHP has arrays and the SPL.

The only problem he's noted so far is that containers made in userland would be slower than ones created natively. A comment from Antony Dovgal points out a project similar to what he's looking for that's already in the works.

An official guide to choosing names for identifiers in userland has been added to the PHP manual on PHP.net. In his latest post, Lukas Smith talks about it:

So now we finally have some guidelines on how users should name their identifiers to be fairly future proof. This should hopefully help reduce the amount of pain people suffer when PHP adds new features like a class for Date or File handling. Although the two mentioned examples have settled on using DateTime and FileObject to get around the issue at least partially.

The guide itself is unfortunately spread over 3 pages, which does not seem to make sense since there is really not that much content there yet. Then again the guide may get expanded in the future. Anyways I recommend that every serious PHP programmer have a look at the guide. If there are any issues please let me (or the PHPDoc team) know. Otherwise make sure you adapt your internal CS to match this guide.

The guide talks about the naming of items in the global namespace (functions, classes, interfaces, etC), some rules to follow for internal identifiers, and some quick tips on naming to create pseudo-namespaces.