On the Zend Framework blog today there's a new post from Enrico Zimuel showing you how you can use Argon2 password hashing in PHP applications (coming natively in PHP 7.2).

PHP 7.2 will be released later this year (2017). This version contains some interesting additions, including two new security features: support of the libsodium library.

With these new features, PHP is the first programming language to adopt modern cryptography in its standard library.

In this article, we demonstrate the usage of the Argon2 password hash algorithm.

He then walks you through the installation of the pre-release version of PHP 7.2 and the argon2 library to get the environment up and running. He briefly talks about what the Argon2 hashing algorithm is and how to use it directly in PHP via the password_hash function. He also mentions the password_get_info function and shows what the result of inspection on an Argon2 application contains.

Logging and information debugging can be approached from a multitude of different angles. Whether you use an application framework or coding from scratch it’s always comforting to have familiar components and tools across different projects. In our examples today, I am going to enable Amazon CloudWatch Logs logging with a PHP application. To accomplish this, I wanted to use an existing solution that is both already popular and well used, and that is standards compliant. For these reasons, we are going to use the open source log library, PHP Monolog (https://github.com/Seldaek/monolog).

They start by introducing the Monolog library for those not familiar with it and how it relates to the PSR-3 standard. The ultimate goal with their implementation is to allow for the logs to be shipped to CloudWatch and implement some alerting around them. The tutorial then kicks in and they show you how to use Composer to install Monolog and an add-on to interface with CloudWatch. Code is provided to set up the initial logger and how to have it to log messages to different places. They then move over to CloudWatch and define a filter for the JSON data to find successful logins to your application. They also show how to use this same functionality in a Laravel application, contained in a test route.

Google Page Insights is a required tool to have when analyzing the speed and usability of your site. As you may know these metrics influence how google ranks your page in search results. If you frequently make changes to your web site designs than it becomes mandatory to check the metrics after each change to make sure that the design changes has not affected the score in any negative way. If you have many pages to test than manual testing can quickly become cumbersome.

Thankfully there are libraries that you can use to automate this process. Once such is given in this post which allows you to get Google Page Insight metrics using PHP.

He then walks you through the installation of the package (via Composer) and how to use it, along with your Google API key, to fetch the information for a given URL. You can get information for different environments (desktop vs mobile) and even a screenshot of the page that's under test. He ends the post with a helpful hint for those that might get a certificate error when making the request and how to fix it.

Any data that you receive needs to be checked and validated. There are number of ways to do this including PHP's filter_var, but I prefer Zend-InputFilter. This is how to use it as a stand-alone component.

He shows you how to get the component installed (along with the Zend ServiceManager) and the creation of a basic validation/filtering on "author" data. He explains the different parts that make up the instance: required, filters and validators. He then shows how to use it in your request and the resulting output if something fails.

Leonid Mamchenkov has an interesting post to his site detailing a plugin for the popular Composer package management tool that makes it easier to apply patches to the current version of libraries in use: composer-patches

composer-patches is a plugin for Composer which helps with applying patches to the installed dependencies. It supports patches from URLs, local files, and from other dependencies.

This plugin makes it so that, during the normal Composer installation flow, you can apply your own patches to fix functionality that may not be corrected upstream yet. It replaces the need to "fork and fix" in your own version of the repository and cleans up the process to a more automated flow. It can also help when working with multiple people on the same code that's not your own and apply their patches to evaluate their changes.

On the Slack Engineering blog there's a new post from one of their engineers talking about a choice the company made about their platform - they decided to take PHP seriously. In this post author Keith Adams talks about why they chose PHP and what kind of experiences they've had with it in their own environment.

Slack uses PHP for most of its server-side application logic, which is an unusual choice these days. Why did we choose to build a new project in this language? Should you?

PHP-the-language has many flaws, which undoubtedly have slowed these efforts down, but PHP-the-environment has virtues which more than compensate for those flaws. And the options for improving on PHP’s language-level flaws are pretty impressive. On the balance, PHP provides better support for building, changing, and operating a successful project than competing environments. I would start a new project in PHP today, with a reservation or two, but zero apologies.

He starts with some background on the history of PHP itself, where the language came from and what kinds of issues it tries to mainly solve. He then gets into some of what he sees are the "virtues of PHP" including the blank slate at the start of every request, one-request-one-process concurrency and the fast programmer workflow. He then gets into the "bad stuff" they've found when working with PHP, things like surprise type conversions, a "failure-oblivious philosophy" and inconsistencies in the standard library. Finally he looks into two options (created by Facebook to improve its use of PHP) - HHVM and the Hack language - and how it was integrated into their environment.

I decided to use Laravel Spark as the foundation for the product, and I thought it would be helpful to share the advice. Whether you’re just starting your Spark app, or are in maintenance mode, I think you’ll find some of these tips useful!

His tips cover a wide range of the product's features:

You Don’t Have to Keep All the Base Files

Use Simple Repositories

Don’t use caret (^) Laravel dependencies

Host on Forge

Re-Arrange Middleware

Each of these comes with a description and, where appropriate, a bit of code to help clarify the point.

If you’re on the fence about trying Spark, I can recommend it. It’s given my product a head-start it wouldn’t have had otherwise. Hopefully these tips will save you even more time.

So you spend most of your time programming in PHP. You meet another programmer out in the wild. You begin explaining what you do. Do you find yourself using vague terms and actively trying to avoid the word "PHP?" Do you dread the question, "What language do you primarily code in?" Do you anticipate them scoffing at you when you say, "PHP?"

We discuss why PHP has such a bad rep in the eyes of many and why some of us feel the need to start conversations with, "I use PHP but let me explain..."

Jordi Boggiano has posted some updated statistics around the use of the Packagist site around PHP version requirements and the relation of package downloads to PHP versions.

Last year I posted stats about PHP versions, and the year before as well, both time in November. However this year I can't wait for November as I am curious to explore the PHP7 uptake!

A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. I look in the packagist.org logs of the last 28 days for Composer installs done by someone. Composer sends the PHP version it is running with in its User-Agent header, so I can use that to see which PHP versions people are using Composer with.

He compares the previous statistics against the ones gathered back in November 2015, both in numbers and graphs. He shows the stats for the PHP versions being used and for the PHP versions that are required. It's interesting to see that there's been a good uptick in supported versions including PHP 7.0+.

In a new tutorial posted on the TutsPlus.com site they get into some detail about what exceptions are in Laravel-based applications, when to use them and how to make your own.

As a PHP developer, you may use exceptions, because they allow you to notice when something has gone wrong or the user has acted in an unusual way (such as division by zero). Without exceptions, your application would end up presenting unwanted errors and being much more difficult to debug. It is also important that you halt execution immediately and take another course of action.

Exceptions are really simple, and they will make your development progress easier. When you learn how to use exceptions, this will be a usual part of your development.

They start by explaining what exceptions are (in the strictest sense, a definition from Martin Fowler) and an example of how one is caught in PHP. They briefly talk about when to use exceptions and how they're implemented in Laravel. The post finishes with a look at creating your own exception types and where to place them in your application. They also make the suggestion of using the Assertion package to verify data and catch the AssertionFailedException if there's an issue.