For quite a while I wanted to upgrade the Docker setup for the open-source Force Login module we develop for Magento 2. We were using a very old version of Mark Shust's Docker Configuration for Magento setup. Since there were a lot of changes how things work nowadays, the upgrade was not simple and came with a few side-effects. The latest version of the setup requires Magento to be checkout out locally and to be mounted in the container. If you develop a Magento application that totally makes sense, but for our module, it felt it makes more sense to have the Magento application code in the container as it used to be in the old setup. This led to a bunch of changes that I'll cover below.
A few weeks back at MageTestFest 2019 in Florence, I gave a presentation on QA tools I like and gave some insights how they can be used in a Magento project. One of the tools I mentioned was PHPStan - a static analysis tool. PHPStan helps you to detect a lot of problems in your code due to using wrong types, calling methods that might not exist, passing the wrong number or types of arguments to methods and so on. PHPStan is also able to create your own rule sets of what behavior you want to check for.
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.
One of our customers asked us to remove the delete option from the mass action element for the product grid. What sounded like a simple task evolved into a lot of debugging and testing. Apparently removing the mass action option from the xml configuration does not work even though a lot of StackOverflow posts say so. The only way that worked for me, was to do it programmatically like this:
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.
Last year I realized that Krunner, the launcher built into the KDE Plasma desktop is extendable by implementing a D-Bus service. I remembered that Derick Rethans once built a dbus extension for PHP5. Unfortunately there does not exist a "final" port of the extension to PHP7, but several people tried to fix most of the problems. I gave both the PHP7 & PHP5 version a try but got segfaults when sending data over D-Bus.
Following the blog post of Christian Münch in which he describes his setup in regard of improved bash command history management, I thought I'd share my setup as well. For years I have used a configuration I originally found in Rob Allen's blog. This gives me a context specific history at the bash prompt:
In a current Magento project we make heavy use of Elasticsearch via the smile/elasticsuite module. Elasticsearch is basically the first point of contact of the single-page application we have built on top of Magento. When we tried to make use of the existing Autocomplete features, we realized that partial word matching was not supported.
This years Web Developer Conference took place in Hotel Novotel in Munich City. The main topics covered PWAs, WebAssembly and Angular.
In a recent project the client asked us to remove a few of the defined dataproviders for the autocomplete functionality. The consolidated DI configuration of the autocomplete element looks like this: