clemens-tolboom pushed to patch-1 in clemens-tolboom/deltachat-desktop

On github - Sat, 2019/09/14 - 12:01pm
clemens-tolboom pushed to patch-1 in clemens-tolboom/deltachat-desktop Sep 14, 2019 1 commit to patch-1
  • 118106e Fix copy/paste log path on Mac

Lullabot: Perspectives of Women in Technology - Part 2

Planet Drupal - Fri, 2019/09/13 - 7:09pm

In part two of our Perspectives of Women in Technology series, Lullabots, Ana Barcelona, Senior UX Designer, Cristina Chumillas, Front-end Developer, and Marissa Epstein, Senior UX Designer share their journeys into technology, which tools they regularly use, the skills they're learning, and advice they'd share with their younger selves. 

Categories: Writing View Mode Templates in PatternLab

Planet Drupal - Fri, 2019/09/13 - 6:53pm
Writing View Mode Templates in PatternLab

Wanna know my rules when I am writing templates in PatternLab for Drupal view modes such as teasers, cards, search results, etc? Read on, my friend...

markconroy Fri, 09/13/2019 - 17:53 BEM Classes for Streamlined Classes

Classes used in the card view mode should be prefixed with card__ not node__

  • We need to make sure that CSS for cards does not leak out into other components
  • We need to make sure we have as little selector specificity as possible - so we have .card__content instead of .card .node__content in our CSS.
Card Variations

If you want to have slight variations for cards, please add that as an option in the classes array. Examples of this might be for a card for a specific content type, or a card when there is no image present, or a card that has the image on the left/right.

  1. {% set classes =
  2. [
  3. "card",
  4. content_type ? "card--" ~ content_type,
  5. image ? "card--has-image" : "card--no-image",
  6. alignment ? "card--" ~ alignment,
  7. ]
  8. %}

This will print:

We can then apply overrides using these variations. For example, if the date field on a event is bold but but on a blog is not, we can have code like so:

  1. .card__date {
  2. color: $c-grey--darkest;
  3. }
  4. .card--event .card__date {
  5. font-weight: $fw--bold;
  6. }
Avoid Twig Blocks

Try not to use Twig blocks in view modes - {% block image %} If we use Twig blocks, then in the Drupal template anything can be put in the {% block %} to override it. If we change the order of things in the {% block %} in PL, this will have no effect in Drupal, since the Drupal version will be overriding it.

For example, the Drupal template could have something like this:

  1. {% block image %}
  2. {{ content.field_date }}
  3. {% endblock %}
Avoid Drupal Templates

Try to avoid having templates based on specific content types for view modes. This is usually necessary for Full view mode, but for Teaser, Card, etc let's try to keep them more generic.

If you need to use a content-type template, that is fine; but it should be the exception, not the rule.

In general, since each content type Card should be similar, then each content type should be able to use the same node--card.html.twig template file.

Avoid {% if not page %}

{% if not page %} Should not be needed in view modes. A Card or Teaser will never be a full page. For the same reason, we can usualy leave this out in the content type full view mode templates, since the full view mode will always be a page.

Do Not Hardcode Heading Levels

Unless you know that the Card view mode is never going to have a item above it, do not set or etc as the heading element.

We do not want to have a HTML structure like this:

  1. Page Title
  2. Views Card Block Title
  3. Card Title
  4. Card Title
  5. Card Title

Instead, we would like this:

  1. Page Title
  2. Views Card Block Title
  3. Card Title
  4. Card Title
  5. Card Title

In general, view modes will take a , so let's place that as our default.

  1. {% set card_title_element = card_title_element|default('h2) %}
  2. <{{ card_title_element }}>{{ card_tite }}{{ card_title_element }}>

Then, in our Drupal template, we can set the element depending on whether it has a parent or not; for example, if it is in a 'Related Content' building block and that building block has a title such as: Read More Like This.

We can do so in the Drupal template with a variation of this:

  1. {% if node._referringItem.parent.parent.entity.field_p_rc_title.value %}
  2. {% set teaser_title_element = 'h3' %}
  3. {% endif %}

If the above returns as false, our default h2 from the PL pattern will kick in.

Use Prefixes for Variables

Let's use prefixes for variables, using {{ card_content }} instead of {{ content }}. This will help avoid global variables being used by accident in our components (unless we want them to, such as the image_alt variable from data.json). The {{ content }} if used, will not necessarily print the content of your component when that component is used outside of its own context: for example, if you print a card in a views list in a sample page.

Variables for Specific Content Types

If there's a variable for a specific content type, such as the location field for an event card, we can just wrap that in an {% if %} statement, like so:

  1. {% if content_type == 'event' %}
  2. {% if event_location %}
  3. {{ card_location}}
  4. {% endif %}
  5. {% endif %}

Then that variable will not print in any other content type's template.

Categories: Blog: Interview with Suzanne Dergacheva of Evolving Web: The sky's the limit with Drupal

Planet Drupal - Fri, 2019/09/13 - 12:24pm

We had a great talk with Suzanne Dergacheva, co-founder of the Canadian web agency Evolving Web and member of the Drupal Association Board of Directors. She's also involved in the Admin UX study and the Promote Drupal initiative, and is an active member of the Canadian Drupal community. Find out more about Suzanne in our interview.


PreviousNext: Classifying, understanding and building models of networked Drupal sites

Planet Drupal - Fri, 2019/09/13 - 4:42am

One of the increasingly popular architectural paradigms that Drupal has been seen as a leader in, is the concept of a single Drupal software package that can be spun up to power networks of websites with varying degrees of commonality. This is usually driven by the ambitious goal of being able to code and configure Drupal once and then leverage that effort as either an entire platform or foundation for many "networked" sites.

by Sam Becker / 13 September 2019

Beginning down the path of starting a project like this is complex and unfortunately isn't helped by some of Drupal's (confusingly named) features which describe aspects of reusability but aren't in themselves a full fledged approach to architecting such a network. In addition to that, there are many misconceptions about Drupal's capabilities and affordances when it comes to building such networks.

In order to try and expose some of the discovery and decision making process behind starting an ambitious Drupal network project, the following is a non-exhaustive list of popular architectural paradigms that exist, evaluated on the following axis:

  • Up-front investment: the up-front cost of starting a network of sites.
  • Per-unit investment: the cost of introducing a new site to the network
  • Flexibility: the ability to customise and create bespoke experiences within each network site
  • Platform maintainability: the ability to iterate and evolve the network as a whole

As with all complex projects, there are a large number of requirements and constraints which factor into technical decision making, so these approaches are a broad view of the landscape of Drupal's capabilities.

Models of networked sites Starter-kits

A starter-kit consists of creating a Drupal distribution or install profile, catering to as much common functionality as possible across the network in an initial development phase and then allowing each new website to make any additional required customisations as needed. These customisations may consist of writing additional code, enabling new dependencies and modifying the configuration shipped with the initial distribution.

For each individual site, this model affords the most flexibility. By allowing each site to evolve independently any new requirements or features perceived as bespoke can be implemented and deployed without making consideration to the starter-kit itself or other websites within the network.

The major drawback of this approach is being able to maintain and evolve the network of sites as a whole. Each new site in the network creates a new deployment with it's own configuration, dependencies and code, meaning new features and bug fixes can't be deployed across the whole network without specific individual effort and conflict resolution for each site. In practice once a site is live under this model, it can effectively be considered a siloed project without a significant relationship to other sites in the network.

As far as how feature rich an initial starter kit is largely depends on the project. For example, early versions aGov 8, the starter-kit distribution PreviousNext built and maintained for Australian government organisations was intentionally fairly rudimentary in the amount of content types it shipped with. The goal was a foundation to launch you into best practices, without being overly prescriptive. When future iterations of aGov were released that baked in Drupal 8's new media capabilities, it was not possible to deploy this iteration to all existing installations.

In a similar vein, I would classify govCMS8, the Australian governments own Drupal distribution under this same model. By default, the distribution ships with a lot more features and a lot more ready to go configuration than most starter-kits, however both SaaS and PaaS deployments of govCMS allow a wide scope of deep structural configuration changes to Drupal, which essentially sets up each project to function as a standalone unit after the initial build.


Another less widespread approach is the product model. Under this model, a Drupal distribution is leveraged as the full feature set for all sites in the network and all sites make use of the initial and ongoing development roadmap of the product. This approach is arguably less flexible, since each individual site doesn't have unfettered access to extend and manipulate the platform.

The major advantage of this approach is, a single team can scale their ongoing enhancement and maintenance efforts to the entire network of sites regardless of the number of sites in the network.

Under the product model, since the feature set running on each site is a known and strictly defined set of configuration and dependencies, a team could feasibly migrate hundreds of sites to using new features of Drupal by working on a single software product. All sites would be the target of all new evolutions of the platform and benefit from it's ongoing maintenance. Evolutions of the platform would not strictly be limited to features, but also updating dependencies or moving to new major versions of Drupal. 

An example of a project PreviousNext delivered under this model was a video content platform for group of media organisations. Each organisation could leverage the product to spin up a website to share their videos and engage with their audience. New features were added regularly and at its height, 26 different websites serving vastly different audiences of users would evolve together. One of the challenges of maintaining a product distribution is the governance around flexibility and change. While tempting to allow each site to develop its own product roadmap, when each site required it's own bespoke features, the process for such requests would be followed:

  • The site owner raises a request a change to their website, "please replace the hero image on the homepage with a slideshow of images".
  • The team evaluates the request and places it on the product roadmap.
  • Instead of replacing all hero images with slideshows, the feature is developed an optional choice for content editors: you may either upload slides or a hero image.
  • The feature would be built, tested and deployed to all sites in the network.
  • The site owner is then able to upload slides and all other site owners in the network have the same capability.

This approach certainly takes a level of control and focused organisation effort to accomplish, however leveraged properly can have significant payoffs for the maintainability of a network of sites as a whole. Examples of product based distributions in the Open Source Drupal ecosystem are Open Social or Drupal Commons.

Federated back-ends

Another approach to building out a network of sites is the notion of a federated back-end. This dovetails with terms like "service oriented architecture", "multi-tenancy" or "content hub", where a single deployment and instance of Drupal is leveraged as a large repository of content for multiple web front-ends.

Under this model, instead of the boundary between users and content being defined by different databases and deployments of Drupal, they must instead be implemented in the application layer. That is, Drupal itself is customised and tailored to meet the access needs of the organisations sharing the same Drupal site. While this is certainly additional work and complexity, if a single group of content authors is responsible for content across the whole network, it can be advantageous to lower these barriers. Maintenance for the content hub is also fairly light touch under this model, since only one installation needs to be updated and maintained.

This pattern also intersects with the "product" style of application. Since all web properties are powered by the same underlying application, they closely share a feature set and product roadmap. While this model is also often deployed in conjunction with a decoupled front-end, Drupal sites are capable of delivering integrated front-ends to network sites from a single federated back-end. In some cases, the federated model has an elevated risk of being a single point of failure, given a single deployment and instance is responsible for sites in the network.

An example of the federated back-end model can be illustrated in the "Tide" component of's "Single Digital Presence" project. Drupal 8 is deployed as a single instance serving multiple decoupled front-ends. The features of the single content repository are documented and available for evaluation by prospective users. 

Independent sites

One option that isn't often considered in of a lot of organisations when evaluating reusability of features and effort across a network of Drupal sites is simply building multiple completely unrelated sites and using smaller units of functionality as a mechanism for reuse. Drupal has a mature concept for sharing functionality across Drupal sites: the humble module.

While this approach in general doesn't strictly fit the theme of this blog post, in some cases writing and publishing a general case module which doesn't boil the ocean on dictating the tools, approach and features used to build a new Drupal site, is the best solution for some projects.

These kinds of projects would be driven by websites that are characterized as mostly unique with various related and unrelated feature sets. This is also an approach consistent with day to day of Drupal development outside the scope of network projects. With Drupal's open ecosystem, opportunities for collaboration and reuse often drive building functionality in reusable modules and publishing those modules on

Common misconceptions Install profiles

Drupal "profiles" or "distributions" are not a silver bullet for developing and organising an architecture for networks of Drupal sites. They are incredibly flexible, so how they are deployed and leveraged still contain the same governance and architectural decisions discussed.

Configuration management

Configuration management is not a silver bullet. While configuration management has simplified a range of complex deployment problems that were present in Drupal 7 sites, it doesn't drive a particular architecture for networks of sites. The tools in Drupal core are continually getting sharper and while innovations in contrib have experimented with new mechanisms for deploying and updating configuration, it's not an end-to-end architectural solution for network sites.


The multisite concept in Drupal is frequently misunderstood as an approach for building a network of sites. In reality, multisites are a tool for deploying any configuration or setup of Drupal sites to a shared document root. It doesn't produce any tangible outcome as far as project architecture is concerned beyond forcing multiple sites to be hosted on the same server.

Headless Drupal & JavaScript frameworks

While some of these approaches, like the "federated back-end" are significantly benefited by a decoupled front-end, headless Drupal is compatible with all models of network sites. You could build a product or starter-kit that was either fully integrated, progressively decoupled or completely decoupled and the same back-end architectural decisions would apply.

Drupal has strong API based functionality, which can be enabled and configured as required. The approach of evaluating and selecting frameworks or front-ends to consume Drupal, have their own set of considerations that need to be carefully evaluated for fitness in any given project.

Styling and appearance

Styleguide-driven development has largely matured to solve issues with reusability, inheritance and extensibility of visual components. This approach has been the foundation for all new sites built by PreviousNext for last few years, see our blog posts. By building components and style guides, duplication of effort when building front-ends has been minimised across both traditional and network based projects. For that reason the visual style and consistency of sites within a network is not necessarily a factor when considering Drupal architectural paradigms.

Summing up

Given the size of Drupal's ecosystem and the increasingly rapid pace of evolution, describing all of the factors and challenges that play into a large network site project is difficult. As always the process of rigorous discovery and deeply understanding a project's goals and requirements should always be the first step in beginning a technical project.


Agaric Collective: Introduction to Drupal 8 upgrades

Planet Drupal - Fri, 2019/09/13 - 4:06am

Throughout the series, we explored many migration topics. We started with an overview of the ETL process and workflows for managing migrations. Then, we presented example migrations for different entities: nodes, files, images, taxonomy terms, users, and paragraphs. Next, we shifted focus to migrations from different sources: CSV, JSON, XML, Google Sheet, Microsoft Excel, and LibreOffice Calc files. Later, we explored how to manage migrations as configuration, use groups to share configuration, and execute migrations from the user interface. Finally, we gave recommendations and provided tools for debugging migrations from the command line and the user interface. Although we covered a lot of ground, we only scratched the surface. The Migrate API is so flexible that its use cases are virtually endless. To wrap up the series, we present an introduction to a very popular topic: Drupal upgrades. Let’s get started.

Note: In this article, when we talk about Drupal 7, the same applies to Drupal 6.

What is a Drupal upgrade?

The information we presented in the series is generic enough that it applies to many types of Drupal migrations. There is one particular use case that stands out from the rest: Drupal upgrades. An upgrade is the process of taking your existing Drupal site and copy its configuration and content over to a new major version of Drupal. For example, going from Drupal 6 or 7 to Drupal 8. The following is an oversimplification of the workflow to perform the upgrade process:

  • Install a fresh Drupal 8 site.
  • Add credentials so that the new site can connect to Drupal 7’s database.
  • Use the Migrate API to generate migration definition files. They will copy over Drupal 7’s configuration and content. This step is only about generating the YAML files.
  • Execute those migrations to bring the configuration and content over to Drupal 8.
Preparing your migration

Any migration project requires a good plan of action, but this is particularly important for Drupal upgrades. You need to have a general sense of how the upgrade process works, what assumptions are made by the system, and what limitations exist. Read this article for more details on how to prepare a site for upgrading it to Drupal 8. Some highlights include:

  • Both sites need to be in the latest stable version of their corresponding branch. That means the latest release of Drupal 7 and 8 at the time of performing the upgrade process. This also applies to any contributed module.
  • Do not do any configuration of the Drupal 8 site until the upgrade process is completed. Any configuration you make will be overridden, and there is no need for it anyways. Part of the process includes recreating the old site’s configuration: content types, fields, taxonomy vocabularies, etc.
  • Do not create content on the Drupal 8 site until the upgrade process is completed. The upgrade process will keep the unique identifiers from the source site: `nid`, `uid`, `tid`, `fid`, etc. If you were to create content, the references among entities could be broken when the upgrade process overrides the unique identifiers. To prevent data loss, wait until the old site's content has been migrated to start adding content to the new site.
  • For the system to detect a module’s configuration to be upgraded automatically, it has to be enabled on both sites. This applies to contributed modules in Drupal 7 (e.g., link) that were moved to core in Drupal 8. Also to Drupal 7 modules (e.g. address field) that were superseded by a different one in Drupal 8 (e.g. address). In any of those cases, as long as the modules are enabled on both ends, their configuration and content will be migrated. This assumes that the Drupal 8 counterpart offers an automatic upgrade path.
  • Some modules do not offer automatic upgrade paths. The primary example is the Views module. This means that any view created in Drupal 7 needs to be manually recreated in Drupal 8.
  • The upgrade procedure is all about moving data, not logic in custom code. If you have custom modules, the custom code needs to be ported separately. If those modules store data in Drupal’s database, you can use the Migrate API to move it over to the new site.
  • Similarly, you will have to recreate the theme from scratch. Drupal 8 introduced Twig which is significantly different to the PHPTemplate engine used by Drupal 7.
Customizing your migration

Note that the creation and execution of the migration files are separate steps. Upgrading to a major version of Drupal is often a good opportunity to introduce changes to the website. For example, you might want to change the content modeling, navigation, user permissions, etc. To accomplish that, you can modify the generated migration files to account for any scenario where the new site’s configuration diverts from the old one. And only when you are done with the customizations, you execute the migrations. Examples of things that could change include:

  • Combining or breaking apart content types.
  • Moving data about people from node entities to user entities, or vice versa.
  • Renaming content types, fields, taxonomy vocabularies and terms, etc.
  • Changing field types. For example, going from Address Field module in Drupal 7 to Address module in Drupal 8.
  • Merging multiple taxonomy vocabularies into one.
  • Changing how your content is structured. For example, going from a monolithic body field to paragraph entities.
  • Changing how your multimedia files are stored. For example, going from image fields to media entities.
Performing the upgrade

There are two options to perform the upgrade. In both cases, the process is initiated from the Drupal 8 site. One way is using the Migrate Drupal UI core module to perform the upgrade from the browser’s user interface. When the module is enabled, go to `/upgrade` and provide the database credentials of the Drupal 7 site. Based on the installed modules on both sites, the system will give you a report of what can be automatically upgraded. Consider the limitations explained above. While the upgrade process is running, you will see a stream of messages about the operation. These messages are logged to the database so you can read them after the upgrade is completed. If your dataset is big or there are many expensive operations like password encryption, the process can take too long to complete or fail altogether.

The other way to perform the upgrade procedure is from the command line using Drush. This requires the Migrate Upgrade contributed module. When enabled, it adds Drush commands to import and rollback a full upgrade operation. You can provide database connection details of the old site via command line options. One benefit of using this approach is that you can create the migration files without running them. This lets you do customizations as explained above. When you are done, you can run the migrations following the same workflow of manually created ones.

Known issues and limitations

Depending on whether you are upgrading from Drupal 6 or 7, there is a list of known issues you need to be aware of. Read this article for more information. One area that can be tricky is multilingual support. As of this writing, the upgrade path for multilingual sites is not complete. Limited support is available via the Migrate Drupal Multilingual core module. There are many things to consider when working with multilingual migrations. For example, are you using node or field translations? Do entities have revisions? Read this article for more information.

Upgrade paths for contributed modules

The automatic upgrade procedure only supports Drupal core modules. This includes modules that were added to core in Drupal 8. For any other contributed module, it is the maintainers’ decision to include an automatic upgrade path or not. For example, the Geofield module provides an upgrade path. It is also possible that a module in Drupal 8 offers an upgrade path from a different module in Drupal 7. For example, the Address module provides an upgrade path from the Address Field module. Drupal Commerce also provides some support via the Commerce Migrate module.

Not every module offers an automated upgrade path. In such cases, you can write custom plugins which ideally are contributed back to ;-) Or you can use the techniques learned in the series to transform your source data into the structures expected by Drupal 8. In both cases, having a broad understanding of the Migrate API will be very useful.

Upgrade strategies

There are multiple migration strategies. You might even consider manually recreating the content if there is only a handful of data to move. Or you might decide to use the Migrate API to upgrade part of the site automatically and do a manual copy of a different portion of it. You might want to execute a fully automated upgrade procedure and manually clean up edge cases afterward. Or you might want to customize the migrations to account for those edge cases already. Michael Anello created an insightful presentation on different migration strategies. Our tips for writing migrations apply as well.

Drupal upgrades tend to be fun, challenging projects. The more you know about the Migrate API the easier it will be to complete the project. We enjoyed writing this overview of the Drupal Migrate API. We would love to work on a follow up series focused on Drupal upgrades. If you or your organization could sponsor such endeavor, please reach out to us via the site’s contact form.

What about upgrading to Drupal 9?

In March 2017, project lead Dries Buytaert announced a plan to make Drupal upgrades easier forever. This was reinforced during his keynote at DrupalCon Seattle 2019. You can watch the video recording in this link. In short, Drupal 9.0 will be the latest point release of Drupal 8 minus deprecated APIs. This has very important implications:

  • When Drupal 9 is released, the Migrate API should be mostly the same as Drupal 8. Therefore, anything that you learn today will be useful for Drupal 9 as well.
  • As long as your code does not use deprecated APIs, upgrading from Drupal 8 to Drupal 9 will be as easy as updating from Drupal 8.7 to 8.8.
  • Because of this, there is no need to wait for Drupal 9 to upgrade your Drupal 6 or 7 site. You can upgrade to Drupal 8 today.
Thank you!

And that concludes the #31DaysOfMigration series. For joining us in this learning experience, thank you very much! ¡Muchas gracias! Merci beaucoup! :-D We are also very grateful to, Drupalize.Me, and for sponsoring this series.

What did you learn in today’s blog post? Did you know the upgrade process is able to copy content and configuration? Did you know that you can execute the upgrade procedure either from the user interface or the command line? Share your answers in the comments. Also, we would be grateful if you shared this blog post with others.

This blog post series, cross-posted at as well as here on, is made possible thanks to these generous sponsors: by Osio Labs has online tutorials about migrations, among other topics, and Agaric provides migration trainings, among other services.  Contact Understand Drupal if your organization would like to support this documentation project, whether it is the migration series or other topics.

Read more and discuss at


Agaric Collective: List of migration related Drupal modules

Planet Drupal - Fri, 2019/09/13 - 2:51am

When one starts working with migrations, it is easy to be overwhelmed by so many modules providing migration functionality. Throughout the series, we presented many of them trying to cover one module at a time. We did this to help the reader understand when a particular module is truly needed and why. But we only scratched the surface. Today’s article presents a list of migration related Drupal modules, all good for Drupal 8, for quick reference. Let’s get started.

Core modules

At the time of this writing, Drupal core ships with four migration modules:

  • Migrate: provides the base API for migrating data.
  • Migrate Drupal: offers functionality to migrate from other Drupal installations. It serves as the foundation for upgrades from Drupal 6 and 7. It also supports reading configuration entities from Drupal 8 sites.
  • Drupal Migrate UI: provides a user interface for upgrading a Drupal 6 or 7 site to Drupal 8.
  • Migrate Drupal Multilingual: is an experimental module required by multilingual translations. When they become stable, the module will be removed from Drupal core. See this article for more information.
Migration runners

Once the migration definition files have been created, there are many options to execute them:

Source plugins

The Migrate API offers many options to fetch data from:

Destination plugins

The Migrate API is mostly used to move data into Drupal, but it is possible to write to other destinations:

  • Migrate (core): provides classes for creating content and configuration entities. It also offers the `null` plugin which in itself does not write to anything. It is used in multilingual migrations for entity references.
  • Migrate Plus: provides the `table` plugin for migrating into tables not registered with Drupal Schema API.
  • CSV file: example destination plugin implementation to write CSV files. The module was created by J Franks for a DrupalCamp presentation. Check out the repository and video recording.
Development related

These modules can help with writing Drupal migrations:

Field and module related Modules created by Tess Flynn (socketwench)

While doing the research for this article, we found many useful modules created by Tess Flynn (socketwench). She is a fantastic presenter who also has written about Drupal migrations, testing, and much more. Here are some of her modules:

  • Feeds Migrate: it aims to provide a user interface similar to the one from Drupal 7’s Feeds module, but working on top of Drupal 8’s Migrate API.
  • Migrate Override: allows flagging fields in a content entity so they can be manually changed by side editors without being overridden in a subsequent migration.
  • Migrate Status: checks if migrations are currently running.
  • Migrate QA: provides tools for validating content migrations. See this presentation for more details.

And many, many more modules!

What did you learn in today’s blog post? Did you find a new module that could be useful in current or future projects? Did we miss a module that has been very useful to you? Share your answers in the comments. Also, I would be grateful if you shared this blog post with others.

Next: Introduction to Drupal 8 upgrades

This blog post series, cross-posted at as well as here on, is made possible thanks to these generous sponsors: by Osio Labs has online tutorials about migrations, among other topics, and Agaric provides migration trainings, among other services.  Contact Understand Drupal if your organization would like to support this documentation project, whether it is the migration series or other topics.

Read more and discuss at


Lullabot: Lullabot Podcast: PM Roundtable: Keeping the Gantt Charts Gantting

Planet Drupal - Fri, 2019/09/13 - 2:00am

Mike and Matt are joined by technical project managers Darren Peterson, Monica Flores, and Chris Albrecht to discuss the ins and outs of managing large Drupal projects.


Agaric Collective: How to configure XDebug, PHPStorm, and DrupalVM to debug Drupal migrations via Drush commands and the browser

Planet Drupal - Fri, 2019/09/13 - 12:24am

In recent articles, we have presented some recommendations and tools to debug Drupal migrations. Using a proper debugger is definitely the best way to debug Drupal be it migrations or other substems. In today’s article, we are going to learn how to configure XDebug inside DrupalVM to connect to PHPStorm. First, via the command line using Drush commands. And then, via the user interface using a browser. Let’s get started.

Important: User interfaces tend to change. Screenshots and referenced on-screen text might differ in new versions of the different tools. They can also vary per operating system. This article uses menu items from Linux. Refer the the official DrupalVM documentation for detailed installation and configuration instructions. For this article, it is assumed that VirtualBox, Vagrant, and Ansible are already installed. If you need help with those, refer to the DrupalVM’s installation guide.

Getting DrupalVM

First, get a copy of DrupalVM by cloning the repository or downloading a ZIP or TAR.GZ file from the available releases. If you downloaded a compressed file, expand it to have access to the configuration files. Before creating the virtual machine, make a copy of default.config.yml into a new file named config.yml. The latter will be used by DrupalVM to configure the virtual machine (VM). In this file, make the following changes:

# config.yml file # Based off default.config.yml vagrant_hostname: migratedebug.test vagrant_machine_name: migratedebug # For dynamic IP assignment the 'vagrant-auto_network' plugin is required. # Otherwise, use an IP address that has not been used by any other virtual machine. vagrant_ip: # All the other extra packages can remain enabled. # Make sure the following three get installed by uncommenting them. installed_extras: - drupalconsole - drush - xdebug php_xdebug_default_enable: 1 php_xdebug_cli_disable: no

The vagrant_hostname is the URL you will enter in your browser’s address bar to access the Drupal installation. Set vagrant_ip to an IP that has not been taken by another virtual machine. If you are unsure, you can set the value to and install the vagrant-auto_network plugin. The plugin will make sure that an available IP is assigned to the VM. In the installed_extras section, uncomment xdebug and drupalconsole. Drupal Console is not necessary for getting XDebug to work, but it offers many code introspection tools that are very useful for Drupal debugging in general. Finally, set php_xdebug_default_enable to 1 and php_xdebug_cli_disable to no. These last two settings are very important for being able to debug Drush commands.

Then, open a terminal and change directory to where the DrupalVM files are located. Keep the terminal open are going to execute various commands from there. Start the virtual machine by executing vagrant up. If you had already created the VM, you can still make changes to the config.yml file and then reprovision. If the virtual machine is running, execute the command: vagrant provision. Otherwise, you can start and reprovision the VM in a single command: vagrant up --provision. Finally, SSH into the VM executing vagrant ssh.

By default, DrupalVM will use the Drupal composer template project to get a copy of Drupal. That means that you will be managing your module and theme dependencies using composer. When you SSH into the virtual machine, you will be in the /var/www/drupalvm/drupal/web directory. That is Drupal’s docroot. The composer file that manages the installation is actually one directory up. Normally, if you run a composer command from a directory that does not have a composer.json file, composer will try to find one up in the directory hierarchy. Feel free to manually go one directory up or rely on composer’s default behaviour to locate the file.

For good measure, let’s install some contributed modules. Inside the virtual machine, in Drupal’s docroot, execute the following command: composer require drupal/migrate_plus drupal/migrate_tools. You can also create directory in /var/www/drupalvm/drupal/web/modules/custom and place the custom module we have been working on throughout the series. You can get it at

To make sure things are working, let’s enable one example modules by executing: drush pm-enable ud_migrations_config_entity_lookup_entity_generate. This module comes with one migration: udm_config_entity_lookup_entity_generate_node. If you execute drush migrate:status the example migration should be listed.

Configuring PHPStorm

With Drupal already installed and the virtual machine running, let’s configure PHPStorm. Start a new project pointing to the DrupalVM files. Feel free to follow your preferred approach to project creation. For reference, one way to do it is by going to "Files > Create New Project from Existing Files". In the dialog, select "Source files are in a local directory, no web server is configured yet." and click next. Look for the DrupalVM directory, click on it, click on “Project Root”, and then “Finish”. PHPStorm will begin indexing the files and detect that it is a Drupal project. It will prompt you to enable the Drupal coding standards, indicate which directory contains the installation path, and if you want to set PHP include paths. All of that is optional but recommended, especially if you want to use this VM for long term development.

Now the important part. Go to “Files > Settings > Language and Frameworks > PHP”. In the panel, there is a text box labeled “CLI Interpreter”. In the right end, there is a button with three dots like an ellipsis (...). The next step requires that the virtual machine is running because PHPStorm will try to connect to it. After verifying that it is the case, click the plus (+) button at the top left corner to add a CLI Interpreter. From the list that appears, select “From Docker, Vagrant, VM, Remote...”. In the “Configure Remote PHP Interpreter” dialog select “Vagrant”. PHPStorm will detect the SSH connection to connect to the virtual machine. Click “OK” to close the multiple dialog boxes. When you go back to the “Languages & Frameworks” dialog, you can set the “PHP language level” to match the same version from the Remote CLI Interpreter.

You are almost ready to start debugging. There are a few things pending to do. First, let’s create a breakpoint in the import method of the MigrateExecutable class. You can go to “Navigate > Class” to the project by class name. Or click around in the Project structure until you find the class. It is located at ./drupal/web/core/modules/migrate/src/MigrateExecutable.php in the VM directory. You can add a breakpoint by clicking on the bar to the left of the code area. A red circle will appear, indicating that the breakpoint has been added.

Then, you need to instruct PHPStorm to listen for debugging connections. For this, click on “Run > Start Listening for PHP Debugging Connections”. Finally, you have to set some server mappings. For this you will need the IP address of the virtual machine. If you configured the VM to assign the IP dynamically, you can skip this step momentarily. PHPStorm will detect the incoming connection, create a server with the proper IP, and then you can set the path mappings.

Triggering the breakpoint

Let’s switch back to the terminal. If you are not inside the virtual machine, you can SSH into the VM executing vagrant ssh. Then, execute the following command (everything in one line):

XDEBUG_CONFIG="idekey=PHPSTORM" /var/www/drupalvm/drupal/vendor/bin/drush migrate:import udm_config_entity_lookup_entity_generate_node

For the breakpoint to be triggered, the following needs to happen:

  • You must execute Drush from the vendor directory. DrupalVM has a globally available Drush binary located at /usr/local/bin/drush. That is not the one to use. For debugging purposes, always execute Drush from the vendor directory.
  • The command needs to have XDEBUG_CONFIG environment variable set to “idekey=PHPSTORM”. There are many ways to accomplish this, but prepending the variable as shown in the example is a valid way to do it.
  • Because the breakpoint was set in the import method, we need to execute an import command to stop at the breakpoint. The migration in the example Drush command is part of the example module that was enabled earlier.

When the command is executed, a dialog will appear in PHPStorm. In it, you will be asked to select a project or a file to debug. Accept what is selected by default for now.  By accepting the prompt, a new server will be configured using the proper IP of the virtual machine.  After doing so, go to “Files > Settings > Language and Frameworks > PHP > Servers”. You should see one already created. Make sure the “Use path mappings” option is selected. Then, look for the direct child of “Project files”. It should be the directory in your host computer where the VM files are located. In that row, set the “Absolute path on the server” column to  /var/www/drupalvm. You can delete any other path mapping. There should only be one from the previous prompt. Now, click “OK” in the dialog to accept the changes.

Finally, run the Drush command from inside the virtual machine once more. This time the program execution should stop at the breakpoint. You can use the Debug panel to step over each line of code and see how the variables change over time. Feel free to add more breakpoints as needed. In the previous article, there are some suggestions about that. When you are done, let PHPStorm know that it should no longer listen for connections. For that, click on “Run > Stop Listening for PHP Debugging Connections”. And that is how you can debug Drush commands for Drupal migrations.

Debugging from the user interface

If you also want to be able to debug from the user interface, go to this URL and generate the bookmarklets for XDebug: The IDE Key should be PHPSTORM. When the bookmarklets are created, you can drag and drop them into your browser’s bookmarks toolbar. Then, you can click on them to start and stop a debugging session. The IDE needs to be listening for incoming debugging connections as it was the case for Drush commands.

Note: There are browser extensions that let you start and stop debugging sessions. Check the extensions repository of your browser to see which options are available.

Finally, set breakpoints as needed and go to a page that would trigger them. If you are following along with the example, you can go to http://migratedebug.test/admin/structure/migrate/manage/default/migrations/udm_config_entity_lookup_entity_generate_node/execute Once there, select the “Import” operation and click the “Execute” button. This should open a prompt in PHPStorm to select a project or a file to debug. Select the index.php located in Drupal’s docroot. After accepting the connection, a new server should be configured with the proper path mappings. At this point, you should hit the breakpoint again.


Happy debugging! :-)

What did you learn in today’s blog post? Did you know how to debug Drush commands? Did you know how to trigger a debugging session from the browser? Share your answers in the comments. Also, I would be grateful if you shared this blog post with others.

This blog post series, cross-posted at as well as here on, is made possible thanks to these generous sponsors: by Osio Labs has online tutorials about migrations, among other topics, and Agaric provides migration trainings, among other services.  Contact Understand Drupal if your organization would like to support this documentation project, whether it is the migration series or other topics.

Read more and discuss at


Drupal blog: Who sponsors Drupal development? (2018-2019 edition)

Planet Drupal - Fri, 2019/09/13 - 12:24am

This blog has been re-posted and edited with permission from Dries Buytaert's blog.

An in-depth analysis of how Drupal's development was sponsored between July 1, 2018 and June 30, 2019.

The past years, I've examined's contribution data to understand who develops Drupal, how diverse the Drupal community is, how much of Drupal's maintenance and innovation is sponsored, and where that sponsorship comes from.

You can look at the 2016 report, the 2017 report, and the 2018 report. Each report looks at data collected in the 12-month period between July 1st and June 30th.

This year's report shows that:

  • Both the recorded number of contributors and contributions have increased.
  • Most contributions are sponsored, but volunteer contributions remains very important to Drupal's success.
  • Drupal's maintenance and innovation depends mostly on smaller Drupal agencies and Acquia. Hosting companies, multi-platform digital marketing agencies, large system integrators and end users make fewer contributions to Drupal.
  • Drupal's contributors have become more diverse, but are still not diverse enough.
Methodology What are issues?

"Issues" are pages on Each issue tracks an idea, feature request, bug report, task, or more. See for the list of all issues.

For this report, we looked at all issues marked "closed" or "fixed" in the 12-month period from July 1, 2018 to June 30, 2019. The issues analyzed in this report span Drupal core and thousands of contributed projects, across all major versions of Drupal.

What are credits?

In the spring of 2015, after proposing initial ideas for giving credit, added the ability for people to attribute their work in the issues to an organization or customer, or mark it the result of volunteer efforts.

A screenshot of an issue comment on You can see that jamadar worked on this patch as a volunteer, but also as part of his day job working for TATA Consultancy Services on behalf of their customer, Pfizer.'s credit system is truly unique and groundbreaking in Open Source and provides unprecedented insights into the inner workings of a large Open Source project. There are a few limitations with this approach, which we'll address at the end of this report.

What is the Drupal community working on?

In the 12-month period between July 1, 2018 and June 30, 2019, 27,522 issues were marked "closed" or "fixed", a 13% increase from the 24,447 issues in the 2017-2018 period.

In total, the Drupal community worked on 3,474 different projects this year compared to 3,229 projects in the 2017-2018 period — an 8% year over year increase.

The majority of the credits are the result of work on contributed modules:

Compared to the previous period, contribution credits increased across all project types:

The most notable change is the large jump in "non-product credits": more and more members in the community started tracking credits for non-product activities such as organizing Drupal events (e.g. DrupalCamp Delhi projectDrupal Developer DaysDrupal Europe and DrupalCon Europe), promoting Drupal (e.g. Drupal pitch deck or community working groups (e.g. Drupal Diversity and Inclusion Working GroupGovernance Working Group).

While some of these increases reflect new contributions, others are existing contributions that are newly reported. All contributions are valuable, whether they're code contributions, or non-product and community-oriented contributions such as organizing events, giving talks, leading sprints, etc. The fact that the credit system is becoming more accurate in recognizing more types of Open Source contribution is both important and positive.

Who is working on Drupal?

For this report's time period,'s credit system received contributions from 8,513 different individuals and 1,137 different organizations — a meaningful increase from last year's report.

Consistent with previous years, approximately 51% of the individual contributors received just one credit. Meanwhile, the top 30 contributors (the top 0.4%) account for 19% of the total credits. In other words, a relatively small number of individuals do the majority of the work. These individuals put an incredible amount of time and effort into developing Drupal and its contributed projects:

Rank Username Issues 1 kiamlaluno 1610 2 jrockowitz 756 3 alexpott 642 4 RajabNatshah 616 5 volkswagenchick 519 6 bojanz 504 7 alonaoneill 489 8 thalles 488 9 Wim Leers 437 10 DamienMcKenna 431 11 Berdir 424 12 chipway 356 13 larowlan 324 14 pifagor 320 15 catch 313 16 mglaman 277 17 adci_contributor 274 18 quietone 266 19 tim.plunkett 265 20 gaurav.kapoor 253 21 RenatoG 246 22 heddn 243 23 chr.fritsch 241 24 xjm 238 25 phenaproxima 238 26 mkalkbrenner 235 27 gvso 232 28 dawehner 219 29 e0ipso 218 30 drumm 205

Out of the top 30 contributors featured this year, 28 were active contributors in the 2017-2018 period as well. These Drupalists' dedication and continued contribution to the project has been crucial to Drupal's development.

It's also important to recognize that most of the top 30 contributors are sponsored by an organization. Their sponsorship details are provided later in this article. We value the organizations that sponsor these remarkable individuals, because without their support, it could be more challenging for these individuals to be in the top 30.

It's also nice to see two new contributors make the top 30 this year — Alona O'neill with sponsorship from Hook 42 and Thalles Ferreira with sponsorship from CI&T. Most of their credits were the result of smaller patches (e.g. removing deprecated code, fixing coding style issues, etc) or in some cases non-product credits rather than new feature development or fixing complex bugs. These types of contributions are valuable and often a stepping stone towards towards more in-depth contribution.

How much of the work is sponsored?

Issue credits can be marked as "volunteer" and "sponsored" simultaneously (shown in jamadar's screenshot near the top of this post). This could be the case when a contributor does the necessary work to satisfy the customer's need, in addition to using their spare time to add extra functionality.

For those credits with attribution details, 18% were "purely volunteer" credits (8,433 credits), in stark contrast to the 65% that were "purely sponsored" (29,802 credits). While there are almost four times as many "purely sponsored" credits as "purely volunteer" credits, volunteer contribution remains very important to Drupal.

Both "purely volunteer" and "purely sponsored" credits grew — "purely sponsored" credits grew faster in absolute numbers, but for the first time in four years "purely volunteer" credits grew faster in relative numbers.

The large jump in volunteer credits can be explained by the community capturing more non-product contributions. As can be seen on the graph below, these non-product contributions are more volunteer-centric.

Who is sponsoring the work?

Now that we've established that the majority of contributions to Drupal are sponsored, let's study which organizations contribute to Drupal. While 1,137 different organizations contributed to Drupal, approximately 50% of them received four credits or less. The top 30 organizations (roughly the top 3%) account for approximately 25% of the total credits, which implies that the top 30 companies play a crucial role in the health of the Drupal project.

Top contributing organizations based on the number of issue credits.

While not immediately obvious from the graph above, a variety of different types of companies are active in Drupal's ecosystem:

Category Description Traditional Drupal businesses Small-to-medium-sized professional services companies that primarily make money using Drupal. They typically employ fewer than 100 employees, and because they specialize in Drupal, many of these professional services companies contribute frequently and are a huge part of our community. Examples are Hook42, Centarro, The Big Blue House, Vardot, etc. Digital marketing agencies Larger full-service agencies that have marketing-led practices using a variety of tools, typically including Drupal, Adobe Experience Manager, Sitecore, WordPress, etc. They tend to be larger, with many of the larger agencies employing thousands of people. Examples are Wunderman, Possible and Mirum. System integrators Larger companies that specialize in bringing together different technologies into one solution. Example system agencies are Accenture, TATA Consultancy Services, Capgemini and CI&T. Hosting companies Examples are Acquia, Rackspace, Pantheon and End users Examples are Pfizer or bio.logis Genetic Information Management GmbH.

A few observations:

  • Almost all of the sponsors in the top 30 are traditional Drupal businesses with fewer than 50 employees. Only five companies in the top 30 — Pfizer, Google, CI&T, bio.logis and Acquia — are not traditional Drupal businesses. The traditional Drupal businesses are responsible for almost 80% of all the credits in the top 30. This percentage goes up if you extend beyond the top 30. It's fair to say that Drupal's maintenance and innovation largely depends on these traditional Drupal businesses.
  • The larger, multi-platform digital marketing agencies are barely contributing to Drupal. While more and more large digital agencies are building out Drupal practices, no digital marketing agencies show up in the top 30, and hardly any appear in the entire list of contributing organizations. While they are not required to contribute, I'm frustrated that we have not yet found the right way to communicate the value of contribution to these companies. We need to incentivize each of these firms to contribute back with the same commitment that we see from traditional Drupal businesses
  • The only system integrator in the top 30 is CI&T, which ranked 4th with 795 credits. As far as system integrators are concerned, CI&T is a smaller player with approximately 2,500 employees. However, we do see various system integrators outside of the top 30, including Globant, Capgemini, Sapient and TATA Consultancy Services. In the past year, Capgemini almost quadrupled their credits from 46 to 196, TATA doubled its credits from 85 to 194, Sapient doubled its credits from 28 to 65, and Globant kept more or less steady with 41 credits. Accenture and Wipro do not appear to contribute despite doing a fair amount of Drupal work in the field.
  • Hosting companies also play an important role in our community, yet only Acquia appears in the top 30. Rackspace has 68 credits, Pantheon has 43, and has 23. I looked for other hosting companies in the data, but couldn't find any. In general, there is a persistent problem with hosting companies that make a lot of money with Drupal not contributing back. The contribution gap between Acquia and other hosting companies has increased, not decreased.
  • We also saw three end users in the top 30 as corporate sponsors: Pfizer (453 credits), Thunder (659 credits, up from 432 credits the year before), and the German company, bio.logis (330 credits). A notable end user is Johnson & Johnson, who was just outside of the top 30, with 221 credits, up from 29 credits the year before. Other end users outside of the top 30, include the European Commission (189 credits), Workday (112 credits), Paypal (80 credits), NBCUniversal (48 credits), Wolters Kluwer (20 credits), and Burda Media (24 credits). We also saw contributions from many universities, including the University of British Columbia (148 credits), University of Waterloo (129 credits), Princeton University (73 credits), University of Austin Texas at Austin (57 credits), Charles Darwin University (24 credits), University of Edinburgh (23 credits), University of Minnesota (19 credits) and many more.

It would be interesting to see what would happen if more end users mandated contributions from their partners. Pfizer, for example, only works with agencies that contribute back to Drupal, and uses Drupal's credit system to verify their vendors' claims. The State of Georgia started doing the same; they also made Open Source contribution a vendor selection criteria. If more end users took this stance, it could have a big impact on the number of digital agencies, hosting companies and system integrators that contribute to Drupal.

While we should encourage more organizations to sponsor Drupal contributions, we should also understand and respect that some organizations can give more than others and that some might not be able to give back at all. Our goal is not to foster an environment that demands what and how others should give back. Instead, we need to help foster an environment worthy of contribution. This is clearly laid out in Drupal's Values and Principles.

How diverse is Drupal?

Supporting diversity and inclusion within Drupal is essential to the health and success of the project. The people who work on Drupal should reflect the diversity of people who use and work with the web.

I looked at both the gender and geographic diversity of contributors. While these are only two examples of diversity, these are the only diversity characteristics we currently have sufficient data for. recently rolled out support for Big 8/Big 10, so next year we should have more demographics information

Gender diversity

The data shows that only 8% of the recorded contributions were made by contributors who do not identify as male, which continues to indicate a wide gender gap. This is a one percent increase compared to last year. The gender imbalance in Drupal is profound and underscores the need to continue fostering diversity and inclusion in our community.

Last year I wrote a post called about the privilege of free time in Open Source. It made the case that Open Source is not a meritocracy, because not everyone has equal amounts of free time to contribute. For example, research shows that women still spend more than double the time as men doing unpaid domestic work, such as housework or childcare. This makes it more difficult for women to contribute to Open Source on an unpaid, volunteer basis. It's one of the reasons why Open Source projects suffer from a lack of diversity, among others including hostile environments and unconscious biases.'s credit data unfortunately still shows a big gender disparity in contributions:

Ideally, over time, we can collect more data on non-binary gender designations, as well as segment some of the trends behind contributions by gender. We can also do better at collecting data on other systemic issues beyond gender alone. Knowing more about these trends can help us close existing gaps. In the meantime, organizations capable of giving back should consider financially sponsoring individuals from underrepresented groups to contribute to Open Source. Each of us needs to decide if and how we can help give time and opportunities to underrepresented groups and how we can create equity for everyone in Drupal.

Geographic diversity

When measuring geographic diversity, we saw individual contributors from six continents and 114 countries:

Contribution credits per capita calculated as the amount of contributions per continent divided by the population of each continent. 0.001% means that one in 100,000 people contribute to Drupal. In North America, 5 in 100,000 people contributed to Drupal the last year.

Contributions from Europe and North America are both on the rise. In absolute terms, Europe contributes more than North America, but North America contributes more per capita.

Asia, South America and Africa remain big opportunities for Drupal, as their combined population accounts for 6.3 billion out of 7.5 billion people in the world. Unfortunately, the reported contributions from Asia are declining year over year. For example, compared to last year's report, there was a 17% drop in contribution from India. Despite that drop, India remains the second largest contributor behind the United States:

The top 20 countries from which contributions originate. The data is compiled by aggregating the countries of all individual contributors behind each issue. Note that the geographical location of contributors doesn't always correspond with the origin of their sponsorship. Wim Leers, for example, works from Belgium, but his funding comes from Acquia, which has the majority of its customers in North America.

Top contributor details

To create more awareness of which organizations are sponsoring the top individual contributors, I included a more detailed overview of the top 50 contributors and their sponsors. If you are a Drupal developer looking for work, these are some of the companies I'd apply to first. If you are an end user looking for a company to work with, these are some of the companies I'd consider working with first. Not only do they know Drupal well, they also help improve your investment in Drupal.

Rank Username Issues Volunteer Sponsored Not specified Sponsors 1 kiamlaluno 1610 99% 0% 1% 2 jrockowitz 756 98% 99% 0% The Big Blue House (750), Memorial Sloan Kettering Cancer Center (5), Rosewood Marketing (1) 3 alexpott 642 6% 80% 19% Thunder (336), Acro Media Inc (100), Chapter Three (77) 4 RajabNatshah 616 1% 100% 0% Vardot (730), Webship (2) 5 volkswagenchick 519 2% 99% 0% Hook 42 (341), Kanopi Studios (171) 6 bojanz 504 0% 98% 2% Centarro (492), Ny Media AS (28), Torchbox (5), Liip (2), Adapt (2) 7 alonaoneill 489 9% 99% 0% Hook 42 (484) 8 thalles 488 0% 100% 0% CI&T (488), Janrain (3), Johnson & Johnson (2) 9 Wim Leers 437 8% 97% 0% Acquia (421), Government of Flanders (3) 10 DamienMcKenna 431 0% 97% 3% Mediacurrent (420) 11 Berdir 424 0% 92% 8% MD Systems (390) 12 chipway 356 0% 100% 0% Chipway (356) 13 larowlan 324 16% 94% 2% PreviousNext (304), Charles Darwin University (22), University of Technology, Sydney (3), Service NSW (2), Department of Justice & Regulation, Victoria (1) 14 pifagor 320 52% 100% 0% GOLEMS GABB (618), EPAM Systems (16), Drupal Ukraine Community (6) 15 catch 313 1% 95% 4% Third & Grove (286), Tag1 Consulting (11), Drupal Association (6), Acquia (4) 16 mglaman 277 2% 98% 1% Centarro (271), Oomph, Inc. (16), E.C. Barton & Co (3),, Inc. (1), Bluespark (1), Thinkbean (1), LivePerson, Inc (1), Impactiv, Inc. (1), Rosewood Marketing (1), Acro Media Inc (1) 17 adci_contributor 274 0% 100% 0% ADCI Solutions (273) 18 quietone 266 41% 75% 1% Acro Media Inc (200) 19 tim.plunkett 265 3% 89% 9% Acquia (235) 20 gaurav.kapoor 253 0% 51% 49% OpenSense Labs (129), DrupalFit (111) 21 RenatoG 246 0% 100% 0% CI&T (246), Johnson & Johnson (85) 22 heddn 243 2% 98% 2% MTech, LLC (202), Tag1 Consulting (32), European Commission (22), North Studio (3), Acro Media Inc (2) 23 chr.fritsch 241 0% 99% 1% Thunder (239) 24 xjm 238 0% 85% 15% Acquia (202) 25 phenaproxima 238 0% 100% 0% Acquia (238) 26 mkalkbrenner 235 0% 100% 0% bio.logis Genetic Information Management GmbH (234), OSCE: Organization for Security and Co-operation in Europe (41), Welsh Government (4) 27 gvso 232 0% 100% 0% Google Summer of Code (214), Google Code-In (16), Zivtech (1) 28 dawehner 219 39% 84% 8% Chapter Three (176), Drupal Association (5), Tag1 Consulting (3), TES Global (1) 29 e0ipso 218 99% 100% 0% Lullabot (217), IBM (23) 30 drumm 205 0% 98% 1% Drupal Association (201) 31 gabesullice 199 0% 100% 0% Acquia (198), Aten Design Group (1) 32 amateescu 194 0% 97% 3% Pfizer, Inc. (186), Drupal Association (1), Chapter Three (1) 33 klausi 193 2% 59% 40% jobiqo - job board technology (113) 34 samuel.mortenson 187 42% 42% 17% Acquia (79) 35 joelpittet 187 28% 78% 14% The University of British Columbia (146) 36 borisson_ 185 83% 50% 3% Calibrate (79), Dazzle (13), Intracto digital agency (1) 37 Gábor Hojtsy 184 0% 97% 3% Acquia (178) 38 adriancid 182 91% 22% 2% Drupiter (40) 39 eiriksm 182 0% 100% 0% Violinist (178), Ny Media AS (4) 40 yas 179 12% 80% 10% DOCOMO Innovations, Inc. (143) 41 TR 177 0% 0% 100% 42 hass 173 1% 0% 99% 43 Joachim Namyslo 172 69% 0% 31% 44 alex_optim 171 0% 99% 1% GOLEMS GABB (338) 45 flocondetoile 168 0% 99% 1% Flocon de toile (167) 46 Lendude 168 52% 99% 0% Dx Experts (91), ezCompany (67), Noctilaris (9) 47 paulvandenburg 167 11% 72% 21% ezCompany (120) 48 voleger 165 98% 98% 2% GOLEMS GABB (286), Lemberg Solutions Limited (36), Drupal Ukraine Community (1) 49 lauriii 164 3% 98% 1% Acquia (153), Druid (8), Lääkärikeskus Aava Oy (2) 50 idebr 162 0% 99% 1% ezCompany (156), One Shoe (5) Limitations of the credit system

It is important to note a few of the current limitations of's credit system:

  • The credit system doesn't capture all code contributions. Parts of Drupal are developed on GitHub rather than, and often aren't fully credited on For example, Drush is maintained on GitHub instead of, and companies like Pantheon don't get credit for that work. The Drupal Association is working to integrate GitLab with GitLab will provide support for "merge requests", which means contributing to Drupal will feel more familiar to the broader audience of Open Source contributors who learned their skills in the post-patch era. Some of GitLab's tools, such as in-line editing and web-based code review will also lower the barrier to contribution, and should help us grow both the number of contributions and contributors on
  • The credit system is not used by everyone. There are many ways to contribute to Drupal that are still not captured in the credit system, including things like event organizing or providing support. Technically, that work could be captured as demonstrated by the various non-product initiatives highlighted in this post. Because using the credit system is optional, many contributors don't. As a result, contributions often have incomplete or no contribution credits. We need to encourage all Drupal contributors to use the credit system, and raise awareness of its benefits to both individuals and organizations. Where possible, we should automatically capture credits. For example, translation efforts on are not currently captured in the credit system but could be automatically.
  • The credit system disincentives work on complex issues. We currently don't have a way to account for the complexity and quality of contributions; one person might have worked several weeks for just one credit, while another person might receive a credit for 10 minutes of work. We certainly see a few individuals and organizations trying to game the credit system. In the future, we should consider issuing credit data in conjunction with issue priority, patch size, number of reviews, etc. This could help incentivize people to work on larger and more important problems and save smaller issues such as coding standards improvements for new contributor sprints. Implementing a scoring system that ranks the complexity of an issue would also allow us to develop more accurate reports of contributed work.

All of this means that the actual number of contributions and contributors could be significantly higher than what we report.

Like Drupal itself, the credit system needs to continue to evolve. Ultimately, the credit system will only be useful when the community uses it, understands its shortcomings, and suggests constructive improvements.

A first experiment with weighing credits

As a simple experiment, I decided to weigh each credit based on the adoption of the project the credit is attributed to. For example, each contribution credit to Drupal core is given a weight of 11 because Drupal core has about 1,1 million active installations. Credits to the Webform module, which has over 400,000 installations, get a weight of 4. And credits to Drupal's Commerce project gets just 1 point as it is installed on fewer than 100,000 sites.

The idea is that these weights capture the end user impact of each contribution, but also act as a proxy for the effort required to get a change committed. Getting a change accepted in Drupal core is both more difficult and more impactful than getting a change accepted to Commerce project.

This weighting is far from perfect as it undervalues non-product contributions, and it still doesn't recognize all types of product contributions (e.g. product strategy work, product management work, release management work, etc). That said, for code contributions, it may be more accurate than a purely unweighted approach.

The top 30 contributing individuals based on weighted issue credits.

The top 30 contributing organizations based on weighted issue credits.


Our data confirms that Drupal is a vibrant community full of contributors who are constantly evolving and improving the software. It's amazing to see that just in the last year, Drupal welcomed more than 8,000 individuals contributors and over 1,100 corporate contributors. It's especially nice to see the number of reported contributions, individual contributors and organizational contributors increase year over year.

To grow and sustain Drupal, we should support those that contribute to Drupal and find ways to get those that are not contributing involved in our community. Improving diversity within Drupal is critical, and we should welcome any suggestions that encourage participation from a broader range of individuals and organizations.


TEN7 Blog's Drupal Posts: Case Study: Bloomington Public Schools

Planet Drupal - Thu, 2019/09/12 - 6:34pm
The Hub - No Question It Can't Answer

The Bloomington Public Schools District in Bloomington, MN is a leader in harnessing technology to support student learning. We’ve been working with them since 2012, when we helped them move their K-12 site from a proprietary content management system that was expensive, inflexible and not mobile-friendly to a Drupal-powered site that provided more control over the site structure and content.


Texas Creative: Why I Like Drupal 8 and You Should Too

Planet Drupal - Thu, 2019/09/12 - 5:30pm

The profession of building websites has seen many changes in the last few years. SEO, website performance, multi-screen responsiveness, and accessibility are no longer luxuries. On top of that, tools have emerged that have improved the development experience and simplified scalability. Finding a modern CMS or framework that can incorporate ALL of these considerations is difficult. Especially when the flexibility to be able to create unique websites is also important. This is where Drupal 8 outshines other frameworks.

Read More

clemens-tolboom opened an issue in dasDaniel/svelectron-example

On github - Thu, 2019/09/12 - 11:18am
clemens-tolboom opened an issue in dasDaniel/svelectron-example Sep 12, 2019 I got a white screen without the Hello World #1

cd /tmp/ $ git clone Cloning into 'svelectron-example'... remote: Enumerating objects: 24, done. re…

clemens-tolboom pushed to patch-1 in clemens-tolboom/svelectron-example

On github - Thu, 2019/09/12 - 11:13am
clemens-tolboom pushed to patch-1 in clemens-tolboom/svelectron-example Sep 12, 2019 1 commit to patch-1
  • 0330bd8 Add npm install for the first timers