Recently we hit a problem in our Force Login Magento 2 module: The module was not compatible anymore 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.

Last weekend, I visited the PHPBenelux Conference 2018. I experienced a very well organized event with a wide range on interesting topics. As expected there were many PHP focused sessions like "Advanced debugging techniques" (Patrick Allaert), "How PHP ticks" (Sara Golemon) or "Disco – A fresh look at DI" (Stephan Hochdörfer). But also broader issues which are interesting, too. I visited "Go for PHP Developers" (Terrence Ryan) and "Learning Machine Learning" (Joel Lord) and many more. Besides, the official talks there was always an opportunity to have interesting conversations or challenging some fun games. It can only recommend to visit the tenth jubilee next year.

Yesterday, we released version 3.0 of our Force Login Module for Magento 2 which brings some requested features and fixes, here are the highlights of the current release:

We released version 2.3 of our Force Login Module for Magento 2 which brings some requested features and fixes, here are the highlights of the current release:

We released the new 2.2.0 version of the Force Login Module for Magento 2 providing support for Magento 2.2.

This year, I attended the reasons.to conference in Brighton, UK.

While working on this prooph components powered API, I realized it would make sense for our mobile client to know when data changed on the server-side without constantly pulling all data from the API and comparing it locally. In a "traditional" application I would have used a checksum mechanism - e.g. creating a checksum of all the data in the datastore - but with an event sourced application this is no longer needed as we can simply rely on the timestamp of the last event happened to know if things have changed.

A while I ago I covered the upsert feature PostgreSQL introduced with version 9.5. Back then I showed you how to make use of upsert with one field - the primary key - as conflict target. In a recent attempt to modify the upsert logic to take 2 fields into account I tried to add the additional field to the conflict target:

In one of our current Magento 2 projects we have the need to create a custom shipping method which that should not be selectable when there a product in our cart with a specific value selected in a custom attribute.

As it seems there is no out-of-the-box way in Sencha ExtJS to provide a configuration based on the build environment (development, testing or production) to your application. Since you need at least different urls for your proxys, it makes sense to have a mechanism in place that would generate the respective configuration for you. This is our solution for the problem.