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 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 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 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]

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

Make 2019 the Year of Drupal Talent Development

Jan 30 2019
Jan 30

Automatic removal of .git directories from Composer dependencies

Dec 09 2018
Dec 09

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 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...
 

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 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 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.

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.

Feb 19 2018
Feb 19
When I walk along with two others, from at least one I will be able to learn. 
 – Confucius

Drupal development as a career is usually also a commitment to constant learning through ongoing professional development.  Whether you make it a point to read blog posts or watch screencasts, sign up for some type of live-instructor training, or partake in co-working and meet-ups, on-going learning is a critical piece to being a professional Drupal  developer. Years ago, when DrupalEasy was presenting our Drupal Career Technical Education program exclusively in-person (now Drupal Career Online), the lab-portion (where we met in a less formal way than classroom sessions) became so popular with students, that we decided to continue to host them after graduation for anyone who had taken the class.

Six years later, these "office hours"are still going strong, now online and attended by people weekly from all over the country. It’s amazing to see the developers who first learned how to spell Drupal years ago in our riverside classroom in Cocoa, Florida; now the veterans assisting and connecting with those from recent sessions. People from former sessions, even those who attend at different times, also support each other beyond the labs, which has all contributed to the development of, what we think, is a pretty cool DrupalEasy Learning Community.

Weekly on Thursday afternoons U.S. Eastern Time, you can find DrupalEasy’s Mike Anello leading Go-To-Meeting ofice hours sessions, which are open to anyone who is enrolled in, or has taken any long-form DrupalEasy training courses. It’s a loose session devoted to helping anyone overcome issues, figure out how to approach something, share insights on particular modules and also talk Drupal. Learning experts call this collaborative learning, and it has even more advantages than we realized, which explains why it is so popular and seemingly effective as both an initial learning strategy and ongoing professional development tool. Everyone learns (Even Mike).

The Cornell University Center for Teaching Innovation explains that  “Collaborative learning is based on the view that knowledge is a social construct.”  (Wow, that relates to Drupal and open source projects on so many levels!)  They also explain that there are four principles to the ways collaborative learning happens, including that those who are learning are the primary focus, it is important to “do” and not just listen, working in groups is key, and the group should be learning by developing solutions to real problems.  

DrupalEasy’s learning community organically grew and developed all of these principles over the years, which is a pretty good confirmation that from both learning and solutions perspectives, we are on the right track. At the onset of each week’s office hours session, we say our hellos and figure out the first problem someone is having, or had, and the group works together to come up with a solution. There is of course also a bit of Nerd banter that keeps things fun and allows us to get to know each other a bit more. Cornell’s experts also confirm that group learning contributes to developing a lot of the soft skills (oral communication, leadership,etc.) that can help make a good developer great. We agree!

We also especially appreciate the value of the problem-solving approach to teaching, and also use it in our structured training. Cornell again has some great insight into the types and characteristics of problem solving as a mode of teaching that really resonates with us. They go in pretty broad and deep with references and explanations, so let’s pull the one element they cite that we feel we can attribute a good part of the success of our programs: “The problem is what drives the motivation and the learning.” (Boom!)  

So, knowledge is a social construct and problems motivate us to learn and figure out solutions. Working together as a community to overcome problems and build viable solutions. It’s all very Drupal-y, don’t you think?

The next session of Drupal Career Online begins March 26th. Two no-cost Taste-of-Drupal information sessions about the course are coming up at 1:30pm EST on February 28 and March 14.  Sign up!

Feb 03 2018
Feb 03

Over the past several weeks, I've been working with three of the more well-known Docker-based local development environments that involve a Drupal focus: Docksal, DDEV, and Lando. The goal is to not only to figure out which one I prefer, but also to figure out which our two long-form online Drupal training classes should potentially standardize on.

Docksal logoOur classes are often comprised of folks from all different technical backgrounds, so it is important that we not only teach them tools that Drupal professionals use, but also something that folks of myriad of skill levels can easily consume. Perhaps most importantly, while the majority of our students are on Mac OS X, we still have a consistent number of students using Windows, so any solution we recommend should work similarly on all platforms.

As a Mac OS X user myself, it is important to me that I can instruct our Windows-based students without having to resort to a separate set of instructions. To that end, I have an actual Windows 10 Pro machine (not a virtual machine) that I've been using to evaluate these local development environment options. 

I've decided to focus on DDEV, Lando, and Docksal because I really like the idea of Docker-based containers; being able to customize your local development environments to each project has too many advantages to ignore. Also, as one of our classes is Pantheon-focused, Lando's Pantheon integration is a very important differentiator. 

Requirements

DDEV logoI have a basic set of requirements that a local development environment should be able to handle. These requirements are probably focused more on our introductory Drupal Career Online course, but I'd like to be able to recommend the same solution for any of our courses.

  • Run Composer commands (including create-project). It doesn't matter to me if this command is run on the local OS or in a container, as long as it works with a minimum of fuss. The "create-project" command can be a bit tricky on Windows - keep reading to find out why.
  • Run Git commands both on the local OS and in the container. 
  • Be able to get up-and-running with a minimum of downloads. On Mac OS X this isn't much of an issue with Terminal, Git, and PHP preinstalled, but on Windows it is a different story.
  • Be able to get up-and-running with a minimum of "extra" configuration. Granted, once you're comfortable on the command line adding something to your local PATH isn't a big deal, but for folks new-ish to the command line, it can be a significant hurdle. 
  • Have a Linux-based command line interface (to use commands like cd, ls, cat, etc...)
  • Be able to easily (zero configuration) edit text files on the command line (nano or pico).
  • Be able to modify file permissions and ownership from the command line (chown and chmod).
  • Be able to run Drush, Drupal Console, and all of the other Drupal-y things that a professional developer should have.

I am very cognizant that my requirements are probably represent the lower-end of the Drupal skill-level spectrum, but I feel these requirements are a reasonable starting point.

Potential solution

Microsoft Windows 10 logoOver the past few weeks, I think I've installed, uninstalled, and reinstalled various combinations of Lando, Docksal, and DDEV as well as various command line shells (Babun, Cmder, PuTTY, Cygwin) and the Windows Subsystem for Linux at least a dozen times on my Windows machine. All this in an effort to figure out what is the best combination of tools to satisfy the requirements. At the current moment, I'm circling around recommending Lando and Cmder on Windows (Lando requires Windows 10 Pro with Hyper-V enabled) - both are easily installed with no extra configuration necessary to get almost everything working. 

Upsides

Lando logoWith just Lando and Cmder installed almost all of the requirements are met. I can use Git to clone a site down to my local, get it up and running in Lando and get to work.

Downsides

One minor issue is that Cmder doesn't come with nano nor pico for editing text files from the command line. It does come with vim, however (which we all know has a steeper learning curve). I can probably mitigate this issue with a little bit of config to have students run a command to open text files in something like Notepad++ or teach some basic vim commands.

The other issue is a bit more serious. With only Lando and Cmder installed, there's no way to run "composer create-project". While Lando makes Composer available in the container, developers don't normally create the containers until they have a code base. This is a bit of a chicken-and-egg issue:

  1. We need Composer to get the new code base.
  2. We need the Lando container to be up-and-running to get Composer.
  3. We need a code base before we start Lando.
  4. (return to step 1 above)

So, I think I know what you're thinking: just install Composer. Well, this isn't as simple as it sounds, as Composer requires PHP, and as far as I can tell, installing PHP on a Windows machine isn't super-straight-forward. Granted, if the developer already has another AMP stack on their Windows machine, the Composer install can be configured to use the php.exe installed with it. 

Docksal actually has a command that allows a developer to run Composer without actually having a set of containers already initialized for the project using the "fin run-cli" command. This utilizes a standalone cli container and completely removes the need to install Composer on the local OS. 

Next steps

So, where does that leave us? I'm not 100% sure, but I wanted to put this out there and get some feedback. Are you a professional Drupal developer that uses Windows as your main OS? If so, what's your setup? Am I missing anything? 

While I often try to steer new Drupal developers towards Mac OS X or Linux, sometimes it is not possible due to corporate policies or even just personal preference. I'd love to be able to teach a solution that provides a professional-level Drupal developer experience to Windows users.

Jan 31 2018
Jan 31

As trainers, feeders of the Drupal Talent pipeline, and researchers of strategies to attract and build the numbers and excellence of Drupal talent across the world, we spend a lot of time finding and training people in the ways of Drupal. Through resources, Mike Anello's many sessions and trainings at Camps and Cons, and through our flagship Drupal Career Technical Education program, we pursue our passion to teach more people Drupal. We think we have the training side of this down, but like the Drupal Community's general shortage of talent, it’s finding more people that is the challenge.

Why is that? And why aren’t there people coming in droves to this opportunity-rich, community-based vocation? We think it has a lot to do with a lack of the right information getting to the right people. Here at DrupalEasy, we fill a lot of (sometimes too much) time observing and noodling the various paths people take to find Drupal, aspects of Drupal as a career and reaching those who could benefit. We think if Drupal opportunities were presented more broadly, a bit better, and were more accessible to those who are not aware (especially those who historically have not embraced IT careers,) the floodgates (or at least a stream) might start to bolster up the Drupal talent pipeline.  

Drupal's foundations are really quite inspiring.  A vocation built on sharing - open source, an engaged community and building and developing the means upon which our societies connect, build relationships, find information, and buy & sell. The story is also quite practical; well-paying jobs a-plenty. According to Indeed.com, the average salary for "Drupal" ranges from approximately $59,980 per year for Web Designer to $110,572 per year for Full Stack Developer. 

In addition, the US Department of Labor Occupational Outlook, which provides official salary, job growth statistics and job descriptions for just about any career you might want to pursue, has some pretty convincing numbers as well. According to the DoL, Software Developer, Applications positions have a 30% growth rate, rank in the top 10 for job growth in the US, and have the third highest estimated salary! For web developers in particular, the DoL puts job growth at 15% over the next 8 years, which they cite as much faster than average. To put it in perspective, electrical engineerin job growth is predicted to be 7% – less than half of that of web developers.  

So with all of this opportunity, where are all the aspiring Drupal developers? Apparently somewhere they are privy to neither the Drupal narrative nor Web developer job stats.  We have several ideas, some big, others not too difficult, on how to overcome our shortage of talent, as we outline in List #5 to provoke some thought and perhaps follow up from those who feel the pain of the Drupal talent shortage.  We'd love to hear from you. 

But perhaps we can all give small efforts a go to see where it might improve things on a smaller scale; beginning with awareness we can build within and on the fringes of our personal and professional networks. So, in the spirit of spreading the word about how great the opportunities are in Drupal, we thought we would compile a few easily shareable lists you may want to dole out to those around you. We'd also love for you to share with us your lists (and ideas) that may make Drupal a bit more accessible to those who may become a part of this engaging community. 

#1  Top 10 Drupal Talent-Starved States

If you live in one of the 10 states listed below, especially near the major metropolitan areas, your outlook for finding a Drupal job is pretty positive. Likewise if you are looking for talent in these places, we feel your pain. The list includes the highest number of open positions we found on Indeed. (To be fair, if you live in Idaho, Mississippi, Nebraska, South Dakota or Wyoming, the chances of finding a commuter/non-distributed position in Drupal is pretty slim, considering we could not find a single open position in any of these states using a pretty comprehensive list of job search sites.)  

  1. California: 270

  2. New York: 233

  3. Virginia: 130

  4. Maryland: 118

  5. Massachusetts: 106

  6. Pennsylvania: 95

  7. Texas: 85

  8. Washington: 60

  9. (tie)Florida: 55

  10. (tie) Illinois: 55

[*Source, Indeed.com, as of January 29, 2018. (Indeed has the greatest number, therefore the most complete list, of Drupal job openings. It also provides the tools to ensure accuracy. The other sites support these rankings, ]

# 2 Top 10 Jobs Sites to find Drupal Positions (by number of Drupal jobs and ease of calculation!)

We went on a job finding expedition earlier this week to see where people looking for Drupal jobs or just gauging the opportunities have the best shot. Indeed.com won by shear numbers, but also because they make searching, and compiling information like these lists the easiest. The list includes the site and the number of Drupal and Drupal related jobs in the United States as of January 29, 2018. 

1 Indeed; 2,015

2 Glass Door; 2,012

3 Simplyhired;1,798

4 Monster; 1,164

5 job.net ~500

6 ihiretechnology; 491

7 Justtechjobs; 273

8 Dice; 259

CareerBuilder; 135

10 DrupalJobs; 80

*Of note:  I tried not to use sites that compile listings from other sites, like Ziprecruiter, but many sites now share listings. Also, if you are looking specifically for a federal government job, try USAjobs.gov

#3 Top 10 Drupaliest Companies in the US

For those who wish to get into larger organizations (by Drupal size standards of course) with lots of Drupal people to associate with throughout the day, the companies who have the greatest number of employees registered on Drupal.org, and have headquarters or major facilities in the US are listed in order of Drupaliness, which means according to the number staff members on Drupal.org.

  1. Acquia; 618

  2. FFW; 231

  3. CI&T; 220

  4. Cognizant; 117

  5. Phase2; 92

  6. Pantheon; 86

  7. Booz Allen Hamilton; 74

  8. Appnovation; 69

  9. Epam; 68

  10. Mediacurrent; 67

[Source Drupal.org: Organizations using Drupal: United States which shows the number of employees who are on Drupal.org.]

# 4. Top Ten Articles to Guide Aspiring Drupal Developers

OK, so we’ll preface this by again explaining that we spend a lot of time thinking about, researching, interviewing, writing and presenting a lot of materials on Drupal careers and jobs. That said, you’ll see quite a few entries below with our fingerprints on them. Not sure how to shed the cloak of shameless promotion, but avoiding it does not seem like a good reason to leave out helpful information (we’ll take whatever sneers you'd like to offer.) The list was compiled from a variety of Google searches using several key words and variations, and based on our impressions of the credibility and helpfulness of the information.  If you have any additional materials that we missed and you’d like to share, please let us know and we’ll add it to our Career Resources Page.

  1. How Do I Start a Career in Drupal? DrupalEasy Academy Resources page

  2. Why Become a Drupal Developer? Drupal Partners, August 2015

  3. How Do I get a Job in Drupal?; OSTraining’s March, 2015

  4. Become a Drupal Developer, Drupalize.me

  5. What Does it Mean to Be a Drupal Developer?; Promet Source, August 2016

  6. How to Become a Successfull Web Developer; Mobomo, August  2016

  7. How to Become a Successful Web Developer, Zyware; 2015

  8. 6 Steps for New Drupal 8 Developers; Web Omlette

  9. What Skills should a Drupal Developer Have? ValueBound, February 2017

  10. Drupal Career Resources; DrupalEasy Academy

# 5. Top 10 ways to grow Drupal Talent

This one is for all of us, especially the folks on the #3 list, who, we noticed are among many of the companies tallying up the numbers for states on list #2. Since we started Drupal Career Training, we have met with dozens of people, educational institutions, workforce boards, other Drupal training companies and all sorts and sizes of companies about the Drupal talent shortage issues, the lack of diversity issue, and the "lack of experience" issue for those new to Drupal. We feel like if just a few in the community, together or independently, start any of these initiatives, it will go a long way in ensuring that the 15% growth in web developer positions is not lost on Drupal in the future. The only resource for this list is the collection of ideas we have heard, discussed, conceptualized, written into white papers and schemed up during DrupalEasy lunches. If you have another idea, or want our help getting one of these concepts going, let us know.

  1. Collaborate with other companies, especially in the states that made the #2 list, to reach out to regional workforce agencies to get them involved in finding and underwriting training for potential Drupal hires.

  2. Develop geographic mentoring networks for those considering and new to Drupal through the local users’ groups.

  3. Take on Interns (Contact DrupalEasy for well-trained candidates or find them at local meetups.)

  4. Develop a Drupal community scholarship fund for under-represented groups to use one of the many Drupal Training organizations to get skilled up in Drupal.

  5. Partner with Not-For-Profits to fund Drupal training, mentoring and internship programs for women, minorities, veterans, and other underutilized populations.

  6. Promote Drupal as a career in your local and non-Drupal community outreach. 

  7. Reach out to contacts at local colleges about adding Drupal to their curriculum (DrupalEasy’s state licensed Career Technical Education program is an option.)

  8. Host/sponsor beginner information nights at Meetups.

  9. Share these lists to spark interest and action.

  10. Contact DrupalEasy to help with these or any other ideas you may have!

 

The Spring 2018 session of DrupalEasy's Drupal Career Online training begins on March 26th, with two more free informational webinars about the course in February and March. Registration is also open for the Spring Session of Mastering Professional Drupal Developer Workflows with Pantheon, which starts on February 28th. 

 

Jan 27 2018
Jan 27

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

One of the necessary skills for a professional Drupal developer (one who codes either modules or themes) is to be able run a solid debugging tool. As part of my evaluation of Lando, I decided to figure out how to set up local PHP debugging with Xdebug and PhpStorm on Mac OS X.

This process described below is largely based on a comment in an issue thread in the Lando issue queue by David Hunt - thanks, David!

My local setup includes:

  • Mac OS X Sierra 10.12.6  
  • Lando v3.0.0-beta.21  
  • Google Chrome with the Xdebug helper extension 
  • PhpStorm 2016.1.1  

Starting point

This tutorial assumes that you have a local Drupal site up-and-running in Lando and set up as a project in PhpStorm. In this example, my local site is using the Lando "Pantheon" recipe, but as you'll see in a bit, any recipe can be used. Also - my local site is based on the standard Drupal project composer template (with a nested docroot).

PhpStorm project

Enable Xdebug in Lando

The first step is to enable Xdebug in Lando - this is easily done by modifying the local site's .lando.yml file. In my case, I added the following:
 

Enabling Xdebug in Lando

If your .lando.yml file is defining a custom appserver service, then you should be able to just add the "xdebug: true" bit to the appserver definition. 

Once added, you'll need to perform a "lando rebuild" - this will rebuild your environment based on your .lando.yml, including adding Xdebug. The documentation page for the "rebuild" command includes a caution about how there's no guarantee that data will persist between rebuilds. In my experience, I haven't had any issues with losing my database. If you're concerned, then you may want to perform a "lando db-export" prior to rebuilding.  

Configuring PhpStorm

Here's where some magic comes in. Admittedly, I don't fully understand the details of some of the configuration necessary in PhpStorm to get debugging working, but I can confirm that following these steps, it has worked every time for me so far.

The first step is to add the Lando recipe folder as an "Include path" in your PhpStorm project. Open Preferences > Languages & Frameworks > PHP, click the "+" button at the bottom of the list, and manually type in the name of the folder of the Lando recipe you're using. On my machine it is: /Users/michael/.lando/services/config/pantheon. If you're using the standard "Drupal8" recipe, then it would be: /Users/michael/.lando/services/config/drupal8. Unless your username is also "michael", you'll want to update the path.
 

PhpStorm PHP preferences

Then, go to Preferences > Languages & Frameworks > PHP > Servers

PhpStorm listening for incoming connectionsIf no server for your project exists (it might be called “appserver”), then enable PhpStorm to listen for Xdebug connections, load a page from your local site in your browser and PhpStorm will prompt you to accept the incoming connection. In my case, it didn’t matter if the Xdebug helper is set to debugging or disabled at this point.
 

Incoming connection from Xdebug

Then, once a server for your local site exists (remember, it might be called "appserver”), select it and ensure that "Use path mappings" is checked, and ensure that your project folder is mapped to "/app" for the "Absolute path on server". Also ensure that the "Absolute path for the server" for the “include path” is "/srv/includes".

PhpStorm PHP Servers preferences

Give it a try!

At this point, we should be ready for debugging! As a test, open up the site's index.php in PhpStorm and place a breakpoint.

PhpStorm set a breakpoint.

Then, using the Xdebug Helper extension, enable debugging. Also ensure that PhpStorm is still set to listen to incoming Xdebug connections. 

Xdebug helper enable debugging

Finally, load your local site's home and watch how PhpStorm will pause code execution at your breakpoint in the index.php file.
 

PhpStorm debugger working.

Warning - performance will suffer

While Xdebug is a powerful tool and will absolutely save you loads of time, there's a dark side. Performance will suffer. I recommend disabling Xdebug in your .lando.yml - by setting "xdebug: false" - (and rebuilding) when you're not using it. You can leave it enabled and gain back some (but not all) performance by disabling PhpStorm's listener as well. 

Final thoughts

In case you're wondering where some of the configuration settings come from, here's what I've figured out so far:

  • "appserver" is the name of the Lando service that contains the codebase. 
  • "/app" is the absolute path of the codebase in the "appserver" Docker container. 
  • "/srv/includes" is the absolute path to a Lando-provided "prepend.php" file in the "appserver" Docker container. As far as I can tell, this file defines and sets a bunch of environment variables depending on the recipe used.
     
Jan 21 2018
Jan 21

Over the past few months, I've been evaluating three Docker-based local development environments trying to figure out which is best not only for me, but also for students of our long-form Managing Professional Drupal Development Workflows with Pantheon (next semester starts February 17) and Drupal Career Online (March 26) classes.

I've been test driving Docksal (actually, I've been using it for over a year), DDEV Community, and Lando (I'm a recovering Kalabox user) trying to figure out where the "sweet spot" is for flexibility, ease of use, documentation, Windows-compatibility (we routinely have students on Windows machines), performance, and some other criteria.

I recently stumbled upon a cool open source project (thanks Brian!) called Mailhog that makes it dead easy to test outgoing emails from a local development environment. While I tested it on Lando, both Docksal and DDEV both support Mailhog and have supporting documentation here and here

The general idea of Mailhog is that it acts as a local STMP server that by default, doesn't send emails to the addressed recipients. Rather, it includes a clean UI that allows the developer to view outgoing emails. 

Getting Mailhog up-and-running in an existing Lando site is quite easy. Simply add the following to your .lando.yml

proxy:
  mailhog:
    - mail.lemp.lndo.site
services:
  mailhog:
    type: mailhog
    hogfrom:
      - appserver


You'll probably want to change the URL of the Mailhog UI from "mail.lemp.lndo.site" to something specific to your project - in my case, I should have set it to "mail.de8.lndo.site".

Then, run "lando rebuild". Caution should be used when using this command, as while most services retain their data during a rebuild, some may not. So far, I can confirm that my databases come through just fine. 

After rebuilding, you're just about done. When you run "lando start" the next time, you'll see a new set of URLs for the local Mailhog UI (you can also get this information via "lando info").

Mailhog local URLs

On your local Drupal site, if you're using the SMTP module or another SMTP-based sending solution, be sure to disable it:

Turn SMTP off.

Then, sending an email from a local contact form (screenshot shows a local copy of DrupalEasy.com):

Contact us form

Results in this in the Mailhog UI:

Mailhog interface

Then, if you want to "release" a message to its intended recipient, Mailhog provides you the option to do that as well via a button when viewing an email:

Mailhog release button

The button leads to an SMTP settings form:

Mailhog STMP release settings

Summarizing, regardless of if you're using Lando, Docksal, DDEV, or another local development stack, Mailhog is a great tool to help you test sending emails from your local development environments. 

While the screenshots in the blog post demonstrate setting up Mailhog with Lando, I can confirm that the process is just as easy with Docksal using the documentation, as I was able to configure it for a local client site in about 5 minutes.

For more information about using Mailhog with Lando, see the official documentation page.  
 

Jan 16 2018
Jan 16

Spoiler alert! If you haven't seen “The Last Jedi” yet, this blog post includes what can be considered a minor spoiler. I've seen the movie a few times now (I saw the original Star Wars movie when I was 7 years old, and I've been hooked ever since), and I've been able to fully indoctrinate at least one of my kids in my love for the series. When we first saw the movie on opening night, there was a line of dialog that resonated with me more than usual - I've been thinking about that line for over a month now and have figured out how to relate my love of Star Wars with my obsession for teaching Drupal. 

"The Greatest Teacher, Failure Is"

There's a point in the movie when Yoda is speaking to another character and utters this line. As a former mechanical/aerospace engineering college adjunct professor and a current Drupal trainer, I've always believed that for a lesson to truly take hold, there has to be a little bit of pain - not physical pain, but rather the kind of pain that comes from doing something incorrectly (often numerous times) before realizing the proper way of doing something that leads to a more satisfying, correct (and often efficient) result. As usual, I didn't have the proper words to describe it - thanks to Yoda, I do now.

As I look back at my eleven years in the Drupal community, I can point to more things that I care to admit that I didn't do correctly the first time. If I narrow that list to technical mistakes, it becomes very clear that many of the mistakes I've made have had a direct impact on the curriculum I've written for our various training classes.

As we gear up to teach Mastering Professional Development Workflows with Pantheon for the second time, allow me to share some of the failures I've had in the past and how they've had a direct result on the curriculum for this 6-week class.

  1. "Everything is a content type" - this is something I learned only by repeatedly designing the information architecture for various sites that ended up not being able to completely fulfill all the project's requirements. Understanding the differences between various kinds of entities is key to building a sustainable site that meets 100% of a project's requirements.
  2. "Core search is fine" - I'm embarrassed to say how late I was to get on board the Search API train. Being able to provide faceted search to clients of all sizes is a huge win.
  3. "I don't need the command line" - looking back at the first half-ish of my Drupal career, I used Drush only when absolutely necessary. Not learning basic command line tools until well into Drupal 7 definitely held me back. With Drupal 8, if you want to be a professional Drupal developer, there is no way to avoid it. Luckily, using command line tools like Composer, Drush, and Drupal Console are not only "the right thing to do", but also save time. 
  4. "MAMP is fine" - I was late to the party in moving my local development environment from MAMP and Acquia Dev Desktop to a Docker-based solution. I had played around a bit with virtualized solutions, but once you get accustomed to a professional-grade, modern, Docker-based solution, you'll never go back.

While I could list additional examples (multi-branch development, configuration management, display modes) of previous failures - or even one or two that I feel like I'm currently failing (test-driven development), the point is that sometimes it is necessary to fail in order to really understand the value of a success. 

DrupalEasy's 6-week live, online Mastering Professional Development Workflows with Pantheon, not coincidentally, addresses the failures listed above. The next session begins on February 27, 2018.  

The next session (our 11th!) of our 12-week, live, online more-introductory-focused Drupal Career Online begins March 26, 2018.
 

Jan 09 2018
Jan 09

The following is a guest blog post by Brian Coffelt.

Brian Coffelt

Train to Reign

I’m surprised often by the slow adoption rate of quality development workflows. Time probably plays a big part. One thing I have experienced though, is that in order to get the full value of tools, especially software, you really need to spend the time learning how to use them properly.  

Since I changed my career to become a Drupal developer, I haven’t had a day of regret, nor a day when I did not realize that the key to success is learning more: More about the software, more about techniques, and more about the tools that make Drupal development better. It all feeds into what I learned early on in DrupalEasy’s Career training program, and that I still feel are the best parts of this amazing Drupal-based vocation: to create quality work and become part of the Community.

So when I had the chance to take DrupalEasy’s Mastering Pantheon Workflows course, I jumped at it.  I have been relying on (and loving!) Pantheon’s website management platform since my early career training, and am a huge fan of the great workflow and development tools it offers.  The Workflows class, which is several afternoons a week for six weeks, was time truly well spent. It taught me to really leverage Pantheon’s advantages, and has made me a better developer.

Top 5 Takeaways

The quality of the curriculum and instruction of this course are second to none.  I mean it. DrupalEasy’s insight on what is important provides tremendous value to the time spent in the class and honing your skills. As any professional web developer knows, a great development workflow is worth its weight in gold. This class helped me learn a Docker-based local development workflow that has been directly applied to my everyday routine as well as that of my team.  In addition, learning how Composer manages dependencies was an eye opener for me. It allows my projects to be very lean, efficient, and modular. There are plenty more topics I can point to, but the top 5 area’s we covered that make my day-to-day better and easier are:

  1. Composer integration and dependency management
  2. Drupal 8 configuration management (exporting & importing)
  3. Docksal/Lando local environment structure & setup
  4. Higher level Terminus commands
  5. Development workflows between Pantheon environments and local

The instruction, either direct or via additional screencasts, was always thorough, well planned, and thoughtful. The instructor, Mike Anello (@ultimike), always allows time for questions and troubleshooting. Integrating a class Slack channel was valuable for questions and troubleshooting between classes as well as resource sharing (links, documents, etc.). I still keep in contact with my classmates as often as I can via Slack, email or Drupal events.

Worth the time

It may seem like a few afternoons a week for six weeks will chew up your schedule, but in fact, the opposite is the case. The skills acquired from this class can immediately boost your production, proficiency, and overall value, all of which are well worth the financial and time commitment.

I am definitely a better Drupal developer after having taken the Workflows course. The knowledge, experience, and overall comfort level I achieved has given me valuable skills that I use and share with others every day. The class always stresses the pursuit of best practices to minimize development time and maximize results. I recommend this course to Drupal developers looking to streamline their Pantheon development workflow. It’s certainly well worth the investment.

DrupalEasy’s next Mastering Professional Drupal Development Workflows with Pantheon course starts in February.  Contact DrupalEasy for more information.

Dec 26 2017
Dec 26

We'd like to introduce the Fall, 2107 graduates of Drupal Career Online (DCO), DrupalEasy's exclusive 12-week, live online Drupal training program. This is our 11th graduating class and the first of our recently updated all Drupal 8 curriculum.

Fall 2017 Drupal Career Online class photo

Class members include (from top, left):

  • Michael Anello (instructor)
  • Adrian Nolt
  • Lisa Streeter
  • Jared Nolt
  • John MacDonald
  • Steve Versteeg
  • Alona Kotliar
  • Evrim Campbell
  • Donald Sangster
  • Madeeha Kahn (below)

Madeeha KahnWhile many of this semester's graduates have pre-existing full-time jobs, several are aspiring Drupal contractors and consultants, so if you're looking for a junior level Drupal developer or intern, don't hesitate to let us know

This semester's class included Drupal 7 site builders looking to learn Drupal 8 workflows and module development, a WordPress developer and a self-taught Drupal 8 developer looking to learn best practices, as well as several Drupal hobbyists looking to learn professional development techniques.

Our always-being-updated curriculum dropped support for Drupal 7 with this most recent class. The curriculum now teaches Drupal 8 best practices around using Composer to manage site codebases, Drupal Console for module development, and proper use of Drupal's settings.php and settings.local.php files. 

The next semester of Drupal Career Online begins March 26 - learn more about it.  

We're also offering our Mastering Professional Drupal Developer Workflows with Pantheon class starting February 27. This 6-week, 3 half-day per week, live online class is for those with previous Drupal development experience who are looking to learn professional Drupal 8 workflows focusing on Composer and Pantheon. In addition, there are dedicated lessons about Drupal information architecture, using Search API and Solr, and utilizing advanced Pantheon hosting features. 
 

Aug 22 2017
Aug 22

Resources to learn Drupal are many and certainly vary in delivery, focus and quality. When you are trying to figure out the best way to train up, considerations like schedules, learning styles, and trainer reputations play pretty heavily. You also need to look at the program and compare it to what you already know, what you need to know, and what you should know to get into practice as quickly possible. One of the biggest obstacles is often finding, and then choosing the training program(s) that are right for you, and perhaps your team. But what if you didn’t have to choose?

Drupalize.me and DrupalEasy are proud to announce that we are making it easier to get trained up in Drupal in a way that helps overcome challenges, meets needs, and addresses the different ways people learn. We are bundling our training programs and resources beginning with DrupalEasy’s Fall 2017 session of Drupal Career Online. The DCO will include access to all of the thousands of Drupalize.me tutorials during the 12-week course, and a deeply discounted subscription after graduation. Current Drupalize.me subscribers will also receive a special Drupalize.me tuition rate for this and any future sessions of the DCO.

Drupalize.me’s Addison Berry came up with the partnership idea as a way to help the community grow by helping along the learning process of people who can more quickly become solid developers. Addi says, “Any way we can make it easier, and better for people to get quality training to become developers is good for the community, and good for all of us.” In addition to providing comprehensive Drupal training that focuses on best practices, Drupalize.me and DrupalEasy share a love of building the Drupal talent base across the world.

Drupalize.me provides a premium, membership-based training library of thousands of tutorials divided into specific pathways according to your learning goals. It is trusted by users around the world, and backed by Lullabot, one of the top open source strategy, design, and development companies.

DrupalEasy has been offering instructor-led comprehensive Drupal career technical education (the first of its kind) programs since 2011, launching the 12-week, 132 hour Drupal Career Online program in 2015. The DCO ensures individuals and teams can rely on expert live instruction, office hours and mentorship, expansive learning resources, and a curriculum that thoughtfully stacks skills and emphasizes best practices to ensure graduates have the best possible foundation to become practicing Drupal developers.

The first session of Drupal Career Online that includes unfettered access to the Drupalize.me’s tutorials in the Site Building, Theming and Development learning pathways begins October 2, with an application deadline of September 26th. To learn more and get an idea of the DrupalEasy learning platform, sign up for one of two Taste of Drupal free information sessions in August and September or contact DrupalEasy.

Jul 30 2017
Jul 30

Brian Coffelt

We've had more than 100 students complete our 12-week Drupal Career long-form training since 2011, working with individuals, teams, young and old, men and women, all with different backgrounds, abilities, motivations and aspirations. We've seen talents explode, helped keep people engaged and even watched interest fizzle. About the only constant is that everyone in every class wants to or needs to learn Drupal, whether they have decided on their own, or need to build their Drupal talent as part of a developer team.

Every so often, we run into a student who really brings to life our vision of what the course can help people accomplish; someone who does everything before, during and after that just exudes enthusiasm and commitment toward predictable success. Brian Coffelt (@briancoffelt), a student in the Spring 2015 Drupal Career Online session, and now Web Administrator and Developer for Duke Cancer Institute in Durham, NC, is one of those sensations.

Brian, after 15 years of serving as a public school health and physical education teacher, realized he was in a situation that fell short of providing him the professional fulfillment and the type of income potential he desired. "I wanted to challenge myself and better provide for my family," he recalls. "I learned of Drupal from my brother-in-law (Shaun Heath, an earlier DrupalEasy graduate) and began to research how powerful Drupal was. I also saw a great need for quality Drupal developers and a promising job market."

The Drupal job market was actually the key ingredient in the creation of DrupalEasy's long-form career technical education program, which was born as a solution for Florida's Space Coast when the end of the Shuttle program left about 7,000 people, including lots of IT-types, without jobs. The in-person course was a hit, and the positive outcomes led us to make things official, with a license through the Florida Department of Education, Commission for Independent Education, which we continually qualify for and renew annually. Since we moved the course live-online, we've been able to train up people in Drupal from all over the country.

Brian lived in Nashville at the time he started the program. He came to us with a not-so relevant degree in education, but made up for it with true desire, commitment and hard work. He dove straight into course curriculum as a star student from the first day. "His comprehension was very high, most likely because of his diligence and strong interest in the topics," says Mike Anello (@ultimike), who created and teaches the DCO. It also had a lot to do with his self-study before the class even started; delving into a roadmap of languages, frameworks, and workflows that Shaun provided and that he researched in preparation.

"During the training, I made it a point to watch all DCO webcasts before class to ensure that I retained the concepts. Mike also recommended additional courses and topics to look into which I took full advantage of," he explained. He also participated in every optional co-working lab during the course, and completed every assignment and project. Brian was very comfortable with his abilities, and once the course ended, skipped going for an internship and sent out applications and landed a full-time Drupal developer job almost immediately. Brian and his family later relocated from Tennessee to North Carolina for his current position, where he's found his niche in front-end development for Duke.

Even now, Brian is still eager to learn. "I try to attend the DrupalEasy office hours when it fits into my work schedule," he says. Mike holds Thursday office hours for all current and former students, to get information and help with issues, both from Mike and the others in the DrupalEasy learning community that's been formed. The learning community, especially former classmates are important to Brian as well. He keeps in touch with one fellow student several times a week, with whom he has also collaborated on Drupal projects and attend DrupalCamps together.

Brian maintains his status as a rising star in Drupal by seeking out professional development and Drupal learning as much as possible, attending local Drupal meetups as often as he can, participating in the Duke Drupal users group and going to camps and cons when he can. He also spends at least a couple of hours a week reading up on the newest trends in Drupal, although, he explains, "Fatherhood cuts into my reading time quite a bit."

According to Brian, "the best part of Drupal development is the satisfaction that comes with creating quality work. A close second would be the Drupal community." He set out with a goal for professional fulfillment and greater opportunities for his family. "My new Drupal career has allowed me to attend events throughout the country. The pay scale and benefits available to me now greatly outweigh those of a public school teacher. I also enjoy the ability to work remotely from home when needed. This flexibility is in stark contrast to my previous profession," he explains. Mission accomplished!

He also offers a bit of guidance for those looking to become Drupal developers. "My advice to someone learning Drupal is that you get what you put into it. If you sacrifice your time and energy, Drupal can be very rewarding. There's plenty of opportunities for those who are willing to work hard and push themselves." he explains. He continued, "I can't recommend DrupalEasy enough! It has opened so many doors for me and the instruction I received was second to none!"

The next session of Drupal Career Online starts in October. You can learn more about Drupal, Drupal Careers and our career training program at an upcoming Taste of Drupal free mini-webinar.

Jun 12 2017
Jun 12

Over the past 6 years, we've training hundreds of people through our 12-week Drupal Career Online class, our new 6-week Mastering Professional Drupal Developer Workflows with Pantheon class, as well as our dozens of public and private trainings (literally) around the world. As part of our long-form 12- and 6-week classes, we've been providing on-going support for our graduates in the form of DrupalEasy Office Hours.

Each week, we set aside two hours for any current student or graduate of any of our long-form classes to join our online classroom to ask just about any Drupal-related question they have. It might be about a project they're working on, something they learned in the course, or advice on how to tackle something that is a bit outside of their comfort zone. Regularly using screen-sharing, we can almost always help the person with their request - and most of the time, those watching pick up a thing or two as well.

The most rewarding aspect of DrupalEasy Office Hours (for us, at least) is watching students helping students. As Robert A. Heinlein once said, "when one teaches, two learn" is something that we try to encourage in all of our classes as well as DrupalEasy Office Hours.

This type of learning community has been a hallmark of what DrupalEasy training, consulting, and project coaching is all about. By engaging a subset of the larger Drupal community, our students gain experience, knowledge, and most of all - the confidence to ask fellow community members for help in an environment that is supportive and nurturing. 

Over the past few years, we've heard of similar programs by various Drupal shops who provide a similar service for their clients. We can't think of a better way to provide on-going goodwill and mentoring.

If you're a graduate of one of our long-form classes, be sure to pop-in and say hello (contact us for details). 

Mar 10 2017
Mar 10

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

Here at DrupalEasy, we're such big fans of Drupal Console, we've designed our "Introduction to Drupal 8 Module Development" full-day workshop around it (<shameless-plug>we're offering it at DrupalCon Baltimore</shameless-plug>). To some newcomers, getting Drupal Console up-and-running can be a bit tedious as there are a few ways to install it. Plus, the distinction between the Drupal Console Launcher (global executable) and the rest of Drupal Console can be confusing.

This blog post's goal is to describe one method for installing Drupal Console Launcher and Drupal Console on an existing Drupal 8 site. This example will not utilize a fully-Composer-ized™ Drupal 8 install (possibly expect a second blog post once best practices evolve a bit more - see below), rather it will focus on a "standard" (old school?) Drupal install via traditional methods. That being said, you'll still need Composer installed, as we're going to use it to install part of Drupal Console (a bit confusing, I know). 

So, let's assume you have a local Drupal 8 instance installed and up-and-running on your local machine. For this exercise, your local development environment doesn't matter all that much unless you're running a virtualized solution. If you are, you're probably clever enough to modify these instructions appropriately. In the past, I've often used Acquia Dev Desktop when teaching new students to use Drupal, so I can confirm that these instructions work just fine in that environment. The only real prerequisite is that Drupal Console requires PHP 5.5.9 (on the command line) or higher.

As mentioned above, there are actually two parts of Drupal Console that users are strongly recommended to install - the "Drupal Console Launcher" and "Drupal Console" itself. The launcher is installed globally on your machine, while Drupal Console is installed separately on each of your local Drupal 8 projects. This is a bit different than earlier (pre-release-candidate) versions of Drupal Console, and can be a source of confusion.

Installing the launcher should be pretty straight-forward on Mac or Linux as there's a simple curl command:

curl https://drupalconsole.com/installer -L -o drupal.phar

Once downloaded, run:

mv drupal.phar /usr/local/bin/drupal
chmod +x /usr/local/bin/drupal

These commands will move the launcher into your /usr/local/bin directory and set it to be executable by everyone. You may need to use "sudo" with the "mv" command.

On Windows the project documentation is pretty good (as well as this Evolving Web blog post by Dave Vasilevsky). With just the launcher installed, you're limited to just a few Drupal Console commands involving installing (via the very cool "chain" command) Drupal, working with generic .yml files, and some Drupal Console non-site-specific functionality. 

You can verify the launcher is installed properly by doing a drupal about command from anywhere in your file system - this will show you the current version of the launcher as well as some available commands. 

It is the launcher's job to provide the global executable for which to run Drupal Console commands against any site on your system from any location (using the --root option - similar to the Drush --uri option) or by running the command from inside the site root. 

But, in order to run most Drupal Console commands (including the glorious "generate" related ones), each Drupal 8 site on your local must have Drupal Console (and its dependencies) installed. Luckily, this is pretty easy to do as well. Navigate into your site root, then (because Drupal 8 ships with composer support) run the following command to install:

composer require drupal/console:~1.0 --prefer-dist --optimize-autoloader --sort-packages

This will modify your site's composer.json and composer.lock files with their new Drupal Console dependency and then download Drupal Console and all of its dependencies into the site's vendor directory. That's it - you're done! Remember - you must do this for each Drupal 8 site on your local. 

You can test the Drupal Console goodness with a drupal site:status command (similar to drush status). Once confirmed, you're good to start using Drupal Console to help you generate all those custom modules.

Updating Drupal Console

Looking at the Drupal Console project page, it's easy to see that it's still a work in progress (there are commits almost daily). So, the next (hopefully) obvious question is "how do I update Drupal Console"? Well, first off, remember that there are now two things to update - the global launcher as well as all the Drupal Console stuff in your site's vendor directory. 

To update the global launcher, navigate to somewhere outside of your Drupal 8 site (your home directory works) and run drupal self-update (you may need to use "sudo"). 

To update your site's Drupal Console "stuff" (I'm struggling to figure out exactly what to call it - "files"? "dependencies"?, "code"? I'm open to suggestions), navigate to your site root and, remembering that we used Composer to install it, run the following command to update it:

composer update drupal/console --with-dependencies

Keep in mind that you'll need to do this for each Drupal 8 site on your machine.

The Future?

So, what will the differences in this blog post be once we all fully embrace Composer as the-one-and-only-way-to-manage-Drupal-projects? I'm not entirely sure there will be any. Stay tuned.

Feb 27 2017
Feb 27

People in auditorium

Last weekend the Florida Drupal community hosted its ninth annual Florida DrupalCamp (FLDC) at Florida Technical College in Orlando.  It was a great success. At this point, we (the organizers) have a pretty good idea how to put on this event. (Since a good number of us have been involved in all nine iterations, (and all still seem to like each other!) some aspects of the camp organizing process are on veritable auto-pilot.

If you're a camp organizer, you know what goes into securing sponsors and a location, spreading the word, finding presenters, arranging for swag and catering, etc… For this year's event, we wanted to step things up a bit by focusing on three things: more learning, more fun, and more networking. Based on feedback and our own experiences, we feel like we achieved all three goals with some changes from previous years' camp recipes.

More Learning

In the past, FLDC has been a 2-day event; Saturday has been the main event - a day full of sessions, while Sunday has been a "community day" with sprints, Coding for a Cause, BoFs, and a generally less-defined schedule. 

This year we decided we stepped it up to a full-on three-day event; full-day training workshops on Friday, sessions on Saturday and Sunday, as well as a professionally mentored code sprint on Sunday. 

Adam Bergstein session

With the generosity of five trainers, we were able to provide full-day workshops to almost 80 people on Friday. Many, many, many thanks to our trainers:

Code sprint

The other change to facilitate more learning is to provide experienced sprint mentors for our Sunday sprint. With a nudge or two (maybe three) from xjm, we decided to have a Major Issue Triage Sprint at this year's camp. We brought in YesCT and nerdstein to mentor the sprinters to great success. During the Sunday sprint, we were able to make progress on well over 20 Drupal core major issues.

Finally, we decided to bring in Kevin Thull (@kevinjthull) to handle all the session recording, processing, and uploading for the event. Kevin's work with recording other Drupal events is top-notch. Having all of our sessions recorded will allow those who weren't able to attend (or those who did attend but couldn't make a particular session) to be able to benefit from our speakers. All of the sessions are currently posted on our website schedule, as well as on our Youtube channel.

More Networking

Traditionally, we have always had a full-day beginner track on the main day of the camp. This had the effect of keeping the vast majority of the beginners in the same room all day - limiting their networking opportunities. By having a full-day introductory workshop on Friday, beginners became fully-involved in camp activities the rest of the weekend. The feedback we received from this change is overwhelmingly positive.

The other big-ish change aimed at more networking was to increase the amount of time between each session to a full 30 minutes. This had the side-effect of us having fewer sessions on Saturday, but was mitigated by adding a half-day of sessions on Sunday. Again, the response we received from this change was overwhelmingly positive. It provided a less "rushed" day for all attendees, gave presenters a little more leeway if they went a few minutes over their allotted window, and provided ample time for the hallway track. In addition, our sponsors loved this change, as it gave attendees more time to stop and chat with sponsors in our exhibition area. 

During the closing session, we announced that any leftover funds from the event can (and should!) be used by Florida local meetup organizers to promote and grow their local meetups. In the past, we've informally made these funds available, but we're going all-in this year. If you're a Florida Drupal meetup organizer, we have $$$ for you for meetup.com memberships, food for your meetups, or just about anything else that will help you grow your local community. Look for more details on https://groups.drupal.org/florida soon.  

More Fun

While Drupal events tend to be very positive events for all attendees, we made the conscious decision to ensure that we maximized the enjoyment of our attendees while we kept the Drupal knowledge flowing. It was also very important to us that we make a positive first impression on those new to Drupal and attending one of their first Drupal events. We wanted folks to be able to leave the event with positive feelings for the Florida Drupal community. 

Networking at the after party.

To this end, we increased the fun factor in several ways. First off, we further "official-ized" our Friday night dinner gathering. Over the past few years, organizers and a few others have always gathered at Bubbalou's a local BBQ restaurant just down the street from the camp venue after prepping the venue for the event. This year, with the full-day trainings on Friday, we invited everyone to meet up at the restaurant for a pay-on-your-own dinner. This turned into a wonderful, casual evening for well over 75 people. The restaurant has a large indoor/outdoor picnic table eating area, perfect for networking. 

Suzanne Dergacheva with Skywalker

On Saturday, we set the tone early and put smiles on people's faces from the very start. We worked with the folks from Gatorland to have a professional animal handler and a friendly alligator named Skywalker on-hand to greet guests when they arrived. Many attendees went for a cuddle with Skywalker even before getting coffee. 

Druplicon chocolates

Additionally, we wanted to provide unique swag to our attendees. A former attendee of previous Florida DrupalCamps, Kathryn Neel, is now running custom chocolate business, Sappho Chocolates. We worked with her company to create Druplicon chocolates for all attendees. As part of the process, we funded the development of the custom molds for the Druplicon chocolates, so if any other Drupal event organizers want to order chocolates for their event, the molds are there for your use!

Finally, for the last Saturday session, we went with a single session of lightning talks. This ended up being one of the highlights of the weekend, as we had a some amazing 5 minutes talks. With most of the camp attendees in the room, it left everyone with smiles on their faces and provided a great transition to the closing session and after party. 

Sponsor Happiness

Most camp organizers always have trepidation about camp finances right up to the actual event. Sponsor needs have evolved as the Drupal community has evolved, and camp organizers have to evolve as well. Today's Drupal event sponsors are more focused on getting a return-on-investment from their sponsorship dollars than ever before, so it is up to event organizers to do everything they can to make that happen. 

By providing more time for attendees to visit sponsor tables as well as the opportunity for Platinum and Gold sponsors to receive an opt-in version of our attendee list, as well as all of the other "standard" sponsor benefits, the feedback from our sponsors has been very positive. Additionally, we gave Platinum and Gold sponsors the opportunity to place text ads in our emails to attendees leading up to the camp.

Achieve Agency logo

Our Platinum sponsor, Achieve Agency is a newly-formed Florida digital agency based in West Palm Beach. John Studdard, their COO (and formerly of Big Couch Media), has been a long-time FLDC supporter and attendee, and wanted to use FLDC as a vehicle to announce Achieve Agency to the community. As event organizers, we couldn't be happier that our top-level sponsor is a Florida-based organization. 

Featured Speakers

Megan Sanicki at FLDC17.

Keeping with our tradition of not having a single keynote speaker (mainly due to the fact that our venue's auditorium can't accommodate all attendees, we invited three featured speakers to this year's event. We were lucky to get our top three choices - check out their (recorded) sessions below:

Room for Improvement

As always, our post-camp organizer retrospective highlights a few areas we need to address for next year's event.

  • Have a printer on-hand for printing emergencies.  
  • Find a volunteer to arrange for food donations for left-overs.  
  • Figure out a magical solution for badges that will make everyone happy.  
  • Find a new official hotel: We had a fair number of complaints.  
  • Figure out a way to improve the slow service at the after-party.  

Quick hits

  • Camp attendance was a bit more than last year. Overall, we had 251 registered attendees. A bit more than 100 participated on Friday, almost 200 participated on Saturday, and about 100 participated on Sunday.  
  • Camp budget was about $18,000, the majority went to catering, but we also had significant costs for featured speakers and sprint leads travel and swag.  
  • We had a total of 17 fiscal sponsors which provided about two-thirds of our income.  
  • The registration fee for attendees was $35 ($25 early-bird), with an optional $25 individual sponsorship. We had 41 individual sponsors.  
  • Our camp organizing volunteers are way better than yours.  
  • We invested a bit this year in large signage that we can re-use in future years.  
  • Another change this year - volunteers got in for free (sorry this took so long).  
  • We had attendees from 9 countries and 19 states.  

Summary

What more can we say? Florida DrupalCamp 2017 was a huge success. Our volunteers are the best, our sponsors are the best, and the Florida community is the best!

Be on the lookout for an announcement about the dates for Florida DrupalCamp 2018 by joining our mailing list and following us on Twitter!

Jan 25 2017
Jan 25
Take your time concept clockMiriam Webster defines effort as conscious exertion of power: hard work

If you want to learn Drupal, you need to put forth some effort, and if you want to do it properly, get ready to exert some power for months, not days.  People ask us all the time if they can get a job right out of our Drupal Career Online program. The truth is, it depends on how much hard work you put in to get out ready enough for an internship or junior position. Whether it’s Drupal or anything else, learning something and being able to apply it well depends on how much you absorb and practice, both of which are best done over time.

Last summer, James Dennin wrote an insightful piece of advice for those seeking careers in coding for Fusion.net. It touches on a lot of the same issues with bootcamps that we have heard about for years from students who come to DrupalEasy Academy after disappointing experiences. While we don’t like to throw barbs, we like less the sad stories of lost dollars and time in unguided crash courses where people are seated in a room, immersed in videos and teamed with other, non-skilled newbies on trying learn Drupal. A 5- or 10-day whirlwind of information overload is seldom a successful learning experience.

Becoming proficient in Drupal is no cakewalk; it includes amassing knowledge, learning best practices and developing skills as part of a challenging learning process, whatever your process may include. Education experts recognize as many as seven different styles of learning, including:  Visual, Aural, Verbal, Physical, LogicalSocial and Solitary. Most people find a combination works best. For anyone, regardless of the learning style; taking the time to really soak it in and get some hands on experience is key. The bottom line is that Drupal takes time and practice.

For those who do well on the solitary route, Build-a-Module, which routinely supports students and alumni of our career training program, has a solid, comprehensive library of instructional videos that you can take your time to work through with a modest monthly subscription.  You can also check out Drupalize.me.

For those who learn better with a formal course or need to train-up a team; our Drupal Career Online program uses live instruction; a stackable-skill designed curriculum; practical exercises; and group learning.  We also provide resources like lesson guides, screencasts for every lesson, and help when you need it. In addition to all the great feedback we get from our students and all the great graduate case studies, we ensure our program meets accepted educational standards as a career program, so we go through an annual review to ensure we remain a licensed, post-secondary institution through the Florida Department of Education, Commission for Independent Education (see page 21 of the linked PDF.)  

We are committed to Drupal and developing awesome Drupal talent, which is why we cringe when we hear about drinking-out-of-the-firehose learning scenarios. It is also why we have been perfecting our course (yes even making it longer) over the past 6 years. Best practices and allowing students the time to soak up what they’ve learned, along with hands-on projects and expert-developer instruction are fundamental elements of Drupal Career Online. It includes 84 hours of live, online instruction over 12 weeks as part of the learning community of current students and alumni. The course covers practical projects and assignments, and includes 12 co-working labs and instructor office hours, which are available to current students and alumni every week. The Spring 2017 session begins March 13, with the deadline to apply March 6.  

For most, learning anything, especially Drupal, is a process that takes an investment of time and effort, not just from the students, but from those who endeavor to help them learn.  Don’t cheat yourself and risk wasted time by trying to save time. Whatever learning styles work for you, make sure you take the time and put in the effort to follow a logical path that builds knowledge and helps you get comfortable with key skills in the way that ensures your hard work leads to your ultimate success.

For more resources about becoming a Drupal developer, take a look at our Career Resources.  To learn more about our upcoming Drupal Career Online Spring session, sign up for one of our free Taste of Drupal online information sessions in February.

take your time concept clock Photos by Pond5

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