Changing PHP Version On Vagrant


After nearly 24 hours of working on this issue I finally figure out how to change the running version of PHP from the WEB SERVER under VVV for my WordPress development environment.  I recall, at a WordPress conference last year, someone touting how easy it was to change PHP versions to test plugin and theme development on various deployment stacks.    Sure, if you happen to want to pull a whole new box image with just the right version of PHP along with all your other tools in place.

For me, I wanted to keep my vanilla Vagrant box with a single mapped directory intact.   I wanted the SSL certificates I created to remain as well, which was another day-long project.   The only thing I wanted to do was replace the default PHP 5.5 release with PHP 5.4.43 to match that of a client.  I’d also like to test with PHP 5.2 someday as that is the minimum supported version for WordPress.

It turns out that changing the PHP version at the command line is easy.   Making it take affect in nginx, the default web server for VVV, is a whole other story.  I found lots of resources on doing this “simple trick” but very few were current and almost ALL were missing information or provide cryptic installs such as “on Apache” (not the VVV default web server) or “on Debian” (no the VVV default distro).

The Summary

Install and use phpbrew to build the PHP flavor you are looking for.

Find your particular flavor of PHP under the vagrant user directory and get the path to the socket listener.

Modify the nginx configuration file to use the socket for your flavor of PHP.

Restart nginx.

Installing phpbrew

Install phpbrew either by going to the phpbrew site and following their instructions OR go to the Vagrant site , install Vagrant, and then clone the repo to a local directory.    After cloning the repo checkout the feature/phpbrew branch.   phpbrew will be installed and ready-to-run.

I chose the “install manually” option as I wanted to keep my Customfile and some tweaks to my config files that I already had in place on my current “non-repo based” Vagrant box.

Make sure you run the phpbrew init command, preferably as the default vagrant login NOT as root.  This will create a hidden .phpbrew directory under your user’s (vagrant) home directory (/home/vagrant).

Install Your PHP “Flavor”

Decide what version of PHP you want to run and install it with phpbrew.  This may take a little time.   When it is done  you should have some new directories under your /home/vagrant/.phpbrew/php folder for the version you installed.

You will want some default options as well.   Here is my command for PHP 5.4.43 with the default configuration, FPM support, MySQL support, and CLI support.

Find The Socket Listener

Under the ~/.phpbrew/php//etc directory you will find the configuration files for that version of PHP.    Search the files for the line that loads the socket listener.  The socket listener ends with .sock and is usually in a /run/ directory.     I use grep to search:

The part after the listen = that is returned is the patch to the PHP 5.4.43 socket listener for FPM.

Modify The nginx Config

I edited this directly on my guest box by logging in with vagrant ssh and restarted nginx.  The default config file is at /etc/nginx/nginx.conf

Look for the line that loads the current socket listener, usually in the /var/run directory and comment it out.  Put another line in that points to your specific PHP listener.   Here is my snippet pointing to my PHP 5.4.43 version:

The other option to make this more permanent is to edit the vagrant config files.  Got to the directory that contains your Vagrant environment, the place with the Vagrantfile, and go to the ./config/nginx-conf/ subdirectory.   Edit the nginx.conf file.     This is the file that will build the /etc/nginx.conf file whenever you provision your Vagrant box.    If you change this file you will want to run vagrant provision from your host.

Restart nginx

Again, I did this from the command line on my vagrant box after logging in with vagrant ssh.

Check Your Work

Go to to your web browser and check the phpinfo status.

By default this is found at http://vvv.dev on your host.

Click the phpinfo link.

vvv dev dashboard

vvv dev dashboard

Using PHP Anonymous Functions In WordPress

Recently I published an article “Adding WordPress REST API Security To Basic CRUD Operations” where the permissions callback points directly to a function:

This style of defining a function call is known in PHP as an anonymous function.   The example is based on an example provided by the WordPress REST API documentation.   The problem with such a method is that it is not supported on older versions of PHP;  the anonymous function was introduced in PHP 5.3.  To exacerbate the problem, WordPress recommends PHP version 5.6 but will run on PHP version 5.2.4.    As such many hosting companies opt to take the path of least-effort and run the oldest version of PHP they can.  That means they are running PHP 5.2.4.

Guess what happens when a customer runs your plugin or theme that uses anonymous functions on PHP 5.2.4?  It breaks.

How do you fix the issue?

Use named functions.   Anywhere you use an anonymous function you can use a named function.    In the example above we can convert the anonymous function to a method within the class that is setting up our REST route:

 

Adding WordPress REST API Security To Basic CRUD Operations

Work has been underway adding REST API functionality to the Store Locator Plus plugin.   Most people are familiar with the basic concept of using REST to fetch data from a remote server.   We use this every day when surfing the web using the basic premise of an HTTP GET protocol.   In short this is the simplest form of a REST “read” operation.   Go here, get this thing and show it to me.

REST APIs get more exciting when  you talk about adding basic create/update/delete operations proving the full CRUD functionality via the REST protocol.    The issue with using REST for these operations , especially via the WordPress REST API , is that you are now exposing your data via  service that anyone with even a touch of technical prowess can now create, update, or delete data elements from your site.     In the case of our locator plugin, we don’t want any random person to send a simple HTTP request to our server and delete a location.

The WordPress REST API provides a simple mechanism for adding security to these types of requests.   It uses the built-in WordPress user authentication and roles-and-capabilities to ensure a user has permission to alter the specific object, in our case location data, before handling the REST request.   To employ this security you will need two things;  A plugin that manages authentication requests  and the addition of a permission_callback parameter to your register_rest_route() call within your plugin/theme class that is managing your REST API.

The first part, adding a plugin, is easily handled by fetching one of the git repositories listed at the WordPress REST API documentation site.   You can choose either Basic Authentication (very weak security) or oAuth (much better option).   Using Basic Authentication is great for development and is what I use when testing RESTful services via phpStorm 2016 with its built-in RESTful service applet.

The second part, adding a permission_callback parameter, is done in the coding of your plugin or them that is managing your REST requests.   This can be handled using a simple anonymous function that returns the results of the WordPress current_user_can() function.     In Store Locator Plus we check to make sure the the user, authenticated with one of the above plugins as part of the source of the REST request, has the capability  of ‘manage_slp_user’ assigned.   By default this is assigned to all admin users when Store Locator Plus is installed.   The register_rest_route call looks like this:

This setup will check that the REST request has passed authentication and that the user identified with the request has the manage_slp_user capability before executing the add_location method in our REST API class.

Adding security on your POST/PUT/PATCH REST requests is as simple as that.

There are a lot of other tricks built into the WordPress REST API. Keep track of this blog to watch for more articles on WordPress development as I share what I’ve learned each week.

%d bloggers like this: