Have you tried Composer Scripts? You DO not need Phing.

Have you tried Composer Scripts? You may not need Phing.” is a nice blog post showing how to use Composer scripts to solve simple build and deployment automation.  There’s plenty of good advice in there.

However I have one issue with it.  It’s the “You may not need Phing.” part.  Irrelevant of your use of Composer scripts, you DON’T need Phing.  Phing had its time.  It was one of the first build and deployment tools for PHP and it was better than all the alternatives at the time (manual builds, custom shell scripts, or tools from other programming languages).

Those days are long gone and we have better tools now.  If you are still using (or even considering using Phing), I beg you to look another way.  Check out Deployer.  Check out Robo.li.  Check other alternatives.  Don’t use Phing.

What’s wrong with Phing? Well, I can sum it up in one and one reason only.  It’s XML-based.  Yeah, that’s right.  Phing routes come from Apache Ant, which is a very common build tool for the Java world.  And Java world is full of XML.

In the year of 2018, we’ve figured out better ways.  Both JSON and YAML are better alternatives to XML for both humans and machines.  JSON and YAML are easier to read and generate.

Furthermore, even XML is not the most appropriate format for what Phing is working with.  Sure, as long as you can stick with the basic configuration of existing tasks and options – it doesn’t make much difference.  But at some point, you’ll need to extend and customize your build and deployment process.  And you’ll eventually end up writing PHP code using XML syntax.  And trust me, there is no fun in that at all.

Use PHP to write PHP code.  Use PHP tools for your PHP projects.  We have these now and they are great.  At work we are using Robo.li very extensively and it works amazing!  You don’t have to use it.  Pick whatever works for you.  But if Phing works for you, you’re probably doing something wrong.

Oh, and yes, Composer scripts are awesome too.  Try them out, if you haven’t already.

Let’s Encrypt now supports wildcard certificates

Here are some very exciting news from Let’s Encrypt:

We’re pleased to announce that ACMEv2 and wildcard certificate support is live! With today’s new features we’re continuing to break down barriers for HTTPS adoption across the Web by making it even easier for every website to get and manage certificates.

ACMEv24.0k is an updated version of our ACME protocol which has gone through the IETF standards process, taking into account feedback from industry experts and other organizations that might want to use the ACME protocol for certificate issuance and management some day.

Wildcard certificates5.1k allow you to secure all subdomains of a domain with a single certificate. Wildcard certificates can make certificate management easier in some cases, and we want to address those cases in order to help get the Web to 100% HTTPS. We still recommend non-wildcard certificates for most use cases.

Wildcard certificates are only available via ACMEv2. In order to use ACMEv2 for wildcard or non-wildcard certificates you’ll need a client that has been updated to support ACMEv28.5k. It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet.

Additionally, wildcard domains must be validated using the DNS-01 challenge type. This means that you’ll need to modify DNS TXT records in order to demonstrate control over a domain for the purpose of obtaining a wildcard certificate.

HTTP/2 Server Push with PHP

A few days ago I blogged about the exciting news from the Nginx about the support for HTTP/2 Server Push.  It’s good to see that this is getting picked up pretty fast.  Here are a couple of examples:

Mainstream support and implementation alternatives are not too far away, and that’s super exciting.