Planet Drupal

Syndicate content - aggregated feeds in category Planet Drupal
Updated: 39 min 57 sec ago

Liip: Drupal 8 – Multilanguage Improvements

Wed, 04/12/2017 - 11:19
pAs 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./p pWith Drupal 8, things / 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./p pspan id=more-8881/span/p div id=attachment_8884 style=width: 1034px class=wp-caption alignnoneimg class=wp-image-8884 size-large src= alt=Drupal 8 multilanguage srcset= 1024w, 300w, 768w sizes=(max-width: 1024px) 100vw, 1024px /p class=wp-caption-textemImage: h2Drupal 8 delissues/del multilanguage challenges/h2 h3Challenge 1: Node add / edit menu handling/h3 pThe 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./p h3Challenge 2: Untranslated Nodes show up in Menu/h3 pAnother 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. a href= and a href= 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./p h3Challenge 3: Language Switcher shows all languages #8211; always./h3 pSomewhat 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/p pAn example to illustrate the above-written challenges./p pimg class=alignnone wp-image-8887 src= alt=multilanguage issues with Drupal 8 srcset= 901w, 300w, 768w sizes=(max-width: 898px) 100vw, 898px //p pemEnglish Front-Page with mixed navigation items./em/p pThe screen above shows an installation with 2 languages (English and German). The strongEnglish Page/strong is a basic page which has a translation. English is selected. If you choose emstrongDeutsch/strong/em on the language switcher, the strongEnglish Page/strong becomes strongDeutsche Seite/strong (see image below) and shows the German content. So far so good. But the second menu item you see with the title strongÜber uns (nur Deutsch)/strong 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./p pimg class=alignnone wp-image-8886 size-full src=Über-uns-nur-Deutsch-Drupal1-1.png alt=multilanguage issues with Drupal 8 srcset=Über-uns-nur-Deutsch-Drupal1-1.png 898w,Über-uns-nur-Deutsch-Drupal1-1-300x106.png 300w,Über-uns-nur-Deutsch-Drupal1-1-768x271.png 768w sizes=(max-width: 898px) 100vw, 898px //p pemGerman only Page #8211; Language Switcher visible. /em/p pAlso, 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./p h2How to delfix/del improve this?/h2 pLuckily, 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./p pTo sum up again: emstrongI 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./strong/em/p pSince there is no patch and still some ongoing discussions on a href= you need to implement it on your own. Implement the following two modules./p h3bHide untranslated menu items/b/h3 pCode from a href= Credits go to michaelkoehne./p p/ppre class=crayon-plain-taglt;?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(amp;$variables) { if ($variables['menu_name'] == 'main') { $language = Drupal::languageManager() -gt;getCurrentLanguage(LanguageInterface::TYPE_CONTENT) -gt;getId(); foreach ($variables['items'] as $key =gt; $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-gt;getTranslationLanguages(); // Remove links which are not translated to the current language. if (!array_key_exists($language, $languages)) { return FALSE; } else { if (count($item['below']) gt; 0) { foreach ($item['below'] as $subkey =gt; $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-gt;getPluginId(), 2); $uuid = $menu_link[1]; $entity = \Drupal::service('entity.repository') -gt;loadEntityByUuid('menu_link_content', $uuid); } return $entity; }/prep/p h3Hide untranslated languages in language switcher/h3 pCode from a href= (slightly adapted. Links get a class, not removed by default). Credits to Leon Kessler./p p/ppre class=crayon-plain-taglt;?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 amp;$links, $type, $path) { if ($entity = MYOTHERMODULE_get_page_entity()) { $new_links = array(); foreach ($links as $lang_code =gt; $link) { try { if ($entity-gt;getTranslation($lang_code)-gt;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) lt; 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()-gt;getParameters()-gt;all(); $entity = reset($params); if ($entity instanceof ContentEntityInterface) { return $entity; } return FALSE; }/prep/p pPlease note: The code above is from and therefore thanks to the original authors linked above./p pEnable those two modules and you’re all set!/p pI 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?/p pThere are other attempts to this by altering the menu block. One of them is a href= Block Current Language/a 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)./p pI would love to hear how you guys handle those cases or how you deal with I18N in general. I#8217;m sure there are a gazillion other ways to do it./p

La Drupalera (en): Grunt, automating repetitive work

Wed, 04/12/2017 - 10:50
div data-history-node-id=146 class=node node--type-article node--view-mode-rss ds-1col clearfix img property=schema:image src= width=650 height=432 alt=Grunt, automating repetitive work typeof=foaf:Image class=image-style-max-650x650 /pGrunt 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/p h2Instalation/h2 pre code class=language-bashnpm install -g grunt-cli /code/pre p /p pWe will need two main files that we will place in the root of the project in which Grunt will perform its tasks:/p pstrongpackage.json/strong/p pre code class=language-json{ name: ExampleProject, version: 0.1, dependencies: { }, devDependencies: { } }/code/pre pand strongGruntfile.js/strong/p div class=field field--name-node-link field--type-ds field--label-hidden field__itema href= hreflang=en-x-simpleRead more/a/div /div

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

Tue, 04/11/2017 - 23:26
div class=field field-name-body field-type-text-with-summary field-label-hiddendiv class=field-itemsdiv class=field-item even property=content:encodedpIn recent weeks, I've seen a whole lot of FUD regarding the a href= Community Working Group/a, 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./p pSome 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./p pIn 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 a href= report/a, 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./p pThis 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 a href= incident/a 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: a href= pIf 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 a href= Plan/a is developed. This is summarized as:/p blockquotep 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./p pHowever, 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. /p/blockquote pThe template includes a summary of complaints (all of which have been already vetted by the CWG for validity), the emimpact/em 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./p pThe CWG will bend over backwards to help people emnot/em 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 emneeds/em 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./p pSome 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 a href= first 5 minutes in the Drupal community/a. Had I not been contractually obligated to remain because of Google Summer of Code, that likely would've been my emlast/em 5 minutes in the Drupal community, as well. And there are 1000s of other contributors out there like past webchick. Food for thought./p pSo 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/p /div/div/divdiv class=field field-name-taxonomy-vocabulary-1 field-type-taxonomy-term-reference field-label-abovediv class=field-labelTags:nbsp;/divdiv class=field-itemsdiv class=field-item evena href=/taxonomy/term/1 typeof=skos:Concept property=rdfs:label skos:prefLabel datatype=drupal/a/divdiv class=field-item odda href=/taxonomy/term/48 typeof=skos:Concept property=rdfs:label skos:prefLabel datatype=community/a/div/div/div

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

Tue, 04/11/2017 - 19:54
img typeof=foaf:Image src= width=200 height=152 alt=Drupal vs Adobe Experience Manager Part 1 title=Drupal vs Adobe Experience Manager Part 1 / pThere 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./p

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

Tue, 04/11/2017 - 19:48
span class=field field--name-title field--type-string field--label-hiddenPrevent ambiguity in Drupal 8 migration source query/span span class=field field--name-uid field--type-entity-reference field--label-hiddena title=View user profile. href= lang= about= typeof=schema:Person property=schema:name datatype= class=username xml:lang=Richard Papp/a/span span class=field field--name-created field--type-created field--label-hiddenTue, 04/11/2017 - 19:48/span div class=clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__itemIf 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./div

Code Positive: Living Documentation For Your Drupal Project

Tue, 04/11/2017 - 19:25
img src= width=940 height=230 alt=pickle jar title=Pickle jar typeof=Image class=image-style-rss-banner /hr /pUnderstanding the importance and benefits of living documentation, and why it can be critical for the continuity of your Drupal project./p hr /p /p p /p blog: Technical Advisory Committee Update

Tue, 04/11/2017 - 19:12
div class=field field-name-body field-type-text-with-summary field-label-hiddendiv class=field-itemsdiv class=field-item evenpimg alt=Workflow icon class=left height=238 src=/files/git-icon_0.png width=150 /In October of a href= rel=nofollowlast year the Technical Advisory Committee was formed/a to evaluate options for the developer tools we use on The TAC consists of a href= rel=nofollowAngie Byron/a, a href= rel=nofollowMoshe Weitzman/a, and a href= rel=nofollowSteve Francia/a, acting as advisors to a href= rel=nofollowMegan Sanicki/a, the Executive Director of the Drupal Association./p pThe 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./p h2What is the motivation behind looking at our developer tools now?/h2 pClose followers of the Drupal project will have noticed a trend in the last several months. From Dries' announcement of a href= rel=nofolloweasy upgrades forever/a, to the revamp of the a href= rel=nofollowproject application process/a, to the discussion about a href= rel=nofollowmaking tools for site builders/a— there is a unifying theme: broadening the reach of Drupal./p pThis is the same motivation that underlies this evaluation of our developer tools, and defines the goals and constraints of this initiative:/p ulliAdopt a developer workflow that will be familiar to the millions of developers outside our community/li liPreserve those unique elements of how we collaborate that have made the Drupal project so successful/li liIf possible, leverage an expert partner who will help keeping our tooling up to date as open source collaboration tools continue to evolve/li /ulpThis means looking at a number of elements of the developer tool stack:/p ulliThe underlying git service/li liHow we tag and package releases/li liThe contribution workflow (patch vs. pull request)/li liProject management workflows (the issue queues and tags)/li liCI integration/li liMaintainership/li liProject pages/li /ulpIf this looks like a tremendous undertaking - that's because it is. But there are some things we already know:/p should continue to be the home of project pages/li liWe should adopt a pull request workflow (and ideally we want to be able continue to accept patches as well, at least in the interim)/li liWe should move contrib projects to semver, following core's lead/li liWe want to preserve our familiar understanding of maintainership/li liWe want to avoided forked code and forked conversation/li liWe want to ensure the security team still has the tools they need to provide their service to the community/li /ulpWe 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./p h2What options are being considered?/h2 pAt this time, the technical advisory committee is considering three options as they prepare to make their recommendation. The options are: a href= rel=nofollowGitLab/a, which offers both self-hosted and SaaS options; a href= rel=nofollowGitHub/a, which has recently been adding long-requested a href= rel=nofollownew features/a; or continuing to evolve our custom-built tooling, perhaps via a href= rel=nofollowissue workspaces/a./p h3GitLab/h3 pGitLab 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 a href= rel=nofollowrecently stumbled/a, they have been notably open and transparent about their efforts to build a leading collaboration platform./p pGitlab is a href= rel=nofollowitself open-source/a, and has just a href= rel=nofollowreleased its 9.0 edition/a. GitLab has aggressively pursued the latest in development tools and workflow a href= rel=nofollowfeatures/a, 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 a href= rel=nofollowGitter/a, an IRC alternative for real-time collaboration./p h3GitHub/h3 pFor 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 a href= rel=nofollowmajor projects/a that have made their home there./p pHowever, 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 /  /p pThat said, in recent months, GitHub has been putting a strong focus on a href= rel=nofollowfeature development/a, adding a number of new features including: a href= rel=nofollowautomated licensing information/a,  a href= rel=nofollowprotected branches/a, and a href= rel=nofollowreview requests/a./p h3Custom tooling/h3 pWe 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 a href= rel=nofollowissue workspaces/a 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./p pEach 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./p h2What have we learned so far?/h2 pThe 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:/p ulliMigration effort/li liProject management/li liCode workflow/li liProject handling/li liTesting/li liGit Back-end/Packaging/li liIntegrations beyond tools/li /ulpThis initial study also looked at the impact of each option on Drupal community values, and some key risks associated with each./p h2What comes next?/h2 pThe 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./p pIn the comments below, we would love to hear from the community:/p pWhat 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?/p/div/div/div

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

Tue, 04/11/2017 - 17:40
div class=field field--name-field-preview-image field--type-image field--label-hiddendiv class=field__itemsdiv class=field__item evenimg src=/sites/default/files/public/blog_preview/new_features_in_drupal_8.3.0.png width=937 height=622 alt=Drupal 8.3.0 is out: let’s take a look at its innovations //div/div/divdiv class=field field--name-body field--type-text-with-summary field--label-hiddendiv class=field__itemsdiv class=field__item evenp style=text-align: right;emDrupal 8.3.0 is here — congrats, drupalers and customers!/em/p a href= more/a/div/div/div

Cheppers blog: Sharing your data

Tue, 04/11/2017 - 15:20
a href= img src= width=536 height=300 alt= class=image-style-cheppers-blog-teaser-mobile //a pDuring our recent work on a href= target=_blankthe GatherContent module/a, 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./p

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

Tue, 04/11/2017 - 12:22
div data-history-node-id=301 class=node node--type-article node--view-mode-rss ds-1col clearfix img property=schema:image src= width=650 height=433 alt=Problem installing composer on ubuntu with php versions typeof=foaf:Image class=image-style-max-650x650 /pThe 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.0br /  /p h2Install Composer/h2 pre code class=language-bashcurl -sS curl -sS | sudo php -- --install-dir=/usr/local/bin --filename=composer /code/pre pI get the following error:/p p dir=ltremSome settings on your machine make Composer unable to work properly./em/p p dir=ltremMake sure that you fix the issues listed below and run this script again:/em/p p dir=ltremThe openssl extension is missing, which means that secure HTTPS transfers are impossible./em/p p dir=ltremIf possible you should enable it or recompile php with --with-openssl/embr /  /p div class=field field--name-node-link field--type-ds field--label-hidden field__itema href= hreflang=en-x-simpleRead more/a/div /div Blog: AGILEDROP: Other Top Drupal Blogs from March

Tue, 04/11/2017 - 10:24
a href= src= //a 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… a href= MORE/a

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

Mon, 04/10/2017 - 23:58
div class=field field-name-body field-type-text-with-summary field-label-hiddendiv class=field-itemsdiv class=field-item even property=content:encodedpWhen Microsoft announced the Windows Subsystem for Linux, now seemingly rebranded as a href= on ubuntu on Windows/a, 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 a href= pThen, 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./p/div/div/div

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

Mon, 04/10/2017 - 20:58
pIn the a href= post/a I covered how to use the a href= Libraries/a module and a href= to create simple reusable components, using an SVG sprite icon template as an example./p h2Part 2: Applying Twig Concepts to Write Better Code/h2 pWhen 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./p

Acquia Developer Center Blog: Acquia Cloud CD Launches Today

Mon, 04/10/2017 - 15:00
div class=field field-name-field-blog-image field-type-image field-label-hiddendiv class=field-itemsdiv class=field-item evenimg typeof=foaf:Image class=img-responsive src= width=140 height=85 alt= //div/div/divdiv class=field field-name-body field-type-text-with-summary field-label-hiddendiv class=field-itemsdiv class=field-item even property=content:encodedpToday Acquia is pleased to announce the release of a href= Cloud CD/a. /p pAcquia 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./p/div/div/divdiv class=field field-name-field-blog-tags field-type-taxonomy-term-reference field-label-inline clearfixdiv class=field-labelTags:nbsp;/divdiv class=field-itemsdiv class=field-item evena href=/tags/acquia-drupal-planet typeof=skos:Concept property=rdfs:label skos:prefLabel datatype=acquia drupal planet/a/div/div/div

Dries Buytaert: Next steps for evolving Drupal's governance

Mon, 04/10/2017 - 12:42
pThe last time we made significant changes to our governance was 4 to 5 years ago [a href=, a href=, a href=]. It's time to evolve it more. We need to:/p ulliUpdate 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./li liReview 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./li /ulpI believe that to achieve the best outcome, we will:/p olliOrganize both in-person and virtual roundtables during and after DrupalCon Baltimore to focus on gathering direct feedback from the community on evolving our governance./li liRefocus the 2-day meeting of the Drupal Association's Board of Directors at DrupalCon Baltimore to discuss these topics./li liCollect ideas in the a href= queue of the Drupal Governance project/a. 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./li liActively 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./li /olpIn 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. /p pWe'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./p

Dries Buytaert: An apology to the Drupal community

Sun, 04/09/2017 - 14:10
pLast week Megan Sanicki, executive director of the Drupal Association, and I published a href= joint statement/a. In this blog post, I wanted to follow up with a personal statement focused on the community at large./p pI'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./p pI 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./p pShortly 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. /p pServing 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: emwe care/em. 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./p pI 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./p pem(Comments on this post are allowed but for obvious reasons will be moderated.)/em/p

Tech Rendezvous: Optimizing Bonita BPM

Sun, 04/09/2017 - 02:00

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

Fri, 04/07/2017 - 23:16
div class=field field-name-field-blog-image field-type-image field-label-hiddendiv class=field-itemsdiv class=field-item evenimg typeof=foaf:Image class=img-responsive src= width=140 height=85 alt=javascript image title=javascript image //div/div/divdiv class=field field-name-body field-type-text-with-summary field-label-hiddendiv class=field-itemsdiv class=field-item even property=content:encodedpObject 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./p/div/div/divdiv class=field field-name-field-blog-tags field-type-taxonomy-term-reference field-label-inline clearfixdiv class=field-labelTags:nbsp;/divdiv class=field-itemsdiv class=field-item evena href=/tags/acquia-drupal-planet typeof=skos:Concept property=rdfs:label skos:prefLabel datatype=acquia drupal planet/a/div/div/div

drunken monkey: The problems with config entity overrides

Fri, 04/07/2017 - 17:31
div class=field field-name-field-image field-type-image field-label-hiddendiv class=field-itemsdiv class=field-item evenimg typeof=foaf:Image src= width=320 height=213 alt= title=Overrides – when to use which? //div/div/divdiv class=field field-name-body field-type-text-with-summary field-label-hiddendiv class=field-itemsdiv class=field-item even property=content:encodedpstrongabbr title=too long, didn't readTL; DR:/abbr/strong Config overrides seem very handy, but can be pretty problematic when used for config entities. If you are using them in this way, you should make very sure that there aren't any unintended side effects. And if you maintain a contrib module that defines a config entity type, you should make sure they're safe to use with config overrides./p pstrongFair warning:/strong This blog post is mainly written for developers. While, ideally, site builders who want to use configuration overrides should also understand the inherent problems they come with, I don't feel it's possible to really explain those problems without getting pretty technical./p h2What are config overrides?/h2 pIf you're not familiar with Drupal 8's concept of configuration overrides, I suggest you quickly read up on it a href= the documentation on In short, it allows you to define overrides for configuration (who would have thought?) in your codesettings.php/code, making it easy to have different settings for different environments – very common, of course, if you have separate development or testing environments./p pThe way those overrides work should be properly understood, though: the overrides exist solely in the code, are read into a global variable at the start of the page request and then, when a configuration item is accessed during a page request that global variable is checked for overrides to that specific configuration item. In other words, the config values in the database (or the config storage, if that's not the database in your case) should never contain the overridden values, those should only ever be present in codesettings.php/code./p pTo facilitate this, config items when normally loaded are always read-only – that way, the overrides loaded with them won't be written back to the database. If you want to edit some config values, you need to explicitly load the config item with code\Drupal::configFactory()-gt;getEditable('');/code to obtain a writable copy – which then will come without any overrides. This ensures that, as said before, no overrides will be written back to the storage./p h2Then what's the problem?/h2 pWhile this codegetEditable()/code requirement for editing configuration works pretty well, there is one big problem: this requirement, and whole read-only system, is just not there for config entities! When you load a config entity, even though it's basically just a config item with a class, it will always be writable – there isn't even a way to explicitly get a read-only version. There is codeloadOverrideFree()/code on codeConfigEntityStorage/code, which you should absolutely use when making any chances to a config entity – but who really knows that? (I didn't, and I hope for reasons of vanity that I'm not the only one.)/p pThe smart people working on Drupal Core of course quickly realized this. Their solution: on admin pages (which are already categorized as such to allow having an admin theme), where entities are usually edited, always load the override-free version of the entity for the route controller. That way, the edit will really only affect the values in the storage, and the overrides won't be touched at all. This leads to a a href= UX WTF/a, but is generally a good solution, which works in a lot of cases. The problem, though, is that it's far from working for all of them. Also, since it's working in many cases, we might feel it's less urgent to point this potential problem out to contrib module developers and site builders./p h2So, what problems remain?/h2 pNice of you to ask! In my opinion, there are still several remaining problems. While I'm not sure that all of them could even be fixed in Core, and it might certainly take a while (as it nearly always does – especially for such complicated issues), I think the main thing is to at least educate developers and site builders alike that these problems exist, and maybe how to spot them. Here is an overview of all problems I'm aware of:/p h3Config entities aren't always edited on admin pages/h3 pWhile applying this fix for all admin pages is certainly a good heuristic, I'm pretty sure there are contrib modules out there that save config entities on non-admin pages. When that happens, the user will (unlike anywhere else in Drupal 8) actually see the overridden values while editing, and they will be saved back to the database/storage, which we don't want./p pSo, if you maintain a contrib module, be sure to always load the override-free version of a config entity before editing and saving it! This especially applies to Drush commands, where the generic fix for admin pages of course doesn't apply – unless you explicitly request it otherwise, you'll always get the overridden entity there./p h3Admin pages don't always load config entities just for editing/h3 pThe reverse is also true: sometimes, admin pages will just show information about a certain config entity, not allow any editing. In this case, currently, the overridden values will not be displayed, potentially confusing users. In some cases, they'll not be able to see anywhere that the overridden values are actually applied correctly./p pMore of a problem, though, are other non-editing uses of config entities, which was one of the two main problems we faced in the a href= API module/a (see a href= #2682369: Fix problems with overridden config entities/a): in our case, nearly all of the module's UI (except most searches) is actually on admin pages, and will therefore (as long as the config entity is loaded directly by the route controller – also a peculiar source of potential confusion, see next heading) use the override-free version. While this is great for the edit pages, it's disastrous for the other functionality available there – Index now, Clear indexed data, etc., would all use the entities without overrides. If you used config overrides to make the index read-only, or to attach them to a different search server, this would mean your production site's server could be corrupted or cleared by actions on your development site – not very good, in short./p pLuckily, once you're aware of this problem, there's actually a pretty easy solution: you can just use the codewith_config_overrides/code parameter option in your codeMODULE.routing.yml/code file to get the overridden version of a config entity even on an admin page. That way, on pages where you want to do something else than edit/save the config entity, you'll get the correct version of the entity, with the effective values./p pIt's slightly more complicated on pages where you can emboth/em edit an entity and use it in some other way. In that case, simply choose one of the two to request via the route controller and then manually re-load the other version, with/without overrides, when appropriate./p h3Entities aren't always loaded by the route controller/h3 pIt's important to note that the mentioned fix for admin pages is installed (please correct me here if I'm wrong) in the route controller. So, when the config entity in question is part of the URL (for instance, codeadmin/structure/types/manage/lt;vargt;{node_type}lt;/vargt;/code), it will (by default) be loaded without overrides, but loading it normally within a page callback or form builder method will yield the normal entity, with overrides. This is mostly not even a bug, but a feature: for most entity edit pages, the entity is in the URL, while (for instance) overview pages will do a bulk-load and get the overridden values./p pHowever, in combination with the previous item, about displaying config entities on admin pages, it could lead to confusing situations for users: an overview page for the entities would use the overridden values, while clicking through to a View page for one of them would suddenly show the override-free version of that entity. And since (see the UX WTF above) we never actually show any indication in the UI about which values are overridden, the user could actually wonder which of them are the effective ones./p h3The really complicated problem/h3 pUp to now, the main problem was just being aware of the various problems that could occur. Once you're aware that they exist, they are all actually pretty easy to resolve – just see whether or not you save a config entity, and in either case make sure you load the appropriate version of it./p pHowever, there is one last problem with overridden config entities, and this one is a real doozy – much too complex to put in a heading, for sure. I'd say that it will luckily only affect a minority of modules dealing with config entities, but where it strikes it's hard to spot, and might be even harder to fix. It's also what caused most of the work in a href= Search API issue mentioned above/a./p pLet's take the Search API as the example and suppose you have an index with an overridden server: server1 in the database, server2 as the overridden value. Now, you edit the index and change something else – the description, for example. For editing, of course, the override-free entity version is used, all correct. Upon saving, though, the storage controller loads the previous entity version as the original – but this time emwith/em overrides. So, even though only the description was changed, from within codehook_entity_update()/code and the entity's codepostSave()/code method it will look like the server was changed from server2 to server1. In this case, the Search API will remove all of the index's data from server2 (where it should have remained) and initialize data structures for it on server1 (where they won't be used), probably breaking all searches for that index to at least some extent (depending on backend)./p pSimilar problems exist for read-only flags and other properties, and editing the actual property that is overridden of course leads to yet another set of problems. I'm happy to say that I'm confident we resolved all of these problems for the Search API (though, a href=/blog/search_api_d8_releaseas mentioned before/a, I'd appreciate it if site owners who might be affected could thoroughly test this for their site, with a href= newest Beta release/a), but it's unfortunately very likely that there are other contrib modules that still have such problems, and might not even be aware of them./p pThe Core issue I created for this problem is this one: a href= #2744057: Inconsistencies when updating overridden config entities/a. However, I think it has actually centered more around the problem of reliably fixing the other problems listed above, by bringing the immutable/editable solution that's in place for normal config objects to config entities, too. (I might be mistaken, though – I frankly admit that the complexity of this issue gives me headaches.) Also important, sure, but it doesn't touch this last, actually hard problem, as far as I'm aware. (While the others are arguably also pretty hard to solve generically in Drupal Core, they are easy enough to work around in contrib modules using config entities, as long as you are aware of them.) I'm currently not even sure that a generic solution for this last problem is really feasible./p pTherefore, it's all the more important for module developers, I think, to be aware that this problem exists and to carefully search their own code for places where something like this might happen. To a href= swentel/a:/p blockquotepDamn, overrides are really not a safe thing at all./p/blockquote h2Coda/h2 pI hope I could help at least some of you understand the complex problems with config entity overrides, and maybe in this way help discover and fix some bugs. In any case, many thanks to a href= for first bringing this problem to my attention, patiently explaining it numerous times until I finally understood it, and even fearlessly tackling the Core issue to try and fix this for everyone else./p psmallImage credit: a href= kids/a/small/p /div/div/div

Liip: Advanced Drupal 8 Configuration Management (CMI) Workflows

Fri, 04/07/2017 - 13:59
pAfter implementing some larger enterprise Drupal 8 websites, I would like to share some insights, how to solve common issues in the deployment workflow with Drupal 8 CMI./p h2Introduction to Drupal CMI/h2 pFirst of all, you need to understand, how the configuration management in Drupal 8 works. CMI allows you to export all configurations and its dependencies from the database into yml text files. To make sure, you never end up in an inconsistent state, CMI always exports everything. By default, you cannot exclude certain configurations./p h3Example:/h3 pIf you change some configuration on the live database, these configurations will be reverted in the next deployment when you use/p p/ppre class=crayon-plain-tagdrush config-import/prep/p pThis is helpful and will make sure, you have the same configuration on all your systems./p h2How can I have different configurations on local / stage / live environments?/h2 pSometimes, you want to have different configurations on your environments. For example, we have installed a #8220;devel#8221; module only on our local environment but we want to have it disabled on the live environment./p pspan id=more-8866/span/p pThis can be achieved by using the configuration split module: a href= h3What does Configuration Split?/h3 pThis module slightly modifies the CMI by implementing a Config Filter (a href= Importing and exporting works the same way as before, except some configuration is read from and written to different directories. Importing configuration still removes configuration not present in the files. Thus, the robustness and predictability of the configuration management remains. And the best thing is: You still can use the same drush commands if you have at strongleast Drush 8.1.10 installed/strong./p h3Configuration Split Example / Installation Guide/h3 pInstall config_split using composer. You need need at least #8220;a href=; andstrong gt;/strong drush 8.1.10 for this guide./p p/ppre class=crayon-plain-tagcomposer require drupal/config_split ^1.0/prep/p pEnable config_split and navigate to #8220;admin/config/development/configuration/config-split#8221;/p p/ppre class=crayon-plain-tagdrush en config_split -y/prep/p pOptional: Installing the a href= module/a will make the selection of blacklists / greylists way more easier. You can enable chosen only on admin pages./p p/ppre class=crayon-plain-tagcomposer require drupal/chosen ^1.0/prep/p pI recommend you to create an #8220;environments#8221; subfolder in your config folder. Inside this folder you will have a separate directory for every environment:/p pimg class=alignnone wp-image-8869 size-full src= alt=Drupal 8 Configuration Management Folders //p pNow you can configure your environments:/p pimg class=alignnone wp-image-8867 size-full src= alt=Config Split in Drupal 8 Configuration Management srcset= 957w, 300w, 768w sizes=(max-width: 957px) 100vw, 957px //p pThe most important thing is, that you strongset every environment to #8220;Inactive#8221;./strong We will later activate them according to the environment via settings.php/p pimg class=alignnone wp-image-8870 size-full src= alt=Config Split settings with the Drupal 8 Configuration Management srcset= 781w, 300w, 768w sizes=(max-width: 781px) 100vw, 781px //p pHere is my example where I enable the devel module on local:/p pimg class=alignnone wp-image-8873 size-full src= alt=Dev Environment Example srcset= 949w, 300w, 768w sizes=(max-width: 949px) 100vw, 949px //p h4Activate the environments via settings.php/h4 pThis is the most important part of the whole setup up. Normally, we never commit the settings.php into git. But we have a [environment]-settings.php in git for every environment:/p p/ppre class=crayon-plain-tagsettings.php (not in git) variables-dev.php (in git and included in the settings.php of dev) variables-live.php (in git and included in the settings.php of live) settings.local.php (in git and included locally)/prep/p pYou need to add the following line to the variables-[environment].php. Please change the strongvariable name/strong according to your environmentstrong machine name/strong:/p p/ppre class=crayon-plain-tag// This enables the config_split module $config['']['status'] = TRUE;/prep/p pIf you have done everything correctly and cleared the cache you will see strong#8220;active (overriden)#8221;/strong in the config_split overview next to the current environment./p pNow you can continue using/p p/ppre class=crayon-plain-tagdrush config-import -y drush config-export -y/prep/p pand config_split will do the magic./p h2How can I exclude certain Config Files and prevent them to be overridden / deleted on my live environment?/h2 pThe most prominent candidates for this workflow are strongwebforms/strong and strongcontact forms/strong. In Drupal 7, webforms are nodes and you were able to give your CMS administrator the opportunity to create their own forms./p pIn Drupal 8 webforms are strongconfig entities/strong, which means that they will be deleted while deploying if the yml files are not in git./p pAfter testing a lot of different modules / drush scripts, I finally came up with an easy to use workflow to solve this issue and give CMS administrators the possibility to create webforms without git knowledge:/p h3Set up an #8220;Excluded#8221; environment/h3 pFirst of all, we need an #8220;excluded#8221; environment. I created a subfolder in my config-folder and added a .htaccess file to protect the content. You can copy the .htaccess from an existing environment, if you are lazy. Don#8217;t forget to deploy this folder to your live system before you do the next steps./p pimg class=alignnone wp-image-8874 size-full src= alt=Folders //p pimg class=alignnone wp-image-8877 size-full src= alt=Excluded srcset= 847w, 300w, 768w sizes=(max-width: 847px) 100vw, 847px //p pNow you can exclude some config files to be excluded / grey-listed on your live environment:/p p/ppre class=crayon-plain-tagwebform.webform.* contact.form.*/prep/p pimg class=alignnone wp-image-8876 size-full src= alt=Greylist Webform in Config Split srcset= 726w, 300w sizes=(max-width: 726px) 100vw, 726px //p pSet the excluded environment tostrong #8220;Inactive#8221;/strong. We will later enable it on the live / dev environment via settings.php./p h3Enable #8220;excluded#8221; environment and adapt deployment workflow/h3 pWe enable the #8220;excluded#8221; environment on the live system via variables-live.php (see above):/p p/ppre class=crayon-plain-tag// This will allow module config per environment and exclude webforms from being overridden $config['config_split.config_split.excluded']['status'] = TRUE;/prep/p pIn your deployment workflow / script you need to add the following line before you do a drush config-import:/p p/ppre class=crayon-plain-tag#execute some drush commands echo ----------------------------------------------------------- echo Exporting excluded config drush @live config-split-export -y excluded echo ----------------------------------------------------------- echo Importing configuration drush @live config-import -y/prep/p pThe drush command #8220;strongdrush @live config-split-export -y excluded/strong#8221; will export all webforms and contact forms created by your CMS administrators into the folder #8220;excluded#8221;. The #8220;drush config-import#8221; command will therefore not delete them and your administrators can happily create their custom forms./p h3Benefit of disable #8220;excluded#8221; on local environment/h3 pWe usually disable the #8220;excluded#8221; environment on our local environment. This allows us to create complex webforms on our local machine for our clients and deploy them as usual. In the end you can have a mix of customer created webforms and your own webforms which is quite helpful./p h2Final note/h2 pThe CMI is a great tool and I would like to thank the maintainers of the a href= module/a for their great extension. This is a huge step forward making Drupal 8 a real Enterprise CMS Tool./p pIf you have any questions, don#8217;t hesitate to post a comment./p pnbsp;/p