Tutorials

Over the past few years, the Drupal community has been (sometimes slowly) embracing the Composer dependency manager tool for PHP projects. We have become accustomed to adding Drupal modules and base themes to our projects using composer require but many of us have only scratched the surface of what more Composer can do for us. In this article, we'll go step-by-step in adding a non-PHP dependency to our project using Composer - as well as the helpful Composer installers extender plugin. We'll utilize Asset Packagist, a Composer repository for many popular NPM and Bower assets including things like Javascript libraries

One of the primary goals of the upcoming Composer 2.0 release is decreasing the memory footprint and increasing the performance of common commands. I decided to test out the performance of the second alpha release of Composer 2.0 to see how much real-world change users can expect to see. tl;dr: Composer 2.0 will be much faster and use much less memory. Users can expect to see up to a 2x gain in speed in composer create-project commands, up to a 10x gain in composer require commands, and a over a 2x gain in composer update commands. On the memory side

This blog post was updated October, 2022 with new information about accessCheck, an example for loading fully populate node objects from entityQuery results, and the loadByProperties() method. The Drupal::entityQuery method has been a staple for Drupal developers since the early days of Drupal 8. But without a dedicated drupal.org Documentation page, it can be difficult for new developers to get a really good handle on. I've been using the QueryInterface API documentation for a few years now as my go-to source for help with using entityQuery, but a couple of weeks ago I stumbled on a feature of entityQuery that

Waaaaay back in 2013, I wrote a blog post about importing and mapping over 5,000 points of interest in 45 minutes using (mainly) the Feeds and Geofield modules. Before that, I had also done Drupal 6 demos of importing and displaying earthquake data. With the recent release of Drupal 9, I figured it was time for a modern take on the idea - this time using the Drupal migration system as well as (still!) Geofield. This time, for the source data, I found a .csv file of 814 lighthouses in the United States that I downloaded from POI Factory (which

As always-evolving Drupal developers, we have been in the process of moving towards having a Composer-based workflow for managing our Drupal project codebases. While it is (normally) an easy jump from "drush dl" to "composer require" for Drupal contrib modules and themes, there's another significant opportunity for us to take advantage of during this evolution that should be considered. We are all familiar with the concept that Drupal modules extend the functionality of Drupal site; we should also be embracing the fact that there is a whole class of Composer dependencies that extend Composer's functionality. These are appropriately called "Composer

If you use Drupal 8's configuration system, then you know that one of the trickiest parts of using it effectively is managing configuration on a per-environment basis. Luckily, the Config Split module makes it easy to manage different configurations in different environments, but how to set it up properly isn't always readily apparent. In this blog post, I'll provide one method for setting up Config Split in an efficient manner, with splits for local, remote development, and production environments. The goal is to be able to set things up right the first time, without having to worry about manually enabling/disabling

If you build Drupal 8 sites using the Drupal Composer/Drupal Project Composer template (DCDP), then you've likely noticed the development dependency webflo/drupal-core-require-dev. If you're like me, you probably didn't give it much thought the first 20 or 30 times you used the template. After a while though, I started to dig deeper into the details of DCDP, wanting to be able to understand exactly how it worked and what customizations I may want to make. DCDP was really my first real exposure to Composer, and the more I learned, the more I wanted to learn (as is often the case)

Version 1.9.0 of DDEV-local introduced the ability to share your local project online via a temporary, public URL using ngrok. This allows you the ability to quickly and securely provide access to your local site to other developers and stakeholders as well as an easy way to test your local site on other devices. ngrok is a service that exposes local servers behind NATs and firewalls via public URLs over secure tunnels. Once the small ngrok client is installed on your local machine, the ddev share command will enable the sharing and provide you with a public URL for your

Local development environments are in the midst a bit of a renaissance recently - mainly driven by the maturation and adoption of Docker-based solutions. I've been using (and recommending) DDEV for awhile now, and one of the things that I really like about it is the consistent pace of development. Since early February, there have been three minor releases of DDEV (1.6, 1.7, and 1.8). With each minor release of DDEV comes new, often very useful features. Here's just a few of my recent favorites: NFS Mounting One of the few disadvantages of using a Docker-based solution over a native

As someone who has been building Drupal sites for over 12 years now, I'd like to think that my knowledge and expertise has grown at a rate similar to the power, flexibility, and complexity of the Drupal project itself. For well over 10 years, Drupal training and development has been the focus of my consulting business; over the holidays I took some time to look back and really think about the lessons I've learned and how I can utilize them moving forward. In addition to documenting the process for myself as well as my current and future clients, I also

Over the past year or so, I've been looking to replace my standard local development environment with a Docker-based solution. I've been evaluating DDEV, Docksal, and Lando (listed alphabetically), trying to figure out not only was the best for me, but also the best for me to teach and recommend to the hundreds of folks I teach both long-form and full-day Drupal workshops to each year. As I've test-driven each of these three options, I've been periodically posting tutorials on various related topics. As a long-time Mac OS X user, my previous go-to local development stack has been a mix

Over the past several weeks, I've been working with three of the more well-known Docker-based local development environments that involve a Drupal focus: Docksal, DDEV, and Lando. The goal is to not only to figure out which one I prefer, but also to figure out which our two long-form online Drupal training classes should potentially standardize on. Our classes are often comprised of folks from all different technical backgrounds, so it is important that we not only teach them tools that Drupal professionals use, but also something that folks of myriad of skill levels can easily consume. Perhaps most importantly

Over the past few months, I've been test-driving various Docker-based local development environments with two goals in mind. First, as my "daily driver" for consulting work - I've been a long-time MAMP Pro user and I've been feeling for a long time that I need to modernize my local development tools. Second, I'm trying to figure out what is the most ideal local development environment for students of both our 12-week Drupal Career Online class (starts March 19) and our 6-week Mastering Professional Drupal Development Workflows with Pantheon (starts February 26) courses. One of the necessary skills for a professional

Over the past few months, I've been evaluating three Docker-based local development environments trying to figure out which is best not only for me, but also for students of our long-form Managing Professional Drupal Development Workflows with Pantheon (next semester starts February 17) and Drupal Career Online (March 26) classes. I've been test driving Docksal (actually, I've been using it for over a year), DDEV Community, and Lando (I'm a recovering Kalabox user) trying to figure out where the "sweet spot" is for flexibility, ease of use, documentation, Windows-compatibility (we routinely have students on Windows machines), performance, and some other

is a fantastic tool for helping to write Drupal 8 modules; of that there is little debate. Its "generate" functionality takes much of the pain out of setting up the scaffolding for many types of Drupal 8 modules, and in the process that alone saves developers a significant amount of time. When using Drupal Console, module developers usually don't have to worry too much about basic "use" statements, PSR-4 directory structures and file names, annotations, and much boilerplate code that is normally part of the development process. Here at DrupalEasy, we're such big fans of Drupal Console, we've designed our