It's honestly been over 5 years since I last touched PHP on the back-end. At that time, other than "doing it live", XAMPP was the top dog for local environments. Is there a new player in the space or should I go with the same? I've been working primarily as a front-end engineer for the past few years during my full-time employment roles and touched the back-end on projects I've worked on but they've all been Java-based.

They also ask what other developers are using for their deployment tools and pipelines. Answers to the post so far include some of the usual tools and methods including:

Docker

puphpet (for use with Vagrant)

Homestead from Laravel

Other comments also mention the manual creation of virtual machines and even support for local installations rather than virtual ones. What's your development environment like? Head over to the topic and share your own setup too.

Why in this modern day and age is setting up a development environment still such a complicated process? [...] Why is it still so hard to get one setup that works, that does what you need, and that matches the deployment environment’s of testing, staging, production and so on?

[...] By now our development environments have grown quite sophisticated. But the overhead of both building and maintaining them has increased significantly also. Wouldn’t it be easy if we could set them up, but with only a small investment of time and effort? I think you know where I might be heading with this. You can. Yes, that’s right, you can. Ever heard of Docker?

He then starts in on introducing Docker (for those not already familiar) and how it differs from a VirtualBox/Vagrant setup that's already become quite popular. He talks about "containers" and the role they play as well as an overview of the environment he's going to show you how to create. He then helps you get Docker installed, explains how the containers will work together and provides the Docker YAML configuration for each of them. The docker-compose command is then used to bring the environment up, downloading the containers as needed. The final result of his setup is a set of containers running together to serve up a Zend Framework Skeleton Application.

On the SitePoint PHP blog editor Bruno Skvorc has posted a tutorial showing you how to set up the Packagist alternative, Satis, in a local network configuration instead of requiring users to still access the external web.

While preparing my technical materials for WebSummerCamp, I realized my workshop would rely on a fairly stable internet connection, as we’d have a lot of ground to cover and a lot of packages to install. Rather than rely on the gods of live demos, or pre-installing everything and ruining the experience, I picked another route.

In this post, I’ll show you how to set up a local Satis instance and have it host the packages over the network it’s currently on, so that everyone who’s also connected to it can put the address into composer.json as a custom repository source, and retrieve all packages from your machine locally – no internet connection required!

He then shows you how to set up the system on a Homestead Improved VM locally, cloning Satis inside of it. He includes an example of the configuration of his required packages and how to build the local repository using this setup. Then, using the built-in PHP web server, he shows the result of the setup and how to access it from other machines. Finally, a few updates are required to the user's composer.json to use the local versions instead of the normal remote connection for the package downloads.

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.

In this two-part article series, we’ll be covering how to contribute to the PHP project. This will hopefully clarify what steps need to be taken for those looking to become more involved with PHP.

This first part will be covering how to contribute to PHP’s documentation, including how to request a php.net Account and what to do once an account has been granted.

He starts with a bit about why you should contribute back to the PHP project and how the documentation is a great place to start. He then gets into the structure of the documentation, the DocBook structure it uses and points to the online editor for the first time contributors. He includes a video showing how to use the system to resolve this bug showing an incorrect MongoDB Client example. For those that would rather do it locally, he shows how to setup and configure the source and required tools. He then shows the flow of updating the documentation, building the result and verifying the update looks correct.

Finally he talks about requesting a php.net account to push the changes back upstream and provides some general tips on things like style guidelines, page ordering and correctly versioning files.

In a post over on Medium.com Barry vd. Heuvel shows you how to use a recently added feature of Composer, the ability to use local repositories, to install Magento extensions quickly and easily.

I’m a fan of using Composer (in- and outside Magento), so I like to use that option. This works great for free packages listed on Magento connect or Firegento Packages, because you can just require the packages and run composer update. [...] This is all great for public packages, which are download through the Firegento repository. But what about private packages? Ideally we could also use Composer for the packages we purchase. [...] In this blog I’d like to explain how to tackle these 2 problems, so you can keep using the Composer workflow.

He walks you through the two steps you'll need to set up the module so it can be installed via Composer: creating a mapping (package.xml) and the composer.json. For the first he recommends using the Magerun modman tool to help with this. Creating/updating thecomposer.json file to work with the extensions is relatively easy. He makes use of the "path repositories" functionality to points the package at the "extensions/" directory using wildcards in the path name to allow for inclusion of all extensions without having to list each one (see this PR). Finally, to help make the process a bit more clear, he walks through a full example using the Amasty module.

This past weekend I decided it was finally time to wipe my Macbook’s hard drive and start fresh. I have used it daily for several years now and still had artifacts from when I used Mamp. Since then Vagrant has turned to my local server of choice and one of the reasons is how clean you can keep your machine by utilizing it.

After finishing the new Mac OS X install it felt like a new beginning. So clean, so minimal. [...] This go around I wanted to keep it as minimal as possible and only install things I know I need and use. This tutorial covers how I set up my Mac for local PHP Development.

His list of software includes the previously mentioned four as well as the ZSH shell replacing the default bash and, obviously, PHP itself installed via Homebrew.

Composer has definitely made a huge impact on how PHP packages and libraries are integrated into other applications. Sometimes, though, it makes more sense for you to keep your code internal to the organization rather than have it public where Composer can install it. In this case, using some thing like Satis (a self-hosted Packagist-ish server) makes more sense.

We all love Composer. It changed dramatically the way we build PHP applications, based on small and reusable components, but this creates new challenges, especially when we have a single point of failure (SPO). With Satis, the deployment process can be made robust by adding redundancy in all potential SPOFs (Packagist and GitHub). Let’s see how it works.

They start with a brief look at how Composer works for those not familiar, making the connection with Packagist and ultimately the public repository. In the context of the "single point of failure" they talk about Packagist being down and it preventing the install (or deployment!) of your application. Satis is prefect to help prevent this. The article then shows how to install Satis (via Composer, naturally) and how to set up the configuration file to define the repositories. The server is then built and can be run using the built-in PHP server on the port of your choice. They include a screenshot of the end result and a quick example of how to use it via your project's Composer configuration.

When I first started writing this post, I considered giving it a title such as “How to set up local PHP development with dynamically configured mass virtual hosting on Apache 2.4″, “Quick and easy prototyping using Liip PHP, Dnsmasq or Proxy Auto Configuration” or even “The Ultimate Guide to Rapid Development on OSX 10.10″. I did not.

In my daily job as a Development Manager, I don’t get to code very much, but when I do, I want to have a setup that allows me to quickly create development projects and prototypes in the ~/Sites folder and have them show up as vhosts automagically, without having to edit any configuration file(s).

His three steps do require a few prerequisites including Homebrew, but that's easy enough to set up. Here's his process:

Step 1 – installing (my preferred version of) PHP

Step 2 – enable hosting under ~/Sites

Step 3 – add a local DNS server

He also includes a "Step 3a" that shows how to test the installation via a simple response from each of the domains.

On the VG Tech blog this latest post shows you how to use local packages as dependencies in your Composer-enabled applications.

Composer changed pretty much everything when it comes to including dependencies in PHP projects. No more SVN externals or copying large library folders into your project. This is really great, but there’s one thing I’ve been struggling to find a smooth process for; developing dependencies for your project. When implementing your project, the need for some module, library, service provider or something else will arise, and sometimes you’ll have to implement it yourself. So, how to do that?

He starts with a list of three suggestions (including actually having the code in the project or mirroring the package) but suggests the last of the three: using a repository with a relative file system setup. He uses the "repositories" configuration option in the Composer config to define a "vcs" type and gives it a path to the package contents. He ends the post with the resulting output of the Composer install command, showing the package pulled in and being able to commit to it just like any other repo.