In a current Magento 2 project we are focussing on building a headless instance that communicates with a kind of PWA application. In such an environment testing the APIs via Postman makes sense and since the Magento 2 API is documented via Swagger, one can easily import the API definition into Postman. Here is how to do it with httpie:
When setting up Rancher via its Docker container, you are not able to configure SSL termination out-of-the-box. Instead the Rancher documentation gives some advice on how to set up SSL termination via nginx or Apache. But why would you install such a service on the host when Rancher is running in a container? Ideally the SSL proxy would also run in a container. Searching on Docker Hub for a solution, I found the dictcp/rancher-ssl image that provides exactly that. The set up is trivial.
In one of our projects we had the need to access a web application via a .dev domain. The application was shipped with a self-signed SSL certificate, usually not a big deal. But not this time. Chrome and Firefox both complained that the application was using a self-signed certificate, an error I have seen many times. But this time things were a bit different, neither Chrome nor Firefox offered the possibility to whitelist the server certificate because the website was using HSTS. I checked the webserver configuration for the HSTS configuration but could not find anything. It took me quite a while to remember having read about a change in Chrome which added the HSTS configuration for the .dev gTLD by default. Also Firefox made a similar change recently which I learned about while looking on how to solve the issue.
On 13 April 2018 we visited the React Amsterdam conference. The conference took place in the Kromhouthal, Amsterdam and is the biggest React conference worldwide. Two tracks were offered: General and React native.
In one of our projects we use Traefik as a reverse proxy together with nginx and gunicorn to run a Django app in a docker-based environment. When deployed to production, we wanted to make the Traefik UI accessible for the customer, but keep it secure from unwanted visitors. Fortunately, Traefik offers a very simple yet powerful configuration option, which we enabled in a traefik.toml configuration file:
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 any more. 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:
It's been a while since the last Disco release. Over the last few months quite a few improvements have been made to the code, new features have been added and unfortunately some BC breaks had to be done. As always, find the BC breaks covered in the upgrade guide.
In a recent attempt of moving an application from one server to another, I needed the MySQL server running on the old server on localhost to listen on another IP address. Digging into the MySQL documentation I realized there's only an all-or-nothing approach built into MySQL server. This means MySQL is only able to listen on one IP address or all IP addresses. Of course, I could have configured MySQL to listen on all IP addresses (networks) and then use a couple of firewall rules to lock access, this seems like a common approach.
Recently we hit a problem in our Force Login Magento 2 module: The module was not compatible any more with Magento 2.1 due to a change in a constructor of a Magento base class we extended. This broke the DI configuration which in turn meant the module was not installable in a Magento 2.1 project any more. We were not able to spot this problem early on as our Travis build did only run against the latest Magento version 2.2. Inspired by this blog post of the heidelpay developers, I began to restructure our Travis build.