Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 8 hours 58 min ago

Valuebound: How to use Configuration Split Module to Split Configurations in Drupal 8

12 April 2017 - 4:53am

The configuration Split module allows users to define sets of configuration that will get exported to separate directories when exporting and get merged together when importing.

  • Drupal split module depends on Config Filter for the integration with the import/export pipeline of the Drupal UI and drush.
  • It is possible to define in settings.php which of these sets should be active and considered for the export and import

                                Here are a few things that are considered configuration:

Configuration split exposes a configuration entity which controls what you want to split off. Currently, you can

  • Blacklist modules: Any configuration that…
Categories: Drupal

Liip: Drupal 8 – Multilanguage Improvements

12 April 2017 - 2:19am

As a Swiss-based Drupal Agency, we have to create a lot of multilingual sites. Since Switzerland has three official languages (German, French, Italian) and even one more national language (Rumantsch), we are used to this requirement and we found our way with Drupal to make this an easy task (usually). We mainly used node translations in Drupal 7 for maximum flexibility. We used to separate languages from each other using the various i18n modules, language specific menus, blocks, URL-patterns, terms and so on.

With Drupal 8, things changed.
I struggled a little doing multilingual sites in Drupal 8 the same way I was used to in Drupal 7 because node translation is not available anymore (which is good) so I had to find another way to achieve the same easy to handle translations system. For us and for our clients. Let me explain, what I have learned.


Drupal 8 issues multilanguage challenges Challenge 1: Node add / edit menu handling

The main challenge I had using Drupal 8, was the ease to build your menus directly from the node creation page. You can do it, but only for the initial language. If you try to add a translated node to another menu or rename the item, it always ends up moving / renaming the source node instead of adding a link to the translation. So it can become quite confusing building a navigation directly from the node creation page or to add translations to the menu. A workaround was to add all navigation items manually in the menu administration if you are using a menu per language. With lots of languages and menus / items, this is not really a convenient task. Fortunately, translations from the node creation page have been implemented with a later release of Drupal 8.

Challenge 2: Untranslated Nodes show up in Menu

Another thing which bothered me was that untranslated nodes show up in the navigation (if you use only one menu). This can be quite confusing since most of the times not every page is translated in every language. Or in some languages, you need a little more than in others. You can read a lot about this topic and the reasons behind (e.g. here and here). However you do it, it’s always wrong in some situations and perfectly fine in others. But to be “limited” and “locked in” to a certain way is not nice and you have to deal with it. To sum up, once a node is put into a menu, it will show up everywhere. Regardless if there are translations or not.

Challenge 3: Language Switcher shows all languages – always.

Somewhat confusing is the Language Switcher. In Drupal 7, a language link was not available or strikethrough if there was no translation available. In Drupal 8, every language is always visible and linked. So if you look on a German page which is only available in German, the language switcher will present you all language links to the same node. A click on those language links mainly changes the interface language but the node content remains the same (since not translated). Usually also with a drupalish URL (node/xxxx) because there is no translation for the node and therefore also no URL alias available. This behavior is confusing and wrong in my point of view

An example to illustrate the above-written challenges.

English Front-Page with mixed navigation items.

The screen above shows an installation with 2 languages (English and German). The English Page is a basic page which has a translation. English is selected. If you choose Deutsch on the language switcher, the English Page becomes Deutsche Seite (see image below) and shows the German content. So far so good. But the second menu item you see with the title Über uns (nur Deutsch) should not appear here since it’s only available in German. But it does. And if you actually go on this page, you will see the German text with everything English around it and no URL-Alias (/node/2 in this example). This is usually not very useful for us.

German only Page – Language Switcher visible.

Also, the language switcher shown in the image above is from my point of view wrong or not very useful. It shows a link to the English version, but there is no English translation for this node. So why is it there? To see a German page with English decoration? Not sure. But I want to get rid of this link or at least modify it to be stroked through if the language is not available.

How to fix improve this?

Luckily, the Drupal community is always good for help. After some “research” on the web, I finally found (besides lots of discussions and comments in the issue queues) a way to achieve the desired setup.

To sum up again: I want to see only menu items which are available in my language and only see a link to another language, if a translation is available.

Since there is no patch and still some ongoing discussions on you need to implement it on your own. Implement the following two modules.

Hide untranslated menu items

Code from Credits go to michaelkoehne.

<?php use Drupal\Core\Menu\MenuLinkInterface; use Drupal\menu_link_content\Plugin\Menu\MenuLinkContent; use Drupal\Core\Language\LanguageInterface; /** * Implements hook_preprocess_menu(). */ function MYMODULE_preprocess_menu(&$variables) { if ($variables['menu_name'] == 'main') { $language = Drupal::languageManager() ->getCurrentLanguage(LanguageInterface::TYPE_CONTENT) ->getId(); foreach ($variables['items'] as $key => $item) { if (!$variables['items'][$key] = MYMODULE_checkForMenuItemTranslation($item, $language)) { unset($variables['items'][$key]); } } } } function MYMODULE_checkForMenuItemTranslation($item, $language) { $menuLinkEntity = MYMODULE_load_link_entity_by_link($item['original_link']); if ($menuLinkEntity != NULL) { $languages = $menuLinkEntity->getTranslationLanguages(); // Remove links which are not translated to the current language. if (!array_key_exists($language, $languages)) { return FALSE; } else { if (count($item['below']) > 0) { foreach ($item['below'] as $subkey => $subitem) { if (!$item['below'][$subkey] = MYMODULE_checkForMenuItemTranslation($subitem, $language)) { unset($item['below'][$subkey]); } } } return $item; } } } function MYMODULE_load_link_entity_by_link(MenuLinkInterface $menuLinkContentPlugin) { $entity = NULL; if ($menuLinkContentPlugin instanceof MenuLinkContent) { $menu_link = explode(':', $menuLinkContentPlugin->getPluginId(), 2); $uuid = $menu_link[1]; $entity = \Drupal::service('entity.repository') ->loadEntityByUuid('menu_link_content', $uuid); } return $entity; }

Hide untranslated languages in language switcher

Code from (slightly adapted. Links get a class, not removed by default). Credits to Leon Kessler.

<?php /** * @file * Hide language switcher links for untranslated languages on an entity. */ use Drupal\Core\Entity\ContentEntityInterface; /** * Implements hook_language_switch_links_alter(). */ function MYOTHERMODULE_language_switch_links_alter(array &$links, $type, $path) { if ($entity = MYOTHERMODULE_get_page_entity()) { $new_links = array(); foreach ($links as $lang_code => $link) { try { if ($entity->getTranslation($lang_code)->access('view')) { $new_links[$lang_code] = $link; } } catch (\InvalidArgumentException $e) { // This language is untranslated so do not add it to the links. $link['attributes']['class'][] = 'not-translated'; $new_links[$lang_code] = $link; } } $links = $new_links; // If we're left with less than 2 links, then there's nothing to switch. // Hide the language switcher. if (count($links) < 2) { $links = array(); } } } /** * Retrieve the current page entity. * * @return Drupal\Core\Entity\ContentEntityInterface * The retrieved entity, or FALSE if none found. */ function MYOTHERMODULE_get_page_entity() { $params = \Drupal::routeMatch()->getParameters()->all(); $entity = reset($params); if ($entity instanceof ContentEntityInterface) { return $entity; } return FALSE; }

Please note: The code above is from and therefore thanks to the original authors linked above.

Enable those two modules and you’re all set!

I did not encounter any issues yet using those two modules. If ever something changes in the way Drupal handles those cases, you just need to switch off the modules and everything should be back to normal. So nothing to lose right?

There are other attempts to this by altering the menu block. One of them is Menu Block Current Language but I had no luck with this one. On my most recent project, it worked with one menu but not if you separate your menu by two blocks (different starting levels).

I would love to hear how you guys handle those cases or how you deal with I18N in general. I’m sure there are a gazillion other ways to do it.

Categories: Drupal

La Drupalera (en): Grunt, automating repetitive work

12 April 2017 - 1:50am

Grunt is a Javascript task automator that allows us to launch a series of tasks at the same time with just a single order. Being based on Javascript, both the syntax and the operation is very simple, working based on plugins

Instalation npm install -g grunt-cli


We will need two main files that we will place in the root of the project in which Grunt will perform its tasks:


{ "name": "ExampleProject", "version": "0.1", "dependencies": { }, "devDependencies": { } }

and Gruntfile.js

Read more
Categories: Drupal

Verbosity: Talking migrations at DrupalCon Baltimore

11 April 2017 - 5:00pm

If you are imporitng content to Drupal 8, or planning to do so in the future, there are two upcoming talks at DrupalCon Baltimore that may be of interest to you...

Migrate with the Maintainers Lab

At the Migrate with the Maintainers Lab we will walk you through the process of importing data into your Drupal 8 site, using a variety of approaches based on the Drupal Core Migrate module. In the past I have offered this as a full-day seminar at camps in New Jersey, Chicago, and San Francisco. This time we will have 3 of the core contributors as well! It is a 2h session so it will be a fast paced workshop.

Planning & Managing Migrations

The Planning & Managing Migrations session is a standard DrupalCon talk. I'm doing this one in conjunction with Aimee from Hook 42. I have done a similar talk with my colleague Novella at the Ottawa DrupalCamp, and solo in other places. Aimee and I have collaborated on large-scale migrations before so this talk will cover the issues you find at scale! It presumes only basic Drupal knowledge and is aimed at project managers but it will still be beneficial to developers who want to improve their processes.

Hope to see you there!

Categories: Drupal

Angie Byron: The Drupal Community Working Group: What it is, what it isn't

11 April 2017 - 2:26pm

In recent weeks, I've seen a whole lot of FUD regarding the Drupal Community Working Group, and what it is they do or don't do. While I no longer serve in the CWG (I stepped down from all "extra-curricular" Drupal activities back in 2015 to focus on my family), most of the portrayals I've read are misinformed at best and completely inaccurate at worst. So, as an ex-member, who was uninvolved in recent events and therefore can perhaps speak more freely(?), I’d like to try and clear up a few misconceptions I've seen.

Some have characterized the CWG as some nebulous dark secret court of frothing SJW activists, gleefully acting as judge/jury/executioner, deliberately seeking out “bad apples" in the community to oust, laughing malevolently all the way. This is patently false, and nothing could be further from the truth.

In reality, barring "flash point" incidents like the most recent one, it’s a pretty mundane gig. It mostly involves watching for something to be brought across your "desk" via an incident report, then trying your best as an unpaid volunteer—appointed based on your demonstrated ability to stay neutral and diplomatic in a crisis—to help empower people in the community to solve their own problems.

This takes different forms. A lot of the times it’s simply giving people a safe place to post concerns where they know they’ll be looked at seriously. The CWG provides someone to speak to who will genuinely listen to your concerns, and will give both parties a chance to speak and feel heard. If the situation escalates, the CWG will sometimes suggest neutral third-parties to help mediate, or in the “bigger” cases, get directly involved with mediation themselves. And while the CWG is empowered to oust people from the community in extreme circumstances, a) to-date, they have only done so once, following a harassment incident at DrupalCon, and b) barring "extreme" circumstances such as that, it is only done after a last, *last* resort. All of this is laid out in the Conflict Resolution Policy and Process:

If an individual has multiple, *multiple* complaints against them, in many cases driving others to either leave the community entirely or dramatically reduce their involvement in the project, and if every other attempt to resolve the situation has failed, which includes private mediation, one-on-one mentoring, sterner warnings, etc. then as a last-ditch effort something like an Action Plan is developed. This is summarized as:

"The aim of an action plan is to find a path forward that avoids additional harm to the community. Drafting an action plan should help people recognise what triggers these incidents and help them learn to respond differently by using alternative approaches to problem-solving.

However, the action plan may also serve as a "final warning." If further complaints come to the CWG, further action may be necessary. As a group, our authority derives from Dries, and when necessary, we also consult Dries and involve him in the process."

The template includes a summary of complaints (all of which have been already vetted by the CWG for validity), the impact the person's actions have had on members of the community, and a clearly outlined set of steps to perform to prevent future complaints (e.g. if you're feeling frustrated, WALK AWAY instead of engaging in online battles in the heat of the moment). The intent is to wake the person up a bit, to help them understand that their actions — regardless of how justified they feel they are in having taken them — have consequences, often on people they care about, and to give them a clear path to re-engage with the community in a constructive and healthy way.

The CWG will bend over backwards to help people not get to that point, *especially* if they have an extensive contribution record. At a certain point though, if a “body trail” develops of people leaving the community because of an individual's conduct, it becomes something that needs to be addressed, especially if you sit on a governing body with the mandate to keep the community healthy. This is the situation that happened with chx, whose self-ban from the community was widely publicized, and which keeps getting brought up in the context of recent events as somehow related, which it is not.

Some people might respond to this with "Well, then contributors should just grow a thicker skin." That's certainly one approach. However, you lose a lot of great contributors that way (and indeed, we already have), as well as a lot of new blood into your project. I've previously documented my first 5 minutes in the Drupal community. Had I not been "contractually obligated" to remain because of Google Summer of Code, that likely would've been my last 5 minutes in the Drupal community, as well. And there are 1000s of other contributors out there like "past webchick." Food for thought.

So thanks, CWG, for doing your part of the thankless and difficult job that is ensuring that the Drupal community remains a respectful and collaborative place for all of us to do awesome things. <3

Tags: drupalcommunity
Categories: Drupal

Mediacurrent: Comparing Drupal and Adobe Experience Manager, Part 1 of 2

11 April 2017 - 10:54am

There is a good deal of publicly-accessible content comparing enterprise-level Content Management Systems (CMS) in terms of features, functionality, and cost. Each CMS comes with its own strengths and weaknesses in light of an organization’s requirements, and it behooves the organization to read up on these comparisons and consult with digital agencies like Mediacurrent before deciding on which CMS to use.

Categories: Drupal

LakeDrops Drupal Consulting, Development and Hosting: Prevent ambiguity in Drupal 8 migration source query

11 April 2017 - 10:48am
Prevent ambiguity in Drupal 8 migration source query Richard Papp Tue, 04/11/2017 - 19:48 If you customize the database query in Drupal 8 migration source plugins, you may run into an integrity constraint violation. This can be resolved by setting an alias for the table.
Categories: Drupal

Code Positive: Living Documentation For Your Drupal Project

11 April 2017 - 10:25am

Understanding the importance and benefits of living documentation, and why it can be critical for the continuity of your Drupal project.



Categories: Drupal blog: Technical Advisory Committee Update

11 April 2017 - 10:12am

In October of last year the Technical Advisory Committee was formed to evaluate options for the developer tools we use on The TAC consists of Angie Byron, Moshe Weitzman, and Steve Francia, acting as advisors to Megan Sanicki, the Executive Director of the Drupal Association.

The TAC's mandate is to recommend a direction for the future of our tools on Megan will evaluate this recommendation, make a decision, and prioritize that work in the development roadmap of the Drupal Association engineering team.

What is the motivation behind looking at our developer tools now?

Close followers of the Drupal project will have noticed a trend in the last several months. From Dries' announcement of easy upgrades forever, to the revamp of the project application process, to the discussion about making tools for site builders— there is a unifying theme: broadening the reach of Drupal.

This is the same motivation that underlies this evaluation of our developer tools, and defines the goals and constraints of this initiative:

  • Adopt a developer workflow that will be familiar to the millions of developers outside our community
  • Preserve those unique elements of how we collaborate that have made the Drupal project so successful
  • If possible, leverage an expert partner who will help keeping our tooling up to date as open source collaboration tools continue to evolve

This means looking at a number of elements of the developer tool stack:

  • The underlying git service
  • How we tag and package releases
  • The contribution workflow (patch vs. pull request)
  • Project management workflows (the issue queues and tags)
  • CI integration
  • Maintainership
  • Project pages

If this looks like a tremendous undertaking - that's because it is. But there are some things we already know:

  • should continue to be the home of project pages
  • We should adopt a pull request workflow (and ideally we want to be able continue to accept patches as well, at least in the interim)
  • We should move contrib projects to semver, following core's lead
  • We want to preserve our familiar understanding of maintainership
  • We want to avoided forked code and forked conversation
  • We want to ensure the security team still has the tools they need to provide their service to the community

We also know that whatever decision is made, these changes cannot happen all at once. We'll need to take a progressive approach to the implementation, and focus on the parts of the stack that need to change together, so that we don't bite off more than we can chew.

What options are being considered?

At this time, the technical advisory committee is considering three options as they prepare to make their recommendation. The options are: GitLab, which offers both self-hosted and SaaS options; GitHub, which has recently been adding long-requested new features; or continuing to evolve our custom-built tooling, perhaps via issue workspaces.


GitLab is the up-and-comer among Git hosts. GitLab can be self hosted using either their community or enterprise editions, or repositories can be hosted at Though they recently stumbled, they have been notably open and transparent about their efforts to build a leading collaboration platform.

Gitlab is itself open-source, and has just released its 9.0 edition. GitLab has aggressively pursued the latest in development tools and workflow features, including project management tools, a ui for merge conflict resolution with in-line commenting and cherry-picking, docker registries for projects, integration with CI tools, and even Gitter, an IRC alternative for real-time collaboration.


For quite some time, GitHub was the only real player in git repository hosting outside of rolling a custom solution (as we did for Over the years it has become the home of many open source projects, and while most of those don't match the sheer scale of Drupal in terms of codebase size and number of contributors, there are certainly other major projects that have made their home there.

However, for all of its presence and longevity in the open source world, there are very few options for customizing its toolset for our needs, and we could no longer self-host our canonical repositories. The Drupal project would need to adapt to GitHub, rather than the other way around.

That said, in recent months, GitHub has been putting a strong focus on feature development, adding a number of new features including: automated licensing information,  protected branches, and review requests.

Custom tooling

We also must consider that the tools we have now are what built Drupal into what it is today. A great deal of work has gone into our existing developer tools over the years, and we have some unique workflows that would have to be given up if we switched over to a tooling partner. An idea like the issue workspaces proposal would allow us to achieve the goal of modernizing our tools, and likely do so in a way that is better tailored to those unique things about the Drupal workflow that we may want to preserve. However, doubling down on building our own tooling would come at a cost of continuing to be unfamiliar to the outside development community, and dependent on an internal team's ability to keep up with the featureset of these larger players.

Each of these three options would be a compromise between reaching outward and creating familiarity, and looking inward to preserve the Drupal specific workflows that have brought the project to where it is today.

What have we learned so far?

The TAC has conducted their own internal evaluation of the options as well as worked with Drupal Association staff in a two day exploratory session at the end of last year. The primary focus was to identify and triage gaps between the different toolsets in the following areas:

  • Migration effort
  • Project management
  • Code workflow
  • Project handling
  • Testing
  • Git Back-end/Packaging
  • Integrations beyond tools

This initial study also looked at the impact of each option on Drupal community values, and some key risks associated with each.

What comes next?

The next step for the TAC is to make their formal recommendation to the Executive Director of the Drupal Association. At that point, she will direct staff to validate the recommendation by prototyping the recommended solution. Once the recommendation has been validated, Megan will make a final decision and prioritize the work to fully implement this option, relative to other Drupal Association imperatives.

In the comments below, we would love to hear from the community:

What aspects of the way the Drupal community collaborates are the most important to you? What workflow elements do you feel need to be preserved in the transition to any new tooling option?

Categories: Drupal

InternetDevels: Drupal 8.3.0 is out: let’s take a look at its innovations

11 April 2017 - 8:40am

Drupal 8.3.0 is here — congrats, drupalers and customers!

Read more
Categories: Drupal

Cheppers blog: Sharing your data

11 April 2017 - 6:20am

During our recent work on the GatherContent module, we received a feature request to allow other modules to modify the data we were saving. As this is not a very well known topic for non-contrib and non-core development, we decided to write a short blogpost about the different approaches in Drupal 7 and Drupal 8.

Categories: Drupal

La Drupalera (en): Problem installing composer on ubuntu with php versions

11 April 2017 - 3:22am

The problem I raise is due to duality of php (cli), which means several versions of php are installed in our computer. In my case it had 5.3.29 and 5.5.9 versions. Composer needs php version > = 5.4.0

Install Composer curl -sS curl -sS | sudo php -- --install-dir=/usr/local/bin --filename=composer

I get the following error:

Some settings on your machine make Composer unable to work properly.

Make sure that you fix the issues listed below and run this script again:

The openssl extension is missing, which means that secure HTTPS transfers are impossible.

If possible you should enable it or recompile php with --with-openssl

Read more
Categories: Drupal Blog: AGILEDROP: Other Top Drupal Blogs from March

11 April 2017 - 1:24am
After our Drupal blogs from the previous month, it's always time for Drupal Blogs that were written by other authors. Here are the best Drupal Blogs from March. We'll begin our list with Alanna Burke and Drupal 7 Features vs. Drupal 8 Configuration Management. She praised the new configuration management system in Drupal 8 as one of its best pieces and explained, how it helps developers to export configuration into code compared to the old way of Features on Drupal 7. You can read the full blog post here. Our second choice is Drupal Serialization Step-by-Step by Mateu Aguiló Bosch, who… READ MORE
Categories: Drupal

Jeff Geerling's Blog: Using Ubuntu Bash in Windows Creators' Update with Vagrant

10 April 2017 - 2:58pm

When Microsoft announced the Windows Subsystem for Linux, now seemingly rebranded as Bash on ubuntu on Windows, I was excited at the possibility of having Drupal VM (and other similarly command-line-friendly open source projects) work better in a Windows environment. But unfortunately, the Anniversary update's version of WSL/Ubuntu Bash was half-baked, and there were a lot of little issues trying to get anything cohesive done between the Windows and Ubuntu Bash environments (even with cbwin).

Then, a year or so later, Microsoft finally announced that tons of improvements (including upgrading Ubuntu in the WSL from 14.04 to 16.04!) would be included in the 'Creators Update' to Windows 10, dropping tomorrow, April 11.

Categories: Drupal

Chapter Three: Twig Concepts in Drupal 8 Themes - Part II

10 April 2017 - 11:58am

In the previous post I covered how to use the Component Libraries module and Twig to create simple reusable components, using an SVG sprite icon template as an example.

Part 2: Applying Twig Concepts to Write Better Code

When learning Drupal theming, overriding templates is one of the key topics of interest. It’s a simple thing. Copy the source template into your theme, modify it and clear the cache. Easy! However, doing just that over and over again, can lead to a mess of unmaintainable code.

Categories: Drupal

Acquia Developer Center Blog: Acquia Cloud CD Launches Today

10 April 2017 - 6:00am

Today Acquia is pleased to announce the release of Acquia Cloud CD.

Acquia Cloud CD is a new service for development process and devops automation which makes life easier for teams working on the Acquia Cloud Platform. It's an evolution of our developer tools which we believe will help to accelerate code delivery and make life easier and more productive for teams.

Tags: acquia drupal planet
Categories: Drupal

Dries Buytaert: Next steps for evolving Drupal's governance

10 April 2017 - 3:42am

The last time we made significant changes to our governance was 4 to 5 years ago [1, 2, 3]. It's time to evolve it more. We need to:

  • Update the governance model so governance policies and community membership decisions are not determined by me or by me alone. It is clear that the current governance structure of Drupal, which relies on me being the ultimate decision maker and spokesperson for difficult governance and community membership decisions, has reached its limits. It doesn't work for many in our community -- and frankly, it does not work for me either. I want to help drive the technical strategy and vision of Drupal, not be the arbiter of governance or interpersonal issues.
  • Review our the Code of Conduct. Many have commented that the intentions and scope of the Code of Conduct are unclear. For example, some people have asked if violations of the Code of Conduct are the only reasons for which someone might be removed from our community, whether Community Working Group decisions can be made based on actions outside of the Drupal community, or whether we need a Code of Conduct at all. These are all important questions that need clear answers.

I believe that to achieve the best outcome, we will:

  1. Organize both in-person and virtual roundtables during and after DrupalCon Baltimore to focus on gathering direct feedback from the community on evolving our governance.
  2. Refocus the 2-day meeting of the Drupal Association's Board of Directors at DrupalCon Baltimore to discuss these topics.
  3. Collect ideas in the issue queue of the Drupal Governance project. We will share a report from the roundtable discussions (point 1) and the Drupal Association Board Meeting (point 2) in the issue queue so everything is available in one place.
  4. Actively solicit help from experts on diversity, inclusion, experiences of marginalized groups, and codes of conduct and governance. This could include people from both inside and outside the Drupal community (e.g. a leader from another community who is highly respected). I've started looking into this option with the help of the Drupal Association and members of the Community Working Group. We are open to suggestions.

In order to achieve these aims, we plan to organize an in-person Drupal Community Governance sprint the weeks following DrupalCon Baltimore, involving members of the Drupal Association, Community Working Group, the Drupal Diversity & Inclusion group, outside experts, as well as some community members who have been critical of our governance. At the sprint, we will discuss feedback gathered by the roundtables, as well as discussions during the 2-day board meeting at DrupalCon Baltimore, and turn these into concrete proposals: possible modifications to the Code of Conduct, structural changes, expectations of leadership, etc. These proposals will be open for public comment for several weeks or months, to be finalized by DrupalCon Vienna.

We're still discussing these plans but I wanted to give you some insight in our progress and thinking; once the plans are finalized we'll share them on Let us know your thoughts on this framework. I'm looking forward to working on solutions with others in the community.

Categories: Drupal

Dries Buytaert: An apology to the Drupal community

9 April 2017 - 5:10am

Last week Megan Sanicki, executive director of the Drupal Association, and I published a joint statement. In this blog post, I wanted to follow up with a personal statement focused on the community at large.

I've talked to a lot of people the last two weeks, and it is clear to me that our decisions have caused much alarm and distress in our community. I feel this follow-up is important even though I know it doesn't undo the hurt I've caused.

I want to deeply apologize for causing grief and uncertainty, especially to those in the BDSM and kink communities who felt targeted by the turmoil. This incident was about specific actions of a single member of our community. This was never meant to be about sexual practices or kinks, so it pains me that I unintentionally hurt you. I do support you and respect you as a key part of our community.

Shortly after I started Drupal more than 15 years ago, I based its core values on openness and equality. Gender, race, religion, beliefs, sexuality ... all are welcome in our community. We've always had people with wildly different views and identities. When we walk into a sprint at DrupalCon, we've been able to put our opinions aside, open our laptops, and start collaborating. Diversity has always been a feature, not a bug. I strongly feel that this foundation is what made Drupal what it is today; a global family.

Serving a community as unique and diverse as Drupal is both rewarding and challenging. We've navigated through several defining moments and transitions in our history. I feel what we are going through now is another one of these defining moments for our culture and community. In an excruciating but illuminating way this has shown some of what is best about our community: we care. I'm reminded that what brings us together, what we all have in common, is our love and appreciation of open-source software. Drupal is a positive force, a collective lifting by thousands and thousands, created and maintained by those individuals cooperating toward a common goal, whose other interests have no need to be aligned.

I want to help our community heal and I'm open to learn and change. As one of the next steps, I will make a follow-up post on improving our governance to a healthier model that does not place such sensitive decisions on me. I love this community, and recognize that the things we hold in common are more important than our differences.

(Comments on this post are allowed but for obvious reasons will be moderated.)

Categories: Drupal

Tech Rendezvous: Optimizing Bonita BPM

8 April 2017 - 5:00pm
Categories: Drupal

Acquia Developer Center Blog: ES6 for Drupal Developers: Arrow Functions, Concise Methods, and Other Syntactic Features

7 April 2017 - 2:16pm

Object structures and functions are possibly two of the most commonly utilized syntactic features in JavaScript, as they both have important roles in defining classes in object-oriented programming. In ES6, defining methods and functions has become much easier with the help of concise properties and methods, and especially arrow functions, which may help to limit the lines of code you have to write.

Tags: acquia drupal planet
Categories: Drupal