Drupal Planet

Subscribe to Drupal Planet feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 5 hours 38 min ago

Tag1 Consulting: Drupal Load Testing with Locust.io

April 13, 2017 - 12:48pm
Apache JMeter and I have a long and complicated relationship. It is definitely a trusted and valuable tool, but I am also quite confident that certain parts of it will make an appearance in my particular circle of hell. Due to this somewhat uncomfortable partnership, I am always interested in new tools for applying load to an infrastructure and monitoring the results. Locust.io is not exactly a new tool, but I have only recently begun to use it for testing. What Is Locust? Locust is a load-testing framework which allows you to write your load plan in regular Python. This is a welcome experiencRead more nnewton Thu, 04/13/2017 - 08:48
Categories: Blogs

Mediacurrent: DrupalCon Baltimore - Mediacurrent's GamePlan

April 13, 2017 - 10:54am

DrupalCon Baltimore here we come! We are Gold sponsors once again this year and there are a ton of ways to connect with our team. Here are some of the highlights:

Categories: Blogs

Acquia Developer Center Blog: 12 Questions that Project Managers Should Ask Before a Drupal Project Kickoff

April 13, 2017 - 10:38am

You are a Project Manager, sitting at your desk, maybe sipping a fresh-brewed coffee. Suddenly you receive a heads-up that a new Drupal Project is headed your way. Sprint 0 will be starting in the next two days.

You can assume that the SOW (Statement of Work) is signed, or almost signed, and a few SWAGs (Sophisticated Wild Ass Guesses) have already been ventured.

Tags: acquia drupal planet
Categories: Blogs

Amazee Labs: Render a menu tree from custom code in Drupal 8

April 13, 2017 - 7:54am
Render a menu tree from custom code in Drupal 8

Having menus rendered on a site in Drupal 8 is pretty simple. Most of the time this can be accomplished with site building, in a few clicks. And if you need some more advanced features on top of what the Drupal 8 core has, you can also have a look at modules like Menu Block, or have a look at this (a bit outdated) contributed modules for menus page.

However, you may have some special requirements, for example, to display some small portion of a menu inside the template of a node. There is no simple 'site building' solution for that. You most probably need to code a bit.

Vasi Chindris Thu, 04/13/2017 - 12:54

Let's say you have these requirements: a node which can be part of the main menu, and which could also have menu items bellow it, should display the first level of those menu items somewhere inside its template (so just as you would display a regular field).

The image above shows a very simple visual representation of what we'd like to achieve.

Now let's break this down into smaller and independent pieces. You can also skip to the entire code. Basically, you have to:

  • Load and render a menu (or parts of a menu).
  • Have a custom field available on the Manage display page for a content type, so that you can place it on the node page.

Let's actually start with the second part, as it is simpler.

Custom (extra) fields

There is the hook_entity_extra_fields_info hook which can be used to expose custom or extra fields on the entities. We'll use this hook to provide a custom field on a node.

The visible flag represents the default visibility setting of the field. Usually, you want this to be false, so you decide when the element is displayed and not when it is NOT displayed.

Now clear the cache and go to Structure >> Content types >> YourContentType, click on the Manage display tab and you should see your new field available there.

The next thing is to implement the hook_ENTITY_TYPE_view and particularly, in this case, hook_node_view. Here it is:

Save it, clear the cache, make sure that the field is visible in the display setting for that content type and visit a node of that type. You should see the custom text displayed.

So, we're done with the second part. Let's go and actually load the menu for this node and display the first level of menu items.

Render the menu

For this, we'll have to load a menu using a menu tree service and a set of parameters which define the root to start with, how many levels to load, and so on, then to apply a set of manipulators on the loaded tree that would check the access, do the sorting, etc, and finally to build the menu tree.

The root menu item

One of the tricky things is to get the correct root menu item. We know that the node can be part of a menu. It would be great if we could load a menu link based on the route name and some route parameters. For that, you can use the plugin.manager.menu.link service.

Menu tree parameters

When loading a menu, we have to provide some parameters. For example, what the root of the menu you want to load (if you want to load a subtree, which is our case) is, or how many levels to load. These parameters are specified using a \Drupal\Core\Menu\MenuTreeParameters object.

More details about the MenuTreeParameters can be found here.

Load the menu

To load the menu, we will use the menu.link_tree service.

Menu tree manipulators

After we have the menu loaded, it is time to actually apply some manipulators on its menu items. These manipulators will deal with access checking, sorting according to the weights, or whatever other things you want to do with the menu tree. The code looks like that:

So, in this case, we want to check for the access and sort the items. There's a default tree manipulator service in Core which is Drupal\Core\Menu\DefaultMenuLinkTreeManipulators. That already provides a few basic manipulators you can apply to a menu tree, which is enough in our case. But of course, you can add any other callable to that array and use the implementation from Core as a guideline.

Build the menu

Finally, we have to build the menu. This is as simple as:

This would replace the

$build['my_custom_menu'] = [   '#markup' => 'Some custom menu', ]

that you used as a placeholder in the custom_node_view() hook.

And that's it. The first level of navigation, having the current node as root, will be displayed inside the template of your node.

Here is the entire code:

Categories: Blogs

Agiledrop.com Blog: AGILEDROP: Agiledrop going to the WebCamp

April 13, 2017 - 4:19am
We must admit that in the past we were not so informative about where we will be and on which (Drupal) event we will go. We promise we'll do better from now on. This means that if you would like to talk to us in person, you'll know where to find us (you can also find us in our office of course). We'll start with a Web Camp we will attend next. A WebCamp will be held in Ljubljana on Saturday 22nd April 2017 in the Faculty of Computer and Information Science, Ljubljana. This is a place very familiar to our development director Bostjan Kovac because he got his bachelor’s degree there. An event… READ MORE
Categories: Blogs

Valuebound: How to build a simple form using AJAX in Drupal 8

April 13, 2017 - 4:15am

Ajax is a script on the client side communicating asynchronously with the server without a complete page refresh.The best description I came across about Ajax as “the method of exchanging data with a server, and updating parts of a web page – without reloading the entire page.”

In our project, while creating a new account if we give the existing username, on submitting the page it will throw an error. But, instead of reloading the page, we can just update certain parts of DOM. This can be achieved using AJAX. So, here is the example how to implement this ajax in drupal 8 forms.

In order to build a simple form using AJAX in Drupal 8 , we created a form with Username field. Using ajax we are going to validate that field. To achieve this, create a…

Categories: Blogs

erdfisch: Drupal Camp Northern Lights (Part 3)

April 12, 2017 - 1:03pm
Drupal Camp Northern Lights (Part 3) 12.04.2017 Michael Lenahan Body: 

This has, for reasons we are not quite sure of, ended up being a three-part blog post.

Part 1 is here and part 2 is here.

So, where we left off was at the tomato farm, where it felt like being in a future farm in outer space.

But the tomato farm is not only that. It is a pony (sorry, "Icelandic horse") farm as well!

On our way back to Reykjavik that evening, we were told "we have to hurry because a big storm is on its way".

When we woke up the next day, Reykjavik had experienced the biggest snow fall in 80 years, and all roads were closed.

There are some beautiful pictures of this here: http://www.standard.co.uk/lifestyle/travel/icelands-capital-reykjav-k-s…

None of this extraordinary weather deterred the incredible team who organized this event.

The Drupal camp at Drupal Camp Northern Lights

The amount of effort that went in to making sure we had a great time was truly amazing, and this was carried over into the sessions as well.

Sprint room

Oftentimes, I don't go into the sprint room at Drupal camps, you can have the feeling that you are interrupting something very important that you don't understand.

This time I thought "no, I'm among friends now" so I ventured in to the sprint room, and sheepishly explained that I'm new and looking for something to work on.

Enzo was there, and he helped me get started on a Drupal Console issue.

Here's how you get started:

https://gist.github.com/jmolivas/97bbd07f328217be3564a434c5bd2618

And here is the issue I fixed a few weeks after coming back. I feel so proud!

https://github.com/hechoendrupal/drupal-console/issues/3197

Thanks, Enzo!

Drupal Twig - Mauricio Dinarte

https://twitter.com/dinarcon

This session was full of insider tips on how to get the most out twig, with lots of entertaining examples out of Drupal core.

You can see the slides here:

http://bit.ly/twig-recipes

Gitpal.org - real version control of content - Rouven Volk

Rouven explained an interesting way of managing content using a git repository. We're used to having code in git, but there are times when the content needs to be equally trackable.

Rouven's approach is to use Drupal's content revisioning system together with git-wrapper to write all content revisions as commits into a git repository.

That means you can track changes to your content like this:

If you want to get involved with this, join us and work on it at https://drupal.slack.com/messages/gitpal

The Continuing Saga of Layouts in Drupal 8 - Tim Plunkett

Despite being a "certified" front-end developer I'm not really a front-end developer at all.

For this reason I'm very supportive of efforts to make Drupal front-end work less insane.

I was surprised and happy to discover that Tim's talk on Layouts was easy to understand, I even asked a question related to the way panels can be used without a UI.

I think all of this must have had something to do with the magic of Iceland, and this particular Drupal camp, where the entire atmosphere was so friendly that you felt you could chat with anyone about anything.

The Flexibility of Drupal 8 - Michael Miles (mikemiles86)

Mike Miles is a very entertaining and fun speaker to listen to. His talk showed 8 different ways to do a simple change in Drupal.

Slides and link to the code are here: https://mikemiles86.github.io/dnlights-drupal-flex

Or just go and watch the video already https://www.youtube.com/watch?v=8UV1-NfSR1E

Wrapping up

All that's left to say is thank you, thank you, thank you.

To the organizers https://www.drupal.org/u/baddysonja and https://www.drupal.org/u/drupalviking and all the others who I haven't named here.

As you said, Baddy: this was the coolest Drupal camp ever and an experience I think all of us will always remember.

Schlagworte/Tags:  planet drupal-planet Ihr Name Kommentar/Comment Kommentar hinzufügen/Add comment Leave this field blank
Categories: Blogs

erdfisch: Drupal Camp Northern Lights (Part 2)

April 12, 2017 - 12:35pm
Drupal Camp Northern Lights (Part 2) 12.04.2017 Michael Lenahan Body: 

Thanks for sticking around. There will be more than just photos of us goofing around in Iceland, I promise.

For stuff about the actual Drupal Camp, please jump to the end of part three.

So, when we left you in part one, we were exploring the beautiful Golden Circle in Iceland.

We did, indeed, feel like true explorers.

We saw this awesome waterfall, the same one that was made famous by Kim Kardashian in her "Iceland Waterfall" tweet.

And then we went for dinner at this incredible place that grows tomatoes year-round using geothermal energy

More in part three which also features an Icelandic horse.

Schlagworte/Tags:  planet drupal-planet Ihr Name Kommentar/Comment Save Leave this field blank
Categories: Blogs

OpenLucius: 16 Cool Drupal modules For site builders | April 2017

April 12, 2017 - 12:25pm

It took a while before I could write a new edition, I was just busy with the production of customer social intranet projects :) Here again with a brand new version, what struck me in module updates in the past month:

1. D8 Editor Advanced link
Categories: Blogs

Acquia Developer Center Blog: ES6 for Drupal Developers: ES6 Modules, Classes, and Promises

April 12, 2017 - 12:10pm

Some of the most important new features in ES6 originate from existing solutions for problems shared by a large swath of JavaScript applications. This is particularly true of ES6 modules, a new system of class-based inheritance, and promises. Prototypal inheritance can be difficult for those new to JavaScript. And at some point, modules and promises have both been present in various JavaScript libraries, but until now, they were impossible to implement natively.

Tags: acquia drupal planet
Categories: Blogs

erdfisch: Drupal Camp Northern Lights (Part 1)

April 12, 2017 - 11:32am
Drupal Camp Northern Lights (Part 1) 12.04.2017 Michael Lenahan Body: 

tl;dr: Drupal Camp Northern Lights was even better than the actual Northern Lights.

This was the best Drupal event I have ever attended. So, even though it is two months late, it deserves a blog post.

95 very, very lucky people attended.

Instead of a camp t-shirt, the organizers gave us some memories we will always live with.

We had dinner at the Icelandic broadcasting corporation's offices. This was the view from the roof of RÚV.

Apologies to any real Drupal Vikings out there for this photo.

Here we are at the intercontinental divide between North America and Europe. North America is to the left and is, as you can see, by far the more impressive of the two tectonic plates.

We felt like true explorers.

More of this in part two.

Or you can skip to part three where the stuff about the Drupal camp actually is.

Schlagworte/Tags:  planet drupal-planet Ihr Name Kommentar/Comment Save Leave this field blank
Categories: Blogs

Another Drop in the Drupal Sea: On being the change I want to see in the community

April 12, 2017 - 10:39am

Yes, this is another one of "those posts."

No, this is not another one of "those posts."

read more

Categories: Blogs

Evolving Web: Migrate translated content from Drupal 6 to Drupal 8

April 12, 2017 - 10:15am

Now that Drupal 6 has reached end-of-life, many sites are moving to Drupal 8. If you had multilingual content in Drupal 6, this upgrade used to be very difficult—but since Drupal 8.2 there is support for migrating all your translations! In this article, we will discuss how to migrate translated content from Drupal 6 to Drupal 8.

This article would not have been possible without the help of my colleague Dave. Gracias Dave!

The problem

We have a Drupal 6 database containing story nodes about animal hybrids. Some nodes have translations in English, Spanish and French; some are untranslated; and others are language-neutral (non-translatable). Our goal is to migrate the D6 nodes into a D8 website, preserving the translations.

Before we start The module

To write the migrations, we create a module - in our case, migrate_example_i18n. There's nothing special about the module declaration, except for the dependencies:

  • migrate_plus and migrate_tools provide various features for defining and executing migrations.
  • migrate_source_csv: Will be used for demonstrating migration of translated content from non-Drupal sources in an upcoming article.
  • migrate_drupal: This module provides tools for migrating data from older versions of Drupal. It comes with Drupal 8.x core. Since this migration uses a Drupal 6 site as a source for its data, we need the migrate_drupal module.
How do translations work?

    Before jumping into writing these migrations, it is important to mention that Drupal 6 and Drupal 8 translations work very differently. Here's the difference in a nutshell:

    • Drupal 6: When we translate a node, a new node is created with a different ID. This translated node has a property named tnid, which stores the ID of the original node, linking the two nodes together. For language-neutral or untranslated content, the tnid is set to 0.
    • Drupal 8: When we translate a node, no new node is created! The translation is saved in the fields of the original node, but with a different language code.

    To map between the D6 and D8 translation models, we'll use two migrations:

    • The example_hybrid_base migration will migrate the original content of each node, untranslated.
    • The example_hybrid_i18n migration will migrate in all the translations, and connect each one to the original node from example_hybrid_base..

    We group the two migrations using the example_hybrid migration group to keep things clean and organized. Then we can execute both migrations with drush migrate-import --group=example_hybrid --update.

    Step 1: Base migration

    Let's start with the example_hybrid_base, to migrate all the base data (non-translations) in this migration. Described below are some noteworthy parameters:

    Source source: plugin: d6_node node_type: story key: drupal_6 constants: node_article: article body_format: full_html
    • plugin: Since we want to import data from a Drupal installation, we need to set the source plugin to d6_node. The d6_node source plugin is introduced by the migrate_drupal, module and it helps us read nodes from a Drupal 6 database without having to write queries manually.
    • node_type: This tells the source plugin that we are interested in just one particular Drupal 6 node type, namely story.
    • key: Our Drupal 6 data doesn't come from our main Drupal 8 database—instead it comes from a secondary database connection. We choose a key to identify each such connection, and we need to tell the source which such key to use. The keys themselves are defined in the $databases variable in our settings.php or settings.local.php. See the example settings.local.php file to see how it's done.
    • constants: We define some hard-coded values under this parameter.
    • translations: Notice there is no translations parameter here. The default value (false) tells the source plugin that we're only interested in migrating non-translations, i.e. content in the base language and language-neutral content.
    Destination destination: plugin: 'entity:node'
    • plugin: Since we want to create node entities in Drupal 8, we specify this as entity:node. That's it.
    • translations: Again we do not define the translations parameter while migrating base data. Omitting the parameter tells the destination plugin that we are interested in creating fresh nodes for each record, not translations of existing nodes.
    Process process: type: constants/node_article langcode: plugin: default_value source: language default_value: und 'body/value': body 'body/format': constants/body_format title: title field_one_liner: field_one_liner sticky: sticky status: status promote: promote

    This is where we map the old node properties to the new node properties. Most of the properties have been assigned as is, without alteration, however, some noteworthy properties have been discussed below:

    • type: We specify that we want to create article nodes.
    • langcode: The langcode parameter was formerly language in Drupal 6, so we rename it here. Also, if a Drupal 6 node is language-neutral, it will have no value at all here. In that case,  we default to und.
    • body: We can assign this property directly to the body property. However, the Drupal 6 data is treated as plain text in Drupal 8 in that case. So migrating with body: body, the imported nodes in Drupal 8 would show visible HTML markup on your site. To resolve this, we explicitly assign the old body to body/value and specify that the text is in HTML by assigning full_html to body/format. That tells Drupal to treat the body as Full HTML.
    • nidThere is no nid parameter here, because we don't care what nid each new node has in Drupal 8. Drupal can just assign a new nid to each node in the normal way.

    This takes care of the base data. If you run this migration with drush migrate-import example_hybrid_i18n --update, all Drupal 6 nodes which are in base language or are language-neutral will be migrated into Drupal 8.

    Step 2: Translation migration

    We are halfway through now! All that's missing is migrating translations of the nodes we migrated above. To do this, we create another migration with the ID example_hybrid_i18n:

    source: plugin: d6_node node_type: story translations: true # ... destination: plugin: 'entity:node' translations: true process: nid: plugin: migration source: tnid migration: example_hybrid_base langcode: language # ... migration_dependencies: required: - example_hybrid_base

    The migration definition remains mostly the same but has the following important differences as compared the base migration:

    • source:
      • translations: We set this to true to make the source plugin read only translations.
    • destination:
      • translations: We set this to true to make the destination plugin create translations for existing nodes instead of creating fresh new nodes for each source record.
    • process:
      • nid: In this case, we do care what the Drupal 8 nid is for each node. It has to match the nid for the untranslated version of this content, so that Drupal can add a translation to the correct node. This section uses the migration process plugin to figure out the right nid. It tells Drupal to check the previously-executed example_hybrid_base migration for a D6 node that has the same tnid as this D6 node. It will then then reuse the resulting nid here.
      • langcode: We define the language in which the translation should be created.
    • migration_dependencies: Since we cannot add translations to nodes that do not yet exist, we tell Drupal that this migration depends on the base migration example_hybrid_base. That way, the base migration will run before this migration.

    That's it! We can run our translation migration with drush migrate-import example_hybrid_i18n --update and the translations will be imported into Drupal 8. Alternatively, we can use the migration group we defined to run both these migrations at once - the base migration will automatically be executed first and then the i18n migration. Here's how the output should look:

    $ drush migrate-import --group=example_hybrid --update Processed 8 items (8 created, 0 updated, 0 failed, 0 ignored) - done with 'example_hybrid_base' Processed 9 items (9 created, 0 updated, 0 failed, 0 ignored) - done with 'example_hybrid_i18n'

    You can check if everything went alright by clicking the Translate option for any translated node in Drupal 8. If everything went correctly, you should see that the node exists in the original language and has one or more translations.

    Next steps + more awesome articles by Evolving Web
    Categories: Blogs

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

    April 12, 2017 - 8: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: Blogs

    Liip: Drupal 8 – Multilanguage Improvements

    April 12, 2017 - 6: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.

    Image: drupal8multilingual.org

    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 drupal.org you need to implement it on your own. Implement the following two modules.

    Hide untranslated menu items

    Code from https://www.drupal.org/node/2466553#comment-11991690. 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 https://www.drupal.org/node/2791231#comment-12004615 (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 Drupal.org 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: Blogs

    La Drupalera (en): Grunt, automating repetitive work

    April 12, 2017 - 5: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:

    package.json

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

    and Gruntfile.js

    Read more
    Categories: Blogs

    Verbosity: Talking migrations at DrupalCon Baltimore

    April 11, 2017 - 9: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: Blogs

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

    April 11, 2017 - 6: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: https://www.drupal.org/conflict-resolution

    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: Blogs

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

    April 11, 2017 - 2:54pm

    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: Blogs

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

    April 11, 2017 - 2:48pm
    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: Blogs

    Pages