Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jul 04 2020
Jul 04

If you write custom Drupal 8 (or 9) modules, then you've probably used the entity QueryInterface - which is accessible from the Drupal::entityQuery() static method. If not, then you're missing out on this incredibly useful tool that allows you to easily query a Drupal site for entities of any kind. 

For example, if you are looking for all nodes of type Movie that have a Release year of 2009, you can do something like this:

$result = \Drupal::entityQuery('node')
  ->condition('type', 'movie')
  ->condition('field_release_year', '2009')
  ->execute();

But what if you want to base the condition on a value of a referenced entity? Maybe you want to find all nodes of type Movie where the director of the movie was born in 1981? Assume nodes of type Movie have an entity reference field to nodes of type Director, where one of the fields on the Director content type was Birth year. It's almost as easy to write an entityQuery condition for this situation as well:

$result = \Drupal::entityQuery('node')
 ->condition('type', 'movie')
 ->condition('field_director:entity:node.field_birth_year', '1981')
 ->execute();

Note the entity:node bit in the second condition - this is what allows you to access fields in the referenced entity.

Jun 28 2020
Jun 28
All US lighthouses on a map.

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 also appears to be a Drupal site). 

Starting point

First, start with a fresh Drupal 9.0.1 site installed using the drupal/recommended-project Composer template. Then, use Composer to require Drush and the following modules:

composer require drush/drush drupal/migrate_tools drupal/migrate_source_csv drupal/migrate_plus drupal/geofield drupal/geofield_map

Then, enable the modules using

drush en -y migrate_plus migrate_tools migrate_source_csv geofield geofield_map leaflet

Overview of approach

To achieve the goal of importing all 814 lighthouses and displaying them on a map, we're going to import the .csv file using the migration system into a new content type that includes a Geofield configured with a formatter that displays a map (powered by Leaflet).

The source data (.csv file) contains the following fields: 

  • Longitude
  • Latitude
  • Name
  • Description

So, our tasks will be:

  1. Create a new "lighthouse" content type with a "Location" field of type Geofield that has a map formatter (via Geofield map).
  2. Prepare the .csv file.
  3. Create a migration that reads the .csv file and creates new nodes of type "Lighthouse".

Create the Lighthouse content type

We will reuse the Drupal title and body field for the Lighthouse .csv's Name and Description fields. 

Then, all we need to add is a new Geofield location field for the longitude and latitude:

Geofield configuration

Next, we'll test out the new Lighthouse content type by manually creating a new node from the data in the .csv file. This will also be helpful as we configure the Geofield map field formatter (using Leaflet).

Mystic lighthouse
 

By default, a Geofield field uses the "Raw output" formatter. With Leaflet installed and enabled, we can utilize the "Leaflet map" formatter (with the default configuration options).

Leaflet formatter

With this minor change, our test Lighthouse node now displays a map!
 

Mystic lighthouse on a map!

Prepare the .csv file

Prior to writing a migration for any .csv file, it is advised to review the file to ensure it will be easy to migrate (and rollback). Two things are very important:

  • Column names
  • Unique identifier

Column names help in mapping .csv fields to Drupal fields while a unique identifier helps with migration rollbacks. While the unique identifier can be a combination of multiple fields, I find it easiest to add my own when it makes sense. 

The initial .csv file looks like this (opened in a spreadsheet):
 

CSV file before modifications

In the case of the lighthouse .csv file in this example, it has neither column names nor a unique identifier field. To rectify this, open the .csv as a spreadsheet and add both. For the unique identifier field, I prefer a simple integer field. 

Once manually updated, it looks like this:

CSV file after modifications

Create the migration

If you've never used the Drupal 8/9 migration system before it can be intimidating, but at its heart, it is basically just a tool that:

  • Reads source data
  • Maps source data to the destination
  • Creates the destination

Writing your first migration is a big step, so let's get started.

The first step is to create a new custom module to house the migration. First, create a new, empty web/modules/custom/ directory. Then, easily create the module's scaffolding with Drush's "generate" command:

$ drush generate module

 Welcome to module-standard generator!
–––––––––––––––––––––––––––––––––––––––

 Module name:
 ➤ Lighthouse importer

 Module machine name [lighthouse_importer]:
 ➤ 

 Module description [The description.]:
 ➤ Module for importing lighthouses from .csv file.

 Package [Custom]:
 ➤ DrupalEasy

 Dependencies (comma separated):
 ➤ migrate_plus, migrate_source_csv, geofield

 Would you like to create install file? [Yes]:
 ➤ No

 Would you like to create libraries.yml file? [Yes]:
 ➤ No

 Would you like to create permissions.yml file? [Yes]:
 ➤ No

 Would you like to create event subscriber? [Yes]:
 ➤ No

 Would you like to create block plugin? [Yes]:
 ➤ No

 Would you like to create a controller? [Yes]:
 ➤ No

 Would you like to create settings form? [Yes]:
 ➤ No

 The following directories and files have been created or updated:
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
 • modules/lighthouse_importer/lighthouse_importer.info.yml
 • modules/lighthouse_importer/lighthouse_importer.module

Then, let's create a new web/modules/custom/lighthosue_importer/data/ directory and move the updated .csv file into it - in my case, I named it Lighthouses-USA-updated.csv.

Next, we need to create the lighthouse migration's configuration - this is done in a .yml file that will be located at web/modules/custom/lighthouse_importer/config/install/migrate_plus.migration.lighthouses.yml

The resulting module's file structure looks like this:

web/sites/modules/custom/lighthouse_importer/
  config/
    install/
      migrate_plus.migration.lighthouses.yml
  data/
    Lighthouses-USA-updated.csv
  lighthouse_importer.info.yml
  lighthouse_importer.module

Note that the lighthouse_importer.module, created by Drush, is empty. 

While there are a couple of ways to create the migration configuration, we're going to leverage the Migrate Plus module. 

For more information about writing migrations using code or configurations, check out this blog post from UnderstandDrupal.com.

One of the big hurdles of learning to write Drupal migrations is figuring out where to start. It doesn't make much sense to write the migrate_plus.migration.lighthouses.yml from scratch; most experienced migrators start with an existing migration and tailor it to their needs. In this case, we'll start with the core Drupal 7 node migration (web/core/modules/node/migrations/d7_node.yml)

Let's break up the configuration of the new lighthouse migration into three parts: 

  • Everything before the "process" section.
  • Everything after the "process" section.
  • The "process" section.

Everything before the "process" section

Our starting point (d7_node.yml) looks like this:
 

id: d7_node
label: Nodes
audit: true
migration_tags:
  - Drupal 7
  - Content
deriver: Drupal\node\Plugin\migrate\D7NodeDeriver
source:
  plugin: d7_node

Let's update it to look like this:

id: lighthouses
label: Lighthouses
source:
  plugin: 'csv'
  path: '/var/www/html/web/modules/custom/lighthouse_importer/data/Lighthouses-USA-updated.csv'
  ids:
    - ID
  fields:
    0:
      name: ID
      label: 'Unique Id'
    1:
      name: Lon
      label: 'Longitude'
    2:
      name: Lat
      label: 'Latitude'
    3:
      name: Name
      label: 'Name'
    4:
      name: Description
      label: 'Description'

The main difference is the definition of the "source". In our case, since we're using a .csv as our source data, we have to fully define it for the migration. The Migrate Source CSV module documentation is very helpful in this situation.

Note that the "path" value is absolute. 

The "ids" section informs the migration system which field(s) is the unique identifier for each record.

The "fields" section lists all of the fields in the .csv file (in order) so that they are available (via their "name") to the migration. 

Everything after the "process" section

This is often the easiest part of the migration configuration system to write. Often, we just have to define what type of entity the migration will be creating as well as any dependencies. In this example, we'll be creating nodes and we don't have any dependencies. So, the entire section looks like this:

destination:
  plugin: entity:node

The "process" section

This is where the magic happens - in this section we map the source data to the destination fields. The format is destination_value: source_value.

As we aren't migrating data from another Drupal site, we don't need the nid nor vid fields - we'll let Drupal create new node and revision identifiers as we go.

As we don't have much source data, we'll have to set several default values for some of the fields Drupal is expecting. Others we can just ignore and let Drupal set its own default values.

Starting with the just the mapping from the d7_node.yaml, we can modify it to:

process:
  langcode:
    plugin: default_value
    source: language
    default_value: "und"
  title: Name
  uid:
    plugin: default_value
    default_value: 1
  status: 
    plugin: default_value
    default_value: 1

Note that we set the default language to "und" (undefined) and the default author to UID=1 and status to 1 (published). The only actual source data we're mapping to the destination (so far) is the "Name", which we are mapping to the node title.

One thing that is definitely missing at this point is the "type" (content type) of node we want the migration to create. We'll add a "type" mapping to the "process" section with a default value of "lighthouse".  

We have three additional fields from the source data that we want to import into Drupal: longitude, latitude, and the description. Luckily, the Geofield module includes a migration processor, which allows us to provide it with the longitude and latitude values and it does the dirty work of preparing the data for the Geofield. For the Description, we'll just map it directly to the node's "body/value" field and let Drupal use the default "body/format" value ("Basic HTML"). 

So, the resulting process section looks like:

process:
  langcode:
    plugin: default_value
    source: language
    default_value: "und"
  title: Name
  uid:
    plugin: default_value
    default_value: 1
  status: 
    plugin: default_value
    default_value: 1
  type:
    plugin: default_value
    default_value: lighthouse
  field_location:
    plugin: geofield_latlon
    source:
      - Lat
      - Lon
  body/value: Description

Once complete, enable the module using 

drush en -y lighthouse_importer

It is important to note that as we are creating this migration using a Migrate Plus configuration entity, the configuration in the migrate_plus.migration.lighthouses.yml is only imported into the site's "active configuration" when the module is enabled. This is often less-than-ideal as this means every time you make a change to the migration's .yml, you need to uninstall and then re-enable the module for the updated migration to be imported. The Config devel module is often used to automatically import config changes on every page load. Note that this module is normally for local use only - it should never be used in a production environment. As of the authoring of this blog post, the patch to make Config Devel compatible with Drupal 9 is RTBC. In the meantime, you can use the following to update the active config each time you make a change to your lighthouses migration configuration:

drush config-delete migrate_plus.migration.lighthouses -y  && drush pm-uninstall lighthouse_importer -y && drush en -y lighthouse_importer

Testing and running the migration

Use the migrate-status (ms) command (provided by the Migrate Tools module) to check the status of our migration:

$ drush ms lighthouses
 ------------------- -------------- -------- ------- ---------- ------------- --------------- 
  Group               Migration ID   Status   Total   Imported   Unprocessed   Last Imported  
 ------------------- -------------- -------- ------- ---------- ------------- --------------- 
  Default (default)   lighthouses    Idle     814     0          814                          
 ------------------- -------------- -------- ------- ---------- ------------- --------------- 

If everything looks okay, then let's run the first 5 rows of the migration using the migrate-import (mim) command:

$ drush mim lighthouses --limit=5
 [notice] Processed 5 items (5 created, 0 updated, 0 failed, 0 ignored) - done with 'lighthouses'

Confirm the migration by viewing your new nodes of type "lighthouse"!

If all looks good, run the rest of the migration by leaving out the --limit=5 bit:

$ drush mim lighthouses          
 [notice] Processed 804 items (804 created, 0 updated, 0 failed, 0 ignored) - done with 'lighthouses'

If you don't like the results, then you can rollback the migration using "drush migrate-rollback lighthouses" (or "drush mr lighthouses"), make your changes, update the active config, and re-import. 

Next steps

There's a lot more to the Drupal migration system, but hopefully this example will help instill some confidence in you for creating your own migrations. 

The "Leaflet Views" module (included with Leaflet) makes it easy to create a view that shows all imported lighthouses on a single map (see the image at the top of the article). Once you have the data imported, there's so much that you can do!
 

Jun 27 2020
Jun 27

Ashraf Abed, founder of Debug Academy and Drupal.tv talks with Ryan about the Debug Academy's long-form Drupal training. Also, Mike and Ryan take a trip around recent events in the Drupal Community.

URLs mentioned

DrupalEasy News

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Jun 20 2020
Jun 20

Composer logoAs 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 plugins".

Composer Plugins 101

If your Drupal project is using the drupal/recommended-project or drupal-composer/drupal-project Composer template (or similar), then you're already using Composer plugins. The second part of this article will surface some additional Composer plugins that you may want to consider adding to your Drupal codebase.

Adding a new Composer plugin is normally a two-step process. First, use "composer require" to add the plugin to your project. The second step usually (but not always) involves adding some plugin configuration to your project composer.json's "extra" section. 

For example, one of the dependencies of the drupal/core-recommended Composer template is the composer/installers plugin - this is how Composer knows to put Drupal modules in the modules/contrib/ directory and not in the (Composer default) vendor/ directory. 

If you were working on a project that didn't already use composer/installers, then you would need to add it to the project using

composer require composer/installers

Then, after reading a little bit of documentation, you would learn that in order for Composer to place dependencies of type "drupal-module" (as defined in the module's composer.json file) in your project's web/modules/contrib/ directory, you would need to add the following to your project composer.json's "extra" section:

"extra": {
    "installer-paths": {
        "web/modules/contrib/{$name}": ["type:drupal-module"],
    }
}

One other thing to be aware of when it comes to Composer plugins is that many (most?) plugins are able to run directly via a Composer command. For example, the drupal/core-composer-scaffold command (details below) can be run at any time via "composer drupal:scaffold". 

Side note: if I have one complaint about Composer plugins it is that often the plugin's vendor/name are not consistent with the plugin's defined key in the "extra" section (composer/installers vs. installer-paths). I would much prefer if the key was defined based on the plugin's vendor/name. For example, something like "composer-installers-paths" - this would make it easier for new users to recognize the relationship between plugins and data in the "extra" section, IMHO.

Useful Composer Plugins for Drupal projects

Must haves

composer/installers

  • Description: Allows dependencies to be placed in directories other than /vendor/. 
  • Availability: Included as part of drupal/recommended-project Composer template (via drupal/core-recommended), part of the default drupal-composer/drupal-project template.
  • Configuration key: installer-paths

drupal/core-composer-scaffold

  • Description: Places default Drupal scaffolding files outside of the /core/ directory and allows for modifications to scaffolding files.
  • Availability: Included as part of drupal/recommended-project Composer template, part of the default drupal-composer/drupal-project template.
  • Configuration key: drupal-scaffold

cweagans/composer-patches

  • Description: Automatically applies patches (both local and remote) to dependencies. 
  • Availability: Included as part of the default drupal-composer/drupal-project template.
  • Configuration keys: patches, patches-file, enable-patching, patches-ignore.

Worth considering

zaporylie/composer-drupal-optimizations

  • Description: Provides Composer performance boost for Drupal projects by ignoring legacy symfony tags. 
  • Availability: Included as part of the default drupal-composer/drupal-project template.
  • Configuration keys: composer-drupal-optimizations.

topfloor/composer-cleanup-vcs-dirs

  • Description: Automatically removes .git directories for cloned dependencies. Only necessary when dependencies are committed to the project's Git repository. 
  • Availability: Install as you would any other Composer dependency.
  • Configuration keys: None.

szeidler/composer-patches-cli 

  • Description: Companion plugin to cweagans/composer-patches that allows for the addition of patches (and other functionality) from the command line.
  • Availability: Install as you would any other Composer dependency.
  • Configuration keys: None.

oomphinc/composer-installers-extender

  • Description: Companion plugin to composer/installers that allows for any arbitrary package type (such as npm packages) to be defined and then handled by the composer/installers plugin.
  • Availability: Install as you would any other Composer dependency.
  • Configuration keys: installer-types.

joachim-n/composer-manifest

  • Description: Creates a simple "composer-manifest.yaml" file in the project root listing all dependencies (and their exact version numbers) currently used in a project.
  • Availability: Install as you would any other Composer dependency.
  • Configuration keys: None.

hirak/prestissimo

  • Description: Composer performance boost - enables parallel downloads of dependencies during Composer commands. Will not be necessary in Composer 2.x.
  • Availability: Install as you would any other Composer dependency.
  • Configuration keys: None.

Not necessary for experienced developers

drupal/core-project-message

  • Description: Allows text to be displayed after "composer create" and "composer install" commands have completed.
  • Availability: Included as part of drupal/recommended-project Composer template.
  • Configuration key: drupal-core-project-message

Am I missing any? If so, please let me know in the comments below. Thanks to everyone who responded to my Twitter post on this topic!

Want to learn more about Composer? Check out our Composer Basics for Drupal Developers workshop.

Jun 14 2020
Jun 14

When creating a Drupal 8 or 9 project using the drupal/recommended-project Composer template, you may notice during certain Composer commands that the scaffolding files are copied from an "assets" directory inside of Drupal's core directory to their proper place in the codebase. 

But, did you know that the plugin that manages this process, drupal/core-composer-scaffold, can be easily customized in your project's composer.json file to not copy some of the scaffolding files?

For example, if you don't want the core README.txt scaffolding file created, then all you need to do is add the following to the "drupal-scaffold" data of the "extras" section of your project's composer.json:

"file-mapping": {
    "[web-root]/README.txt": false
}

The syntax of the file-mapping is simply: "to: from". Meaning, copy the [web-root]/README.txt from "false" (nowhere). 

The power of the scaffolding plugin doesn't stop there - you can also add additional scaffolding files and modify existing ones, all automatically.

Want to learn more about Composer? Check out our Composer Basics for Drupal Developers workshop.

Jun 13 2020
Jun 13

Ted Bowman, Drupal core contributor and member of Acquia's Drupal Acceleration Team (DAT) talks about the Drupal.org Project Update Bot. Also, Michael Schmid, the CTO of amazee.io joins us to talk about their Drupal hosting solution, Lagoon, and how it fits in to a best-practice focused Drupal development workflow.

URLs mentioned

DrupalEasy News

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Jun 07 2020
Jun 07

The standard Drupal 8 block visibility page settings allow you to either include the listed paths (via "Show for all listed pages" or exclude the listed paths (via "Hide for all listed pages") - but you can never include and exclude at the same time. The Block Exclude Pages module provides a solution to this.

Consider the following situation: you have a block that needs to appear at all pages whose URL begins with "/about", with the exception of "/about/me". With just Drupal 8 core visibility rules, it isn't possible to easily make this happen.

With the Block Exclude Pages module installed and enabled, the following visibility rules can then be used:

/about
!/about/me

(Show for all listed pages" selected.)

The Block Exclude Pages module allows you to use the "!" character as a negation - problem solved!

Jun 07 2020
Jun 07

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 different "splits" depending on the environment. 

The key to it all is leveraging Config Split's ability to enable/disable individual splits with configuration in the settings.php file.

The first step is to set up your splits - I normally start by doing this on my local environment. Once Config Split is enabled, via the admin toolbar, head to Configuration | Development | Configuration Split Settings (/admin/config/development/configuration/config-split). Click to add a new split setting - in this example, we'll use the following settings:

  • Label: Local
  • Folder: ../config/splits/local
  • Active: (selected)
  • Modules: Complete Split: Devel, Devel Generate, Devel Kint, Reroute emails
  • Configuration items: reroute_emails.settings

Let's also add a second split - this one for remote development environments:

  • Label: Dev
  • Folder: ../config/splits/dev
  • Active: (selected)
  • Modules: Complete Split: Reroute emails
  • Configuration items: reroute_emails.settings

Note that we're not going to split out the Config Split configurations (meta, I know), rather we're going to allow the Local and Dev Config Split settings to be exported to the main /config/sync/ directory. 

Next, when exporting config, the following directories and files will be created:

/config/splits/local/
    reroute_email.settings.yml
/config/splits/dev/
    reroute_email.settings.yml
/config/sync/
    ...
    config_split.config_split.local.yml
    config_split.config_split.dev.yml
    ...

At this point, if we did nothing else, then both the "Local" and "Dev" splits would be automatically active all the time in all the environments and we really wouldn't have accomplished anything yet. 

The final step to make this all work is to add a couple of lines of code to each environment's settings.php file. For example, in the settings.local.php, add:

$config['config_split.config_split.local']['status'] = TRUE;
$config['config_split.config_split.dev']['status'] = FALSE;

Then, in the settings.php for the remote development environments, add:

$config['config_split.config_split.local']['status'] = FALSE;
$config['config_split.config_split.dev']['status'] = TRUE;

If you use a single settings.php for all environments, then you can use if-statements to determine the current environment and then enable/disable the appropriate splits. For example:

if ($env == 'local') {
  $config['config_split.config_split.local']['status'] = TRUE;
  $config['config_split.config_split.dev']['status'] = FALSE;
if ($env == 'dev') {
  $config['config_split.config_split.local']['status'] = FALSE;
  $config['config_split.config_split.dev']['status'] = TRUE;
else {
  $config['config_split.config_split.local']['status'] = FALSE;
  $config['config_split.config_split.dev']['status'] = FALSE;
}

With this type of Config Split setup, you'll always be able to immediately run a configuration import after pulling in new commits from the project repository without having to worry about manually enabling or disabling your splits. 
 

Jun 03 2020
Jun 03

Composer logoWe recently debuted our brand-new, 7-hour, live-instructor, online Composer Basics for Drupal Developers workshop to alumni of our flagship Drupal Career Online program. We've been gearing up for this launch for well over a year now, teaching select parts of the curriculum as part of Drupal Career Online, at various Drupal events as in-person workshops and presentations, as well as our own experience working with Composer with our clients. 

We believe that the result is the most complete and best-practice-focused Composer training available for Drupal developers today. (And a super-helpful 50-page reference document that comes with the course.) Not only does the workshop cover the absolute basics of Composer, but it also includes in-class examples of converting an existing site to using the new drupal/recommended-project dependencies, as well as how to handle Git code conflicts in composer.lock files.

We are thrilled with the impact the course has had based on our beta-testing of the workshop:

I've attended multiple DrupalEasy workshops and the Composer Basics workshop helps demystify the tool that can seem like a blackbox for so many developers. Mike is a great teacher. He makes sure to thoroughly explain and demo confusing topics so everyone understands the problem and the solution.
- Bo Shipley, May 2020 workshop participant

The material in the Composer Basics handout is thorough and a great standalone resource.
- Micah Burnett, May 2020 workshop participant

Understanding Composer is a necessity when working with modern Drupal, Mike makes everything clear and understandable so you can get out there and make something great.
 - May, 2020 workshop participant

This course will actually enable me to utilize composer in my daily workflow. Erased my fears of the unknown. 
- May, 2020 workshop participant

The first public offering of this workshop will be on Monday, June 15 from 1:30-5pm ET (part 1) and Tuesday, June 16 from 1:30-5pm ET (part 2). The cost is $250, but if you signup for our newsletter (via the form in the page footer below), you'll receive a 25% off promo code. 

The workshop includes the 50+ page PDF of the material. Topics covered in the workshop include:

  • What is a dependency manager?
  • Composer fundamentals
  • Creating a new Composer project
  • Autoloader basics
  • Using Composer with Git
  • Version constraints
  • Troubleshooting updates
  • Deconstructing the drupal/recommended-project template
  • Customizing Drupal scaffolding files.
  • Converting an existing Drupal 8 codebase
  • Dealing with code conflicts in composer.lock
  • Adding dependencies from private repositories
  • Helpful Composer plugins

Interested? Check out all the details and register today! Interested in a private workshop for your development team - contact us to make it happen!

May 31 2020
May 31

Ryan Price talks with Michael Meyers about Yjs (an open-source project that enables real-time, collaborative editing similar to Google Docs) and Goose (a load testing tool), after that, Mike Anello talks with Dane Powell about Acquia BLT.

URLs mentioned

DrupalEasy News

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

May 17 2020
May 17

We missed a week, but we're back with a super-sized retro episode where we talk with two of the original DrupalEasy podcast hosts! First, Andrew Riley drops by to cover some recent Drupal news and make some module picks-of-the week (including a Drupal logo memory game!) Then, Mike speaks with Ryan Price about feature flags - it's not a module, not a service, but rather a design pattern. Finally, Chris Weber also has some new change records for us.

URLs mentioned

The Change Notice

DrupalEasy News

Sponsors

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

May 17 2020
May 17
Congratulations image for DCO graduates

Last week, the 15th semester of Drupal Career Online concluded, and we're proud to announce 10 new graduates of the program! Congrats to Aida, Ashley, Avery, Carla, Jada, Kim, Matt, Micah, Tonderlier, and Tyler!

Drupal Career Online is a 12-week, live-instructor, online Drupal training program designed to teach best practices and sound fundamentals for Drupal developers. 

The course includes not only (virtual) classroom instruction, but also a number of other experiences designed to provide students with various opportunities to learn and practice the material. 

  • Community mentors - each student is (optionally) introduced a volunteer Drupal community mentor. The mentor and student decide how best to work together to achieve the student's goals. Thanks so much to this semester's mentor volunteers: Ofer, Doug, Adam, Philip, Andy, Brian, Albert, and Corey.
  • Office hours - each week during the 12-week class, in addition to 7 hours of classroom time, there are 4 additional (optional) office hours. These operate much like traditional college office hours; we open a Zoom room, student show up and ask questions, or just hang out and listen in on others. 
  • Screencasts - in addition to dedicated, produced screencasts for each lesson, every classroom period (all 3.5 hours) is recorded and provided to students as raw video. This way, if they have to miss class for any reason, they can watch the recording. Many students who attend class also take advantage of these videos to rewatch portions of class that they need additional practice with. 
  • Weekly activity reports and evaluations - both the students and the instructor provides weekly feedback. This allows us to ensure that each student is getting exactly what they need to succeed in the DCO. 

While the DCO has been around for over 6 years, that doesn't mean that our curriculum is stale. In fact, just the opposite - every semester, the curriculum is updated with the latest best practices. In the Spring 2020 semester, for example, lessons were updated to include the new drupal/recommended-project Composer template, our module development lesson was updated to avoid Drupal 9 deprecations, our class project was updated, and best practice layout tools were update (with more of an emphasis on Layout Builder). These ongoing curriculum iterations ensure our graduates are learning current best practices!

Perhaps the most important aspect of the DCO is the fact that our alumni have access to weekly, office hours - each and every week throughout the year. These office hours provide an opportunity for alumni to re-connect, ask questions when they get stuck, and sometimes just lurk to hear what others are asking about. We feel that it provides a level of comfort to our alumni - that we are as invested in their future as they are.

The next semester of Drupal Career Online begins August 31. Interested in learning more about it? Come to one of our free, 1-hour Taste of Drupal webinars where we'll tell you all about the DCO and you can ask any questions you may have. 

Jul 09 2019
Jul 09

AmyJune HinelineFrom Nursing to Open Source

It’s difficult to describe the amazing AmyJune Hineline’s impressive three year old Drupal Career without using a slew of adoring adjectives, since she really does embody everything great about Open Source technologies and the communities that support them.

It’s also difficult to concede that, as much as we’d like to take credit for her remarkable commitment, expertise and all of the goodness and light she brings to Drupal; Drupal Career Online (DCO) was indeed just a well leveraged tool that this very smart, insightful woman chose to help her along her path.

This path and her passion has led her to become the Open Source Community Ambassador for Kanopi Studios. She ensures that the Kanopi team maintains an active connection to the communities it serves, which include Drupal and Wordpress. "...This focus enables others to forge deep community connections that benefit the whole. I help communities discover how they can contribute back in more ways than code," she explains.

Kanopi designs, builds, and supports websites for clients that want to make a positive impact on the world: A great fit for the former hospice nurse and mother of two young adults. Part of her responsibilities also include creating dashboards for data visualization and performing accessibility audits, which also feeds her passion in the accessibility realm.

AmyJune helps to organizes events, is on the Drupal Core mentoring team and leads first time contributor workshops at regional and local DrupalCamps, and helps mentor attendees in general contribution spaces. It’s an impressive list of responsibilities, especially when you remember she has been at this for just 3 years.

Her early career route offers no clues as to how she arrived in this auspicious role in Open Source. She began with a college degree she did not use that led her into retail, then a sharp turn into Volkswagen repair. After having children, she rolled into nursing, focusing on hospice, and eventually earned a BS, and later picking up another degree, this one in Human Communication.

As a hospice nurse, she embraced her role as a guide for patients and families transitioning through the phases of terminal illness, but over time the work took a toll. The unexpected onramp to Drupal came after she did a bit of content entry on a Drupal site. She was intrigued, and decided to become a developer. “My colleague and mentor (loopduplicate) knew of DCO from DrupalEasy podcasts and Mike's (ultimike) presence in the Drupal community.” she recalls.

Coming into the DCO without much technical background, AmyJune had a lot more to learn than most students, which she quickly overcame. Mike recalls she took advantage of every possible resource full force. She worked closely with her mentor, was active in the weekly office hours/co-working labs and was truly engaged in every class session.

In addition to the classes and lab, she recounts she spent two to three hours a week, perhaps a bit more toward the end, outside of class to get the most of her education. Within a week after graduating, she was offered a paid internship at Kalamuna which led to her first full time position, and then on to a higher level gig with Hook42.

In her current position with Kanopi Studios, AmyJune also helps to organize camps and conventions throughout North America, with a focus on helping communities be more inclusive, as well as playing a mentoring role at events and beyond. These projects help her realize the gratification she drew from nursing. She explains, “...there is a feel good factor that comes when empowering others to get involved in Open Source projects. I love the smiles and reactions when someone I have mentored get theirs first credit or attribution. It feels good to help others feel good.”

As for her thoughts on Drupal Career Online, AmyJune is a big fan of the active and ever growing DrupalEasy Learning Community. "The continued support and mentorship is unbelievable. I love attending the weekly office hours...I like to hear what the other students are working on. Also I enjoy the camaraderie. (and sometimes the commiseration!)" She adds, "The relationships I have forged through the program have been valuable and essential to my growth as a developer."

"The trajectory of my career has been amazing," she reflects. "I started as an intern in programming, moved to a team's community lead, and now being an Open Source Ambassador for Kanopi allows me the time to be a Mentor and Drupal community lead in the camp organizer space…," she explains. Looking forward, she continues, "I would love to be able to move into a lead mentoring or diplomacy role involving accessibility and inclusion."

AmyJune’s advice to those looking to get into Drupal?

  1. Find a good mentor. Always ask questions. Never stop asking. Every great Drupaller was once a beginner.
  2. Share what you know. You will always know more than someone else, and when helping others with something you don't know, you can always figure it out together.
  3. Trust in yourself. Imposter Syndrome is a bitch.

As a developer, AmyJune admires patience and humor in the other developers she works with. "Developers who are patient are good collaborators and mentors, and being able to laugh and joke makes the day-to-day work flow so much easier," she explains.

You can follow AmyJune at volkswagenchick, on Twitter @volkswagenchick, and learn more about some of the Projects she is working on:

  • A11yTalks- a monthly online meetup dedicated to promoting community discussions on a variety of accessibility issues.
  • BADCamp (Bay Area Drupal Camp) - the largest free Drupal Camp in North America.
  • WordCamp US

The next session of Drupal Career Online will be launching new careers beginning August 26th. If you’d like to learn more about this 12-week certificate program, you can attend one of DrupalEasy’s no-cost Taste of Drupal mini webinars, or visit DrupalEasy’s Drupal Career Online page. You can also contact me at [email protected]

Jun 01 2019
Jun 01

AmyJune Hineline, Open Source Community Ambassador at Kanopi Studios joins Mike Anello to talk about her upcoming Contribution Tour 2019, as she visits numerous Drupal and WordPress events to help train new contributors.

Discussion

DrupalEasy News

Upcoming Events

Sponsors

  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Apr 01 2019
Apr 01

Get ready for your trip to Seattle with this April Fool's Day special episode of the DrupalEasy Podcast.

Drupal Fools

a Dr. Seuss joint (sortof)

From the top of your head to the tips of your toes,
You are a Drupaller, everyone knows.

You think about Drupal all day and all night.
You’re more than obsessed with getting things right.

Your Views and your Fields and your Content Types,
Simply scream “Drupal!” here are some reasons why:

Your User Experience is so Steve Jobs-esque
Your Splash Awards medals are spilling off your desk!

Your API documentation site,
Lets your developers get sleep at night.
You’re well known to eat your own dog food.
When you’re done with work you’re still in a good mood.
And why not? Your patches have all been applied,
The hackers can’t get in, and they even tried!

I heard a rumor at DrupalCon Seattle,
That your coding standard leaves code reviewers rattled.
Before you go saying that I must be kidding,
Know that I suck a peek, I did some digging…
I couldn’t find one curly brace out of place,
One line break too many or one poor stack trace.

Have you ever noticed just how our community
Is one of the best at promoting unity?
We’re very good at giving hugs,
Especially to those who have fixed our bugs.
But if you’re not a fan of physical affection,
We don’t make a big deal of your objection.
(We’re still glad you chose to sit in our section)

Like Birds of a Feather or a Business of Ferrets,
The Drupal community celebrates merits.
Even if you don’t pretend to know code,
Your contribution deserves to be showed.
Webchick will help you, as luck would have it,
When your first core improvement is ready to commit.
(Stick around until Friday, and you won’t regret it)

And if this is your first time at DrupalCon...

Did you know that Drupal is eighteen years young?
We’re just getting started, we’re still having fun!
Of all websites, we’re say, five in a hundred,
The more ambitious ones are quite well funded,
But even for NGOs our scopes are not blunted.
We’ve got thousands of community projects,
To extend, integrate, and meet all of your specs.
Even if you don’t speak like a geek,
I’m sure the vendors won’t judge you like some kind of freak.
They’ll help you translate the Greek, so to speak.

If this is your first event, or your hundred and first,
We welcome you to dive in to Drupal head first.
Bring us a challenge, we’ll find you a guru,
As long as you understand our Kool-Aid is blue.
(We do have other interests besides Open Source,
We’re human aren’t we? Why yes, of course!)

Have you met Dries Buytaert? He’s the project’s creator.
Without him, I might be a Red Lobster waiter.
He’s tall and Belgian, well over two meters,
(Not that I’ve measured him, that would be cheating),
He’s the lead of this project and he helps set the agenda
To give us some staying power and stay just a bit trendy.
There are really so many others to thank,
Given ten thousand thank you notes, none would be blank.
It takes a village, at least that’s what I think.

So welcome to the land of rainstorms and coffee,
Of mega-giant software companies,
To DrupalCon Seattle, it’s like my family reunion.
Think Digital. Be Human.

DrupalEasy News

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

11 Tips to start your Drupal 8 project right

Feb 05 2019
Feb 05

DrupalEasy Podcast 215 - Kaleem Clarkson - Drupal Event Organizers Working Group

Feb 04 2019
Feb 04

Make 2019 the Year of Drupal Talent Development

Jan 30 2019
Jan 30

DrupalEasy Podcast 214 -Travis Carden - Drupal Spec Tool

Dec 20 2018
Dec 20

DrupalEasy Podcast 213 - Ted Bowman - Layout Builder in Core

Dec 17 2018
Dec 17

Automatic removal of .git directories from Composer dependencies

Dec 09 2018
Dec 09

DrupalEasy Podcast 212 - Commerce Guys: decoupling and roadmap with Bojan Zivanovic and Matt Glaman

Dec 03 2018
Dec 03

New book: Local Web Development with DDEV Explained

Nov 17 2018
Nov 17

Drupal 8's Allowed Formats module

Sep 22 2018
Sep 22
Sep 22 2018
Sep 22

Debugging a Drupal 8 module can take many forms. Often, one of the first tools most developers use is the ability to output variables using the "Devel Kint" module (part of the Devel project). Much like the dsm() function from pre-Drupal 8 versions of Drupal core, the ksm() function provided by Devel Kint provides a slick way to output any variable type to the screen in a readable way. 

Unfortunately, many folks find Kint output to be a bit more cumbersome, and they're right, but Kint is doing a whole lot more than dsm() ever did. In addition to outputting just the variable's values, if said variable is an object, then Kint also outputs that object's methods and other valuable debugging information. Unfortunately, all that information comes with a cost - it tends to really bog down web browsers.

I was finding that some large variables in Drupal core ($form and $node, I'm looking at you) could even crash my browser (out of memory) due to the sheer depth of information returned by a simple ksm(). Out of desperation, I searched for a way to tame Kint a bit so that I could go about my debugging business.

Luckily, I stumbled upon this gist by Julian Pustkuchen which demonstrated how to limit the number of levels returned by a ksm() call. This solved my problem - no more browser out-of-memory issues. The downside is that sometimes a ksm($form) call doesn't get me deep enough into the array, so I have to be a bit more specific when ksm-ing. 

I took Julian's gist and dropped it in my settings.local.php file as follows:

include_once(DRUPAL_ROOT . '/modules/contrib/devel/kint/kint/Kint.class.php');
if(class_exists('Kint')){
  // Set the maxlevels to prevent out-of-memory. Currently there doesn't seem to be a cleaner way to set this:
  Kint::$maxLevels = 4;
}
Sep 22 2018
Sep 22

I've been a big fan of Drupal 8's configuration system since the beta-days of Drupal 8, and even more so now as the contributed module ecosystem around it has matured. I've been using the Config Readonly module from the very beginning to "lock down" configuration on production environments in order to help enforce developer workflows. 

Using the Config Readonly module is a bit of a double-edged sword. On one hand, it really helps in helping get developers accustomed to making configuration changes on local, then exporting them using Drupal 8's configuration system, committing them to the repository, and then moving them up through the project's defined deployment workflow.

On the other hand, sometimes it just really gets in the way. Two areas where I find that clients really find Config Readonly annoying in the live environment is when configuring menu items and block placement, both which can be affected by locked-down configuration. When the Config Readonly module is active, it is not possible to drag-and-drop menu links to reorder them. Nor is it possible to place a block or move a block to a new location.  

Luckily, the Config Readonly module maintainers added the ability to "whitelist" some configurations in version 8.x-1.0-beta3. This allows developers to keep certain configurations "unlocked" on the live environment via the settings.php file. For example:

if (IS_LIVE_ENVIRONMENT) {
  $settings['config_readonly'] = TRUE;
  $settings['config_readonly_whitelist_patterns'] = [
    'page_manager.page_variant.*',
    'system.menu.main',
  ];
}

In this code snippet, all Panel page variant configuration as well as the main menu are whitelisted, allowing site authors to modify these aspects of the site directly on the live environment.

Sep 22 2018
Sep 22

I ran across a situation the other day that had me a bit frustrated for a few minutes until Ted Bowman nudged me in the right direction. I was working on a small custom module for a client - one that involved altering a node form using hook_form_alter() - where I needed to know the value of the node ID being edited.

I had spent more than a few minutes digging into both the $form array and $form_state object desperately looking for the node ID, to no avail. I had pinged Ted on Slack about something else and I asked him if he knew how to find what I was looking for - he told me "maybe the form object is better".

That's all I needed to get unstuck, a few minutes and a Google search or two later, I stumbled upon the following:

$form_state->getformObject()->getEntity()->id()

Not only would this return the node id, it will actually return the id for any type of entity.

Just to be safe, I went ahead and wrapped it in a if-statement to make sure that the form object returned is actually an entity form:

if ($form_state->getFormObject() instanceOf EntityFormInterface) {
  $nid = $form_state->getformObject()->getEntity()->id();
}
Aug 13 2018
Aug 13

Drupal Career Online Case Study: Rosewood Marketing

Like their arboreal namesake, Rosewood Marketing is amazingly sound and particularly suited for very specific applications. Where the Rosewood tree serves to form the structure of certain fine musical instruments, billiard cues and chess pieces, Rosewood Marketing serves as a bridge for dozens of Amish and Mennonite small businesses to mainstream society. Their growth and development over the 22-year span of their success is not just in their marketing prowess, but in their inherent, sincere understanding of their client culture.    

If you really think about it, Rosewood has perhaps one of the most focused and secluded market segments in the US, which interestingly enough allows them to bring a type of diversity to the Drupal Community we don’t often consider. They do this amazingly well in their approach to business development and hiring. They first truly match new employees to their market and their company culture, and then leverage training programs to ensure the team has the skills and best practices in technology and communications to meet their business standards.  A person hired as a graphic designer receives training in tools such as Photoshop, InDesign, design principles and customer service. An online marketer receives training in analytics, SEO, and PPC, while a new manager learns time management.

Others become web developers, and as our luck would have it, DrupalEasy students and graduates. Of Rosewood’s 16 member staff, two are Drupal Career Online graduates and one new hire has just been enrolled in the upcoming Fall 2018 session.  Our new Rosewood student already has experience in Drupal 7, but needs to move forward in Drupal 8. Adrian Nolt, a 4-year employee of Rosewood and a Fall 2017 DCO graduate, explains, “Even though Stephen has...Drupal site-building experience, I recommended that he take DCO in order to acquire a common training foundation as our other Drupal developers...For me as a primarily self-taught Drupalist, DCO filled in knowledge gaps, and I would like for Stephen to experience the same joy.”

Stephen Ebersole, who was hired recently, works remotely for Rosewood, with his primary residence in Georgia, and currently living in Honduras serving his church. He, like most Rosewood employees, is a member of a Mennonite community.  Adrian explains, “Since Rosewood's target market is businesses run by members of the Plain Communities...besides the native understanding of our target market, we feel that while Drupal may be hard to learn, it is easier to pick up than people skills and a solid work ethic.”  

Adrian highlights the importance of this native understanding by explaining, “Many members of the Plain Communities are devout Christians with strong convictions...If a Rosewood team member does not...appreciate why his or her client will, for example, give up internet access in order to free himself from unnecessary temptations, he or she will not be able to make recommendations that align with our client's values. This understanding is more important to our ability to serve our clients well than expertise in a specific technology.”

Adrian continues, “...as soon as an employee has sufficient proficiency to perform basic tasks, he or she begins working on paid work, even if it means billing our clients at a reduced shop rate for a time. We believe that learning by doing is one of the most efficient ways to learn..though... can leave holes in a person's knowledge. For some of us, taking DrupalEasy's DCO course is about filling in the gaps and providing a common foundation for working together. However, it is also one of the fastest ways I know to get a Drupal beginner up to speed and productive with Drupal.”

The team at Rosewood has used video courses, but they have found for their purposes,  says Adrian, that “...many are too basic or not opinionated enough to apply to most real-life Drupal development practices.” He continues, “For example, they may teach installing Drupal 8 from a tarball, but we had already committed to a composer-driven workflow for Drupal 8 as the safest long-term bet, and I was looking for a course that teaches a professional development workflow. DrupalEasy DCO has proven to be the well-rounded, just-deep-enough training we were looking for, and as long as Drupal remains one of our specialties, we expect to consider it as part of our Drupal training regimen.”

Adrian feels the most valuable aspects of the DCO include clarifying the intersections of fields, blocks, entity types, content types, and relationships, which he says can be an "ah-ha" moment to someone just getting started. He also appreciates becoming familiar with command-line, git, local development, and views, as it is a must for success in Drupal 8, which he feels is a huge hurdle for those getting started. He adds “...the value of DCO lies in how it connects all the pieces, such as workflow, data architecture, module development, theming, and the business of Drupal, together into one comprehensive introduction to the Drupal ecosystem.”

Rosewood’s clients are primarily in the agricultural industry, or are builders, retailers, craftsmen, and small manufacturers, including small businesses such as  Vierbike, MM Weaver and Blue Ridge Furniture. The company is now going with other CMS options for simpler sites, but Adrian emphasizes,  “Drupal continues to excel at use cases that require structured data and over 30 pages. We feel that having Drupal in our tool bag allows us to provide outside-the-box marketing solutions to our clients simply by combining modules and configuring the user interface. On other platforms, competitors may need to resort to custom code or make compromises in order to use an out-of-the-box solution.”

As far as their training philosophy, that is evolving as well, according to Adrian, “In the past, we prescribed training when a person was hired or when they needed to learn something new. However, we have begun budgeting training dollars and time into our annual budgets in order to continually grow as professionals and as a company.” He continues, “Hiring and training people is a way to scale our service-based business to serve more clients. Continued education adds to our in-house skill set to allow us to serve them in more ways and more efficiently. Happy clients = successful Rosewood.” He adds, “We don't know the future, but judging by the past, we will continue to hire and train employees.”

The Fall 2018 session of Drupal Career Online starts September 3rd.  Group rates and government discounts are available. If you‘d like more information, join us for our no-cost mini-webinar Taste of Drupal on Monday, August 27.  

Jul 22 2018
Jul 22

A Drupal Career Online Case Study

Lisa StreeterA lack of off-the-shelf eCommerce software products that could meet the unique needs of her family’s biotech manufacturing company was a real issue for Lisa Streeter. “We’re not a big enough company to afford large, custom database solutions, so we needed to figure out how to do everything in-house,” she explains. (Lisa’s work responsibilities included everything computer-related, and “some other stuff.”) That’s how it started, but instead of just a solution, Lisa Streeter wound up with a whole new, fulfilling career.

Her initial quest for a database solution quickly began to grow her fascination in web development (primarily eCommerce,) and lessen her interest in the family business. “I like the idea that in web development, you’re actually building something, architecting information rather than just analyzing it,” she explains. She fine-tuned her focus, and after discovering Drupal, began to seek an effective way to become proficient.

“I don’t remember exactly how I first learned about Drupal Career Online. I didn’t know anybody who did anything with Drupal, so in the beginning I was just trying to figure out how I could learn Drupal," she explained. She tried some self-teaching methods, but those were not providing her a clear and effective path forward. DrupalEasy was regularly popping up in Google searches and referenced on sites like Drupal.org. “Early on it made my short list of potential “good places to learn Drupal” and then it was just a matter of finding the right time,” she recalls.

It turned out the time was the Fall 2017 session, and according to Lisa, that’s when her interest took a fast track, “I started really getting Drupal. It was a transformative experience.” She dove into the curriculum, participated in class, and DrupalEasy matched her with Matt Glaman from Commerce Guys as her mentor.  From there, her path became clear and direct. “DCO was just the right level of time commitment and intensity for me. It demanded enough of my time and effort to really accelerate the pace of my Drupal learning,” she explained. “At the same time, while I needed to give the class my full attention, it didn’t completely take over my life like going back to school full time would have,” she added.

Lisa has far exceeded our expectations as a developer hired with no previous Drupal experience. The discipline and experience she developed as a PHP developer transferred directly to Drupal development under the tutelage of DrupalEasy, and she's already making a huge impact in our team and community.

-Ryan Szrama, Commerce Guys

The online, live instruction by an expert in Drupal and training was a great fit for Lisa. “Mike is an exceptional teacher who helped me really “get” what Drupal is all about, how to do things and think about solving problems in the “Drupal way.” This was something I wasn’t able to learn on my own from books, screencasts, or trial-and-error,” she recalled.  She also appreciates the small class size and Mike’s personal commitment to everyone enrolled. She explained, his “personal interest in getting to know every student individually made the class seem tailor-made for me, even as I could see that it was also meeting the needs of my classmates in different ways,” she continued.

Mike Anello, (@ultimike) has been a part of the Drupal project for more than 12 years, and developed and has been delivering Drupal career training since 2011 via live in-person and online sessions and contracted programs with organizations needing to train their development teams in Drupal. His curriculum has become the model for the development of several other long-form training programs. He keeps alumni connected and engaged in learning through the DrupalEasy learning community, which evolved from his weekly online office lab hours. According to Lisa, “When you take the DCO course, you definitely feel like Mike is personally invested in the success of each and every student.”

With her interest in eCommerce in mind, Mike connected her with mentor Matt Glaman, a Drupal project maintainer and one of the Commerce Guys.  “For me, this resulted in a perfectly matched mentor, one who challenged me to tackle harder problems than I would have thought possible,” she said.  Matt recognized Lisa’s passion and talent, shared his insights with Commerce Guys partner Ryan Szrama, and then according to Lisa, “It all happened pretty quickly! “ The DCO ended just before Christmas, and she was offered a position on January 16th.

This fast track is a result of Lisa’s passion and Commerce Guys confidence in her abilities and training. She explained, “Ryan decided that he’d rather not hire me as a “Junior Developer”, even though there was an expectation that I’d be learning and working to improve my Drupal skills. Instead, I was hired as a “Drupal Developer,” with the understanding that I’d take responsibility for my own progress.”  It appears she has done just that, since in addition to serving as a developer, she recently was given the opportunity to be “Documentation Lead” (in addition to continuing dev work.)

Six months into her new career, Lisa is clearly fulfilled.  She recounts, “Before I started at Commerce Guys, I was worried about whether I could really handle a real, professional job (working for someone other than my family) while also being a stay-at-home mom.  But Commerce Guys has been a perfect fit in that respect. Many of my coworkers also have young children - everybody at Commerce Guys has been very gracious and understanding about my time.”

Commerce Guys is equally thrilled with Lisa. According to Ryan, "Lisa has far exceeded our expectations as a developer hired with no previous Drupal experience. The discipline and experience she developed as a PHP developer transferred directly to Drupal development under the tutelage of DrupalEasy, and she's already making a huge impact in our team and community."  Commerce Guys is still in hiring mode, looking for "...people who align with our company's core values and core focus. We value making an impact, taking initiative, and serving our customers with integrity. We focus on solving hard problems (our passion) within the eCommerce space (our niche,)" Ryan added.  

In addition to her documentation responsibilities, Lisa is currently doing site building, writing custom code and site administration. She also works on Drupal Commerce and related contrib module issues. “I write patches, including automated test code. Someone from the team reviews my code and gives me helpful feedback, which is also a really great way to learn and improve my coding skills, with the bonus that I’m directly contributing to the Drupal community,” she explains.

“The best part about my new career is that I have a “career.” For years, I’ve had an ambiguously defined job at my family’s company. I didn’t report to anybody, and nobody reported to me; I just “fixed” lots of random problems...I had to invent my own job title. So being able to say now that, “I’m a web developer” is pretty awesome!  

She also loves being part of a team, she explains “After so many years of working independently, it’s great to have job that involves a lot of collaboration, especially when the people I work with are so talented. And being part of the Commerce Guys, an organization that strives to make an impact with the software it creates, I have a sense of greater purpose.”

Even with all of her success, she highlights that she is still learning.  “In DCO, Mike talked about how he’s continually working to improve his own skills and how that’s something you need to enjoy doing to succeed as a web developer. I’m finding that to certainly be true for me. It’s just a really good feeling to be able to look back a month or 6 months and see how much I’ve learned and improved since then,” she explains.

The next session of Drupal Career Online starts September 3. Learn more at an upcoming Taste of Drupal free mini webinar, and check out our career resources for information on web developer and Drupal-specific careers. 

Jul 09 2018
Jul 09

Book cover: Local Web Development with DDEV ExplainedLocal Web Development with DDEV Explained, by Mike Anello, now available on amazon.com!

Looking to move to a professional local development environment? Learn how to use DDEV for your everyday development work with numerous step-by-step examples including installing DDEV, getting an existing Drupal site up-and-running, adding a Solr container, and everyday DDEV commands and workflows.

Only $5.99 for a digital copy and $9.99 for the dead tree edition - pick up your copy today!

Jul 04 2018
Jul 04

Quote: Great hands on intro...We're happy to announce that we've partnered with the folks at DRUD Tech to create and deliver a live, online, hands-on workshop that will teach the basics of professional local Drupal development using DDEV-Local.

DDEV-Local is a Docker-based local development environment that is designed to get your projects up-and-running quickly on your local development machine. DDEV-Local can be used with Drupal 7 and 8 as well as WordPress and other content management systems.

One of the big advantages of using this type of local development environment (as opposed to an old-school WAMP/MAMP-type solution) is that DDEV helps to ensure that every member of the development teams is using the exact same development environment, increasing productivity and decreasing the chances of environment specific bugs. Furthermore, you'll find that getting team projects up-and-running on your local machine is super-fast!

If you've been reading our recent blog posts or listening to our podcast, then you probably already know that we've taken a keen interest in local development environments lately. 

In fact, we've been diving deep into local development environments for almost a full year now, as we're in the process of evolving our long-form training classes to teach and utilize a more professional local development environment solution. A couple of months ago, we decided to standardize our trainings on DDEV, and since then we've been talking with the DRUD Tech folks (the creators of DDEV) about putting together a workshop that will provide students what they need to get up-and-running with DDEV-Local.

Here's a quick overview of what this new workshop will cover:

  • What is DDEV? 
  • Installing DDEV-Local (Mac OS X and Windows 10 Pro)
  • Getting an existing project up-and-running in DDEV-Local
  • Everyday DDEV-Local commands and functionality
  • DDEV-Local integration with hosting providers  
  • Updating DDEV-Local
  • DDEV-Local Tips and Tricks
  • Getting help with DDEV-Local

The first workshop will take place on Wednesday, July 18, 2018, 1-3pm EDT, and the cost is $75. Following the completion of the workshop, you'll have access to the 20+ page curriculum PDF as well as more than 10 screencasts demonstrating installation and basic usage of DDEV-Local. 

Register today and start using a professional local development environment!

We’ll be running the workshop monthly, so If you can't make it on July 18, upcoming dates include: 

  • Wednesday, August 22, 2018, 10am-noon EDT
  • Wednesday, September 19, 2018, 9-11am EDT

Quotes on this page were shared by participants in our beta-test of the course

Quote: Mike consistently ensures...
 

Jun 18 2018
Jun 18

Stefanie Gray, (stefaniegray), Engineer and Open Data Specialist for CivicActions joins Mike Anello to discuss all things DKAN.

Interview

DrupalEasy News

News

Sponsors

  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

May 27 2018
May 27

This summer, we're taking the all-new "Upgrading your local development environment with DDEV" lesson from our 12-week Drupal Career Online class and bringing it with us as we visit three different Drupal events around the USA. At each event, we'll be presenting it as a full-day workshop at no- or (very) low-cost to event attendees.

Twin Cities Drupal Camp, Asheville Drupal Camp, Colorado DrupalCamp logos

If you're looking to move your local development environment to a more modern solution, then we believe this workshop is exactly what you're looking for. DDEV is a Docker-based environment built on modern principles and designed to be flexible, customizable, and powerful. 

We have been using DDEV with our current Drupal Career Online students, and are confident that our workshop is providing the skills they need to use it as their day-to-day local environment. The workshop (and DDEV) is designed for developers on Mac OS X and Windows 10 Pro - at the end of the day, you'll have the confidence you need to make the switch.

In addition to the full-day of training, you'll also leave with access to our 20+ page workshop handout (PDF) as well as access to all of our DDEV-related screencasts.

So, if you're interested in making the change, be sure to sign up for one of our in-person workshops this summer!

May 19 2018
May 19

Have you ever been building a form and found yourself wishing that you could insert additional help text - or even other forms of content (images, video) inline with the form? While each field's "Description" field is useful, sometimes it isn't enough.

The Markup module solves this problem in an elegant way by providing a new "Markup" field type.

Markup field type

This field doesn't expose any input widgets to the end user, rather it just allows for site builders to add additional markup (content) to an entity form.

Editing a Markup field.

The markup isn't saved with the resulting entity - it's just there to provide additional information to the user filling out the form.

Granted, this has always been possible by writing a small custom module utilizing hook_form_alter(), but having it as a field type makes it much more convenient to use.

Apr 24 2018
Apr 24

Ted Bowman and Mike Anello, both back from DrupalCon Nashville, spend some quality time together to catch up on all the latest happenings involving local development environments. Ted hosted some BoFs about the topic, and Mike posted a comparison of some of the more popular Docker-based, Drupal-focused local development tools, so we figured it was a good time to devote an entire podcast on the topic. In addition, Mike and Ted name their "favorite thing" from DrupalCon Nashville.

Discussion

Sponsors

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Apr 23 2018
Apr 23

With Drupal 8, the use of view modes (both default and custom) is gaining momentum. This is especially true because of their ability to be easily utilized by Views. Rather than specifying a list of fields with all the required configuration in a View configuration, many site-builders are finding it much easier to define a set of view modes for their entities, have them themed once, then re-used throughout the site - including as part of a View's output via the "Show: Content" option in a View's "Format" configuration. 

One hiccup that can slow this down is the not-uncommon occurrence of when a field needs to be output as a link to some destination. While this is relatively easy to do with Views' "Rewrite fields" options, there isn't an obvious solution when using view modes.

Enter the Linked Field module. As its name implies, it provides the ability for any field to be output as a link via its formatter settings. The formatter can be configured with a custom URL or it can use the value of a URL from another field value.

Linked Field module formatter settings

Think of this module as an "Output this field as a custom link" option for view modes!

The "Advanced" configuration section for the formatter settings includes the ability to custom things like the title, target, and class attributes for each link. 

If your goal is to maximize the use of display modes throughout your site, then this contributed module is an important tool in your arsenal.  

Mar 25 2018
Mar 25

Brooke Candelaria, (htownbrooke), the new Conference Director for the Drupal Association joins Mike Anello to introduce herself to the Drupal community as well as to provide a preview of DrupalCon Nashville as well as her thoughts on the evolution of DrupalCon Europe. Topics discussed include trivia night, the decoupled summit, rodeos, Hurricane Harvey, The Princess Bride, the DrupalCon Europe licensing bidding process, shoulder pads, and perhaps the greatest answer ever to our always challenging "exotic animal" question.

Interview

DrupalEasy News

Sponsors

  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Mar 20 2018
Mar 20

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.

DDEVAs a long-time Mac OS X user, my previous go-to local development stack has been a mix of MAMP Pro and Acquia Dev Desktop. For teaching, I've mainly been recommending Acquia Dev Desktop, but I think the time has come for a more flexible and professional-level solution. The ability to customize each project's development environment with various versions of PHP, different database and search index servers (adding a Solr server to any of the options in this article is just plain easy), and other things is too big of an opportunity to let pass.

My evaluation of DDEV, Docksal, and Lando has not been quick. I've been using Docksal for several client projects for well over a year now. In fact, during the initial Mastering Professional Drupal Development Workflows with Pantheon course, I recommended it to all of our students. I've even written and shared a somewhat Pantheon-flavored version of a Docksal configuration. It includes custom scripts for automatically downloading and importing a copy of a remote Pantheon database to the local environment as well as running some initial Drush commands after the import is complete.

As the Lando project matured, I was attracted to it mainly for its recipe-based configuration, including a Pantheon-flavored recipe that outdid my custom Docksal scripts. Currently, I'm using Lando for about 5 different client projects (as well as my local development environment for DrupalEasy.com).

Finally, a few months ago, I saw down with a few folks from the DDEV project at BADCamp for an extended walkthrough. It took me another month or two before I really dove into it, using it for a new client project, but at this point (spoiler alert), I'm leaning towards it being my go-to local development environment for teaching.

Comparison

What follows below is just a summary of the various features that I've focused on while test-driving each option. By no means it is a comprehensive list of features, but I think it is safe to say that these are what are most important in my use cases. As I mentioned above, my needs are twofold: a solid local development environment for client work, and an easy-to-install-and-configure local development environment for my students on both Windows and Mac OS X. I imagine that most folks don't have the latter requirement, so be sure to select the best environment for your needs.

In no particular order, here's what I focused on:

User interface

All three options are only command-line driven at this point; none have a graphical user interface (yet). All three options provide a command-line tool with different (but similar) commands. For example:

  • To start a project's containers: lando start, fin start, ddev start ("fin" is Docksal's command-line tool)

  • To stop a project's containers: lando stop, fin stop, ddev stop

As Lando evolved from Kalabox, there is talk that a GUI may be part of a paid add-on in the future. The DDEV team has also made it known that a GUI is in currently being developed.

Hard drive space

As all three options are Docker-based; each project on your local has its own set of containers. I've found that for a typical project, these containers require (I think) around 500(ish)MB of hard drive space (not including your project's data). Obviously, this can add up quickly depending on the number of projects you have on your local. I've found that DDEV has an advantage in this area, as it stores your project's data (database, files directory) in a directory shared with the host operating system - so you can remove a project's containers without losing your site's data (database) - thus saving hard drive space. For someone like me who creates a lot of sites (for teaching), this is non-trivial. DDEV's "ddev remove" command that removes only the containers. If you want to remove a project's data as well, "ddev remove --remove-data" does the trick. Both Lando and Docksal have commands to remove a project's containers and data as well, but neither (currently) has an option to preserve data.

LandoAs someone who had zero knowledge/experience with Docker at the beginning of this process, estimating how much hard drive space this stuff takes up is a bit of a black art. The "500(ish)MB" number I mentioned in the previous paragraph isn't anything more than an estimate as I watch my available hard drive space grow and shrink as I create and remove sites. I would love to have easy-to-use commands (for someone that isn't familiar with Docker) showing how much space is being used, options for clearing Docker caches, and anything else that could help developers manage hard drive space.

Drush and Drupal Console support

DDEV, Docksal, and Lando's command line tool provide a command to run Drush commands: fin drush <drush-command>, lando drush <drush-command>, ddev exec <drush-command>.

Pantheon and other remote host support

I tend to use Pantheon quite a bit, both for clients and teaching. The ability to easily get a local environment's database up-to-date from a remote environment quickly is a huge time-saver (and solid development practice). Having integration with Pantheon (and hopefully other hosts in the future) is an important factor for me.

  • DDEV's Pantheon integration isn't as complete, but it does have the valuable "pull" command which will bring down the database and files directory. I really wish it had separate commands for pulling the database and files directory. Often, it only makes sense to only pull the database, and then use something like Stage File Proxy for local files.

  • Docksal lags behind in this area - it don't provide any built-in tools for interacting with remote hosts, but they do provide useful examples for creating your own custom commands.

  • Lando has the edge here, with its robust push-and-pull commands for moving databases, files directories, and codebases between your local and any remote Pantheon environment.

Pre-made configurations

  • DDEV has various "quickstarts", similar to Lando's recipes, including ones for Drupal 6, 7, and 8, as well as Backdrop, Wordpress, and Pantheon hosting.

  • Docksal provides some basic default stack configurations, including an Acquia Cloud one, but not on the same level as Lando or DDEV. UPDATE: I've been corrected - Docksal does example configurations available for Drupal 7, Drupal 8, WordPress, and a few other CMSs.

  • Lando provides local development environment "recipes" for a plethora of development projects - including recipes for Drupal 6, 7, and 8, as well as recipes for Pantheon, Python, Dotnet, Joomla, Wordpress, and several other commonly used frameworks and providers (it is really quite impressive).

It doesn't appear that any of the options support Acquia, Platform.sh, or any of the other so-called "modern" Drupal hosting solutions (yet), but I don't think there's anything stopping that from happening in the future. In fact, it is already starting to happen.

Support and Documentation

All three options have both issue queue support as well as real-time chat support. Your mileage may vary, but I've found all three projects have very responsive maintainers, with a slight edge going to DDEV for responsiveness.

In addition, they all have relatively good documentation, considering their rapid development schedules and frequent additions. With all three options, I've found that I've had to hunt down answers not easily found in the documentation.

As an example, a few times while creating a new DDEV-powered site, I kept getting a message that port 443 was in use, but I couldn't figure out by what. It was easy enough to change the DDEV config to use a different port number, but it wasn't until I stumbled on a blog post where I learned about "lando poweroff" - this command spins down all Lando containers, including a "traefik" container that holds on to - you guessed it - ports 80 and 443. While there is a documentation page for "lando poweroff", there's nothing on the "Getting started" documentation page about it. It was only by searching the web and finding a blog post that I was able to figure out what the root cause of the issue was. I'm not picking on Lando here (far from it), as I've run into similar documentation issues with DDEV and Docksal as well. Bottom line - use all the support resources available to you.

Frequency of updates

One measure of a project's health and momentum is the frequency of updates. In all three cases, development is clearly on-going in each project.

  • DDEV - 6 releases in 2018 (5 minor, 1 patch), 13 releases in 2017 (10 minor, 3 patch).  

  • Docksal - 0 releases in 2018, 11 releases in 2017 (1 major, 6 minor, 1 patch).  

  • Lando - 4 releases in 2018 (4 betas), 51 releases in 2017 (20 alphas, 31 betas).  

Windows support

While I'm a Mac OS X user, not all of my students always are. Therefore, it is important to me that I select a tool that works well on both Mac and Windows, with a minimum of any "unique configurations" on Windows. All three options utilize some form of automated testing to ensure that each build works on both platforms. To date, I haven't discovered any major issues with any of these tools on Windows. In all cases, I've found it to be much easier to use a 3rd-party command line emulator, rather than using Windows' default command line tools.  

Requires internet connection

  • DDEV works fine without an internet connection - no configuration necessary.

  • Docksal can be run without an internet connection by manually adding an entry to your hosts file via the "fin hosts add mysite.docksal" command.

  • Lando has a documentation page about offline development, but it is only for Mac OS X, and the process is a bit more involved. UPDATE! I goofed! The previous link is if you want to manage your own local DNS, if you just want to work offline, it is much easier!

PHP options

All three tools provide the ability to swap in different versions of PHP via their configuration files.

  • Docksal allows you to place a partial php.ini file as part of your project's configuration. The directives in this file will override any default PHP settings provided by the container.

  • Lando has some support for some PHP settings as part of their configuration files and also supports a php.ini file as part of a project's configuration.

In all three tools, it is possible to ssh into the CLI container and modify the php.ini settings directly - using this approach, these changes are only temporary, however, as the next time the container is rebuilt, the custom php.ini changes will be lost.

Performance

DocksalWhile I didn't run a full suite of tests on all three options, I did want to quantify their relative speed in a real-world situation. My method was to take an actual (Drupal 8) client site, get it up-and-running in all three options (sequentially), and simply time how long it took to run a "drush cache-rebuild all". I ran the command three times for each option and then calculated the average. Other factors depending on your exact site and configuration may come into play (having Xdebug enabled is a bit of a performance hit), so your mileage may vary.

  • DDEV: 90 seconds
  • Docksal: 20 seconds  
  • Lando: 89 seconds  

Why the huge advantage for Docksal? It's pretty simple - I'm currently using Docksal in "virtual machine" mode instead of utilizing Docker for Mac (both Lando and DDEV utilize Docker for Mac/Windows). It's pretty well-known that native Docker for Mac/Windows solutions are a bit performance-challenged. According to Docksal documentation, Docker for Mac/Windows will eventually become the recommended way of working with Docksal, despite the performance losses.

Other stuff

  • Docksal has a cool "automatic stand-alone CLI container" - this is a container that is not tied to a specific project and is always available. One big advantage to this container is that it can be used to run Composer commands without having to have Composer installed on the host operating system. This is (IMHO) a big deal on Windows, where installing Composer can be tricky (due to its dependency on PHP). There is talk for doing something similar in Lando as well as DDEV.  

  • Docksal utilizes a separate command to start and stop its main virtual machine (fin vm start/stop). It's not a big deal, just a small extra step (but the performance gains are worth it, as mentioned above.)

  • DDEV automatically writes a settings.local.php file, overwriting the entire file. So, if you're like me and you like to have configuration settings specific to your local environment (Stage File Proxy, Environment Indicator, as well as some of the stuff found in example.settings.local.php, you'll have to either recreate your settings whenever DDEV overwrites the file, or you can create a second settings.local2.php file. There is an open issue about possibly modifying this behavior.

Summary

Things I love about each option

  • DDEV - the fact that I can completely remove a project's containers without losing the project's database (and other data) is really nice. While their Pantheon integration isn't as robust as Lando's, it does enough (for now). The team behind DDEV appears to have the most consistent release schedule, and I've found their various support channels to be the most responsive. Also - DDEV has a "ddev sequelpro" command that automatically launches the Sequel Pro app (Mac OS X) and connects to the current project's database. I know it's a trivial thing, but I love it so much.

  • Docksal - its fast. If/when the maintainers decide to make using Docker for Mac/Windows the default, it'll be back on even ground with DDEV and Lando, but for now, it's just plain fast. I also really like that Docksal includes a "fin run-cli" command that allows you to run Composer commands ("composer create-project", for example) before setting up a project's containers. So handy.

  • Lando - its Pantheon integration is second-to-none. The ability to push and pull code, database, and/or files makes it a breeze when integrating with Pantheon sites. I'm really looking forward to when additional hosting-based recipes are available.

Things I don't love about each option

  • DDEV - I use a MacBook Air with 8GB RAM and a 1.7GHz Intel Core i7 as my main development machine. The stunning performance gap between DDEV and Lando compared with Docksal is completely attributed to Docker for Mac. I don't know all the ins-and-outs about why its performance is so lame, but I find it maddening sometimes. Also, the settings.local.php issue I mentioned above, but fingers-crossed that gets resolved soon.

  • Lando - re-read what I just wrote about DDEV (except for the settings.local.php stuff). Same. Also, whenever Docker is restarted, the Lando proxy also automatically starts up and grabs hold of port 443 - regardless of if I have any local Lando sites up-and-running. This can cause conflicts with other processes that want to use that port. Lando's "push" command for Pantheon is a little too aggressive for my tastes - it automatically adds, commits and pushes all outstanding changes in your local codebase to the Pantheon repository (I don't care for "git add ." either).

  • Docksal - lack of Pantheon integration. Granted, it's not terribly difficult to write custom commands to automate pulling databases from Pantheon, but it sure would be nice if it was built-in.

While going through this exercise, I've realized that there's really no single globally "the best" solution. There are pros and cons for each option, and it's really up to the developer (or development team) to determine what's best for them.

Regardless of which option you decide to go with, here are some important things that I've learned:

  • Pay attention to updates and apply them appropriately (including Docker updates if you're using DDEV or Lando). The pace of each option is such that something that doesn't work today might very well be fixed in the very near future. Pay attention to the release notes for each update, as sometimes there are incompatibilities with specific versions of Docker.

  • All of these options take up a non-trivial amount hard drive space for each project. For projects that are dormant, go ahead and destroy the containers - that's the whole point of having a solid developer workflow. Recreate the containers (re-import the DB and files directory if you're using Lando or Docksal) when you need to work on the project again.

  • Get familiar with the real-time chat support for whichever option you go with. They can be real time-savers.

Which will I be using going forward? For client work, the answer is "probably all three". For more complex sites, I'm addicted to Docksal's performance. For teaching, I'll be test-driving standardizing on DDEV starting with the Spring, 2018 class of Drupal Career Online. It's ease of installation on both Windows and Mac OS X, along with its straightforward commands, hard-drive-space-saving architecture, and incredibly responsive support channels give it the edge (at least for me) over Lando.

Which solution should you use? It really depends on you and/or your team's situation. You're going to want to take into account factors such as host operating system (Mac OS X or Windows), hosting environment (on-site, managed VPS, Acquia/Pantheon/Platform.sh), skill level, and other factors. We're experiencing a bit of a renaissance in local development environments with a good deal of innovation and momentum - which makes it a buyer's market, so take advantage and find the solution that works best for you.

Official project links

Blog posts

Acknowledgements

Thanks to Mike Pirog from the Lando project, Rick Manelius from the DDEV project, and David Hernandez from the Docksal project for their input on this blog post.

DrupalEasy Podcast 207 - David Needham - Pantheon, Docker-based Local Development Environments, and Hedgehogs

Mar 12 2018
Mar 12
Mar 04 2018
Mar 04

DrupalEasy faviconEvery Drupal 8 site should have a custom favicon that helps to reinforce the site's brand - of this there is really no argument. But, over the past (more than a few) years, the role of the lowly favicon has grown from just the little icon on a browser tab. These days, favicons are also used on mobile devices as the gateway to your site. Keeping your brand strong in all contexts is more important than ever.

Luckily, the Responsive Favicons module, combined with Favicon Generator makes it pretty easy to keep your site's branding consistent across multiple platforms. 

Favicon contexts

Assuming you have a relatively square-ish version of the site's logo, making this all happen is pretty easy.

First - head to Favicon Generator, upload the site's logo, then review/tweak the settings for the various contexts. You'll be asked for the "App name" (usually the site's name), suitable background colors (I selected a nice pear-color for the DrupalEasy logo - you can see it in the iOS mockup above), as well as image overrides (optional) for each context. For the "Favicon Generator options", select the "I will place favicon files at the root of my web site" option (at the recommendation of the Responsive Favicons module maintainers). At the end of the process, you'll get a zipped file full of all the necessary icons and meta data. 

Next, download and install the Responsive Favicons module. Head to its configuration area (/admin/config/user-interface/responsive_favicons) and complete the form. For the "Path to responsive favicon files", I just used "favicons". The "Favicons tags" section is provided at the end of the Favicon Generator's process. Finally, point the zip file generated by the Favicon Generator to the final form field. Click to "Save configuration" and you should be all set!

Lessons like this (and much, much more) are taught during our 12-week, 3x/week Drupal Career Online course. Learn more and register for our free Taste of Drupal webinar to dive into the details of the course.

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web