Auch dieses Jahr ist es wieder so weit! Am 13.10.2018 öffnet die bitExpert AG die Türen für die 5te unKonf. Wie in der Vergangenheit richtet sich die unKonf an interessierte Software-Entwickler die sich zu aktuellen Themen gemeinsam austauschen möchten.
I had a hard time getting the Axon.ivy Designer to run on my KDE Neon desktop. The designer application - basically a custom Eclipse build - starts fine but when I try to launch the browser view, the Eclipse instance crashes. Browsing the Eclipse bugtracker showed that this is a common problem or in other words "practically speaking the embedded browser widget is unusable" on a recent Linux version. It was proposed that installing libwebkitgtk-1.0 would fix the problem, but that did not work for me. Instead installing libwebkitgtk-3.0 and a minor tweak finally fixed the problem for me.
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 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:
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.