As I have written before, we are big fans of Mark Shust's Docker Configuration for Magento project. Even though we customized the setup a bit for our needs, it comes with a lot of good stuff out of the box, like Xdebug support.
For a few projects we make use of the Event Engine by prooph software which is a biased - in a good way(tm) - way of quickly building event sourced applications. While building a user registration context, I was stuck a bit how and where to properly hash the password for the user. I could have done it in the init() method of the command, that way I would have made sure that the cleartext password is not "visible" anywhere in the application code. In the end, I decided to make use of a provider class. The return value of the provider will be passed to the specified aggregate method and allows me to pass it to the respective event.
We are big fans of Mark Shust's Docker Configuration for Magento project. We use a lot of our projects, the ones we start from scratch as well for ones that we have taken over and have some weird setup in place that we simply cannot get to work.
In a recent project, we make use of the Event Engine which is an Event Sourcing framework for PHP helping you to rapidly develop event sourced applications. Since parts of the exposed API by the Event Engine should be access proteced, we decided to use OAuth2 for access delegation. That way each route exposed by the Event engine application can be marked as "protected" if needed.
A few days ago Jordi announced the first dev build of Composer 2.0. I immediately went and downloaded it. Since version 2.x should be a lot faster, I thought it is a good idea to test it against a current Magento 2 project I am working on. I was a bit disappointed first because Composer failed with quite a few errors like that:
On the 24th and the 25th of January 2020 I was able to go to the PHPBenelux Conference in Antwerpen. It is a community-driven technology conference. As the name implies it is mostly about PHP and related topics. It was the first conference I visited besides our very own unconference at bitExpert. Therefore I was very excited and did not know at all what to expect.
These days we get more and more in situations where we have to push our code into Git repositories of our customers, either because the customer wants access to the source code or because we are working closely with their in-house team. Maintaining our own local copy of the source code and constantly keeping our copy in sync is a no brainer with Git.
Back at MageTestFest in Florence, I introduced the audience to a tool called Captain Hook for managing Git hooks. In the QA section of my talk, the question was raised why I have not recommended to use GrumPHP. A valid question since all the QA tools I talked about are already supported by GrumPHP out-of-the-box.
After trying to upgrade our (very) old Tine 2.0 installation to the latest version of Tine 2.0, Tine 2.0 was not able to connect to our mailservers anymore. After testing a few things, it became clear that the PHP IMAP module had problems with the SSL certificate we are using for our mailservers. Even though it is not a self-signed certificate, imap_open() failed to connect to the mailserver. After digging a bit in the Tine 2.0 sources, I found that peer verification can be disabled by setting the peerVerify flag to false. Since I could not find a UI setting in the Tine 2.0 setup for this option, the solution was simple: Look for the imap configuration in the tine20_config database table and add the peerVerify:false setting to the existing JSON object for the connection configuration.
Given you want to introduce Disco into a legacy project, you need to manually convert the existing DI configuration into Disco's class based configuration format. This requires you to have in-depth knowledge about the DI container format your project is using right now as well as some in-depth knowledge of Disco's configuration. Some examples to give you guidance for the conversion process can be found online in the disco-demos repository. But there is more, Andreas Heigl created a CLI tool called manero to help you to automatically convert existing DI configuration into Disco's class based configuration format. In the first step, manero is only able to convert Zend Expressive configurations. The current conversion process looks like this: First you need to clone the repo and create a .phar file of manero yourself: