PHP 7 was released last December. Once you've tested your code locally to run on it, it's time to upgrade your production server. Generally, I found that most of my sites run well on it.

However, I suspect that not many sites have upgraded yet. It's often safer and easier to stay on older releases. [...] But PHP 7 has now been out for nearly a year.

In today's episode, I'll walk you through my recommended approach to upgrading to PHP 7 on Ubuntu 14.x and resolving problems with PHPMyAdmin, which a lot of early upgraders ran into.

He starts by helping you identify any customizations that you might have related to PHP 5, specifically related to configuration options. He then provides the commands to remove PHP 5 packages from the system and add in the "ondrej/php" PPA for apt-get as the source for the PHP 7 packages. After a quick apt-get cleanup, he includes the commands to install the "php7" packages, enable a few extra modules and getting phpMyAdmin back up and in working order.

The main highlight of re:Invent is always the keynotes and the new services and features announcements they make during the keynotes. One of the new services caught my attention, and I decided to give it a try. That service is AWS CodeBuild.

CodeBuild is designed to be used as part of the AWS CodePipeline, but it may also be used by itself. [...] Out of the box, CodeBuild provides some managed images that you may use to build your projects. These include environments for Android, Java, Python, Ruby, Golang, and Node.js. PHP is missing from this list, but since you’re able to use other images, I decided to see how easy it is to get up and running on CodeBuild with a PHP project. I chose to try out my ramsey/uuid library for a simple test.

He walks you through the creation of a new CodeBuild instance (complete with screenshots of the UI) and how to configure your project, explaining each of the settings as he goes. He includes the full build command he's using for the library running tests, a lint check and codesniffer checks for formatting. He shows how to get the project to build and what the UI will show when the build is successful (all green).

The SitePoint PHP blog has a new article posted taking a look at Packer (from Hashicorp) and if it's something that's relevant to a PHP developer's needs. Packer is a tool that makes it easier to machine images that can be reused across platforms based on a single configuration.

If you do a lot of server work for your clients or on the job, along with development work, then yes. Packer can help you a lot.

If you are only a developer and don’t really do much work on the server directly, then no. Packer won’t be very helpful.

That being said, it is wise for any PHP developer to learn the basics of creating server environments. You will run into these technologies in your career in one way or another (everything you create runs on them!). This specialized knowledge will help your career in the future for sure! At a minimum, you’ll understand your dev-ops colleagues and the work they do much better.

The article starts with a "look back in time" to when server setup was more manual and server admins/developers had to go in and change configurations/update software by hand. From there they move forward to the changes that virtualized servers made possible followed quickly by tools like Vagrant. Vagrant makes it easier to create and configure virtual machines so why would you need something like Packer? The article provides a summary of the features that Packer provides and how its overall workflow operates.

With all this information under your belt, the tutorial then starts in on using the Packer tool:

installing the Packer software

creating a new server instance

setting up the JSON configuration

the build process

working with provisioners

installing the VM with VirtualBox

The environment is now all set up and configured so the next step is, naturally, installing a PHP-based application. They opt for a basic Symfony demo application, showing how to change the configuration to pull it in and set everything up.

PHP has an SSH2 library which provides access to resources (shell, remote exec, tunneling, file transfer) on a remote machine using a secure cryptographic transport. Objectively, it is a tedious and highly frustrating task for a developer to implement it due to its overwhelming configuration options and complex API with little documentation.

The phpseclib (PHP Secure Communications Library) package has a developer friendly API. It uses some optional PHP extensions if they’re available and falls back on an internal PHP implementation otherwise. To use this package, you don’t need any non-default PHP extensions installed.

The first step is getting the library installed (via Composer) and a few example use cases including generating SSH keys dynamically and testing a SSH/SFTP connection. The tutorial then talks about three methods you can use with phpseclib to connect to remote servers: using an RSA key, using a password-protected RSA key and just the normal username/password combination. With the connection made they then show you how to:

execute (single and multiple) commands on the remote server

exit on the first error

gather the output from the commands

There's also a bit included about some other interesting configuration options and a few alternatives to the library if phpseclib doesn't work exactly right for your application.

OAuth2 is a security framework that controls access to protected areas of an application, and it’s mainly used to control how different clients consume an API ensuring they have the proper permissions to access the requested resources.

Laravel Passport is a full OAuth2 server implementation; it was built to make it easy to apply authentication over an API for laravel-based web applications.

For those not familiar with some of the terms around OAuth and its handling, they start with a few brief definitions (those that are familiar can skip them). Following this the post gets into the creation of a two kinds of grant handling with Passport: third-party authorizations and first-party applications (your own apps authenticating against the OAuth server). The post ends with a brief mention of creating access tokens manually, but points out that thing functionality should probably only be used during testing.

Normally, when I work with websockets, my stack is a socket.io server and a Silex frontend. Protect a PHP frontend with one kind of authentication of another is pretty straightforward. But if we want to use websockets, we need to set up another server and if we protect our frontend we need to protect our websocket server too.

If our frontend is node too (express for example), sharing authentication is more easy but at this time we we want to use two different servers (a node server and a PHP server). I’ve written about it too but today we`ll see another solution.

He sets up a simple Silex application with three routes - the root (/), a login route and a "private" one requiring a user to be logged in. This last route makes the connection to the websocket server in the template. This connection sends the current session ID to the backend where it's verified with a simple Socket.io middleware. Sometimes the session ID cookie will be set as HttpOnly so he provides an alternative for that: a new endpoint just for getting the current session ID for the websocket request.

One of the latest offerings in the Laravel ecosystem, Laravel Valet, was released this past week. It makes setup of new applications simpler and even allows tunneling back from the public web to a local system for easy sharing. In this post to his siteMohamed Said takes a look at the "magic" behind Valet and how it does what it does.

So yesterday Taylor Otwell and Adam Wathan released Laravel Valet, it's simply a tool that helps OS X users easily run their websites locally for development purposes, without the need to configure anything each time a new project needs to be created.

The idea behind valet is that it configures PHP's built-in web server to always run in the background when the operating system starts, then it proxies all requests to a given domain to point to your localhost 127.0.0.1

He starts by helping you get the tool downloaded (via Composer) and what happens when you run the valet install command. He gets into the detail of each piece that valet sets up:

the OS X daemon to run the PHP built-in server

the Valet configuration files

Dnsmasq (a DNS server)

He then talks about how handles the requests for your local ".dev" sites and the "drivers" it uses to decide which site to serve up.

If you are a seasoned Laravel developer, you know the usual project setup drill that involves creating a new project, a fresh database, and adding a virtual host entry to Apache.

If you are starting from scratch, the Apache and MySQL installation can take some time and slow things down for you. However, I will show you how you can jump start your Laravel development without Apache and MySQL.

The tutorial shows you how to use the internal PHP server to host the application, run a Laravel site inside it and integrate SQLite as the database. Each section comes with some example code and the commands/configuration you'll need to make the system work. They also take a "deep dive" into Larvel's serve command and how it bootstraps the Laravel instance for the PHP built-in server. The post ends with a look at switching back to MySQL and a comparison of SQLite vs MySQL (as well as using SQLite for production).

Most developers by now internalized that we should not invest time in optimizations before we know what happens exactly. [...] This is true for optimizations in your PHP code but also for optimizations regarding your infrastructure. We should measure before we try to optimize and waste time. When it comes to the assumed performance problems in your system architecture most people guess the root cause will be the database. This might be true but in most projects we put under load it proved to be false.

So, how can we figure out where the problems are located in our stack?

They talk about some common testing practices using basic tools (like ab and siege) and having them perform common operations on the application. They then talk about testing for high load, monitoring the stack for the impact and a few tools you can use to gather statistics. They end the post with a quick mention that, despite popular opinion, the issue isn't always the database's fault. Sometimes other technology that's in play - like file locking issues or processing for server-side includes - and other things that may only show up under high load.

Loïc Faugeron, author of the recent "Ultimate Guide" to Symfony components series has a new kind of post to his site today. In this latest article he shows you how to integrate Symfony and ReactPHP for "super speed Symfony" sites.

HTTP frameworks, such as Symfony, allow us to build applications that have the potential to achieve Super Speed.

A first way to make use of it is to run our application as a HTTP server. In this article we'll take a Symfony application and demonstrate how to run it as HTTP server using ReactPHP.

He walks you through the installation of the ReactPHP HTTP server and provides some simple code to get a server up and running. He uses this to provide a "Hello world" example and helps you test it to be sure everything's up and running as expected. He then creates a basic Symfony application that uses the HttpFoundationRequest handling to wrap that same server and yield the same results. He includes some benchmarking examples and some updates he needed to make to have it work correctly with the Blackfire.io profiling service. He ends the post with a look at some of the alternatives to ReactPHP (including IcicleIO, Aerys and PHP FastCGI), why it improves performance and how to make it production ready with [] Supervisord(http://supervisord.org/).