In a recent attempt to upgrade Disco to the latest version of ProxyManager I ran into this FATAL ERROR: "Declaration of Mock_ClassGenerator_f7ebad25::setExtendedClass($extendedClass): ProxyManager\Generator\ClassGenerator must be compatible with ProxyManager\Generator\ClassGenerator::setExtendedClass($extendedClass): Zend\Code\Generator\ClassGenerator" when I tried to execute the unit tests. It took me a while to understand the source of the problem, thus I think sharing the problem might help my future me and probably you as well. Let's assume you have two classes The_Parent and The_Child:
This blog post has been sitting on my desk for quite a while but due to a lot of work in the last weeks I was not able to finish it earlier. Luckily, I found some time during my travels to finish the blog post and share my findings on the "require-dev gone wrong!" problem. While some people thought the former blog post was mostly click bait or proposed a "fix" which does not actually solve the general problem, I actually got a lot of good feedback on twitter. Even an issue for Composer was created to discuss the problem even though it was closed by now.
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:
Yesterday, we released the stable version 2.0 of our Force Login Module for Magento 2. To upgrade, you can get the latest release here, or update the dependency in your composer.json.
For a long time, I have been advocating to make use of require-dev to install development tools locally. We use this on a daily basis to install tools like Phing, PHPUnit or phpDocumentor locally for each of our (customer) projects. Given that our focus is on custom projects, this absolutely makes sense. I do not want our projects to use an old version of a given tool or update all our projects constantly to use the latest version of all the tools involved. In addition to that, a simple composer.phar install in the project root should be sufficient to install all dependencies required to build and run the project.
Using the JMS serializer in recent project, I ran into the problem that the serializer does not support inheritance in a handler configuration. A handler is used to to change the serialization, or deserialization process for a single type/format combination.
In our "old" Jenkins set-up things were simple: The Jenkins master and Satis were running on the same host thus Jenkins could easily invoke Satis via a command-line call. Unfortunately GitLab does not allow that. The only option which is currently available in GitLab is to trigger Satis via a webhook. Neither Satis itself or Satisfy which we actually use provide support for webhooks. Thus we extended Satisfy with a simple controller which invokes the Satis cli command. Definitely not the best solution but it works for us.
A few months back I was looking for a HTTP reverse proxy and load balancer to put in front of our Docker setup. By accident I came across traefik. I deployed it on one of our internal servers and it worked out-of-the box. Recently we configured a Docker setup for one of our clients and I picked traefik again. Since this setup will host some public instances the customer demanded SSL encryption. Luckily traefik comes with support for Let's Encrypt built in. I added the needed configuration to the traefik configuration file:
Finally PSR-11 - the Container standard - got approved by the PHP FIG. To celebrate this fact I just merged a PR to make Disco PSR-11 compatible. The latest 0.8.0 release is compatible with the 0.7.0 relase. The only difference being that 0.7.0 relies on the container-interop standard and the 0.8.0 release relies on the PSR-11 standard.
Recently I was in the need to create multiple directories at once in my Dockerfile. Using bash as a shell the shell expansion feature comes in handy: