Every new Symfony release tries to brings some small but useful improvements. Let's dive into some of them for Symfony 2.3 (in no particular order).

Things in his list include:

• A text-based output of the exception handling stack trace
• A default configuration for the Serializer component
• The ability to run the framework in a production environment in development
• An update to make debugging configuration parameters easier
• Conversion process of short controller names
• Overload generated code in the bundle bootstrapping code

Check out the post for the rest of the changes on his list and check out the RC1 of Symfony 2.3.0 to see some of them in action.

Use of random values is very important in the computer security field. It is crucial in computer programming for development of secure systems that are not vulnerable to malicious subversion. Cryptography relies on random value's generation and their reproducibility for unpredictable output that is core for security of any system. Random values are fundamental for secure coding practices and PHP highly makes use of them for security. You will find them used in all libraries and frameworks and almost all codes rely on them for the generation of tokens, salts and as inputs for further functions.

He talks about the important of good random numbers and some of the common uses for it including generating salts and unique identifiers. He mentions the "pseudorandomness" of PHP's generators and how they're seeded to help increase this randomness. He finishes up the tutorial with some suggestions and language features for creating "as random as possible" values like using "/dev/urandom" on Linux-based systems.

The PHP development process is still a bit frustrating. Many developers hoped that PHP had certain features but those are still missing due to several reasons. One way to see those features happen is to write code to implement the features and then submit the code to the PHP core. However that is not a guaranteed process. Even if you provide the necessary code, other developers may object to the addition of those features and the effort is wasted.

Among the things he lists as features that are desired but not implemented yet are things like:

• Aspect oriented programming
• Annotations
• Class generics
• Introspection of private variables and functions
• Named parameters

There's a summary of each of the features mentioned and in some cases links to RFCs that presented the same ideas. If you're interested in presenting your own ideas to the PHP project for inclusion, you can "demystify" the RFC process by checking out this post from Chris Jones with lots of good suggestions and the flow of how the process (usually) works.

My original patch for array_column() was written for PHP 5.2, but it sat around collecting dust for many years, until April of last year, when PHP moved to git and GitHub. That's when it became easy enough to apply the patch and send a pull request, which I did. [...] My goal for array_column() was simplicity. Many implement the functionality in different ways, and many call the function by other names (such as "pluck"), but I wanted to keep it simple and recognizable.

He includes an example of some sample data and how the function could be used to pull out the "last_name" field from each of the records and return just those as an array. If you're interested in seeing the original proposal and the RFC that was created for it, you can see it on the PHP wiki.

What's the next big thing in PHP? Or more accurately, how do you get to wish/want for a next big thing in PHP? PHP currently is seen as a jack of all trades, master none by most of people outside of PHP world and it's starting to look the same way for people who are using it as well. How did we got there?

He spends a lot of the post talking about the future of PHP, though - what could be coming along with a PHP 6 release. He suggests that, with the way things are going, PHP could not be around too much longer if something dosen't change. He also makes several suggestions to the core PHP developers about what they could do to help the situation including strong typed variables, a "smarter parser" and a poll for PHP.net asking the users what they want in the language.

This should be the next big thing in PHP. Collaboration and better community interface for both worlds, users and devs. Help us help you on PHP6, help us making a better world for everyone using PHP.

Why do almost no web frameworks provide any default authentication/authorization functionality, with default examples of best practices for common use cases. The standard response I've gotten for years was/is "well, everyone's needs for authentication are different". No, they are not. A (very?) large majority of web applications (which is what most web frameworks are used to build), require some form of user login and authorization management, and often self-registration, dealing with lost passwords, etc.

He points out that by not having something a user can immediately deploy that's been well tested and relatively risk-free, it can introduce security holes as a developer is "left to fend for themselves". He suggests that the "not everyone's the same" mentality that seems to go with authentication/authorization isn't as valid as once thought. He does point out that both Symfony2 and Zend Framework 2 come with ACL functionality, but no common user handling. He mentions ones in a few other tools used in other languages too like Devise in Ruby, Spring Security in Grails and a membership system in ASP.NET.

The PHP RFC process has been in place for a while, and users new to core PHP development are starting to use RFCs to propose desirable features. Here are some personal observations and suggestions that show how I have seen feature acceptance and the (newish) RFC process work in practice. These notes augment the steps in How To Create an RFC. I hope they help set expectations about the PHP RFC process and feature acceptance in the PHP language.

He lists the steps in the process from start to finish including things like:

• Avoid presenting an RFC idea to the "internals" mail list with email that begins "I don't know much about ... but ...". Do some research first.
• Your RFC should talk about all PHP areas that will be affected: php.ini, different SAPIs, engine, extensions, etc. List similar features. List similar features in other languages. Link to references. Give an estimate of the actual positive impact to user code.
• If you do have an implementation, make it clear whether the implementation is a simple prototype or is expected to be the final code. This is specially important during the vote.
• There is no need to respond to every discussion email individually. You should batch up your responses and manage the discussion intelligently.
• With long, fragmented discussions, not everyone will read every email. Update the RFC at regular intervals, and let people know what has changed.
• Some areas of PHP are complex or niche. Sometimes feature suggestions will be greeted by an apparent lack of interest. Don't be discouraged. This just means you need to take a stronger leadership role, and also prove your credentials by first working on the existing code base.
• During the voting period, it is common for people to continue mail list discussion. You may need to halt the vote and address any issues.

Obviously, there's a lot more to it than that - his post does a great job of letting you know what to expect and includes useful tips on helping you get your idea across.

In early March 2012, the PHP Group announced the release of PHP 5.4. Developer eagerly anticipated the release because of the many new features 5.4 would bring, the most sought after being traits. [...] Traits have have been generally accepted by the PHP development community, mainly because it's a feature that exists within other programming languages like Java, C++, and Python. [...] Are they a feature which will help raise the level of PHP development, or are they just a fad?

The starts with a few reasons why he thinks traits are bad like their potential for abuse and the difficulties that could be caused by using them instead of something like an interface. On the good side, though, he mentions things like allowing for "multiple inheritance" and their addition showing growth in the language.

Sometimes I need to stop/start remote Windows services with PHP. It's quite easy to do it with net commnand. This command is a tool for administration of Samba and remote CIFS servers. [...] Today we are going to create a PHP wrapper for [net rpc service].

He uses Behat to create a feature (test) file, the code behind the features and a service class that handles the actual work of interacting with the service (with methods to do things like stop, start and list running services). Examples of its use are also included.

There's been some talk about PHP 5.5.0 over the past couple of months even though it is barely on the horizon. The reason for this is that the PHP project has seen some increased levels of activity over the last two years since the dawn of PHP 5.4 and now in to the early twilight phase of PHP 5.5.0-dev. For those of you that haven't been following the internals mailing list I'm about to give you a quick test-drive and sneak-peak at PHP 5.5 using the latest 5.5.0-dev branch (which is still TBD).

Obviously, since the actual release of this version has yet to be determined, some of this may change over time. He gets into some of the major advancements and features that will be included like:

• the "finally" keyword
• list() support in foreach()
• the Password Hashing API
• generators
• a new property accessor syntax
• scalar type hints

Code samples are provided in some places to help make a bit more sense out of the example.