Quicktips

DrupalEasy Quicktips are short, focused posts intended to accomplish a very specific goal. Quicktips are exclusively available first via our @drupaleasy Twitter account.

Updating the DrupalEasy.com codebase to use Composer 2

After teaching folks how to use Composer effectively over the past couple of years, I figured it was time for me to (finally) update DrupalEasy.com to use Composer 2. I figured it would be a pretty easy process, and I was correct.

I've had a few people ask me about the process, so I thought I'd write up what it took to update this site to Composer 2. First a few facts about this codebase:

Drupal 8 and Composer - working with cloned dependencies

If you use the Drupal Composer Drupal Project template for managing your Drupal 8 site’s codebase, and you commit dependencies to your Git repository, then you’ve probably run into issues involving cloned dependencies. Sometimes when requiring a dependency via Composer, you end up with a cloned version (which includes a .git directory) instead of a release version. 

Layout Builder in core - first impressions

I recently decided to begin rebuilding the various landing pages on DrupalEasy.com using Layout Builder, introduced as a stable module to Drupal 8.7 core. Prior to this, the various landing pages on the site had been built using Paragraphs module.

While I appreciate what Paragraphs module can do as a layout tools for individual entities, I learned the hard way that perhaps it isn't the best tool for the job of building landing pages. 

Importing large databases to a Pantheon environment

Code flows up, data flows down.

I repeat this phrase in just about every workshop I teach - it is one of the basic principles of being a professional web developer. The idea is that we should be working locally, then pushing our changes (using Git) up to the project's dev, then QA, the live environments. As for the project's data (database and files directory for Drupal sites), the direction is opposite, we should only be moving data "down" - from live to QA, or live to dev, or live to local.

Automatic removal of .git directories from Composer dependencies

If you've adopted a Composer-based Drupal 8 workflow (hopefully using the Drupal Composer/Drupal Project template) where you're keeping dependencies in your project's repository, then you've no-doubt experienced the annoyance of a rouge .git directory ending up in one of your project's dependencies. This will always happen when you're using the -dev version of a Drupal module.