Feb 06 2020
Feb 06

Thomas Edison famously said, "The three great essentials to achieve anything worthwhile are, first, hard work; second, stick-to-itiveness; third, common sense." This quote made me wonder if "sticking-to-it" is contradictory to innovation; does it make you resistant to change? But, the more I pondered on it, I realized that innovation is fueled by perseverance.

Before Drupal 8 was introduced, the Core committee had not just promised to innovate; they decided to be persistent. Persistent in continuous reinvention. Persistent in making Drupal easier to adopt—not only by the market but also by developers with various levels of expertise. However, to be able to make Drupal successful and relevant in the long run, a drastic change was needed—a change that would build a better future. For this, Drupal 8 had to dismantle the Drupal 7 architecture and lay a fresh foundation for a promising future. Moving on to Drupal 9 (coming soon) and subsequent versions will now be easy and straightforward.

Freedom to innovate with open source

Innovation brings freedom, and freedom creates innovation. Open source gives you the freedom to access, learn, contribute, and, most importantly, the freedom to innovate. The ability to learn, catch up, and reinvent is extremely crucial today. Drupal began as a small internal news website and later went on to become an open source content management system (CMS) because there was a potential to make it much more compelling by attracting more contributions. It gave developers the freedom to collaborate, re-use components, and improvise on it to create something more modern, powerful, and relevant.

Promises delivered: Drupal 8 version history

The web is always changing. To stay relevant, Drupal had to introduce changes that were revolutionary but, at the same time, not so hard to accept. Drupal 7, as a content management system, was widely welcomed. But it lacked in certain aspects like developer adoptability, easy upgrade paths, better API support, and more. Drupal 8 changed everything. They did not choose to build upon Drupal 7, which would have been an easier choice for an open source CMS. For a more future-proof CMS that is ready to accept changes, Drupal 8 had to be rebuilt with more modern components like Symfony, Twig, PHP 7, and initiatives like the API-first initiative, mobile-first initiative, Configuration Management initiative, etc.

Drupal 8 was released with a promise of providing more ambitious digital experiences with better UX improvements and mobile compatibilities. The goal was to continuously innovate and reinvent itself. For this to work, these practices needed to be put in place: semantic versioning (major.minor.patch), scheduled releases (two minor releases per year), and introducing experimental modules in Core. All of this while providing backward compatibility and removing deprecated code.

Let’s look at some of the promises that have been delivered with each minor version of Drupal 8.

  • Drupal 8.0
    • Modern and sophisticated PHP practices, object-oriented programming, and libraries.
    • Storage and management of configuration was a bit of a messy affair with Drupal 7. The Configuration Management Initiative was introduced with Drupal 8.0, which allowed for cleaner installations and config management. Configurations are now stored in easily readable YAML format files. These config files can also be readily imported. This allows for smooth and easy transitions to different deployment environments.
    • Adding Symfony components drastically improved Drupal 8’s flexibility, performance, and robustness. Symfony is an open source PHP framework, and it abides by the MVC (Model-View-Controller) architecture.
    • Twig is a powerful template engine for PHP, replaced Drupal’s engine since 2005, PHPTemplate. With Twig, the code is now more readable, and the theme system is less complex, uses inheritance to avoid redundant code, and offers more security by sanitizing variables and functions.
    • The Entity API, which was quite limited and a contributed module in Drupal 7, is now full-fledged and is in Drupal 8 Core. Since Drupal 8 treats everything as an "entity," the Entity API provides a standardized method of working with them.
    • The CKEditor, which is a WYSIWYG (What You See Is What You Get) editor, was introduced. It allows for editing on the go, in-context editing, and previewing your changes before it gets published.
  • Drupal 8.1
    • The alpha version of the BigPipe module got introduced to Core as an experimental module. BigPipe renders Drupal 8 pages faster using methods like caching and auto-placeholder-ing.
    • A Migrate UI module suite got introduced to Core as an experimental module. It makes migrating from Drupal 7 to Drupal 8 easier.
    • The CKEditor now includes spell-check functionality and the ability to add optional languages in text.
    • Improved testing infrastructure and support especially for Javascript interactions.
    • Composer is an essential tool to manage third-party dependencies of websites and modules. With Drupal 8.1, Drupal Core and all its dependencies are now managed and packaged by Composer.
  • Drupal 8.2
    • The Place Block module is now an experimental module in Core. With this module, you can easily play around with blocks right from the web UI. Configuring and editing blogs can be done effortlessly.
    • A new Content Moderation module that is based on the contributed module Workbench Moderation has been introduced as an experimental module in Core. It allows for granular workflow permissions and support.
    • Content authoring experiences have been enhanced with better revision history and recovery.
    • Improved page caching for 404 responses.
  • Drupal 8.3
    • The BigPipe module is now stable!
    • More improvements in the CKEditor. A smooth copy-paste experience from Word, drag and drop images, and an Autogrow plugin that lets you work with bigger screen sizes and more.
    • Better admin status reporting for improved administrator experience.
    • The Field Layout module was added as an experimental module in Core. This module replaces the Display Suite in Drupal 7 and allows for arranging and assigning layouts to different content types.
  • Drupal 8.4
    • The 8.4 version calls for many stable releases of previously experimental modules.
    • Inline Form Errors module, which was introduced in Drupal 8.0, is now stable. With this module, form errors are placed next to the form element in question, and a summary of the errors is provided on the top of the form.
    • Another stable release—the DateTime Range module that allows date formats to match that of the Calendar module.
    • The Layout Discovery API, which was added as an experimental module in Drupal 8.3, is now stable and ready to roll. With this module, the Layout API is added to Drupal 8 Core. It has adopted the previously popular contributed modules—Panels and Panelizer—that were used extensively to create amazing layouts. Drupal 8’s Layout initiative has ensured that you have a powerful Layout building tool right out of the box.
    • The very popular Media module is added as an API for developers to be able to port a wide range of Media contributed modules from Drupal 7. For example, media modules like the Media entity, media entity document, media entity browser, media entity image, and more. However, this module is still hidden from site builders till the porting and fixing of issues are over with.
  • Drupal 8.5
    • One of the top goals that Drupal 8 set out to reach was making rich images, media integration, and asset management easier and better for content authors. It has successfully achieved this goal by adding the Media module now in Core (and it isn’t hidden anymore). 
    • Content Moderation module is now stable. Defining various levels and statuses of workflow and moving them around is effortless.
    • The Layout builder module is introduced as an experimental module. It gives site builders full control and flexibility to customize and built layouts from other layout components, blocks, and regions. This has been one of the top goals for Drupal 8 site builders.
    • The Migrate UI module suite that was experimental in Drupal 8.1 is now considered stable.
    • Big pipe module which got previously stable in version 8.5, now comes by default in the standard installation profile. All Drupal 8 sites are now faster by default.
    • PHP 7.2 is here, and Drupal 8.5 now runs on it and fully supports the new features and performance improvements that it offers.
  • Drupal 8.6
    • The very helpful oEmbed format is now supported in the Drupal 8.6 Media module. The oEmbed API helps in displaying embedded content when a URL for that resource is posted. Also included within the Media module is support for embedding YouTube and Vimeo videos.
    • An experimental Media Library module is now in Core. Adding and browsing multiple media is now supported and can also be customized.
    • A new demo site called Umami has been introduced that demonstrates Drupal 8's Core features. This installation profile can give a new site builder a peek into Drupal’s capabilities and allows them to play around with views, fields, and pages for learning purposes. It also acts as an excellent tool for Drupal agencies to showcase Drupal 8 to its customers.
    • Workspaces module is introduced as an experimental module. When you have multiple content packages that need to be reviewed (status change) and deployed, this module lets you do all of it together and saves you a lot of time.
    • Installing Drupal has now gotten easier with this version. It offers two new easy ways of installing Drupal. One with a "quick start" command that only requires you to have PHP installed. In the other option, the installer automatically identifies if there has been a previous installation and lets you install it from there.
  • Drupal 8.7
    • One of the most significant additions to Drupal Core that went straight there as a stable module is the JSON:API module. It takes forward Drupal’s API-first initiative and provides an easy way to build decoupled applications.
    • The Layout Builder module is now stable and better than ever before. It now even lets you work with unstructured data as well as fieldable entities.
    • Media Library module gets a fresh new look with this version release. Marketers and Content editors now have it much easier with the ability to search, attach, drag, and drop media files whenever and wherever they need it.
    • Fully supports PHP 7.3.
    • Taxonomy and Menu items are revision-able, which means that they can be used in editorial workflows and can be assigned statuses.
  • Drupal 8.8
    • This version is going to be the last minor version of Drupal 8 where you will find new features or deprecations. The next version, Drupal 8.9, will not include any new additions but will be very similar to Drupal 9.0.
    • The Media Library module is now stable and ready to use.
    • Workspaces module is now enhanced to include adding hierarchical workspaces. This gives more flexibility in the hands of the content editor. It also works with the Content Moderation module now.
    • Composer now receives native support and does not need external projects to package Drupal with its dependencies. You can create new projects with just a one-line command using Composer.
    • Keeping its promises on making Drupal easier to learn for newbies, a new experimental module for Help Topics has been introduced. Each module, theme, and installation profile can have task-based help topics.

Opening doors to a wider set of developers

Although Drupal was largely accepted and loved for its flexibility, resilience, and, most of all, its content management abilities, there was a nagging problem—the "deep learning curve" issue. While many Drupalers argue that the deep learning curve is part and parcel of a CMS that can build highly complex and powerful applications, finding Drupal talent is a challenge. Dries, the founder of Drupal, says, "For most people new to Drupal, Drupal 7 is really complex." He also adds that this could be because of holding on to procedural programming, large use of structured arrays, and more such "Drupalisms" (as he calls them).

This issue needed to be tackled. With Drupal 8 adopting modern platforms and standards like object-oriented programming concepts, latest PHP standards, Symfony framework, and design patterns, the doors are now flung wide open to a broad range of talent (site builders, themes, developers).

Final thoughts

"The whole of science is nothing more than a refinement of everyday thinking."– Albert Einstein.

Open source today is more than just free software. It is a body of collaborated knowledge and effort that is revolutionizing the digital ecosystem. The digital world is moving at a scarily rapid pace, and I believe it is only innovation and perseverance from open source communities that can bring it to speed. The Drupal community unwaveringly reinvents and refines itself each day, which is especially seen in the latest release of Drupal 8.

Mar 28 2019
Mar 28

Behavior-driven development is a great way to write tests for code because it uses language that real humans can understand. Once you learn about BDD and its benefits, you may want to implement it in your next project. Let's see how to implement BDD in Drupal using Behat with the Mink extension.

Since it is good practice to use Composer to manage a Drupal site's dependencies, use it to install the tools for BDD tests: Behat, Mink, and the Behat Drupal Extension. The Behat Drupal Extension lists Behat and Mink among its dependencies, so you can get all of the tools by installing the Behat Drupal Extension package:

composer require drupal/drupal-extension --dev

Mink allows you to write tests in a human-readable format. For example:

Given I am registered user,
When I visit the homepage,
Then I should see a personalized news feed

Because these tests are supposed to emulate user interaction, you can assume they will be executed within a web browser. That is where Mink comes into play. There are various browser emulators, such as Goutte and Selenium, and they all behave differently and have very different APIs. Mink allows you to write a test once and execute it in different browser emulators. In layman's terms, Mink allows you to control a browser programmatically to emulate a user's action.

Now that you have the tools installed, you should have a behat command available. If you run it:


you should get an error, like:

FeatureContext context class not found and can not be used

Start by initializing Behat:

./vendor/bin/behat --init

This will create two folders and one file, which we will revisit later; for now, running behat without the extra parameters should not yield an error. Instead, you should see an output similar to this:

No scenarios
No steps
0m0.00s (7.70Mb)

Now you are ready to write your first test, for example, to verify that website visitors can leave a message using the site-wide contact form.

Writing test scenarios

By default, Behat will look for files in the features folder that's created when the project is initialized. The file inside that folder should have the .feature extension. Let's tests the site-wide contact form. Creata a file contact-form.feature in the features folder with the following content:

Feature: Contact form
  In order to send a message to the site administrators
  As a visitor
  I should be able to use the site-wide contact form

: A visitor can use the site-wide contact form
    Given I am at "contact/feedback"
    When I fill in "name" with "John Doe"
    And I fill in "mail" with "[email protected]"
    And I fill in "subject" with "Hello world"
    And I fill in "message" with "Lorem Ipsum"
    And I press "Send message"
    Then I should see the text "Your message has been sent."

Behat tests are written in Gherkin, a human-readable format that follows the Context–Action–Outcome pattern. It consists of several special keywords that, when parsed, will execute commands to emulate a user's interaction with the website.

The sentences that start with the keywords Given, When, and Then indicate the Context, Action, and Outcome, respectively. They are called Steps and they should be written from the perspective of the user performing the action. Behat will read them and execute the corresponding Step Definitions. (More on this later.)

This example instructs the browser to visit a page under the "contact/feedback" link, fill in some field values, press a button, and check whether a message is present on the page to verify that the action worked. Run the test; your output should look similar to this:

1 scenario (1 undefined)
7 steps (7 undefined)
0m0.01s (8.01Mb)

 >> default suite has undefined steps. Please choose the context to generate snippets:

  [0] None
  [1] FeatureContext

Type 0 at the prompt to select the None option. This verifies that Behat found the test and tried to execute it, but it is complaining about undefined steps. These are the Step Definitions, PHP code that will execute the tasks required to fulfill the step. You can check which steps definitions are available by running:

./vendor/bin/behat -dl

Currently there are no step definitions, so you shouldn't see any output. You could write your own, but for now, you can use some provided by the Mink extension and the Behat Drupal Extension. Create a behat.yml file at the same level as the Features folder—not inside it—with the following contents:

       - FeatureContext
        - Drupal\DrupalExtension\Context\DrupalContext
        - Drupal\DrupalExtension\Context\MinkContext
        - Drupal\DrupalExtension\Context\MessageContext
        - Drupal\DrupalExtension\Context\DrushContext
: ~

Steps definitions are provided through Contexts. When you initialized Behat, it created a FeatureContext without any step definitions. In the example above, we are updating the configuration file to include this empty context along with others provided by the Drupal Behat Extension. Running ./vendor/bin/behat -dl again produces a list of 120+ steps you can use; here is a trimmed version of the output:

default | Given I am an anonymous user
default | When I visit :path
default | When I click :link
default | Then I (should )see the text :text

Now you can perform lots of actions. Run the tests again with ./vendor/bin/behat .The test should fail with an error similar to:

  Scenario: A visitor can use the site-wide contact form        # features/contact-form.feature:8
        And I am at "contact/feedback"                          # Drupal\DrupalExtension\Context\MinkContext::assertAtPath()
        When I fill in "name" with "John Doe"                   # Drupal\DrupalExtension\Context\MinkContext::fillField()
        And I fill in "mail" with "[email protected]"                # Drupal\DrupalExtension\Context\MinkContext::fillField()
        And I fill in "subject" with "Hello world"              # Drupal\DrupalExtension\Context\MinkContext::fillField()
        Form field with id|name|label|value|placeholder "subject" not found. (Behat\Mink\Exception\ElementNotFoundException)
        And I fill in "message" with "Lorem Ipsum"              # Drupal\DrupalExtension\Context\MinkContext::fillField()
        And I press "Send message"                              # Drupal\DrupalExtension\Context\MinkContext::pressButton()
        Then I should see the text "Your message has been sent." # Drupal\DrupalExtension\Context\MinkContext::assertTextVisible()

--- Failed scenarios:


1 scenario (1 failed)
7 steps (3 passed, 1 failed, 3 skipped)
0m0.10s (12.84Mb)

The output shows that the first three steps—visiting the contact page and filling in the name and subject fields—worked. But the test fails when the user tries to enter the subject, then it skips the rest of the steps. These steps require you to use the name attribute of the HTML tag that renders the form field.

When I created the test, I purposely used the proper values for the name and address fields so they would pass. When in doubt, use your browser's developer tools to inspect the source code and find the proper values you should use. By doing this, I found I should use subject[0][value] for the subject and message[0][value] for the message. When I update my test to use those values and run it again, it should pass with flying colors and produce an output similar to:

1 scenario (1 passed)
7 steps (7 passed)
0m0.29s (12.88Mb)

Success! The test passes! In case you are wondering, I'm using the Goutte browser. It is a command line browser, and the driver to use it with Behat is installed as a dependency of the Behat Drupal Extension package.

Other things to note

As mentioned above, BDD tests should be written from the perspective of the user performing the action. Users don't think in terms of HTML name attributes. That is why writing tests using subject[0][value] and message[0][value] is both cryptic and not very user friendly. You can improve this by creating custom steps at features/bootstrap/FeatureContext.php, which was generated when Behat initialized.

Also, if you run the test several times, you will find that it starts failing. This is because Drupal, by default, imposes a limit of five submissions per hour. Each time you run the test, it's like a real user is performing the action. Once the limit is reached, you'll get an error on the Drupal interface. The test fails because the expected success message is missing.

This illustrates the importance of debugging your tests. There are some steps that can help with this, like Then print last drush output and Then I break. Better yet is using a real debugger, like Xdebug. You can also install other packages that provide more step definitions specifically for debugging purposes, like Behatch and Nuvole's extension,. For example, you can configure Behat to take a screenshot of the state of the browser when a test fails (if this capability is provided by the driver you're using).

Regarding drivers and browser emulators, Goutte doesn't support JavaScript. If a feature depends on JavaScript, you can test it by using the Selenium2Driver in combination with Geckodriver and Firefox. Every driver and browser has different features and capabilities. For example, the Goutte driver provides access to the response's HTTP status code, but the Selenium2Driver doesn't. (You can read more about drivers in Mink and Behat.) For Behat to pickup a javascript enabled driver/browser you need to annotate the scenario using the @javascript tag. Example:

 (feature description)

: An editor can select the author of a node from an autocomplete field
    (list of steps)

Another tag that is useful for Drupal sites is @api. This instructs the Behat Drupal Extension to use a driver that can perform operations specific to Drupal; for example, creating users and nodes for your tests. Although you could follow the registration process to create a user and assign roles, it is easier to simply use a step like Given I am logged in as a user with the "Authenticated user" role. For this to work, you need to specify whether you want to use the Drupal or Drush driver. Make sure to update your behat.yml file accordingly. For example, to use the Drupal driver:

: ~
: drupal
: ./relative/path/to/drupal

I hope this introduction to BDD testing in Drupal serves you well. If you have questions, feel free to add a comment below, send me an email to {my first name}@{my last name}.me  or a tweet at @dinarcon.

Mauricio Dinarte will present Behavior-Driven Development in Drupal 8 with Behat at DrupalCon in Seattle, April 8-12, 2019.

What to read next

Mar 27 2019
Mar 27

In the first part of this article, we explained why DevOps is the most important strategy for modern technology organizations. To learn more about how DevOps is being used, we launched the 2019 Drupal Community DevOps Survey, which is collecting data until we present the results at DrupalCon on April 10. The survey asks Drupal community members to assess their teams across 24 DevOps dimensions using a Likert scale.

Each dimension in the survey is scored, averaged across all respondents, and then rolled up into an overall score. Each DevOps dimension is also scored and can be considered individually for the value it has to the team and how the team might start or improve on it. Even though the survey is still in progress as we're writing this, the results (which are updated as responses come in) already seem to be stabilizing across the Drupal community.

The Drupal community has been floating somewhere in the mid-60s on its use of DevOps practices. While the real value is for a team to track its high-level improvement over time, it could be understood superficially as meaning the Drupal community feels like it is consistent with DevOps practices a bit more than some of the time.

A quick-win opportunity: Releasing code quickly

If we scan the results for a high impact, easy win, we might choose something like:

How often is it safe and possible to release code to a production environment at any time?

At 83%, most teams are well on their way and don't have much further to go on this high-impact dimension of DevOps. This means that, for many, this is a solved problem—and with some quick learning and initiative, any team could be well on its way to consistency on this dimension.

Why it's valuable to be consistent

We've likely all had the experience of releasing some kind of critical bug to production. Breaking production eventually is inevitable, and DevOps prioritizes moving quickly over avoiding breakage at any cost. In this case, "moving quickly" means being able to release a hotfix right away to fix the issue. This is impossible if you have changes on your master branch that you aren't 100% sure are ready to go.

How to start

It's hard to beat the GitFlow model for ensuring production can be fixed at any time. GitFlow keeps unreleased work on a separate branch (typically called "develop") until it is deployed. It is merged to the main branch (typically "master") only when it is deployed. This leaves master always clean for a hotfix and allows you to follow an abbreviated version of the normal release process during a hotfix.

Getting started is going to mean learning about version control and using it (if you aren't already—nearly 100% of Drupal respondents report consistently using version control in their work). From there, it's also important to get as much of your site's configuration into code, for example, Features for D7 or Configuration Management in D8 so that all work can be pulled around for review by others on the team. Finally, implementing basic continuous integration (CI) for running your test suite, along with continuous delivery (CD) to a preview environment for visual review, will decouple your ongoing feature development from the production pipeline and allow for more strategic deployments of ready branches or hotfixes as needed without jeopardizing the consistency of the master branch.

Fortunately, many services exist for working with Drupal in this way and can be learned and implemented to a basic degree without too much effort.

Another quick-win opportunity: Security

Another quick win in this 2019 Drupal Community DevOps Survey results set could be:

How often are security considerations made as early as possible rather than being left to the end of the process?

Security can be part of the process while determining how features will be developed. It can also be tested like everything else. And it is clearly a high-impact improvement and should be easy to gain traction, as it starts with a mindset shift that can be learned and practiced.

Why it's valuable to be consistent

When people think of security issues, they tend to think of a single "hole" an attacker slips through to cause a breach. Modern web applications have hundreds or thousands of these tiny security holes, every one of which could be the source of a security issue that could bankrupt the company. Instead of thinking of security as a boolean (secure/not secure) value, think of it as a scale. To move toward the secure end of the scale, you need to prevent or catch security issues before they make it to production.

To accomplish this, you will need security consciousness at every stage of the process.

How to start

On the business end, consider the types of actions you want users to be able to perform. In architecture, design for defense-in-depth. In development, educate yourself on how to use the security mechanisms provided by the framework. In QA, learn how to exploit an application and actively attempt to do so. Considering security at every stage of the process will reduce (but never eliminate) the volume of security issues the team produces.

In Drupal, it's important to ask questions about things like user accounts, forms, integrations, secure libraries and frameworks, and security updates. Following are some questions, using user accounts as example responses, to ask as early as possible:

  • What are we working on? Users can log in for special access to features.
  • What can go wrong? The user's role is misconfigured to allow too much access, causing either business loss or technical disruption.
  • What can we do about it? We can test the roles for misconfiguration on every commit using automated testing and continuous integration.
  • Did we do a good job? Do these tests cover everything? What more could be done?

For more ideas, see Threat Modeling Designing for Security.

How to improve

There are ways to automate some types of security checks. They will be specific to your environment, but some ideas that have worked well include:

  • Test for XSS vulnerabilities by automatically filling your data structures with "malicious" strings then testing for whether those strings are escaped in your output.
  • Monitor your third-party dependencies for insecure libraries and alert when a security update is available. (Bonus: automate a pull request for updating the library.)
  • Include SQL injection strings (e.g., drop tables) when filling out forms during automated testing.

In Drupal, automation offers some chances to do some incredibly robust automated tests with very little effort, if you're clever about it. For example, we can get full-site XSS coverage just by injecting XSS strings at entity load and checking various pages for leakage. There's also a lot that can be done with permissions, like verifying that nobody but the admin user has "dangerous" permissions.

These kinds of tests are possible because of the Drupal CMS, and we should be working as a community to make them accessible and usable to any team who wants them. Having this level of robust automated testing in Drupal enables us to respond quickly in the event of a zero-day vulnerability, since these tests will catch such issues before deployment that would have been disastrous had the release gone out.

A bigger challenge: Test coverage

The Drupal community's DevOps dimension that needed the most attention was:

When features are developed, tests can be written to verify whether they are providing business value. How often are the tests written in a way that allows them to be run in a CI environment?

You'll likely need some pretty good momentum going on your team to tackle this one, but it is well worth it.

How to start

When determining which features need to be tested, consider which ones would cause unplanned work if they broke. For example, if you are creating a recipe database and one of your features is a recipe-entry form, you would want to test that recipes can be entered and the form can be submitted because, without that feature, your application would no longer provide value to your users.

Once your tests are written, they will provide the most value if they are run in a CI system on every commit rather than on a schedule or in an ad-hoc way. This shortens the time it takes for a developer to become aware of a breakage they introduced—the goal is that they become aware of the breakage before they move to the next task so they won't have to switch contexts to come back to fix it.

How to improve

Even if you have an excellent manual-review process, including functional testing by a human, it will quickly become impossible to manually check every feature of your application. Instead, you should be looking to automated testing to cover (at minimum) your business-critical features. The value of this testing will multiply with the number of developers on the project, the number of commits pushed daily, and the number of business-critical features you have.

There are many options when it comes to testing, but here are two types that people generally use:

  • Unit: Exhaustive tests of a single "unit" of code (function, class, etc.). We often do less of this kind of testing for an application but leverage it for particularly complicated or important bits of code. Also, unit testing can force good design practices.
  • Functional: Tests of a piece of functionality as seen by a user, such as user log in. This type of testing can cover many different code paths, but typically it doesn't cover them exhaustively. This is a good choice for applications, and it is typically available using "behavioral" frameworks like Behat or Cucumber.

For Drupal, be sure to learn about Drupal Test Traits, which is a collection of traits "for testing Drupal sites that have user content (versus unpopulated sites)" by Moshe Weitzman, Jibran Ijaz, and Rob Bayliss. DTT was built to make functional testing easy because it operates on your installed site, so you don't need to worry about mocking up a site install from scratch with every test. It also provides tests that naturally evolve with your site since it uses the configuration you have today, not the configuration you wrote into the test.


Having an understanding of the context and history of DevOps will mean the difference between following and leading in an industry. If there's still time, please participate in the Drupal Community DevOps Survey so we can include your input in the results. 

Rob Bayliss and Kelly Albrecht will present the results of the 2019 Drupal Community DevOps Survey in their presentation DevOps: Why, How, and What and host a follow-up Birds of a Feather discussion at DrupalCon 2019 in Seattle, April 8-12.

What to read next

Jan 17 2017
Jan 17

Marina Paych was a newcomer to open source software when she left a non-governmental organization for a new start in the IT sector—on her birthday, no less. But the real surprise turned out to be open source. Fast forward two years and this head of organizational development runs an entire department, complete with a promotional staff that strategically markets her employer's open source web development services on a worldwide scale.

That employer is ADCI Solutions, headquartered in Siberia—Omsk, Russia, to be exact. Their vibrant firm is anything but a newcomer to Drupal, the community-centric platform they rely upon to craft, in Marina's words, "perfectly functioning solutions," including the visual identities of DrupalCon Barcelona 2015 and DrupalCon Dublin 2016. In the spirit of the corporate philosophy that drives her co-workers to become better versions of themselves, every day, Marina keeps busy in her managerial role. That includes both educating the greater Drupal community and sustaining her local Drupal community by welcoming new contributors to the mix.

What is the preferred way to embrace her target audience? We learn it is a recurring, series of events that is the product of hard and principled work. Marina balances it all with a dash of zany, evident by the end of this very long distance interview.

Why is there a need for community events in open source projects?

Since open source technologies are being maintained and developed by amateurs, communication is the only way to keep one direction and get a tangible outcome. Of course, it's possible to communicate online but it's not in the same league with a face-to-face talk. My personal opinion is that there is nothing more motivating than being among soulmates, talking to them in person, and sharing acquired experience.

Please introduce us to "Drupal Cafes." ADCI Solutions pioneered the concept?

A Drupal Cafe is one type of Drupal event that a local community can organize. It is an educational, half-day conference that usually includes several sessions on relevant and useful Drupal topics, and informal communication between participants.

I wouldn't say that we pioneered the concept of the Drupal Cafe. Our community is more or less young; many other local communities started organizing similar meetups much earlier.

As a marketer, how would you describe the vision of this initiative?

From a marketer's point of view there is a huge outcome from such events in terms of Drupal popularization. These events kill two birds with one stone: they broaden the knowledge of current developers, and help engage more people with Drupal.

If I were to create a concrete vision statement, I would put it like this: raising awareness about Drupal while educating developers in order to improve Drupal at large.

Which analytics are most useful for gauging demand? Or do you wing it?

When you are planning your event, you better have numerical goals for the main processes, in order to understand whether you did great or need some improvements next time. The number of people you want to have at your event is one of the most important. All your promotional activities should be planned and implemented based on this goal.

You should also keep in mind that not everyone who submits a registration form will attend. That's called a conversion rate. It varies a lot in different territories. For example, if I want to have 75 people at my Drupal Cafe, the number of submitted registration forms averages out to 125, because our conversion is 60%.

After organizing a couple of your own events, you will know your approximate conversion rate and will no longer need to guess it. Once you know it, then you will to make more accurate predictions.

How do you think community fits into a newcomer's mindset, awareness, and (hopefully) heart?

Based on my experience, a newcomer's impression about a community depends very heavily on the first interaction with that community. In other words, if the first meetup is amazing and full of "wow moments," the community will fit into the newcomer's heart.

I see a lot of examples of this at our events. Developers who haven't worked with Drupal before and attend a well-organized event with an interesting agenda are most likely to come again. Otherwise, if the first interaction is bad, a newcomer will extrapolate it both to a technology and its community, which why we always have to deliver well-prepared events.

You are in Siberia. Tell us about a "wow moment" from one of your local events.

Each time we organize an event we try to include some extra agenda in it to diversify the attendees' experience. As one of our goals is to develop and strengthen our local community, those activities are aimed at encouraging either communication among participants or paying more attention to sessions' content.

One of the funniest activities we have done is an adapted "bullshit bingo" game. We call it Drupal Bingo. Before the event starts, participants get a list of random words they have to cross out when they hear them said by any speaker during the sessions. The one who crosses out all the words first stands up and shouts something funny (even in the middle of a session). The winner immediately gets a prize, everyone applauds, and the session continues.

The first time we did it the prize was a pineapple, which was also fun.

The Drupal Association is hosting the ADCI Solutions webcast, How to Grow Your Drupal Cafe from 10 People to 100. In it you will see Marina detail her strategic methods.

Sep 27 2016
Sep 27

At DrupalCon Dublin 2016, Nikhil Sukul and Vidit Anjaria will discuss animation with Drupal.

Basics of animation


The first hints of 'animation' come from a pottery bowl in Iran, around 5000 years ago. Skip ahead to the 1500s, Leonardo Da Vinci had a few drawings depicting animations. And today, you might think of Walt Disney as the modern animation master.


To make sure we're on the same page: Animation is "the technique of photographing successive drawings or positions of puppets or models to create an illusion of movement." Our eyes cannot view individual objects moving faster than 60 frames per second, so web animation is a series of computer graphics shown in succession at a rate faster than 60 frames per second.


There are 12 basic principles in animations: Squash and Stretch, Anticipation, Staging, Straight Ahead Action and Pose-to-Pose, Follow Through and Overlapping Action, Slow In and Slow Out, Arc, Secondary Action, Timing, Exaggeration, Solid Drawing, and Appeal. Here's a bit more on four of them.

  1. Anticipation: The action predicted from the before action is known as Anticipation. For example, hitting a pile of wood with an axe requires an action of taking the axe back of our head and then hitting on the wood with tremendous force. Taking the axe back of our head is considered as Anticipation. Another example can be, body movements of a pitcher in a baseball game, just before the pitcher actually throws the ball. Based on the pitcher's body movements it is anticipated that the ball will be thrown.

  2. Secondary Action: The reaction of the action is known as secondary action. For example, when a ball touches the ground and kicks up the dust. In this case, ball touching the ground is a Primary action and dust is getting kicked up is Secondary action. Another example could be, spilling out of water while a person is diving in the swimming pool, is a Secondary action.

  3. Staging: When we need to show or highlight only one animated objects from the group of all, we use the staging method. For example, if we are creating a modal popup window which is stagedto show in the middle of the browser screen and disabling all other controls in the background.

  4. Slow-in Slow-out: In animation every object start slow and then reached its appropriate speed and then should slow down to finish the animation. Or it can be that it start fast but slow down at the end to finish. In CSS this is known as easing.

Using Flash

Animation on the web started in 1987 with the invention of the animated GIF, or Graphic Interface Format. GIFs were used mostly for advertisements on websites, but had some problems with the pixelation. Then, in the 1990s Adobe introduced Flash, a tool for animating with audio. This created a revolution and was the best way to do animation on websites for a very long time. But Flash has some issues.

  1. Closed source: Users must purchase Flash from Adobe and cannot make modifications to the software.

  2. Security: Flash allows writing and running complex scripts on websites and scripts can be written that directly access the memory of a computer.

  3. Performance: Flash websites can take a long time to load.

  4. Resource hog: Flash uses a high amount of computing resources and can actually hang or crash your system if multiple applications or flash sites are opened at the same time.

  5. Plugin dependency: You need to have flash plugin installed in your browser. And every month or more, you need to update it.

Using CSS and JavaScript

To achieve animation on a website, we can use open source technologies like CSS and JavaScript.

With CSS, we use animation, transition, and transform properties as parameters. When using animation property, the keyframe property must be used to divide the animation into small pieces. Then we apply necessary transition or transform properties to each piece.

With JavaScript and jQuery, we use the animate() function and apply transformation and transition properties. Other functions are available in jQuery, which we can use directly: they are fadein(), fadeout(), slidedown(), slideup(), as well as the show() and hide() function for adding little delay, which will help to achieve animation.

A key to web animation is to hit the property which has less impact on the browser render capability.

Performance of the website depends completely on the technology we choose for implementation. While implementing robust logic, CSS animations will always be lighter than JavaScript animations. Most of the browsers use position, scale, rotation and opacity very lightly. If we are maintaining 60 fps (frames per second), it will not impact the performance as much. The higher we start on the timeline waterfall, the more work the browser has to do to get pixels onto the screen.

From a business perspective, we can use animation almost anywhere, but mostly it is used to promote the features of a product, like online tutorials and courses, online games, e-commerce websites, interactive portfolios, and much more.

Sep 22 2016
Sep 22

Drupal began as a forum for a few friends to monitor their shared Internet connection, which "was expensive and being spliced between them," according to Jared Whitehead's The rise of Drupal and the fall of closed source. Today, it's one of the most popular content management systems out there, competing with powerhouses like WordPress.

So, what has the Drupal community done to ensure continued competitiveness, usability, and overall sustainability? In this article, I'll walk you through Drupal's evolution chronologically, including key design decisions and feature upgrades. My sources include the History of Drupal: from Drop 1.0 to Drupal 8.0 slideshow by WebSolutions HR and Drupal's CHANGELOG.txt.

Drupal 1.0

Creator Dries Buytaert based Drupal a great deal on Slash, a modular CMS. To start, there were 18 core modules, and each was a PHP file. You could input code into one of the seven hooks in the modules. The admin hook could only be used by administrators. There were themes already in the core, and you could create your own themes as well. With themes you had control of colors, markup, layout, and block positioning. To modify the database, you imported an SQL file. Features included story submissions in hard coded categories, a diary that acted as the blog, accounts, comments, search, RDF headlines, and a calendar that acted as the archive. Importantly, anyone could be a contributor.

Drupal 2.0

The second iteration's major development was a translation feature, which allowed you to either create or overwrite your site in a different language. In order to do this, you had to edit the configuration file and SQL database with the t() function. Version 2.0 also contributed more notes of complexity to the framework by adding user ratings, sections for stories, and a user permission system. The user_access () function became more fine-tuned, allowing for different user groups.

Drupal 3.0

This is the release when nodes, as opposed to pages, became the primary unit for content. All types of content—story, book, diary, forum, blog—existed as a node which was managed by the node module. The key here is that you could create any type of content as a node. Comments became connected to nodes. With the node module, you could arrange how content types were configured and set defaults for how blog posts were displayed. Ten years later, nodes would become the basis for the mobile web.

Drupal 4.0

In 2002, tech news site KernelTrap.org migrated to Drupal 3.0.2, signaling Drupal's ascension in the world of tech. KernelTrap's Jeremy Andrews wrote the Throttle module, which was later included into Drupal Core. Throttle detects surges in traffic and then provides congestion control.

The fourth iteration of Drupal introduced the taxonomy module, which replaced meta tags and attributes. The core taxonomy module was an important classification and organization feature that is still a core Drupal feature. You can create vocabularies based on keywords, assign different types of content to these keywords, and create, assign, and modify content types.

Drupal 4.1 to 4.7

This phase included tons of modifications and growth, including the first e-commerce module (4.4). It was something of a Cambrian explosion for Drupal:

  • a profile module
  • a theme template
  • configurable menus
  • translation improvements
  • WYSIWYG (What You See Is What You Get) support—which allows an editor to see how a bit of code will appear to the user

Overall, Drupal was becoming more accessible to a wider base of users. Version 4.2 included support for the Microsoft SQL server, and in 2003 presidential candidate Howard Dean used Drupal for DeanSpace. This helped lead to a 300% increase in content activity on Drupal.org.

Version 4.7 included a new forms API, which offered greatly expanded freedom to play with any sort of form in Drupal. Additionally, instead of having to manually install databases in modules, modules could now install databases using a simple query-and-install hook.

Drupal 5.0

Version 5.0 featured the famous jQuery, a JavaScript library that makes HTML scripting easier. Drupal was quick to jump on this, and it's now a web standard.

Another feature was support for distributions of pre-created Drupal packages, which people could then customize to their liking. A new web-based installer did away altogether with users having to manually alter the database, and showed runtime requirements. Users could now cache files from the backend, and create custom content types. Modules were moved to their own directory, and became easier to install and uninstall. In terms of themes, a CSS preprocessor migrated cacheable stylesheets into a single compressed folder, improving site load times.

Drupal 6.0

Whitehouse.gov adopted Drupal 6.0 as its CMS, another big step up.

The menu system was rewritten from scratch, making it a lot easier to use. Administrators could now drag-and-drop a number of features, including blocks, menu items, and taxonomy vocabularies and terms. The language system was modified to support right-to-left languages, and overall it was adjusted to make non-English usage easier. The installer was improved with a new form that provided site info during installation, and automatically used the Garland theme, which had been implemented with 5.0. Security feature improvements included an Update Status module to automatically check for available updates and warn sites if they were missing security updates or newer versions.

Drupal 7.0

Three years after Version 6.0, Drupal 7.0 again imporved on core and usability features. All modules could interact with any node at runtime, so that nodes were no longer dependent on a specific module. In that sense, everything on 7.0 and beyond is an independent entity: content types, taxonomy, users, custom entity types. And to process multiple or long-running tasks, Version 7.0 added a queue API. jQuery was upgraded, and translations modified to support message context.

Version 7.0 marked the primacy of web-based apps: The installer was refactored into an API, and node bodies and fields, and taxonomy terms became Field APIs, which enabled custom data fields. In fact, with this version, any object could register as a Field API, allowing custom data field attachment.

For search engine optimization (SEO), Version 7.0 added the rel="canonical" link on nodes and comments to prevent the indexing of duplicate content. Image manipulation was improved, and files became their own entities, or objects.

The addition of OpenID allows users login with their email address when the email domain is powered by Google.

Drupal 8.0

Here we are at present-day Drupal.

Versions 6.0 and 7.0 accomplished a great deal, and 8.0 goes even further. A post on the Appnovation blog encapsulates some of the key innovations: Drupal 8.0: Where features meet functionality.

There is now a standardized release cycle of six months, meaning we'll see Drupal 8.2 in November 2016. Semantic versioning, or SemVer, alerts users to every patch release. Version 8.0 incorporates code from outside of the Drupal community, and that code is largely object oriented. The Views module is now a part of the core, with bulk operations functionality. Several core APIs now have a plugin system. Configuration is housed in YAML files, where it can be managed alongside code.

A concept from Facebook, BigPipe, is a part of 8.1. It helps pages load faster by sending the cacheable parts first. The Migrate module helps ensure seamless upgrades from 6.0 and 7.0. And, on the front end, PHP is simplified into a Twig template that's easier for front-end builders to manage.

What can we expect next?

Drupal's evolution has consistently prioritized quick adjustment and forward-thinking adaptations to prioritize ease of use. The community took it from a specialist's CMS to a wide-ranging site-builder anyone can use. Expect to see continued flexibility as Drupal continues to evolve.

May 06 2016
May 06

I've got quite the treat for you today: an interview with experience analyst Catharine McNally and experience strategist David Spira, who work at Phase2 and are passionate about accessibility on the web—in particular, the part of the web that involves Drupal.

They will be presenting, Easy Accessibility in Drupal 8: Practical, Compassionate, and Cost Effective at DrupalCon NOLA, which Catharine tells me will be an interactive and fun session. She has a passion for utilizing technology to create an equal web for all users, regardless of whether or not they have a disability. And, fun fact, she's into photography, CrossFit, and cooking, not necessarily in that order. David has a background in web design, information architecture, content strategy, and interactive design. His fun fact is that he plays both the acoustic and electric guitar and is excited to check out the music scene in New Orleans this year!

Let's find out how Catharine and David got involved with the Drupal community, the common mistakes people make around accessibility, and what they're talking about at DrupalCon.

Interview banner Q&A.png

How did you get involved with the Drupal community?

David Spira (DS): Back in 2012, I was running a small platform agnostic UX and design consultancy, and was pitching for work with a large health care company. I had a friend over at Phase2, so we teamed up to pitch for the work, and won. That was my first serious Drupal project. A couple years later, I decided to join Phase2, and with it, the Drupal community.

Catharine McNally (CM): In 2011, I joined Phase2 with a focus on accessibility for one of our clients. It was my first experience with Drupal and it was exciting to learn about the platform and the possibilities with accessibility. My focus was distinguishing the accessibility requirements between development and content management, and this type of work continues today in my accessibility consulting with our clients.

What's the biggest mistake most people make with accessibility on Drupal, and how can they avoid it?

(DS): The biggest mistake is bigger than Drupal: They don't consider it at all. This isn't a platform thing, it's a problem that is endemic to the web. Big companies get dragged into accessibility via legal threats. Small companies don't even think about it. Just the act of raising accessibility as an issue, and asking your team to keep it in mind throughout the design and development process is a big deal. You have to start somewhere.

(CM): The biggest? How about two of the biggest? The first is assuming that there's not enough of a market to consider for accessibility. That is the one I hear the most: "But there's not that many blind people accessing my website." While we're updating websites to serve this audience, it also has a positive ripple effect on everyone else from a usability, SEO, and development perspective. The second is the misconception that accessibility is "too hard" to even try to implement. While it may be intimidating to approach an accessibility project, once you focus on one-to-two things at a time, it becomes much more realistic and less overwhelming.

What does a day in the life of an experience strategist look like?

(DS): At Phase2, the experience team covers a lot of ground. On any given day I'm conducting discoveries, meeting with client stakeholders to better understand the needs of their business; researching our clients' users; defining requirements; producing wireframes; seeking feedback/approvals on our work; testing our code for bugs; user testing our work to ensure that it is accomplishing what we originally set-out to do. All of this involves tight partnerships with our developers, project managers, account managers, and clients. One particularly interesting week, this job had me field testing an application during a humanitarian crisis response in the Philippines. We get around.

What are a few things you're looking forward to at DrupalCon NOLA?

(DS): What I most enjoy at any conference is the serendipitous conversation: Meeting people, talking shop, getting inspiration from their work, maybe helping them with their own. The sessions are interesting, but the individual conversations that take place between them is what fuels me. Also... Cajun food and the music scene.

(CM): This will be my first DrupalCon, so I'm really excited about coming to New Orleans. I've heard that DrupalCon is an energetic time in which there is an exchange of ideas and conversation, and I can't wait to be a part of this.

Tell us about your DrupalCon talk Easy Accessibility in Drupal 8: Practical, Compassionate, and Cost Effective. Why should someone attend, what are the takeaways?

(DS): Designing and developing your website with a few accessibility practices can have a very large impact on your website's SEO, usability for all users, and it's transformative for the millions of hearing and visually impaired users who are living in a world that wasn't built for them. Putting a little effort into accessibility is a win for everyone. Added bonus: You won't have to throw quite so much money at SEO consulting and search ads.

(CM): Our session is shaping up to be a fun one! We're doing a few interactive exercises that everyone in the audience can participate in, so we're looking forward to having everyone participate in the conversation. We'll be sharing both perspectives of not only why you should implement accessibility but how it also provides greater benefit to the overall site. Those nuggets of wisdom are all back-pocket items you can take back to your project to steer development into one that is more inclusive of everyone regardless of ability.

May 05 2016
May 05

For open source developer Mike Gifford, founder and president of OpenConcept Consulting Inc., any mention of Drupal accessibility after his name is redundant. He has spent the better part of 10 years improving and cementing accessibility in Drupal, enough to earn the role of official core accessibility maintainer for the project.

Accessibility awareness has grown considerably in the Drupal community, but the Internet changes rapidly and the software needs to keep up to remain relevant. Recent press on the trend of decoupling Drupal—including the milestone post by project founder Dries Buytaert himself—tends to skirt the issue that so-called headless configurations can blot out accessibility functions designed for the theme layer.

Gifford is aware of this and other roadblocks on the path to a native, front-to-back assistive solution. Ahead of his talk at DrupalCon New Orleans, he shared some of his thoughts on Drupal accessibility and more.

Give us an overview of your DrupalCon New Orleans talk How Drupal 8 makes your website more easily accessible. Why should someone attend? What are the major takeaways?

I can't give you the takeaways! What's the point of coming to the talk if I tell you the punchline here?

But seriously, I'll be defining accessibility in the Drupal context, explaining the role of the community in keeping up with changes and best practices, highlighting some of the more exciting elements that we've brought into Drupal 8, and also talking about some of the contributed modules in Drupal 8 that can make your life easier.

How do semantics help assistive technology users (e.g., ARIA and HTML headings)?

Semantics are key for providing meaning and context to any blind user. Whether you are a Googlebot or someone using the open source NVDA screen reader, the site's structure can be interpreted more deeply. ARIA (Accessible Rich Internet Applications Suite) has a lot of ways to build in semantics. The most obvious are landmark roles that play a complementary role to HTML headings. Elements like aria-label, aria-labelledby, and aria-describedby also help tie form elements together. These act as stepping stones for people with disabilities to navigate a site's structure, much like what a table of contents does for a book.

Tell us how you rely on centralized tools in module development.

The easiest, of course, is the replacement for CSS display: none that we implemented in Drupal 7. We've since updated it in Drupal 8 to include hidden, visually-hidden, visually-hidden.focusable, and invisible. By leveraging these common classes, we are able to have a centralized place to manage how content is presented to screen reader and keyboard-only users.

Drupal.announce() is of course very useful when content changes on the screen based on user input. With sites becoming more dynamic, this is a huge deal. Likewise, the Drupal.TabbingManager is very useful in ensuring that keyboard-only users do not find themselves caught in a loop that doesn't allow them to navigate the website properly.

What's missing from Drupal 8? What are the next steps?

There is a lot missing. We keep fixing accessibility errors, but the accessibility tag on Drupal.org keeps growing as people use modules in new ways. Accessibility requires constant vigilance.

I think the top concern for me is fixing the remaining issues with new inline form errors so that it can move from an optional, experimental module to just the default response. Some work needs to go into CKEditor Tables so that figure/summary elements are defined properly in HTML5. We need better support still for Language of Parts. Complex views still don't have a means of presenting images with contextual alt text.

We really need an automated way to check accessibility; it doesn't matter if it is QuailJS, Tenon.io, or something else. It just needs to be easily integrated with open source development, particularly for modules.

I'd also really like to see more support for people who use tools like Dragon Naturally Speaking and Windows Speech Recognition. Users leveraging these tools make up a much larger share of the Internet than screen reader users, but generally there isn't testing/support to make their UX better.

Can you explain ATAG and the authoring experience?

ATAG is the Authoring Tool Accessibility Guidelines from the W3C. It really comes in two parts for content authors:

  1. Is the web editor itself accessible? Does it meet WCAG 2.0 AA?
  2. What can be done to help the author create more accessible content?

Drupal has been building to WCAG 2.0 AA since Drupal 7, so we're almost halfway there. We've known that people with disabilities shouldn't have barriers to create the content. The new piece is what can we do to make it easier for content authors. We've done a few things in Core:

  • Alt text is required by default within CKEditor and default image field types.
  • Help text for modules describes what the accessibility features we've added are (CKEditor, Image, Views, Telephone).
  • In 8.1 there is now a language of parts button to allow users to more easily define text in alternate languages and also enabled the browser's native spell checker for CKEditor.
  • Headers are now allowed by default in the Filtered HTML text format.

What about testing accessibility with users?

We haven't done enough of this. We've had some people with disabilities evaluating pieces of Drupal 8, but there just haven't been enough people involved. This is a really critical step of the process. Fortunately there are many ways to get involved and provide feedback to the Drupal community through the issue queue.

I do hope that more DrupalCamps take on the challenge of testing and evaluation with Drupal 8.1 moving ahead. The Web and how we use it is changing. We need to have opportunities regularly with people with different disabilities to engage in evaluating this technology and provide structured feedback on how to improve Drupal.

May 04 2016
May 04

Meet Greg Anderson, an open source contributor at Pantheon and co-maintainer of Drush. If you've used Drush before, you've probably saved a bunch of time on repetitive tasks. If you haven't used it yet, what are you waiting for?

Greg Anderson is all about boosting productivity and improving development workflows. He shared some of his insights in this interview. We also found out how he got involved with Drupal and got a preview of his session at DrupalCon NOLA on command line tools for Drupal 8 modules.

Interview banner Q&A.png

How did you get involved with the Drupal community?

I started using Drupal because I needed an open source content management system (CMS) to use in several community projects. One of the projects I was involved with was just getting started and had narrowed its CMS selection down to either Drupal or Joomla. At the time I was using a different framework, but I had considered Drupal in the past and knew that I liked it a lot better than Joomla. I convinced them to go with the new Drupal 6 release and converted all of my other projects for consistency. I started working with Drush because I wanted a unified mechanism to work with local and remote sites. My first major contribution to Drush was site aliases and sql-sync in Drush 3.

What's it like being the co-maintainer of Drush?

It seems like everyone uses Drush now, but not very many people recognize me by sight. I am much more likely to be recognized as a member of the planning commission in my town than as an open source contributor anywhere else. Even at a DrupalCon or camp, if I introduce myself to someone I do not know, they will often suspect something and start guessing, "Are you Greggles? Are you @heyrocker?" This is more common than you might think. Working on Drush is more something I do than something I am, though. I find it extremely rewarding to make improvements to tools that shave time off of repetitive tasks and make things easier to do. It feels super good to see someone blog or tweet that the job they just did was a lot easier because of something I wrote.

Can you share any advice or recommend any books on improving development workflow?

I thought that Drush for Developers by Juampy Novillo Requena came out particularly well (I was the technical reviewer for this book). However, setting up and maintaining your own dev/test/live workflow is really expensive in terms of the time it takes to get it working. There are a number of good providers who have free-to-get-started, pay-to-launch professionally managed solutions that will save you a lot more than they cost, and this will compound over the long haul. This is really the smartest way to approach your development workflow.

What are a few things you're looking forward to at DrupalCon NOLA?

I usually end up missing most of the sessions at DrupalCon because I find it so valuable to work with other contributors face-to-face in the sprints. I always enjoy seeing many of the same familiar faces from all over the place at each event and meeting new people I may or may not have interacted with previously online.

Tell us about your DrupalCon talk, Writing command line tools for Drupal 8 modules. Why should someone attend, what are the major takeaways?

A command-line interface to the functionality provided in a module can be a huge benefit and productivity boost. The Features module in particular demonstrated this with its Drush commands to update, revert, and create features, which have been widely used throughout the Drupal community. However, no one wants to have to become an expert in writing command line tools just to add another interface to their module. Drush commands and Symfony Console commands are not difficult to write, but over time we can refine and improve how this is done in ways that decrease the amount of code that needs to be written, keep components decoupled, and provide more out-of-the-box functionality while lowering the barrier to entry for new contributors. In the open source community, there are a lot of different opinions about how things should be done, so the attendees of this session should expect a lively discussion on when an whether an API should be extended and improved, and when it is better to favor the more explicit option of using the existing interfaces directly.

May 03 2016
May 03

A veteran of the web publishing and sports media industries, Jeff Diecks leads professional services and client delivery at Mediacurrent and is an active member of the Drupal community. Jeff also organizes events for his local Louisiana Drupal Users Group and Drupalcamp New Orleans.

I was able to catch up with Jeff ahead of DrupalCon New Orleans 2016, where he'll share insights on site building tools to solve common university needs.

What challenges do universities face with departments having diverse needs when it comes to managing content?

Departments at many universities are really a collection of individual stakeholders, each with unique goals and needs. The departments share the name, logo, and color scheme of the university, but this does not guarantee a shared vision in their online presence. This is also true of any large enterprise. Often, a web agency finds itself in the position of introducing stakeholders with common needs to one another within the organization, and helping to highlight areas of redundancy.

How did the new architecture provide a consistent brand experience across all departments while still providing flexibility for each department to customize their areas?

Via a discovery and planning phase, the project team mapped out the necessary content types, fields, taxonomy and navigation plan to cover a high percentage of the projected at-launch and long-term needs. The team planned for flexibility within the general blueprint to allow individual departments to provide variety in content without heavy and expensive customization. For example, on department home pages, the main content space allows editors the choice of dropdown menus, single-link headers, or headers with teasers and links. The options are all available on the page's edit form, where an editor simply chooses which options to populate with content and the rest are suppressed.

Which modules were key to building a flexible platform with these challenges in mind?

In architecting the new platform, Mediacurrent relied on several contributed modules to maintain a single site installation with the flexibility to serve the needs of the different departments. Organic Groups provides a permissions hierarchy to allow department administrators control of their own department's content without impacting others. Panels and Panelizer provide the flexibility and tools to allow editors the ability to solve for unique needs within their department's content. Features provides the controls and organization to allow site administrators to perform security updates and feature releases with less manual effort and lower risk of regressions and side effects.

What advice would you give to an educational institution looking to consolidate their websites? How can they get started?

Think in terms of building a sustainable platform as a product, and entrust a person or small core team as the product's owner. Charge the product owner with providing a set of tools to solve common goals. It is not necessary to have 15 unique solutions for news pages, event calendars, and staff lists across the campus. Focus on the results the sites need to achieve and the needs of the people who will be using the sites.

Proper planning and prioritization of features is critical to a platform's success. Addressing departmental needs across campus is a complex, lengthy endeavor that requires coordinated planning and consulting before one line of code is written. Universities are often tied to strict procurement procedures and policies and will seek an entire firm fixed price up front. Without a discovery phase of the project, it is difficult for an agency to provide an accurate solution to fully address nuances of platform consolidation that are unique to each institution. In short, fund a discovery phase for the project before issuing an RFP for fixed bid estimates on a complete platform.

What was the biggest challenge managing this project? How did you overcome it?

Like many public universities, LSU faced a limited budget. The office of student life and enrollment managed to reduce costs by having a graduate student on campus provide a style guide and design mockups for the site. Mediacurrent translated the supplied designs into a fully responsive site using Drupal's Omega base theme. The designs were produced in coordination with the technical architecture of the site in order to provide the necessary flexibility for individual departments to achieve unique visual identities while still remaining within a standardized overall template. For example, built-in options included the ability to adjust background images for sections of the site using the Dynamic Backgrounds module.

May 02 2016
May 02

Meet Amber Matz, a Production Manager and Trainer at Drupalize.Me, a service of Lullabot Education. When she's not tinkering around with Arduinos, Raspberry Pis, and electronic wearables, you can find her wrangling presenters for the Portland Drupal User Group.

Coming up at DrupalCon NOLA, Amber will host a session about Drupal and IoT. If you're attending and want to learn about the intersection of open hardware, IoT, and Drupal, this session is for you. If you're not able to join us in New Orleans, Amber has some pretty cool things to share. In this interview, she tells us how she got involved with Drupal, a few of her favorite open hardware projects, and what the future holds for IoT and Drupal.

Interview banner Q&A.png

How did you get involved with the Drupal community?

Back in the day, I was working at a large nonprofit in the "webmaster's office" of the marketing department and was churning out custom PHP/MySQL forms like nobody's business. I finally got weary of that and starting hunting around the web for a better way. I found Drupal 6 and starting diving in on my own. Years later, after a career shift and a move, I discovered the Portland Drupal User Group and landed a job as a full-time Drupal developer. I continued to regularly attend the meetups in Portland, which I found to be a great source of community, friendships, and professional development. Eventually, I landed a job with Lullabot as a trainer creating content for Drupalize.Me. Now, I'm managing the Drupalize.Me content pipeline, creating Drupal 8 content, and am very much involved in the Portland Drupal community. I'm this year's coordinator, finding and scheduling speakers.

We have to know: What is Arduino prototyping, how did you discover it, and what's the coolest thing you've done with an Arduino?

Arduino, Raspberry Pi, and wearable electronics have been these terms that I've heard thrown around for years. I found Adafruit's Wearable Electronics with Becky Stern YouTube show years ago (which, up until recently, when Becky moved on, aired every Wednesday). I was fascinated by wearables and even ordered an LED sewing kit but never did anything with it. I just didn't get it. I had no background in electronics whatsoever, and while I was fascinated by the projects I was finding, I didn't see how I could ever make anything like that. It seemed so out of reach.

Finally, I found a Coursera "Internet of Things" specialization. (So trendy, right?) But I was immediately hooked! I finally got an explanation of what an Arduino was, along with all these other important terms and concepts. I ordered the recommended Arduino starter kit, which came with a getting started booklet. When I made that first LED blink, it was pure delight. I had two weeks' vacation over the holidays and after Christmas, and I did nothing but make and program Arduino circuits from the getting started booklet. It was oddly so relaxing! I enjoyed it so much.

In January, I started creating my own prototypes. When I found out I was emceeing our company retreat's lightning talks, I created a Lightning Talk Visual Timer prototype with five LEDs and an Arduino.

It was a huge hit. I also made my first wearable project, a glowing hoodie, using the Arduino IDE compatible Gemma microcontroller, a tiny round sewable component, to which I sewed using conductive thread, a conductive slider connected to a hoodie's drawstring, which controlled the colors of five NeoPixels sewn around the inside of the hood. So that's what I mean by prototyping: Making crazy projects that are fun and maybe even a little practical.

What are the biggest opportunities for Drupal and IoT?

IoT isn't that much different than the web services and decoupling Drupal trends. It's the movement of data from thing one to thing two and the rendering of that data into something useful. But how does it get there? And what do you do with it? You think there are a lot of solutions, and apps, and frameworks, and APIs out there now? With IoT, that's only going to continue to increase—exponentially. What I've found is that given any device or any "thing", there is a way to connect it to the Internet—many ways. And there are plenty of code libraries out there to help makers get their data from thing one to thing two.

So where does Drupal fit in? Web services, for one, is going to be the first obvious place. But as a maker, I don't want to spend my time coding custom modules in Drupal. I want to plug and play! So I would love to see modules emerge that connect with IoT Cloud APIs and services like ThingSpeak and Adafruit.io and IFTTT and others. I think there's an opportunity, too, for a business to build an IoT cloud service in Drupal that allows people to send and store their sensor data, visualize it charts and graphs, and build widgets that react to certain values or thresholds. Each of these IoT Cloud API services fill a slightly different niche, and there's plenty of room for others.

What are a few things you're looking forward to at DrupalCon?

I love reconnecting with Drupal friends, meeting new people, and also seeing Lullabot and Drupalize.Me co-workers (we're distributed companies)! There's so much to learn with Drupal 8 and it's been overwhelming at times to put together training materials for our customers. So, I'm looking forward to attending Drupal 8-related sessions and getting up-to-speed on the latest developments. Finally, I'm really curious about New Orleans! I haven't been there since 2004 and I'm excited to see what's changed.

Tell us about your DrupalCon talk Beyond the blink: Add Drupal to your IoT playground. Why should someone attend? What are the major takeaways?

My session title, Beyond the blink: Add Drupal to your IoT playground, in itself is so full of assumptions that first off I'm going to get everyone up to speed and on the same page. You don't need to know anything about Arduino, the Internet of Things, or even Drupal to follow along. We'll start with making an LED blink with an Arduino, and then I want to talk about what the main takeaways have been for me: Play, learn, teach, and make. I'll show examples that have inspired me and that will hopefully inspire and encourage others in the audience to give it a try. Then, it's demo time!

First, thing one. Thing one is a Build Notifier Tower Light. In this demo, I'll show how I connected the Tower Light to the Internet and how I got it to respond to data received from a Cloud API service. Next, Thing two. Thing two is a "weather watch" in the form of a steampunk iPhone case. It's got small LED matrix that displays an icon of the local-to-me weather, a barometric pressure and temperature sensor, a GPS module, and a Bluetooth LE module, all connected and controlled with an Adafruit Flora microcontroller. Thing two sends weather and location data to Adafruit.io by connecting to an app on my iPhone over Bluetooth and sends it up to the cloud using an MQTT protocol! Then, on the Drupal side, I'm pulling down that data from the cloud, updating a block with the weather, and updating a map. So folks will get a taste of what you can do with web services, maps, and blocks in Drupal 8, too.

It's been a brain-melting adventure learning and making these demo prototypes, and I hope others will come to the session and catch a little of this contagious enthusiasm I have for this intersection of technologies! I'm very excited to share what I've discovered.

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