Those topics cover a lot of advanced and complex practices, but today, I want to talk about a simpler subject. What is the best approach to pass data from outer layers of the application (actions, controllers, async jobs, CLI commands...) to services that are part of the use case layer, by taking advantage of some of the practices promoted by those subjects.
Earlier last week I found a github repository which collects different resources related with PhpStorm. Plugins, themes, utilities...
I found it very interesting, because I think PhpStorm is the best PHP IDE by far, and I've been using it on an almost daily basis for the last 4 years.
The thing is that finding that repository gave me the idea of writing a post explaining the list of third party plugins I use and why, in case somebody is starting to use the IDE and wants some ideas on where to start.
If you want to get any of them, just search for it inside PhpStorm. It's the easiest way to install them.
I think it is doubtless that modern PHP embraces SOLID principles, and therefore, dependency injection.
That's why every modern PHP application needs a dependency injection container to deal with it.
There are several options out there, depending on the way you like to work. Every container has a slightly different approach.
My choice is zend-servicemanager, it is the one that better suits me.
Other containers rely on auto wiring and auto discovery in order to know which dependencies need to be injected on every service, and I think that leads to errors when an application grows.
I like zend-servicemanager because it is explicit, and you are always in control of what's done, without loosing flexibility in the process.
Sometimes the nature of an application requires you to change the default framework's way to structure error responses (like 404 and 405).
On this article I'm going to explain how to customize those responses when working with Zend Expressive 2.
In Expressive 1, error handling was different.
There used to be an element called error handler, which was responsible of handling uncaught exceptions, but also, other errors, like the ones above (404 and 405).
When using the error handler it was easier to have an standard way to generate error responses for any kind of situation, like unmatched routes (404), routes requested with an incorrect HTTP verb (405) or uncaught exceptions (500), as well as other errors.
In a project I'm working on, we recently needed to add some kind of encryption system that allowed us to store sensitive information in a secure manner, but being able to access to it at runtime in order to pass it to third party services.
Securely storing your own app passwords is easy. You just hash it, and the password can be verified without having to decrypt it, but if you need to "decrypt" it, the solution is not that easy.
We started by building our own solution based on zend/crypt, which is an excellent solution and works like a charm, but you still need to store the master key somehow, and that's the big problem.