On the Delicious Brains site they've continued their series covering the deployment of WordPress applications with part four of the series. In this latest tutorial they walk you through the process to set up automated deployments of your WordPress site. In this case, they focus on the use of either the Buddy or DeployBot tools to help automate the process (rather than a roll-your-own solution).

In my last article, we looked at different methods of deploying a WordPress site using Git. We also looked at using an external CI service (such as Travis) to automatically trigger a deployment on your remote git repo.

In this article, we’re going to build on what we have looked at previously and consider some alternative hosted services that can help us with automated deployments for our WordPress site. There are many hosted services that we could use to deploy our WordPress site but we’re just going to look at a few of the bigger ones: Buddy and DeployBot. Unlike Travis, these services are dedicated to automated deployments and offer a lot more functionality and flexibility.

They start off by listing out some of the prerequisites you'll need for your environment including a WordPress site in a Git repository and a working install of Composer. They then walk you through the process to set up the automation in a similar way on each platform:

• Signing up for Buddy and adding a new project
• Setting up a new pipeline
• Configuring the tasks to run
• Transferring files
• Connecting it to the production environment

Once all of that it set up, you're ready to run the pipeline and test it out. Screenshots are included for each step of the way to make sure you're in the right place and are getting the settings correct.

On his HackerNoon site Sameer Nyaupane has posted part four of his series covering test-driven development in PHP. In this latest post he covers the use of mocking.

Hey there, welcome to part 4! Today we’ll learn how to mock. Mocking is a process where you create a fake instance of a real class, and test against it. This is so that, you do not have to worry about the real functionality of external dependencies inside a class. This makes unit testing a lot easier and reliable.

[...] Although PHPUnit does have mocking capabilities, it is not as full fledged as that of Mockery’s. We’ll be using Mockery for all our mocking needs.

He starts with some sample code, a simple Math class that calculates the area of a square (but doesn't implement it fully). This includes the need for an instance of a Calculate class that doesn't exist yet. He then works up a test for the Math class, mocking the Calculate class and calling the getArea method to evaluate the result. He walks you through each line of the code, sharing what's happening during test execution.

On the Symfony project blog they've posted a series of articles covering some miscellaneous improvements made for the v4.1 release of the framework.

During the past months we've published almost 40 blog posts about the main new features of Symfony 4.1. In this article you'll find some of the other small but nice new features.

Here's the list of the posts and some of the things covered in each:

• Part 1: CSRF without forms, visibility change in progress bar component, showing dotenv files in the profiler
• Part 2: command to delete cache pool items, allowing custom functions in "allow_if" expressions, addition of "dd" debug helper
• Part 3: add/remove LDAP attributes efficiently, keeping the query string after redirect, hasser accessors in PropertyInfo
• Part 4: adding anonymous services in PHP DSL, support for extracting type from constructor, configurable PHP error log level

Check out each post for a brief summary of each change and example code/configuration showing how to make use of it.

On this site Matt Sparks has posted the first few parts of a series covering the creation of a custom framework. Why? Well, as he explains in part one of the series:

So with all of that being said, it begs the question: why on Earth would you want to do this?

The extremely short answer: I want to. The less short answer: A PHP framework encompasses many of the areas I want to learn more about.

The first four posts of the series are already on his site (with more to come):

• Part 1 – Why? Seriously, Why?
• Part 2 – What is a Web Framework?
• Part 3 – Time For Action
• Part 4 – The Foundation

Matt does a great job of laying out some of the fundamentals behind frameworks including structure, design patterns, and commonalities between frameworks. You can follow along with his progress on the project on the AnalyzePHP GitHub repositories.

The Pehapkari.cz blog has continued their series covering domain-driven design with the latest post in the series showing some alternative relational database mapping techniques.

Do you think that multilingual text must always be in a separate database table? Than this article is for you!

We will show that not all arrays have to be mapped as database tables. And we will also show the Doctrine implementation.

The article starts with a bit of background on what they're trying to accomplish: adding internationalization functionality to an e-commerce application. In order to make it simpler to work with the multi-language requirements they show the abstraction of its handling out into a LangValue value object that's used to store the product name value for each language. They then use this and some JSON encoded data to store the different language strings in the database directly with the product record rather than a different table. It then shows how to create the matching Doctrine entity for the LangValueType to work with the serialized column data and extract data from it's JSON blob.

Mark Baker has returned with a new part of his series looking at the use of anonymous classes and closures as an alternative to the typical test mocking functionality. In this latest part (part four) he talks more about the "SpyMaster" class created in the previous article and how it can be refactored to provide the spies with a "mission".

In a prior article in this series, I described the use of a SpyMaster Class to create proxy spies as anonymous classes, that allow external visibility (and potentially update) of protected and private properties within an object. The same basic principle of a spy can also be used to create a proxy that gives us access to execute the private and protected methods of an object.

[...] Unlike the original SpyMaster that I wrote about last July, we’re going to take a slightly different approach here, providing our spies with a “mission”.

He first shares the code for the old class and covers why it was useful. He then moves on to the refactor, showing how it defines the "mission" (what to mock) and an "invoker" that helps with the actual execution. He gives an example of this new class in use, performing an "infiltration" on a sample object and calling previously protected methods directly.

Sergey Zhuk has posted the latest part of his "Building a ReactPHP Memcache client" series to his site today. In this latest article, part four of the series, he focuses on unit testing the client as he's developed it so far.

This is the last article from the series about building from scratch a streaming Memcached PHP client for ReactPHP ecosystem. The library is already released and published, you can find it on GitHub. In the previous article, we have completely finished with the source code for async Memcached ReactPHP client. And now it’s time to start testing it.

He then walks through some of the steps to create the tests for the client, made a little more difficult by its asynchronous handling. He shows how to use Mockery to create tests that evaluate the results of the promises from the client, starting with a simple check on the return of a version call. The post goes on to show testing for other parts of the client and includes all of the code and commands you'll need to execute them in your own environment.

Asmir Mustafic has posted the next part of his series covering the deployment of Symfony applications. In this latest article (part four) he focuses on some of the final steps of the deployment process.

This is the forth post from a series of posts that will describe the whole deploy process from development to production. The first article is available here, the second here and the third here.

After covering the steps 1-3 and having prepared our infrastructure, we can see how to deploy our application to production. Almost the same approach can be used to deploy not only to production but also to test environments.

He starts with the workflow for the deployment process, creating a flow where the "git push" should trigger other actions based on the branch pushed. Then CircleCI will fire off a series of jobs to handle environment setup tasks, connecting to a VPN and deploying the code. This includes a bit of preparation, credential handling and the Docker setup and push. Each step along the way also includes all of the YAML configurations you might need to replicate the deployment.

Sammy Kaye Powers has a series of posts over on his site introducing you to testing the PHP language with .phpt tests. So far he's introduced the topic, shown how to run the tests and debugging failing tests.

If you've ever wanted to get involved with PHP internals, writing tests is a great way to get your foot into the door. The tests are written in PHP so you don't even need to know C to get started.

Each of the posts also comes with a screencast, narrated by Sammy, showing the information presented in the tutorial:

• 01: Compiling PHP from source
• 02: Running the test suite
• 03: All about .phpt files
• 04: Debugging failed tests

There's more to come in the series as he still plans to teach about how to fix current tests and how to eventually create your own. Stay tuned to his site for more tutorials in the series.

Esben Petersen has posted the fourth part of his tutorial series covering the creation of a "modern REST API" with Laravel. In this latest article he focuses on authenticating users with the help of an OAuth2 flow.

OAuth is all around us. Most of us have tried to login to a 3rd party service using our Facebook or Google account as a login. This login mechanism is one of many OAuth authentication types. However, you can also use OAuth to generate simple API keys. One of the OAuth authentication types generates API keys based on username and password and is therefore a solid authentication choice for SaaS-style apps. This article will explore how to setup the password grant authentication type in Laravel using Laravel Passport.

The article is broken up into a few different sections, each with explanations and code where appropriate to help illustrate the point:

• a basic introduction to OAuth2 and grants
• authentication in single-page applications
• dependencies to use (and install/configuration)
• creating the login proxy
• building a consumer

The final step is an example (using a curl command) to test the API and ensure things are working as expected. The post ends with a more "real world" example of a Slack-style application and linking channels and user but only showing the channels users have access to based on scope.