If you're new to PHP and are still learning the ropes, one thing that could be confusing is how the language handles sessions and the data they contain. In this new tutorial from the TutsPlus.com site, they introduce you to the basics of using sessions and the variables they contain to get you up to speed.

Session handling is a key concept in PHP that enables user information to be persisted across all the pages of a website or app. In this post, you'll learn the basics of session handling in PHP.

We'll start with an explanation of how sessions work and how they are related to cookies. Then we'll look at a few code snippets that demonstrate how to work with sessions. You'll learn how to create and destroy sessions, and how to change session variables.

The post starts with a general overview of what a session is and how the information flows back and forth from the user to the server. To illustrate, they provide an example of a simple login process, complete with flow diagram. The tutorial then shows how to:

• start a new session
• get the session ID
• automatically start a session
• destroying a session

It then covers the use of session variables: setting them, removing them and altering their contents.

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 Exakat blog there's a new post sharing five uses of the "static" keyword in PHP applications. This includes the less common static closures and static class names.

Static is a PHP keyword with many usages. It is almost universally used, though there are many variations of it. Let’s review all the five of them :

• static method
• static property
• static closure
• static variable
• static as a classname

The post goes through each of the items in the list giving a brief explanation of how it's used and a code example showing it in action. The post finishes with some tips on evaluating your own code for the use of "static" and tips for each to make your code easier to wrangle and maintain in the future.

In a recent post to his site Marco Perone looks at the idea of "maybe" in PHP, having functionality that acts a default value if no value is present. This idea is implemented in other languages like Haskell and Elm.

Doing functional programming in a language as PHP, which is almost completely used as an imperative or object oriented way, is not always easy. Good progresses have been made thanks to the introduction of callable type hints in PHP 5.4 and the diffusion of functional interfaces like the ones present in PSR-7.

Still, all “good” PHP code is still written using objects and classes and the object oriented perspective on the world strongly influences even the most functional oriented libraries.

In this post I would like to propose as an example how we could implement the Maybe type in PHP. We will see how some open source libraries do this, we will see an alternative solution and we will raise concerns about some modelling issues.

He starts off by describing what the "maybe" functionality is and gives some examples of it in use in other languages. He points out that while there's several PHP libraries that implement this kind of default handling, it's not in the PHP core language. He works through some of these libraries and shows them in use: monad-php, Phunkie, php-maybe-monad and php-fp-maybe. He wraps up the post showing his own suggested implementation and how it could help resolve some of the issues he found with the other libraries as he worked through them.

Mark Baker has posted a tutorial to his site showing how to use closure binding as an alternative to "use" when calling closures in your PHP application.

As a general rule when creating a Closure, arguments are passed when the function is called, but “use” variables (I’m sure that they have a formal name, but have no idea what it might be, so I just refer to them as “use” variables because they’re passed to the Closure through a “use” clause) are fixed as the value that they already contain when the Closure is defined, and the variables themselves must already exist within that scope

[...] Of course, the drawback of this approach is that when we need to change the price minimum and maximum values for filtering, they’re hard-coded in the callback.

He talks about the limits this imposes on calling the closure (ex: can't easily add addition params) and how the values have to already exist before the closure can be called. He points out that calling the variables by reference can help somewhat but it still comes with some of the same baggage. He then shows how to use object binding for a closure to handle the same kind of "min" and "max" by working around it with a closure bound internally to an object and called via a public method.

Freek Van der Herten has a new post to his site sharing some of his ideas around making overloaded functions more readable, functions that can take in variable types of parameters (ex: both a string or an array) and can handle them correctly.

Sometimes you might allow a function to accept multiple data types. I don’t know for certain if it’s the correct term but for the remainder of this post I’m going to call such a function overloaded. In this post I’d like to show you a little trick to make overloaded functions more readable.

He starts off with an illustration from the Laravel framework of a "session" helper method that, in turn, calls "put" and checks for an array versus string input with some interesting logic behind it. He gives another example from a recent pull request where the code could be simplified using the same method as the "put" example, making it much more readable in the end. The post ends with one more example from this package and how the "respond" method was refactored with the same process, simplifying it down to a more readable and less-nested version.

Chike Mgbemena has a new post to his site looking at PHP 7 and the abstract syntax tree and uniform variable syntax changes that came along with it.

On my previous post (PHP 7 In-depth Look), I discussed in-depth about the features of PHP 7 (you can read it here if you have not). In this post, I am going to be talking about The Abstract Syntax Tree(AST)/Uniform Variable Syntax in PHP 7+.

PHP 7 introduced a new layer which is called the Abstract Syntax Tree(AST) which helps in decoupling the process of parsing from the pseudo-compile process. Note that this new layer does not have much impact on performance but it make the syntax uniform. Uniform variable syntax/abstract syntax tree aims to establish internally consistent variable syntax, references are accessed from left to right instead of right to left.

He goes on to talk about dereferencing, how it changed from the PHP 5 handling and what IIFEs have to do with it. Some sample code is included showing some of his points and how PHP 7 interprets things slightly different than PHP 7.

Freek Van der Herten has a post to his site showing how PHP functions can (sort of) be overloaded with the help of a trait from Adam Wathan.

PHP does not support method overloading. In case you’ve never heard of method overloading, it means that the language can pick a method based on which parameters you’re using to call it. This is possible in many other programming languages like Java, C++.

However, with some clever coding, Adam Wathan made a trait, aptly called Overloadable, that makes method overloading possible. It works by just accepting any parameters using the splat operator and then determining which of the given functions must be called according to the given parameters.

He shows how to use the trait in a simple example, defining a single "bar" function and using the "Overloadable" trait to handle the switching between the methods based on the input variables. You can find more information about the trait and the source for it in this gist over on GitHub.

Matt Stauffer has a quick post to his site showing how you can set up and use environment specific variables in Laravel, specifically for your testing environment.

In Laravel, it's easy to set environment variables that are specific to your testing environment. Just edit your phpunit.xml file and set them as entries in the block [...] but what if you find yourself needing to exclude these values from version control?

He talks about the project he's working on and its integration with Twilio. He need to write some tests for a class that connected to the Twilio service but wanted an easy way to swap out the production credentials with the Twilio test ones. Instead of checking in the test credentials, he dropped them into his .env settings file, one specific to the test environment.

In this post to his site Matt Stauffer walks you through how he created a custom @requires annotation to use in his PHPUnit testing. He needed a way to tell a test to only run if it wasn't being executed on the Travis CI service.

I was working on a project this weekend that required skipping certain tests in a particular environment (Travis CI). [...] I remembered that there was a @requires annotation in PHPUnit that works natively to allow you to skip a test under a certain version of PHP or with certain extensions disabled, so I set out to write my own custom @requires block.

He links to an article that helped him get most of the functionality in place but decided to restructure it a bit to make the override of the checkRequirements method a bit clearer. He ends up using the Laravel Collection functionality instead of a basic foreach reducing it down to a closure that looks for an environment variable called TRAVIS and automatically mark the test as skipped.