231 posts tagged with "PHP"

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.

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.

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.

When we made the move to GitLab 1,5 years ago, it was clear to me that we would need some automation to simplify the creation of groups and projects and to sync the LDAP group memberships to the matching GitLab groups. I did a quick search on Packagist for GitLab client libraries and found the m4tthumphrey/php-gitlab-api package.

In my recent talk on introducing Disco - the DI container with the damn coolest name(tm) - I talk about why I believe that using XML or any other non-code configuration (YAML, JSON, ...) is not a good idea. This stirred some twitter discussion recently which led to this blog post.

In a recent attempt to automate a few things even more, I was looking for a way to post messages to our Mattermost instance via the Incoming Webhook feature of Mattermost. I did a quick search on Packagist for Mattermost client libraries and as it turns out there a quite a few. I picked the thibaud-dauce/mattermost-php package simply because it was the first match ;)

Last week we released Disco version 0.9.0 with a few new features and unfortunately some BC breaks. The BC breaks are all covered in the upgrade guide, but I would like to discuss them in greater detail to give you a better understanding why those changes happened:

While working with Zend Expressive, a PSR-7 middleware microframework, I wanted to apply some unit testing with a nice coverage to my middlewares. Middlewares are called by the __invoke method if you provide them as an object and not as a closure. The signature of the __invoke method looks like this:

As it turns out method_exists and is_callable work slightly different, and you might not be aware of it. I figured this out last year when I introduced protected methods in the config classes of bitexpert/disco. Recently I saw a similar issue in another open-source project and thought it might be a good idea to share my findings with the world.