Lesser known CSS quirks & advanced tips

Lesser known CSS quirks & advanced tips” is a collection of some really weird CSS features and behaviors.  These are good to know, as sometimes they can shed some light on strange results or help with implementation of a particular design feature, where no other options are applicable.

200 universities just launched 560 free online courses

200 universities just launched 560 free online courses – this is a somewhat dated blog post – from a few months back, but I’m pretty sure the number of universities and courses is only increases with time.

If you haven’t heard, universities around the world offering their courses online for free (or at-least partially free). These courses are collectively called as MOOCS or Massive Open Online Courses.

In the past six years or so, close to 800 universities have created more than 8,000 of these MOOCs. And I’ve been keeping track of these MOOCs the entire time over at Class Central, ever since they rose to prominence.


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.

Updating WordPress with Composer and WP-CLI

The other day I came across this blog post by Mark Jaquith, who is one of the lead contributors to WordPress, in which he describes his process of updating WordPress plugins with WP-CLI and Git.  I think a lot of people these days are trying to use Git for version control and automate their deployments, so WordPress developers aren’t an exception, and Mark’s post is a useful resource for that.

With that said, however, I think there is a better.  At work, we’ve been dealing with quite a few WordPress-based projects, and automation of builds and deploys is very important to us.  So we’ve taken a different approach.

The initial inspiration for our approach was taken from this blog post by Scott Walkinshaw of the amazing Roots team.

Yes, that’s right, we use Composer to manage the WordPress, plugins and themes, both during the initial installation and the upgrades later.  But we’ve taken it a step further by also integrating the WP-CLI to our setup, which you can find in our project-template-wordpress GitHub repository.

I have oversimplified both the development and deployment process below, mostly for clarity.   (We do a lot more automation for our needs.)

During the development:

  1. Configure Composer to install WordPress into the webroot/wp folder.
  2. Configure Composer to install plugins and themes into webroot/wp-content folder. (Notice: we use a different wp-content folder location from the default WordPress one).
  3. Adjust wp-config.php for the new paths and drop it into the webroot/ folder.
  4. Add Composer’s vendor/ folder, and both webroot/wp and webroot/wp-content to .gitignore.
  5. Add all required themes and plugins to the composer.json.
  6. Run composer update to create or update the composer.lock file.
  7. Commit both composer.json and composer.lock, as well as .gitignore and any other files you modified.
  8. Add a WP-CLI script that automates activation of plugins and sets the current theme.
  9. Push your changes to the git repository.

During the deployment:

  1. Clone or pull the changes from the git repository.
  2. Run composer install to fetch and install specific versions of WordPress, plugins, and themes, from the composer.lock file.
  3. Run the WP-CLI script to finalize the installation or update with the plugin activation, theme selection, etc.

While it might look a little bit more complicated than what Mark and Scott described in their respective blog posts, I think this is a better approach for the following reasons:

  1. Use a specialized tool to solve each problem.   Git is great for version control, so that’s what it should do.  Composer is great for managing dependencies, and that’s what WordPress and its themes and plugins are for your project.  WP-CLI is great for automating WordPress tasks.
  2. Keep the git repository clean and simple.  When working on a project, we never ever modify the code of the WordPress or any of its themes or plugins.  And our setup enforces this approach.  If you need to change the WordPress source code for a particular project, you are probably doing something wrong.  If you need to change the plugin’s source code or the theme’s source code, you are probably doing something wrong again.  Instead create child theme or your own version of the plugin and install those with Composer, keeping the plugin or theme related code changes in a separate repository.
  3. Easily extendable and customizeable.  Git, composer, and WP-CLI are great tools and we love using them.  But the world is moving forward and there are constantly more and better tools to help with the complexities of the web development.  Our setup expands and extends to welcome any tools that we find useful.  For example, we have integrated with Robo, PHPUnit and PHP Code Sniffer, TravisCI, BitBucket Pipelines, and many other tools over time.  We’ve also said good bye to a few that became obsolete or to which we found better alternatives.

Anyways, project-template-wordpress works quite well for us and I hope you’ll find it useful.  Give it a try and let us know if you find any issues or improvements.   Pull Requests are welcome. :)

Oh sh*t, git!

Oh sh*t, git! is a collection of git problems, their solutions, and some explanations of how that happened and how to get out of it.

Git is hard: screwing up is easy, and figuring out how to fix your mistakes is f*cking impossible. Git documentation has this chicken and egg problem where you can’t search for how to get yourself out of a mess, unless you already know the name of the thing you need to know aboutin order to fix your problem.

money – PHP library to make working with money safer, easier, and fun

money is a PHP library that implements Martin Fowler’s design pattern for money.  See the official documentation and this blog post for more information.

Some of the issues addresses by this library are the binding of the money amount to the currency, and currency conversion operations.  If your code needs to deal with multiple currencies, you’ll definitely benefit from this library.  But even if you are dealing with a single currency, it’s still pretty handy, making the code more transparent and future proof.

Web Developer Roadmap

I’ve been saying for years, that there is no such thing as a “full stack developer”, no matter how many CVs your HR department processes per day, matching the title.  Web Developer Roadmap is a cool little GitHub repository, which maps the road for becoming a web developer in 2018.

It shows technologies that you need to get familiar with, depending on what kind of a web developer you want to become – front-end, back-end, or DevOps – and how to organize your learning and move from one technology to another.

The reason the “full stack developer” isn’t there, is, I’m sure, because that just combines all of the other ones.  And each one of them is way more than can fit into a single human head.  So the combination would probably make it explode.

Even if you are already an experienced web developer, this roadmap is a handy thing to keep around, as it gets updated as things change.  And in web development things do change, and they do so frequently.