emGee Software Solutions Custom Database Applications

Share this

Drupal CMS

Agiledrop.com Blog: Let's talk about localization

Drupal.org aggregator - Tue, 09/17/2019 - 23:34

In this post, we'll take a look at localization and explain why translation by itself is not enough. We'll also briefly discuss one website trend that is the same in all cultures and as such doesn't need to be localized.

Categories: Drupal CMS

Promet Source: Trends and Tips for Tapping Tech Talent

Drupal.org aggregator - Tue, 09/17/2019 - 21:24
These are interesting times for securing tech talent. With the current unemployment rate at 3.7 percent, the job market is highly competitive, and that’s particularly true for the technology sector.  Reaching out to agencies that can offer the right talent when and where it is needed is proving to be the solution among savvy organizations.  Key among the advantages that the right agency relationship offers: the opportunity to leverage specific expertise on an ongoing, ad-hoc, or one-off basis.
Categories: Drupal CMS

DrupalCon News: Join us in Amsterdam to learn & network in person

Drupal.org aggregator - Tue, 09/17/2019 - 09:53

DrupalCon Amsterdam is approaching — next month! Are you still deciding about going? With the robust program, each day will be full of exciting sessions, social activities and contribution sprints galore! Check out the breadth and scope of our offerings, with insight you won’t want to miss.

The event kicks off with Trainings on the morning of Monday, October 28. Choose from these seven options to further your learning:

Categories: Drupal CMS

Bounteous.com: Audit Your Drupal Theme

Drupal.org aggregator - Tue, 09/17/2019 - 09:28
Explore tools and methodologies that provide insights to keep your Drupal theme manageable over time as well as concepts to establish metrics within your theme.
Categories: Drupal CMS

Redfin Solutions: Leveraging Custom and Third Party Libraries in React Native: Part 3

Drupal.org aggregator - Tue, 09/17/2019 - 07:11
Leveraging Custom and Third Party Libraries in React Native: Part 3

This is the last in a series of blog posts about creating an app with React Native. To get started with React Native, read the Basics of React Native: Part 1. If you want to include content from a Drupal website in the app, read Integrating Content with React Native: Part 2.

Jacob September 17, 2019
Categories: Drupal CMS

Specbee: Top 13 questions you may STILL have about migrating to Drupal 8 (Answers included!)

Drupal.org aggregator - Tue, 09/17/2019 - 06:07
Top 13 questions you may STILL have about migrating to Drupal 8 (Answers included!) Shefali Shetty 17 Sep, 2019 Top 10 best practices for designing a perfect UX for your mobile app

“Should I upgrade or should I just wait?” This question has been constantly bothering business decision-makers when it comes to migrating their website from Drupal 7 to Drupal 8. Change can be hard and terrifying, especially at its inception. Yet, a change is what allows you to grow, evolve and progress. It can get painful to take a decision as big as a migration of your Drupal 7 (or 6) website – the one that you knew and have loved. But soon you will know you have made the most brilliant business decision, ever! 

Drupal 8 Migration - A Long-term vision

There has always been a perception that Drupal is a difficult CMS to get a hang of. Starting from end-users to developers, Drupal was considered as having a huge learning curve.  Yes, with the previous major versions (before Drupal 8), the process of upgrading and adjusting to the change was harder. It was also more expensive (needed more resource time), the release of contributed modules (and necessary features) were slower and the release cycles got longer.

But with Drupal 8, everything changed. 

Tom Wentworth, (SVP Product Marketing from Acquia), summed up accurately in his article that unlike a few other CMS’s, “Drupal 8 was a teardown all the way to the foundation”. Creating an upgrade based on the same old foundation would have been a much easier task for the Drupal community. But starting from Drupal 8, the Drupal community has focused on long-term sustainability and on getting people to adopt Drupal effortlessly. This called for a complete re-architecture of Drupal 8 with the adoption of Symphony for high performance, Twig for a more modern templating engine, object oriented programming for easier maintenance, modern user experience design creators and editors for rich content editing, and much more. 

Drupal 8’s continuous innovation approach propels an evolution with regular (and shorter) minor releases, semantic versioning (in a ‘major.minor.patch’ format) that helps in backwards-compatibility enhancements and faster stability in modules by releasing experimental modules in core.

Your Drupal 8 Questions, Answered. (To some extent)

Although it has been a while since Drupal 8 has been around and stable, we still get asked a ton of questions by our customers before a migration. 

1. Why should I upgrade to Drupal 8 (from Drupal 7) when Drupal 9 is just around the corner? (We get this nearly every time)

I have a whole blog dedicated to this question, but if you insist, here are your benefits of upgrading to Drupal 8 now -

  • Time crunch – So Drupal 9 does not release until June 2020 and Drupal 7 reaches its end-of-life by December 2021. Which means you have only a year and a half to upgrade to Drupal 9. If your website is considerably simple and needs less customizations, this is a viable option. Else, you’d better off start an upgrade to Drupal 8 now and migrating from Drupal 9 from Drupal 8 is as easy as upgrading to a next minor release.
  • Living with a FOMO – That’s a term I recently learnt about – Fear Of Missing Out. Why do you want to miss out on some powerful and modern enhancements when you can migrate to Drupal 8 now and boost your Drupal website’s performance and experience? Upgrading from Drupal 8 to Drupal 9 is a cakewalk anyway!
  • Just a better version – Drupal 9 is just Drupal 8 minus the deprecated code and modules. Migrate to Drupal 8 now, enjoy a better performing website and an easy upgrade to Drupal 9 (and any future versions of Drupal)
2. We’re still stuck on Drupal 6. Help!

If you’re still stuck on to Drupal 6, you must know that everyone else has moved on. Today, the web has changed and so has Drupal. The Drupal community no longer supports Drupal 6 since February 2016. Which means, there will be no new Drupal modules or features to look forward to, no more bug-fixes, security updates and patches. Thus putting your website’s security at high-risk and of course depriving it of some TLC from the community. If you still want the best for your website, migrate to Drupal 8 now! Yes, you can completely skip Drupal 7. Drupal Migrate module is now included in Drupal 8 core and makes the switch easy and fast.

3. What performance upgrades does Drupal 8 offer?

Drupal 8 comes packed with performance-enhancing features and modules that can turn your website into a speedy and high performing one. Here are a few to name -

  • The Symfony Framework – Drupal 8’s adoption of Symfony framework isn’t just a great move for developers but for website owners as well. Symfony offers a robust, flexible and high-performance framework that allows for easy scalability of a website.
  • BigPipe Caching - It lets you segregate your page into different sections (called Pagelets) which can be rendered as they get available (Cached first). This lets you drastically improve your page’s perceived performance and speed.

  • Caching for Authenticated Users – Drupal 8 uses Varnish to cache page content and serve them to authenticated users for better and faster performance.
  • PHP7 support – Did you know PHP 7 is now two times faster than PHP 5.6 because of its new Zend engine? With PHP 7 support in Drupal 8, your websites can see a performance rise up to about 110% and reduced memory usage.
4. What challenges will we encounter during a Drupal 8 migration? What can be done to alleviate those issues?

Challenges encountered during a website migration from say Drupal 7 to Drupal 8, completely depends upon the complexity of a website, if it includes a redesign, the amount of content needed to be migrated and many more other factors. The first and the most crucial step towards a Drupal 8 migration is to audit your existing website. Auditing and analysing your website could be the biggest challenge if not handled well and could lead to a successful (and quick) migration when done right. If not planned well, you might run into problems where you are unprepared to handle -

  • Module compatibility issues
  • Might migrate old and unused modules that will increase migration time
  • Unavailability of existing modules/features/themes/views/entities (in core or contrib) 
  • The need to rebuild and rewrite custom modules in Drupal 8. (Coz as discussed earlier, D8 has restructured itself to be able to be more future-ready)
  • A rebuild/repackage of features and views
  • A redevelopment of the theme – because of Drupal 8’s new and powerful templating engine Twig

How do we fix this? – Easy. Audit your website well. Get a Drupal technology partner to do a complete analysis and audit of your existing website and list out features, modules and other elements that need to be migrated. They will need to provide you with details on what needs a rebuild and what can just be easily ported. You can also use evaluation modules like the Upgrade checker which will give you a comprehensive list of migration components and an estimate of how long it might take.

5. Can we migrate to Drupal 8 and yet preserve our existing data whilst remaining GDPR compliant?

Absolutely! The reason why Drupal is so successful is because of its proactive and battle-ready Drupal community. The Drupal GDPR Compliance team project aims at providing websites with modules and features that can assist in making them GGDPR compliant. There are over 15 new modules in Drupal 8 for GDPR compliance to choose from with some modules that can be ported to Drupal 8 and some that may need a rewrite. Check here for a list of Drupal modules that help you build GDPR compliant websites.

6. What happens to my content? 

Drupal understands how important content is to every organisation. With efforts from more than 500 contributors, the release of Drupal 8.5.0 brought together a stable and robust Drupal Migrate architecture. Modules like Migrate API, Drupal Migrate module and Migrate Drupal UI allows for a flexible and easy content migration from the database or sources like JSON, CSV or XML.

7. If we migrate to Drupal 8, will it break any of our existing features/modules?

The answer to this question depends on your website structure, complexity and the way Drupal 7 (or Drupal 6) was implemented on your website. Many times, there is no direct path for a Drupal 8 upgrade. Custom modules will need a rebuild and will break if simply ported because Drupal 8 is now built on Symfony framework (and OOPS principles). Themes will need to be redeveloped as with the new template engine Twig, migrating your existing Drupal theme will not work.

8. Will our integrations with third-party software break when we migrate to Drupal 8?

Integrations with third-party software have just gotten better with Drupal 8. With web services in core in Drupal 8, creating RESTful APIs are easy and fast. This is invaluable in connecting with many third-party applications. Additionally, Drupal 8 has added many more integration modules to its list.

9. Will our core Drupal 7 modules still work?

Yes. Drupal 7 Core modules have made their way to Drupal 8 and some of them are even better in Drupal 8! While most of them are automatically upgraded, a few modules will need manual work if they don’t have an automatic upgrade path. Some Drupal 7 (or 6) modules are not mapped to the same Drupal 8 module. For example, the Block module in Drupal 7 is now divided into a Block and Custom Block module in Drupal 8. Nonetheless, many contributed modules in Drupal 7 are now in Drupal 8 core (like the Views module). 

10. What happens to our custom and contributed modules?

After Drupal 8’s adoption of the Symfony framework and Object Oriented Programming principles, Drupal has opened its doors to wider set of developers and programmers. This also helps in building code that is more robust and reusable. But this time-saving, future-ready concept brings along some bad news too. The bad news is that most of the existing custom modules and some contributed modules will need to be rebuilt from scratch to be able to support Drupal 8’s futuristic mission. But the great part about this is from Drupal 8 onwards, any major/minor upgrade will be easy as pie.

11. Will our Drupal theme break on migrating to Drupal 8?

Unfortunately, yes it will. Since Drupal 4.7 up until Drupal 7, PHPTemplate has been the default Drupal Theme engine. But with the adoption of the Twig (part of Symfony2) for a more powerful, secure and modern templating engine, themes will need to be redeveloped. However, parts of code can be replaced as is.

12. How can Drupal 8’s API-first approach benefit us?

By the year 2020, there are going to be more than 50 billion internet connected devices. Content is now consumed via a plethora of mediums – computers, mobiles, IoTs, wearables, conversational interfaces, smart TVs… and the list keeps growing. Which means, your brand needs to interact with a lot more devices and in many more formats than just a website. Content delivery has gotten a lot more challenging.

Just so we are on the same page, an API (Application Programing Interface) is a set of rules or routines (functions or programs) that specifies how applications can interact with each other. For example, if you want to display the current weather on your website, you can invoke an API with websites that offer this service.
To be able to handle the content delivery challenge efficiently, content needs to be treated like well-structured data. Drupal’s API-first approach, lets you create an API before you build your website or mobile app. This futuristic approach allows you to turn content into services which can then interact with diverse devices irrespective of the formats. While Drupal 7, also supports the API-first approach with the help of additional modules, Drupal 8 comes built-in with the content-as-a-service model.
This is what our in-house expert Drupal Practice Head, Malabya Tewari has to say about Drupal 8’s API first approach – “Drupal 8 has taken this approach to another level and here’s why- REST module is now in core, where you can create own custom web-services using Views (which is also added in core in D8). It is easier to create custom REST APIs using the core REST module. Adding basic authentication is in core as well. You can get APIs, including JSON API and GraphQL, for all entities - out of the box! 

13.What are the benefits of upgrading to Drupal 8?

One of the most stunning features of Drupal 8 is that you have (almost) everything you need, out-of-the-box. 

  • Responsive websites are not a luxury anymore, they are a necessity. All of Drupal 8’s themes are responsive off-the-rack – which not only works great with all devices also makes configuration and set up of your Drupal website a lot easier.
  • A built-in, well configured WYSIWYG editor CKEditor lets you preview and edit your content in a breeze. You also have an in-place editor that lets you edit blocks, content, menus, etc. right in the same page.
  • SEO gets you noticed and out-there. With some of Drupal’s built-in powerful SEO modules, you can take your website places! Modules like SEO Checklist, PathAuto, Redirect, MetaTag, etc. are killing it!
  • The newest and most powerful version of HTML, which is HTML5 is now built-into Drupal 8. It lets you embed complex input elements like audio, video, date, email, etc with ease and better functionality across all devices.
  • Take your business global with Drupal 8’s out-of-the-box multilingual support. You can not only create pages enabled with language-based views, even the admin interface allows you to select our preferred language. The built-in content translate modules enables you to translate any content entity into different languages.


It has been a while, more than three years now, since Drupal 8 has made its entry into the field. The best of the Drupal community worked hard for nearly 5 years to produce this masterpiece of a CMS and finally announced its arrival in November 2015. Since then, more than 150,000 Drupal websites have migrated to Drupal 8, only to find a higher performing, robust and a more flexible solution. Yes, the change is not very easy but once you migrate to Drupal 8, life surely gets easier. Reach out to an expert Drupal development company to help you take the best possible approach towards a successful Drupal 8 migration. 

Drupal Planet Shefali ShettyApr 05, 2017 Subscribe For Our Newsletter And Stay Updated Subscribe Shefali ShettyApr 05, 2017 Recent Posts Image Top 13 questions you may STILL have about migrating to Drupal 8 (Answers included!) Image How to Manage your Media using the Drupal 8 Media module Image PHP Debugging - How to Debug your PHP Code (Drupal debugging techniques included!) Explore Our Drupal Services TAKE ME THERE Featured Success Stories

Know more about our technology driven approach to recreate the content management workflow for [24]7.ai


Find out how we transformed the digital image of world’s largest healthcare provider, an attribute that defined their global presence in the medical world.


Develop an internal portal aimed at encouraging sellers at Flipkart to obtain latest insights with respect to a particular domain.

Categories: Drupal CMS

Code Karate: Drupal 8 Publish Content Module

Drupal.org aggregator - Tue, 09/17/2019 - 05:06
Episode Number: 233

The Drupal 8 Publish Content module is a simple module that provides you additional permissions to allow users to publish or unpublish content without having to give the user the ability to administer all the content on your site. This module is a lightweight solution to help you build out your content management workflow on your Drupal 8 site.

The module also adds some additional features such as:

Tags: DrupalDrupal 8Drupal Planet
Categories: Drupal CMS

Aram Boyajyan: Rehash MD5 password in Drupal 8

Drupal.org aggregator - Tue, 09/17/2019 - 03:59
Rehash MD5 password in Drupal 8

Below is a simple code snippet that allows you to convert a password hashed using MD5 into the format that can be used by Drupal 8. This can be useful if you are creating users programmatically and need to re-create their password from an MD5 source.

aram Tue, 17/09/2019 - 12:59
Categories: Drupal CMS

Hook 42: Drupal Core Initiative Meetings Recap - September 9th-13th, 2019

Drupal.org aggregator - Mon, 09/16/2019 - 07:44
Drupal Core Initiative Meetings Recap - September 9th-13th, 2019 Alona Oneill Mon, 09/16/2019 - 16:30
Categories: Drupal CMS

Jacob Rockowitz: A bump in the Webform module's road toDrupal 9

Drupal.org aggregator - Mon, 09/16/2019 - 03:34

The things that make me most excited about the pending release of Drupal 9 in June 2020 is that as a community we have the opportunity to look back at what we have accomplished, let go of some old deprecated code, and can now start thinking about what is next for Drupal 10.


To my mind, the biggest accomplishments with Drupal 8’s release was shifting it’s entire code base and community to be more object-oriented. The adoption of Symfony into Drupal core allowed us to build a more robust and flexible Content Management Framework. The Webform module for Drupal 8 is a testament to how healthy Drupal has become as a framework. Its robustness is a combination of Drupal's Plugin API and Form API with object-oriented concepts, including dependency injection. A straightforward and personal statement is.

Looking at the code and concepts behind core and contributed modules, it is immediately apparent that everyone stepped back and reapproached a lot of technical challenges - our collective hard work and contributions resulted in great solutions and better code. Core improvements are documented as initiatives on Drupal.org. Contributed projects generally don't have initiatives. When you look at the flexibility behind a "simple" module like Metatag, maintained by Damien McKenna (DamienMcKenna) or something potentially as "complex" as Domain Access, maintained by Ken Rickard (agentrickard), it’s...Read More

Categories: Drupal CMS

Srijan Technologies: What’s New in Drupal 9 and Why Do You Need To Upgrade

Drupal.org aggregator - Mon, 09/16/2019 - 02:48

The countdown for Drupal 9 has begun. Whether you’ve recently moved to Drupal 8 or not, soon it will be time for another upgrade.

Categories: Drupal CMS

Lullabot: Perspectives of Women in Technology - Part 2

Drupal.org aggregator - Fri, 09/13/2019 - 10:09

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: Drupal CMS

mark.ie: Writing View Mode Templates in PatternLab

Drupal.org aggregator - Fri, 09/13/2019 - 09:53
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: Drupal CMS

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

Drupal.org aggregator - Fri, 09/13/2019 - 03:24

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.

Categories: Drupal CMS

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

Drupal.org aggregator - Thu, 09/12/2019 - 19:42

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 vic.gov.au'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 drupal.org.

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.

Categories: Drupal CMS

Agaric Collective: Introduction to Drupal 8 upgrades

Drupal.org aggregator - Thu, 09/12/2019 - 19:06

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 Drupal.org ;-) 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 Agaric.coop, Drupalize.Me, and Centarro.io 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 UnderstandDrupal.com as well as here on Agaric.coop, is made possible thanks to these generous sponsors: Drupalize.me 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.coop.

Categories: Drupal CMS

Agaric Collective: List of migration related Drupal modules

Drupal.org aggregator - Thu, 09/12/2019 - 17:51

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 UnderstandDrupal.com as well as here on Agaric.coop, is made possible thanks to these generous sponsors: Drupalize.me 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.coop.

Categories: Drupal CMS

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

Drupal.org aggregator - Thu, 09/12/2019 - 17:00

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.

Categories: Drupal CMS

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

Drupal.org aggregator - Thu, 09/12/2019 - 15:24

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 https://github.com/dinarcon/ud_migrations.

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: https://www.jetbrains.com/phpstorm/marklets/ 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 UnderstandDrupal.com as well as here on Agaric.coop, is made possible thanks to these generous sponsors: Drupalize.me 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.coop.

Categories: Drupal CMS

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

Drupal.org aggregator - Thu, 09/12/2019 - 15:24

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 Drupal.org'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 Drupal.org issues?

"Issues" are pages on Drupal.org. Each issue tracks an idea, feature request, bug report, task, or more. See https://www.drupal.org/project/issues for the list of all issues.

For this report, we looked at all Drupal.org 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 Drupal.org credits?

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

A screenshot of an issue comment on Drupal.org. 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.

Drupal.org'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 Drupal.org 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, Drupal.org'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 Platform.sh. 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 Platform.sh 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 Drupal.org contributors. While these are only two examples of diversity, these are the only diversity characteristics we currently have sufficient data for. Drupal.org 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. Drupal.org'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), Gaggle.net, 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 Drupal.org's credit system:

  • The credit system doesn't capture all code contributions. Parts of Drupal are developed on GitHub rather than Drupal.org, and often aren't fully credited on Drupal.org. For example, Drush is maintained on GitHub instead of Drupal.org, and companies like Pantheon don't get credit for that work. The Drupal Association is working to integrate GitLab with Drupal.org. 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 Drupal.org.
  • 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 https://localize.drupal.org 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 Drupal.org 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 Drupal.org issue credits.

The top 30 contributing organizations based on weighted Drupal.org 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.

Categories: Drupal CMS


1 2 3 4 5 6 7 8 9 next › last »