Jordi Boggiano, lead developer on the Composer project, has posted another of his PHP version statistics posts, this time for the first part of 2018.

It's stats o'clock! See 2014, 2015, 2016.1, 2016.2, 2017.2 for previous similar posts.

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 <a href="https://packagist.org/>packagist.org logs of the last month 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.

The remainder of the post shares some of the results and differences since November 2017. Among the highlights are:

• The use of PHP 7.2 has increased by a large percent
• The use of all over versions (including PHP 7.1) is dropping
• There is still a large number of packages that only require a version in the PHP 5.x range to be installed

Check out the full post for the complete stats on versions in use and trends (along with some nice graphs of the results).

The SitePoint PHP blog has a post about a feature Composer provides to help make tools and libraries easier to use - the ability to install things globally. In this post editor Bruno Skvorc wonders if this feature should be "considered harmful" and a bad practice.

We’ve discussed Composer best practices before, and I’ve always advocated using composer global require when installing packages that can be used across several projects – particularly command line tools. Then, the other day, I ran into this discussion. The short of it is – the majority of people now seem to feel like global require is bad practice, unless the globally installed package has zero dependencies.

The article he references offers an alternative option however: install locally to the project and just update your paths to allow for it to be easily found. This can be difficult and hard to maintain so Bruno offers a counter-suggestion, the "[consolidation/cgr]"(https://github.com/consolidation-org/cgr) tool. This tool handles the "global" install in a way that still isolates it and then automatically updates your .bash_aliases with the command and path to make it easier to use.

On the HHVM blog there's a recent post looking at some of the requirements around traits and interfaces in the Hack language. More specifically, they talk about type checking with traits and how interfaces can be used to help provide extra structure.

In PHP, traits are a mechanism of code reuse that, while very powerful, are also difficult to type check both efficiently and exhaustively. In this post we’ll dive more deeply into the reasons for that and see how Hack solves those problems, allowing you to use traits in a safe way without limiting their expressiveness.

They start by talking about the main problem with PHP's handling of traits (essentially copy and paste into the current class) and how they felt Hack should "just work" in allowing type checking on these "pasted" methods too. Performance limitations prevented them from handling it how they do with other variable types, so they changed things up, using a "require extends" syntax to tell the Hack engine how to allow the checking based on an interface. There's a lot more to it than this, so be sure to read the rest of the post on how they came to that conclusion.

Maybe you've heard about Composer and how it makes working with PHP libraries and packages easier. There's lots of articles (besides the project documentation) that can help you get started but Rafael Dohms has just shared an excellent overview of versioning and the features the tool makes available to fine tune your requirements to just the right level.

I have been putting together a new talk about Composer, and that means looking around the community, doing loads of research and trying to identify the items that need to be covered in a talk. Mostly I have been trying to identify things that people do on a regular basis that according to composer internals is either wrong or not ideal. One such thing that I have found is the proper selection of versions, and that also led me to find a new feature in composer that makes everyone’s life so much easier. So let me break this down.

He starts with a look at the selection of the actual version you'll need and how Composer treats each type of version match (strict vs wildcards vs a mix of the two). He shows an example of adding one of these version strings to a "composer,json" file, both manually and via a command line call.

Several sites have areas that have content protected behind a login making them difficult to pull into a script. Juozas Kaziukenas has created an option to help you past this hurdle - a PHP class (that uses cURL) that can POST the login data to the script and pull back the session ID.

But how you are going to do all this work with cookies and session id? Luckily, PHP has cURL extension which simplifies connecting to remote addresses, using cookies, staying in one session, POSTing data, etc. It’s really powerful library, which basically allows you to use all HTTP headers functionality. For secure pages crawling, I’ve created very simple Secure_Crawler class.

The class uses the built-in cURL functionality to send the POST information (in this case the username and password, but it can be easily changed for whatever the form requires) and provides a get() method to use for fetching other pages once you're connected.

Wez Furlong posted a request for comments to the php.internals and php.pdo mailing lists yesterday about a new ly proposed update to the current PDO functionality - PDO 2. He just wants to clear up a few things...

It became apparent over the past year or so that PDO has been a good and valuable addition to PHP. [...] We believe that having direct involvement from the data access providers would be most effective, which is why we set out to try and get them on board.

There were three steps they would need to make to push things to version two (documentation, define scope/direction and organize data provider integration methods) and the proposal that has caused a huge stir in the community - the idea of requiring a CLA contributors would need to sign.

Comments to this point from the community include:

• Richard Thomas
• Antony Dovgal
• some of Wez's own comments
• Mike Willbanks
• Christopher Jones
• Lukas Smith
• Paul Jones
• Pierre-Alain Joye
• Jay Pipes
• Derick Rethans
• Marco Tabini
• Kristian Kohntopp
• Some PDO humor from David Coallier and Travis Swicegood
• Marcus Borger (and his part two)
• Richard Heyes
• Till's blog entry
• Say No to the CLA

A new tutorial on DevShed today takes a look at a handy bit of functionality that's included with PHP5 - the automatic autoloading of classes.

As you might know, the "__autoload()" function, when used in a clever way, can eliminate almost completely the need to use the "require()/require_once()" and "include()/include_once()". [...] Now is the perfect time to move forward and start learning how to put the "__autoload()" magic function to work for you, and load your classes without having to include them manually into your PHP 5 object-oriented applications.

They show the more traditional approach with a code example (just using the require/include method) then show the difference in using a custom defined autoload function to tell the script where to find the libraries.

A new tutorial on DevShed today takes a look at a handy bit of functionality that's included with PHP5 - the automatic autoloading of classes.

As you might know, the "__autoload()" function, when used in a clever way, can eliminate almost completely the need to use the "require()/require_once()" and "include()/include_once()". [...] Now is the perfect time to move forward and start learning how to put the "__autoload()" magic function to work for you, and load your classes without having to include them manually into your PHP 5 object-oriented applications.

They show the more traditional approach with a code example (just using the require/include method) then show the difference in using a custom defined autoload function to tell the script where to find the libraries.

On the PHP Discovery blog, there's a new post reminding PHP developers of some of the more dangerous ways that remote execution could effect your site and some of the common entry points it can have.

PHP has numerous ways to execute raw PHP code unless you the programmer stops it. Best way in preventing these methods is making sure you check the input of what your users are inputting, and making sure you escape all malicious actions that a hacker,cracker, kiddy scripter might want to do to your website.

He summarizes four of the things from the Pro PHP Security book from Apress (by Chris Snyder and Michael Southwell) that can leave holes in you application for would-be explots - preg_replace, shell_exec/exec, eval (which we all know is only one letter from "evil" anyway) and require/include.

On the PHP Discovery blog, there's a new post reminding PHP developers of some of the more dangerous ways that remote execution could effect your site and some of the common entry points it can have.

PHP has numerous ways to execute raw PHP code unless you the programmer stops it. Best way in preventing these methods is making sure you check the input of what your users are inputting, and making sure you escape all malicious actions that a hacker,cracker, kiddy scripter might want to do to your website.

He summarizes four of the things from the Pro PHP Security book from Apress (by Chris Snyder and Michael Southwell) that can leave holes in you application for would-be explots - preg_replace, shell_exec/exec, eval (which we all know is only one letter from "evil" anyway) and require/include.