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:mehr lesen...
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:mehr lesen...
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 has the need to create a custom shipping method which thhat 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.
We are running Rancher in combination with the in-built load balancer HAProxy. For each of our customers, our application is provided as a single container, many on the same physical server instance. Each of the customers' applications can be accessed via different URLs, so the usage of the HAProxy as the routing component part of the load balancer makes sense.
Linking Docker containers can be done in various ways. In my recent attempt of playing with Docker and our GitLab Review Apps setup, I experimented with different methods to figure out what would work best. These are the different options I played around with: