On the Symfony blog they've made a post about a change in all Symfony versions around how .env files are handled and what prompted the change.

When Symfony 4.0 was released, the .env file was introduced as a way to set environment variables. The core of the system has not changed. But, thanks to recent updates to some core Symfony recipes, .env loading has some new features that can be enjoyed on any Symfony Flex project!

If you have an existing Symfony app (started before today), your app does not require any changes to keep working. But, if/when you are ready to take advantage of these improvements, you will need to make a few small updates.

The post outlines what changed exactly including the removal of the .env.dist, allowing a .env.local to override the settings and that the .env file is now pulled in for testing. The final point is the main reasoning for the changes to make testing much easier when it relies on these environment variable values. It doesn't require any changes to your current application but can be optionally implemented to take advantage of these updates.

Michael Dryrynda has a post to his site sharing a method for using Laravel Telescope in specific environments. Telescope provides enhanced debugging functionality to Laravel applications for introspection into data about requests, jobs, queues and more.

Whilst its primary purpose is as a debugging tool in development, it is also a powerful asset in debugging your production environment. In order to get Telescope, however, I ran in to some stumbling points in my CI environment in GitLab.

To work around this, I set out to conditionally load Telescope. I stumbled upon this comment from Mohamed Said, which suggested loading the TelescopeServiceProvider in one of your application's service providers, but doing so was not enough.

He goes on to talk about the package auto-discover functionality Telescope uses to load its provider and how this, along with the dont-discover configuration option in Composer's extra section can be used to control its loading. He also includes the code needed to register the provider classes but only in the environments other than "build" and "testing".

On the Codewall.co.uk site they've posted another tutorial that will help you set up a part of your PHP development environment: XDebug and the IDE NetBeans.

NetBeans is a fantastic free IDE for not just PHP, but other languages like HTML, JavaScript, C++ and more. For PHP it comes highly prepared for being your predominant development environment. It has a whopping list of features that turbo-charge your programming like it’s auto-complete ability to name just one. A PHP development environment isn’t complete unless you have the power to debug the code you write, in this tutorial, you’ll learn how to correctly set that up.

After covering some of the prerequisites they break down the process into a few steps:

• Download XDebug
• Configuring XDebug in the PHP.ini file
• Checking configuration has been activated
• Configuring NetBeans to use the xDebug module

The last step in the process is an example of actually running the debugger and debugging some code with a breakpoint (and the resulting output)

On the Websec.io site a new tutorial has been posted (a sort of continuation from this previous article) showing how to keep secrets safe in a PHP and Docker environment without too much overhead.

In a previous post I covered one method you can use to secure the credentials in your PHP application. In that article I provided an example specific to the use of Apache and its envvars handling to read in values and pass them along to the waiting PHP process as $_ENV variables. This in combination with the psecio/secure_dotenv library allowed you to pass along an encryption key that could be used to decrypt values from the application's .env file.

While this works for a flat Apache and PHP environment, the world has moved beyond that basic setup and has moved to using another popular environment building tool: Docker. [...] So, if we move forward with current technology, we need a way to secure our credentials in a Docker-based environment that makes use of PHP-FPM and Nginx. Fortunately there's a relatively simple way to handle this with just a few configuration changes.

The tutorial starts with an overview of what technologies are involved in the environment (Docker, PHP-FPM, Nginx and Vault) and some of the options for storing secrets with Docker. It then gets into the configuration files needed to create the environment: a Docker Composer configuration, the Nginx server definition, the PHP-FPM settings and the .env file that contains the secrets. Using these pieces and some special configuration directives, the secrets are injected into Docker when the containers are built and storing them in-memory rather that on disk.

On the Master Zend Framework site Matthew Setter has posted a new tutorial showing you what it takes to get started using Zend Expressive. The article is more about the environment the framework would live in (well, the application written with it) than the actual framework itself.

Ever thought that it's hard to get started with Zend Expressive? Ever think you need to know Vagrant, Ansible, Docker, Puppet, Linux, and more? Nope, you don't! In this post, I'm going to show you that, while these tools can help, if you’re just getting started with the framework (such as learning about it), you don't need them.

I want to be clear, before we go any further, that I’m not talking about doing fully-fledged development. [...] So what I’m talking about here is when you’re just starting out and getting a feel for Zend Expressive, right up to building a test application. I’m not talking about a fully-fledged, deployed application that requires copious tests, one backed by a CI/CD pipeline.

He then talks a bit about the history of Zend Framework and how one of Expressive's goals it to help take some of the sting out of using it. Following this he covers some of the possible tooling you could use including two environment tools: Docker (useful but not required) and Vagrant (handy but also not a must). Finally he gets to the actual requirement - a version of PHP 7 installed on the system. He shows how it, along with its included web server, can be used in development to host an Expressive site by itself.

On the Jolicode Blog there's a new post covering something not often mentioned in PHP development: environment variables. In this tutorial the author provides what you "need to know" about these variables and how to more effectively use them in your applications.

Environment variables for configuration are today’s best practice for application setup – database credentials, API Keys, secrets and everything varying between deploys are now exposed to the code via the environment, instead of configuration files or worse, directly hard-coded. Let’s dive into: how does it work, is it really a good idea, how to deal with them in PHP and finally some recommendations and common errors to avoid – with some real world traps we fell into!

They start with a "101" look at environment variables, covering what they are and how they can be referenced from your code (both in the web server and on the command line). They briefly talk about the potential danger in their use and using a .env file to store and read them rather than having them as web server configuration options. The post also includes examples of importing these values using various libraries and some of the common pitfalls that can come with their use.

Paul Redmond has written up a tutorial sharing his simple approach to using Docker and PHP to provide a more robust development environment.

Getting started with Docker and PHP can still be a steep learning curve. You might feel that you don’t need something like Docker and that Vagrant or full local development work just fine. I still use local development on some projects because the barrier to entry is small.

You will likely face scenarios where you require different versions of PHP, work with multiple developers, and seek consistency between environments. When you’re working with a team, you need a consistent way to develop. I’ve been on teams where different versions of PHP and MySQL varied between developers. I want to show you how Docker can fill the gap of providing consistent development environments, and do so without a huge amount of added complexity.

He starts with some background on why he decided to learn how to use Docker for his PHP development and how it has helped simplify his setup. He then walks you through some of his initial steps with Docker, providing the commands to create a new Laravel project and the structure he uses for his projects and the base image. He covers the contents of the Dockerfile, the Apache VirtualHost setup and how to build out the image. The post also includes instructions for:

• running Apache
• running "docker compose"
• adding a volume for local development
• adding MySQL
• running commands
• how to connect to the MySQL instance running in the container

Each item on the list includes configuration changes and commands that you'll need to get everything set up and running in a simple Docker container on your system.

On the Delicious Brains blog there'a a post that compares four different products for creating local PHP development environments: XAMPP, MAMP, DesktopServer and Local. Both package provide similar functionality but with slight differences.

An easy-to-use local testing server is one of the most important tools in a WordPress developer’s utility belt. Developing in a local environment lets you make changes to dev sites quickly and easily without having to transfer files anywhere and greatly reduces the risk of making breaking changes on a live server.

While many computers are capable of hosting a WordPress site without needing to install any extra packages, there are a few advantages that a dedicated local development environment can offer.

[...] There are quite a few different applications and tools that fit this bill, but for now we’ll be comparing the 4 GUI-based tools that seem to me to be the largest players in this space: XAMPP, MAMP (Pro), DesktopServer, and Local By Flywheel.

The post then walks through each piece of software, covering the installation and getting it up and running with a WordPress application. There's also a mini-review for each with good/bad comments and an overall rating.The post ends with some comments about the author's own preferences, which they use now and which they'd choose in the future.

On the Laravel News site there's a quick post highlighting a tool that can be use to help automate adding sites to your local Homestead environment - Homeboy.

Homeboy is a new package for Laravel Homestead that allows you to add a new local development site quickly. Once you run the command line tool, it will update your host file to point your dev domain, update your Homestead.yaml file to include mapping to for the new project and create a database mapping, and finally, it’ll re-provision Vagrant.

The post also includes a screencast the project has shared showing the tool in use (though the choice of soundtrack is questionable). It basically works as a shortcut to adding the changes to the files yourself, making it simpler to spin up new sites and environments quickly.

On the Hackernoon.com site they've posted a tutorial showing you how to set up a Docker image of a Laravel application to help speed up your development using the framework and standardize the environment it lives in.

With this article you’ll learn how to prepare a Docker image of a Laravel application, push it to the registry, and use Docker in Continuous Delivery.

The post starts with a brief introduction of the two technologies at play, the Laravel framework and Docker, and what they provide. The tutorial then walks you through the entire process of setup, configuration and deployment of the Docker image:

• Install Docker
• Write a Dockerfile (including the install of Laravel)
• Build Docker image (and Run)

At this point you have the image set up and ready to serve Laravel requests so they move on to sharing the image out on a Docker registry. In this case they opt to deploy it to hub.docker.com and use the login and push commands to quickly and easily share your creation. Finally they provide some use cases for this kind of deployment including creating standard development environments, using them for testing and keeping a consistent environment between development, staging and production.