As was announced on both the [PEAR blog](http://blog.pear.php.net/2015/07/25/pear-1-10-0dev1/) and [Christian Weiske](http://cweiske.de/tagebuch/pear-1.10.0dev1.htm)’s blog, the PEAR project has made a major update to add PHP7 support preparing it for the upcoming major release.
The new PEAR installer release adds PHP 7 support while dropping support for PHP 4 – 5.3. It also fixes a nasty SSL issue that made it hard to use on PHP 5.6. With the update, strict warnings about static calls to a non-static PEAR::isError() are a thing of the past.
I’ve just published the first preview version: PEAR 1.10.0dev1.
Upgrading your version of the PEAR installer is as simple as a call to `pear upgrade` specifying this dev1 release (command is included in the post). He also links to some pre-release versions of the `go-pear` and `pear-nozlib` installers.
Remi has announced the release of the remi-php7 repo, available for Fedora ≥ 21 and Enterprise Linux ≥ 6.
Current version is PHP 7.0.0beta2 with about 25 extensions which are already compatible. This repository provides development versions which are not suitable for production usage. […] As for other remi’s repositories, it is disabled by default, so the update is an administrator choice.
This repository can be installed just like other similar remi repos via the „yum“ command to add the repository to the list of available ones, then another to upgrade the PHP installation.
The Facebook HipHop Open Source blog has posted a case study from Box about their migration to HHVM and some of the challenges and benefits that came along with it.
Reducing latency and increasing the capacity of our infrastructure have always been top priorities at Box. We strive to deliver the best possible user experience in the most efficient manner, and historically our choice of PHP hasn’t aligned well with these goals. I’m very happy to report that we’ve recently made very significant strides toward these two ideals by successfully deploying HHVM (the HipHop Virtual Machine) as the exclusive engine that serves our PHP codebase. In the rest of this post, I will detail how we use PHP, how HHVM works, the challenges we faced migrating to HHVM, and the remarkable performance wins it provides.
The post talks about how central PHP is to their overall technology stack and how, despite the work being put in, the processing of requests was starting to be a bit too much. In came the HHVM and some discussion about how it might be used there at Box. They started a yearlong effort to migrate their entire stack to HHVM especially since HHVM has almost reached parity with the PHP language itself. They talk some about the differences in design between the two and how the migration changed their deployment process. They also cover some of the other interesting things that come with a major migration including phased rollout and host-based conversion methods. Finally they share some of the statistics around the performance of the end result, including the better response times and reduced CPU graphs.
The SitePoint PHP blog has posted a tutorial showing you how to „use WordPress without WordPress“ via a basic RESTish API installed via plugin. The article focuses on using the OAuth authentication method to connect a client to the WP instance, linked to a system user via generated tokens.
In this tutorial, we’ll learn how to install and use WP-API with OAuth – a WordPress plugin which uses REST-like API endpoints to allow reading of WP content to unauthenticated users, and writing of WP content to users who authenticate via OAuth (or via Cookies for themes and plugins). Using the plugin isn’t very straightforward, and the prerequisite list is quite long, so this post was written to make it simple and relatively approachable (as long as you’re in control of your own server).
The tutorial walks you through the steps to get a WordPress instance installed (via a git clone) and setting it up to work with Homestead Improved. He then installs the „wp-cli“ tool to get the OAuth1 plugin needed to make things work correctly and how to use it to generate the needed key and secret for the OAuth connection. He then makes a simple script that uses the Guzzle HTTP client and it’s OAuth handling to make the OAuth request for a token, call the callback page and return the bearer token for the remainder of the requests. Finally he creates a simple page that uses this token to submit a new article via the API and views it in the WordPress interface.
Julien Pauli has posted a look at PHP’s closures and how they’re actually handled internal to the language.
He starts at the beginning (a good place to start) and talks about the work that needed to be done on the internals before closures could even be introduced. He walks through the changes made to object handling to make them „callable“ and the addition of the „zend_closure“ object type. He then gets to the part where „the magic happens“ and shows how the userland closure is translated and executed. He ends the post with a look at two other topics: scoping with „$ this“ and the special handling that was needed for reflection and direct calls to „__invoke“.
The Paragon Initiative blog has posted a guide to what they see as a way to safely generate random strings and integers in PHP applications.
Generating useful random data is a fairly common task for a developer to implement, but also one that developers rarely get right. […] It’s generally not okay to use a weak random number generator unless both of the following two conditions are met: the security of your application does not depend in any way on the value you generate being unpredictable or there is no requirement for each value to be unique (up to a reasonable probability).
He gives some examples of places where it’s a must to use a „cryptographically secure pseudo-random number generator“ including generating random passwords, encryption keys or IVs for data in CBC mode. The article goes on to talk about some of the problems that could come from using weak generators. It then gets into the process for generating random values and the use of the random_* functions in PHP (or using this polyfill) to more safely generate the numbers. Included is code showing the process and some advice around converting random bytes to both strings and integers.
Paul Jones has posted an article to his site with another helpful hint to modernize your legacy PHP application. In the post he looks at updating serialized object handling with the help of the class_alias function.
Several weeks ago, a correspondent presented a legacy situation that I’ve never had to deal with. He was working his way through Modernizing Legacy Applications in PHP, and realized the codebase was storing serialized PHP objects in a database. He couldn’t refactor the class names without seriously breaking the application. […] Before I was able to reply, my correspondent ended up changing the serialization strategy to use JSON, which was a rather large change. It ended up well, but it turns out there is a less intrusive solution: class_alias().
He talks about how this function could be useful to prevent the need for updating the class name in every serialized instance by setting up an alias to the new name. You can even use namespacing in the alias that will let the autoloader work with the PSR-0/PSR-4 handling to correctly load the class. With this in place, you can then refactor to the new version of the class without worry of breakage.