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.

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:

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.

The TutsPlus.com site has posted the fourth part of their series covering the use of namespacing and autoloading in WordPress plugins. In this latest tutorial they take everything they've shared (and made) previously and put it all together into a cohesive whole plugin.

At this point, we've laid the foundation for our plugin, written the plugin, and defined and explored namespaces and autoloaders. All that's left is to apply what we've learned.

So in this tutorial, we're going to put all of the pieces together. Specifically, we're going to revisit the source code of our plugin, namespace all relevant classes, and write an autoloader so that we can remove all of our include statements.

He starts off talking about namespacing and how it relates to directory structure and the code you'll need for each of the plugin files for put them in the correct namespace. With just these in place, however, errors are thrown. This requires the setup of a custom autoloader and PHP's own spl_autoload_register handling. He includes the code for the autoloader, taking in the class name and splitting it up to locate the correct directory, making it easier to replace the loading of all plugin scripts.

Ibuildings has posted the fourth part of their "Programming Guidelines" series to their blog, sharing even more helpful hints and tips you can apply to your everyday development. In this new post author Matthias Noback talks about messaging in your application, not in output to the user but in the communication between parts of your system.

Phillip Shipley continues his series looking at creating a client for the Nexmo API with his latest post, part four focusing on the testing of the current connections and state of the code.

At this point in this series we have a complete PHP client for the Nexmo APIs. Hopefully I’ve been able to teach some good practices and designs in the process of developing it, but I know many of you test-driven-development advocates are probably screaming that I’ve left out the most important part: testing, and testing early. Well, in order to keep these tutorials focused I’ve saved the testing to the end, and actually when testing API clients I find it easier to write the tests afterwards, but I’ll get into that later.

He points out that running tests on code that connects to APIs it a bit tricky as you don't want it to make actual API requests every time you run the tests. Instead he shows how to use Guzzle mock responses and the Mockable.io service (when you do actually need to test that HTTP requests are made). He includes the code examples to create the Guzzle mock response as well as a brief look at how to use Mockable along with your current tests with an "override" on the base URL.