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.
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.
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.
Note: This blog post is based on Drupal 8.1.x. It is an updated version of a previous tutorial based on Drupal 8.0.x. While the concepts are largely the same as 8.0.x, a refactoring of the core migrate modules took place in Drupal 8.1.x (migrations will become plugins in 8.1.x). This updated tutorial updates the previous example to work with Drupal 8.1.x, as well as demonstrates how to specify a migration group and run the migration with Drush. If you're familiar with the previous tutorial, you may want to skip to the "Rolling up our sleeves" section below.
Even if you're only casually acquainted with Drupal 8, you probably know that the core upgrade path to Drupal 8 has been completely rewritten from the ground-up, using many of the concepts of the Migrate and Drupal-to-Drupal migration modules. Using the Migrate upgrade module, it is possible to migrate much of a Drupal 6 (or Drupal 7) site to Drupal 8 with a minimum of fuss (DrupalEasy.com is a prime example of this). "Migrate upgrade" is similar to previous Drupal core upgrade paths - there are no options to pick-and-choose what is to be migrated - it's all-or-nothing. This blog post provides an example of how to migrate content from only a single, simple content type in a Drupal 6 site to a Drupal 8.1.x site, without writing any PHP code at all.
Note: This blog post is based on Drupal 8.0.x. While the concepts will remain the same in 8.1.x, the code examples will no longer be valid because migrations will become plugins in 8.1.x. See the updated blog post here.
Even if you're only casually acquainted with Drupal 8, you probably know that the core upgrade path to Drupal 8 has been completely rewritten from the ground-up, using many of the concepts of the Migrate and Drupal-to-Drupal migration modules. Using the Migrate upgrade module, it is possible to migrate much of a Drupal 6 (or Drupal 7) site to Drupal 8 with a minimum of fuss (DrupalEasy.com is a prime example of this). "Migrate upgrade" is similar to previous Drupal core upgrade paths - there are no options to pick-and-choose what is to be migrated - it's all-or-nothing. This blog post provides an example of how to migrate content from only a single, simple content type in a Drupal 6 site to a Drupal 8 site, without writing any PHP code at all.
Mapping address data in Drupal can be confusing, if only because of the great number of contributed modules available that involve online maps. Picking the right module (or combination of modules) is challenging - especially for site builders who are new to mapping in Drupal. In this tutorial, we'll utilize the popular and well-supported Geofield module as one of the key ingredients in the common task of entering address data and having it displayed on an interactive map.
This tutorial contains step-by-step instructions for accomplishing this task, as well as a screencast demonstrating all of the steps.
At Florida DrupalCamp 2013, I presented a session (video included) that demonstrated how to utilize the Feeds, Feeds Tamper, Address field, Geofield, and other modules to create a fully-functional website for searching for Farmers Markets anywhere in the United States. While the session's intent was to inspire people as to what Drupal can do in a very short amount of time, this blog post will focus on the details of the process.
I recently ran into an issue on one of our projects with a Git repository that stumped me for a few days. It was a small project: only three developers committing to a single repository hosted on Pantheon. I kept on running into an issue where I (or any of the other developers) could ever get my local repository to a “clean” state.
Doug Hercules (dhercjr on drupal.org) is a graduate of the 2012 class of the DrupalEasy Career Starter Program and currently working as an intern with DrupalEasy.
This week I was tasked with learning how to automatically close comments on a node two weeks after the node is created. We initially looked into a couple modules that did this well, Comment closer and Comment commander, but since neither is quite ready for Drupal 7, we decided this would be a good opportunity for me to learn more about the Rules module. Maintained by Wolfgang Ziegler (fago) and Klaus Purer (klausi), this module allows you to define actions that are triggered automatically on various Drupal events as they occur. This blog post will walk you through how I accomplished this task.
Doug Hercules (dhercjr on drupal.org) is a graduate of the 2012 class of the DrupalEasy Career Starter Program (http://drupaleasy.com/dcsp) and currently working as an intern with DrupalEasy.
This week I had the opportunity to clone a website from a git repository using Quickstart. Quickstart is a really quick, pre-made PHP Drupal development environment in a VirtualBox, which allows you to install a virtual machine to run Linux on your Windows PC. I've only gone through the process of cloning a site into Quickstart once before, and this time I thought I’d document it in my blog for myself and anyone else who might want to do this in the future. The general idea is this - there’s a site that I need to work on that is stored in a remote git repository. I want to get a copy of the site up-and-running inside Quickstart. To get started, I downloaded Quickstart, installed VirtualBox, then imported the Quickstart file into it.
Using Git to move the code base of a Drupal site from a local development environment to a hosting provider (or vice-versa) is a necessary skill that most Drupal site builders should have. Configuring and utilizing a remote Git repository can be an especially daunting task for people who don't have a strong background with version control systems.
How many times do you find yourself building the same bit of functionality on Drupal sites for various clients? Whether it be a photo gallery, multi-user blog, or slideshow, as Drupal site builders, we often find ourselves re-inventing the wheel. Personally, I’ve been asked to build slideshows on many client (and volunteer) sites that I’m involved with. Over the years, I’ve developed a recipe for a powerful and flexible slideshow that often exceeds the needs of all but the most particular clients. I recently added the ability for the slideshow to be responsive, and now seems to be a good time to share what I’ve done. At the end of this post, I’ve provided the slideshow as a Features that you can implement on your sites.
As part of a Drupal workshop that I'm teaching (the Drupal Career Starter Program), we've been discussing Acquia Commons. Our discussions led us to decide to have a local meetup specifically to learn more about it.
Since we expect a number of newbies at the meetup, I figured I post a quick video showing how to get Commons up-and-running using Acquia Dev Desktop. I found it to be a little bit tricky, mainly because the memory requirements for Commons are a bit higher than for core Drupal. The video shows how to tweak a couple of memory setting in the php.ini file.
NOTE: If you're using the Windows version of Acquia Dev Desktop, you can ignore the "apc.shm_size" change - it isn't used in Windows!