Drupal

Lullabot: Drupalcon Baltimore Edition

Planet Drupal - 20 April 2017 - 1:00pm
Matt and Mike sit down with several Lullabots who are presenting at Drupalcon Baltimore. We talk about our sessions, sessions that we're excited to see, and speaking tips for first-time presenters.
Categories: Drupal

CU Boulder - Webcentral: Upgrading A Drupal 7 Module to Drupal 8: Configuration Forms

Planet Drupal - 20 April 2017 - 12:41pm

In the last post in this series, we set up some routing for our module for three paths. One of those paths is to the module's main configuration form. Since this module has a Drupal 7 version, I am going to go by the old tried and true method of CDD, a.k.a Copy Driven Development. Copy, paste, cry, try to copy something else.

Developer Blog
Categories: Drupal

Acquia Developer Center Blog: Get the most out of your first DrupalCon!

Planet Drupal - 20 April 2017 - 11:59am

To me, meeting and building relationships in person is the glue that holds us together and makes Drupal a community. If this is your first DrupalCon or first Drupal community event, it’ll be your first taste of this crazy, smart bunch of people scattered around the globe most of the rest of the year. Welcome! I’d like to help you get the most out of your first DrupalCon!

Tags: acquia drupal planetcommunityfirst timerseventdrupalcon
Categories: Drupal

Submitted by specific

New Drupal Modules - 20 April 2017 - 11:51am

This module allows you to set the visibility of the information about the author, for each individual node.

Also adds the ability to independently configure display the author and date of publication.

Categories: Drupal

Mediacurrent: Dropcast: Episode 31 - DRUPALCON

Planet Drupal - 20 April 2017 - 9:58am
Dropcast: Episode 31 - DRUPALCON

Recorded April 12th, 2017

Categories: Drupal

The Accidental Coder: The State-of-Drupal Poll

Planet Drupal - 20 April 2017 - 8:25am

Speak out about your feelings on several topics that are swirling in the Drupalsphere. The results of the poll will be published here during Drupalcon Baltimore. 

Take the Poll!

Tags: Drupal Planet
Categories: Drupal

MTech, LLC: Ultimate guide to migrating data into Drupal 8

Planet Drupal - 20 April 2017 - 8:16am
Ultimate guide to migrating data into Drupal 8

I give special greetings to all the people who read us and particularly to Baltimore at the headquarters of Drupalcon 2017.

Charlotte León Thu, 04/20/2017 - 09:16
Categories: Drupal

React VR

New Drupal Modules - 20 April 2017 - 8:10am
What is React VR ?

React VR is a framework for the creation of VR applications that run in your web browser.
It pairs modern APIs like WebGL and WebVR with the declarative power of React, producing experiences that can be consumed through a variety of devices.
Leveraging web technologies and the existing React ecosystem, React VR aims to simplify the construction of 360 experiences and democratize the creation of VR content. I
f you're familiar with React, you can now build in VR – learn once, write anywhere.

Categories: Drupal

Important Notification

New Drupal Modules - 20 April 2017 - 6:34am

Provide Global Notification for Admin Section.

The concept is to provide a tool that serves two notifications to Drupal users when they log into the site:

1. When the admin user first logs into Drupal.
2. As a notification on all Drupal admin pages.

Categories: Drupal

Chromatic: Replacing hook_boot and hook_init Functionality in Drupal 8

Planet Drupal - 20 April 2017 - 6:15am

Adam uncovers methods of firing code on every page in Drupal 8, the right way.

Categories: Drupal

Zivtech: Empowering Drupal 8 Content Editors with EVA: Attach All the Displays!

Planet Drupal - 20 April 2017 - 6:00am

Entity Views Attachment, or EVA, is a Drupal module that allows you to attach view displays to entities of your choosing. We used it recently on a project and loved it. You know it’s good because it has a no-nonsense name and an even better acronym. (Plus, the maintainers have taken full advantage of the acronym and placed a spaceman on the project page. Nice!)

Since the now-ubiquitous Paragraphs module provides the “paragraph” entity type, I figured these two will make good dancing partners.

Getting them to tango is simple enough. You create a paragraph bundle, target that bundle in the settings on an EVA view display, then arrange the view in the paragraph’s display settings. Voila – your view display shows up wherever you add this paragraph!

By attaching a view display to a paragraph entity and enabling that paragraph on a node’s paragraph reference field, you give your content editors the ability to place a view wherever they want within their page content. Better still, they can contextualize what they are doing since this all happens in the edit form where the rest of the node content lives. As far as I can tell, no other approach in the Drupal ecosystem (I’m looking at you Blocks and Panels) makes adding views to content this easy for your editors.

Case Study

The concept is pretty straightforward, but with a little cleverness it allows you to build some complex page elements. Let’s walk through an example. Consider the following design:

This mockup represents Section nodes and lists of Subpage nodes that reference them. In addition, the buttons links should point to the parent Section node. With a little elbow grease, we can build a system to output this with our friends EVA and Paragraphs.

Here’s how I’m breaking this down conceptually:

We have three things to build:

  1. A create a container paragraph bundle

  2. A child paragraph bundle with a Section entity reference field

  3. An EVA of subpages to attach to the child paragraph bundle

Building the Subpage EVA

As I mentioned before, Subpage nodes will reference Section nodes. With this in mind, we can build the EVA that lists subpages and expects a section node ID to contextually filter to subpages that reference that node.

Building the Section paragraph type

Next, we’ll create the Section paragraph type that will handle each grouping of a section node with its related subpages. The Section paragraph will have one field, an entity reference field limited to Section nodes, that gives us all the data we need from our section.

We’ll attach our EVA to this paragraph type and configure it to pass the referenced node’s ID as the contextual filter using tokens in the EVA settings. You will need to install the Token module to do this. Go to /admin/help/token to see all available tokens once installed. You need to grab the node ID through your entity reference field, so your token argument should look something like this:

[paragraph:field_node_reference:entity:nid]

We pass that token to our contextual filter, and we can tell our view to use that argument to create a link to the section node for our “View All Subpages” link. To do this, we’ll add a global text area to the view footer and check the “Use replacement tokens from the first row” checkbox. Then we’ll write some HTML to create a link. It’ll look something like this:

<a href="/node/{{ raw_arguments.nid }}">View all Subpages</a> Building the Section List paragraph type

Lastly, we’ll create the Section List paragraph type. This only really needs a paragraph reference field that only allows the user to add Section paragraphs, but I also added a title field that will act as a header for the whole list.

Tip: Install Fences module to control your field’s wrapper markup. I used this here to wrap the title in <h2> tags.

We’re finished!

Now that everything is built, we can allow users to select the Section List paragraph type in a paragraph reference field of our choosing. A user adds a Section List, then adds Sections via the entity reference. It looks like this in the node edit form:

Do you have any cool ways you use the EVA module in your builds? Let us know in the comments section below.

Categories: Drupal

Evolving Web: Migrate translations from CSV, JSON or XML to Drupal 8

Planet Drupal - 20 April 2017 - 5:38am

In my last post, I showed you how to migrate translated content from Drupal 6 to Drupal 8. But clients often don't start with their data in Drupal 6. Instead there's some other source of data that may include translations, like a CSV spreadsheet. In this article, I'll show you how to migrate multilingual content from such sources to Drupal 8.

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

The problem

We have two CSV files containing some data about chemical elements in two languages. One file contains data in English and the other file, in Spanish. Our goal is to migrate these records into a Drupal 8 website, preserving the translations.

Before we start
  • Since this is an advanced migration topic, it is assumed you already know the basics of migration.
  • To execute the migrations in this example, you can download the migrate example i18n. The module should work without any trouble for a standard Drupal 8 install. See quick-start for more information.
Migrating JSON, XML and other formats

Though this example shows how to work with a CSV data source, one can easily work with other data sources. Here are some quick pointers:

  • Find and install the relevant migrate source module. If you do not have a standard source module available, you can:
    • try converting your data to a supported format first.
    • write your own migration source plugin, if you're feeling adventurous.
  • Modify the migration definitions to include custom parameters for the data source.
  • Some useful source formats are supported by these projects:
The module

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

How to migrate translations

    Before we start writing migrations, it is important to mention how Drupal 8 translations work. In a nutshell:

    • First, we create content in its base language, say in English. For example, we could create a brand new node for the element Hydrogen, which might have a unique node ID 4.
    • Now that the base node is in place, we can translate the node, say to Spanish. Unlike some previous versions of Drupal, this won't become a new node with its own node ID. Instead, the translation is saved against the same node generated above, and so will have the same node ID—just a different language setting.

    Hence, the migration definition for this example includes the following:

    • We migrate the base data in English using in example_element_en migration.
    • We migrate the Spanish translations using the example_element_es migration, and link each translation to the original English version.
    • We group the two migrations in the example_element migration group to keep things clean and organized.

    Thus, we can execute the migrations of this example with the command drush migrate-import --group=example_element.

    Warning

    Note that this plan only works because every single node we are importing has at least an English translation! If some nodes only existed in Spanish, we would not be able to link them to the (non-existent) original English version. If you encounter data like this, you'll need to handle it in a different way.

    Step 1: Element base migration (English)

    To migrate the English translations, we define the example_element_en migration. Here is a quick look at some important parameters used in the migration definition.

    Source source: plugin: csv path: 'element.data.en.csv' header_row_count: 1 keys: - Symbol fields: Name: 'Name' Symbol: 'Symbol' 'Atomic Number': 'Atomic number' 'Discovered By': 'Name of people who discovered the element' constants: lang_en: en node_element: 'element'
    • plugin: Since we want to import data from a CSV file, we need to use the csv plugin provided by the migrate_source_csv module.
    • path: Path to the CSV data source so that the source plugin can read the file. Our source files for this example actually live within our module, so we modify this path at runtime using hook_migration_plugins_alter() in migrate_example_i18n.module.
    • header_row_count: Number of initial rows in the CSV file which do not contain actual data. This helps ignore column headings.
    • keys: The column(s) in the CSV file which uniquely identify each record. In our example, the chemical symbol in the column Symbol is unique to each row, so we can use that as the key.
    • fields: A description for every column present in the CSV file. This is used for displaying source details in the UI.
    • constants: Some static values for use during the migration.
    Destination destination: plugin: 'entity:node'
    • plugin: Nothing fancy here. We aim to create node entities, so we set the plugin as entity:node.
    • translations: Since we are importing the content in base language, we do not specify the translations parameter. This will make Drupal create new nodes for every record.
    Process process: type: constants/node_element title: Name langcode: constants/lang_en field_element_symbol: Symbol field_element_discoverer: plugin: explode delimiter: ', ' source: Discovered By

    This is where we map the columns of the CSV file to properties of our target nodes. Here are some mappings which require a special mention and explication:

    • type: We hard-code the content type for the nodes we wish to create, to type element.
    • langcode: Since all source records are in English, we tell Drupal to save the destination nodes in English as well. We do this by explicitly specifying langcode as en.
    • field_element_discoverer: This field is a bit tricky. Looking at the source data, we realize that every element has one or more discoverers. Multiple discoverer names are separated by commas. Thus, we use plugin: explode and delimiter: ', ' to split multiple records into arrays. With the values split into arrays, Drupal understands and saves the data in this column as multiple values.

    When we run this migration like drush migrate-import example_element_en, we import all the nodes in the base language (English).

    Step 2: Element translation migration (Spanish)

    With the base nodes in place, we define a migration similar to the previous one with the ID example_element_es.

    source: plugin: csv path: 'element.data.es.csv' header_row_count: 1 keys: - 'Simbolo' constants: lang_en: en # ... destination: plugin: 'entity:node' translations: true process: nid: plugin: migration source: Simbolo migration: example_element_en langcode: constants/lang_es content_translation_source: constants/lang_en # ... migration_dependencies: required: - example_element_en

    Let us look at some major differences between the example_element_es migration and the example_element_en migration:

    • source:
      • path: Since the Spanish node data is in another file, we change the path accordingly.
      • keys: The Spanish word for Symbol is Símbolo, and it is the column containing the unique ID of each record. Hence, we define it as the source data key. Unfortunately, Drupal migrate support keys with non-ASCII characters such as í (with its accent). So, as a workaround, I had to remove all such accented characters from the column headings and write the key parameter as Simbolo, without the special í.
      • fields: The field definitions had to be changed to match the Spanish column names used in the CSV.
    • destination:
      • translations: Since we want Drupal to create translations for English language nodes created during the example_element_en migration, we specify translations: true.
    • process:
      • nid: We use the plugin: migration to make Drupal lookup nodes which were created during the English element migration and use their ID as the nid. This results in the Spanish translations being attached to the original nodes created in English.
      • langcode: Since all records in element.data.es.csv are in Spanish, we hard-code the langcode to es for each record of this migration. This tells Drupal that these are Spanish translations.
      • content_translation_source: Each translation of a Drupal node comes from a previous translation—for example, you might take the Spanish translation, and translate it into French. In this case, we'd say that Spanish was the source language of the French translation. By adding this process step, we tell Drupal that all our Spanish translations are coming from English.
    • migration_dependencies: This ensures that the base data is migrated before the translations. So to run this migration, one must run the example_element_en migration first.

    Voilà! Run the Spanish migration (drush migrate-import example_element_es) and you have the Spanish translations for the elements! We can run both the English and Spanish migration at once using the migration group we created. Here's how the output should look in the command-line:

    $ drush migrate-import --group=example_element Processed 111 items (111 created, 0 updated, 0 failed, 0 ignored) - done with 'example_element_en' Processed 105 items (105 created, 0 updated, 0 failed, 0 ignored) - done with 'example_element_es'

    If we had another file containing French translations, we would create another migration like we did for Spanish, and import the French data in a similar way. I couldn't find a CSV file with element data in French, so I didn't include it in this example—but go try it out on your own, and leave a comment to tell me how it went!

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

    Dropsolid: Making a difference, One Drupal security patch at a time

    Planet Drupal - 20 April 2017 - 4:52am
    20 Apr Making a difference, one Drupal security patch at a time Nick Advisory by the Drupal security team

    Recently, the References module started receiving some attention (read here, here and here). The reason for this is that the Drupal security team posted an advisory to migrate away from the References module for Drupal 7 and move to the entity_reference module. At the time of writing (20 April), 121.091 sites are actively reporting to Drupal.org that they are using this module. That makes for a lot of unhappy developers.

    Things kicked off after a security vulnerability was discovered in the References module. The security team tried to contact the existing maintainers of that module, but there was no response. The security team had no choice but to mark the module as abandoned and send out the following advisory explaining that the details would be made public in a month and that everyone should upgrade, as there was no fix available.

    Migrate efficiently

    At Dropsolid, we noticed that for many of our older Drupal 7 installs we were still using this module extensively. Migrating all of the affected sites would have meant a very lengthy undertaking, so I was curious to find a way to spend less time and effort while still fixing the problem. We immediately contacted one of the people who reported the security issue and tried to get more information other than what was publicly available. That person stayed true to the rules and did not disclose any information about the issue.

    We didn’t give up, but made an official request to the security team offering to help and requesting access to the security vulnerability issue. The Drupal security team reviewed the request and granted me access. In the Drupal Security issue queue there was some historical information about this vulnerability, some answers and a proposed patch. The patch had not been tested, but this is where Dropsolid chimed in. After extensively testing the patch on all the different scenarios on an actual site that was vulnerable, we marked the issue as Reviewed and Tested by the Community (RTBC) and stepped up maintain the References module for future security issues.

    It pays off to step in

    I’d like to thank Niels Aers, one of my colleagues, as his involvement was critical in this journey and he is now the current maintainer of this module. He jumped straight in without hesitation. In the end, we spent less time fixing the actual issue compared to the potential effort for changing all our sites to use a different module. So remember: you can also make a similar impact to the Drupal community by stepping up when something like this happens. Do not freak out, but think how you can help your clients, company and career by fixing something for more than just you or your company.

    Categories: Drupal

    Virtual Entities

    New Drupal Modules - 20 April 2017 - 3:27am
    Categories: Drupal

    Obfuscate

    New Drupal Modules - 20 April 2017 - 2:32am

    Obfuscates email addresses as a Field Formatter of the core Email field.

    Provides a simple and flexible way to prevent spam by using the core default Email field.
    For some reasons, you should prefer to leave the field formatter of some view modes to Plain text or Email.
    All the view modes (default / full, teaser, search index, ...) that exposes publicly email addresses should define the fields to Obfuscate.

    Credits to Alexei Tenitski for the obfuscation solution on the first release.

    Categories: Drupal

    Pronovix: Documenting web APIs with the Swagger / OpenAPI specification in Drupal

    Planet Drupal - 20 April 2017 - 1:19am

    As part of our work to make Drupal 8 the leading CMS for developer portals, we are implementing a mechanism to import the OpenAPI (formerly known as Swagger) specification format. This is a crucial feature not only for dedicated developer portals, but also for all Drupal sites that are exposing an API. Now that it has become much easier to create a RESTful API service in Drupal 8, the next step is to make it more straightforward to create its API reference documentation. That is why we think our work will be useful for site builders, and not just for technical writers and API product owners.

    Categories: Drupal

    Zoom API

    New Drupal Modules - 19 April 2017 - 7:35pm

    Integration with the Zoom Video Conferencing Service.

    Zoom unifies cloud video conferencing, simple online meetings, group messaging, and a software-defined conference room solution into one easy-to-use platform. Our solution offers the best video, audio, and wireless screen-sharing experience across Windows, Mac, Linux, Chrome OS, iOS, Android, Blackberry, Zoom Rooms, and H.323/SIP room systems. Founded in 2011, Zoom's mission is to make video and web conferencing frictionless.

    Categories: Drupal

    marvil07.net: Re-activating Vote Up/Down

    Planet Drupal - 19 April 2017 - 7:27pm

    Vote Up/Down is a drupal module that uses Voting API to provide a way to vote.
    These notes are about part of the history of the module, and the recent news about it, including a couple of releases!

    A long time ago...

    The project itself is really ancient, it started in 2006 by frjo, in Drupal 4.7, and the same code has evolved until Drupal 7.
    I took co-maintainership of the project around 2009-2010, when I met with lut4rp, at the time the one maintainer of the project; who made a rewrite to modularize it at the start of 6.x-2.x.
    At that time we were still using CVS officially (and some of us git locally), and we were thrilled to receive and integrate a patch from merlinofchaos, that extended the module a lot, and make it more maintainable.
    With the past of the time, I became the only active maintainer of the module.

    At the start I was pretty active as a maintainer there; but over the years, I have not been responsive enough, especially around the D7 port.
    During that time the community provided several patches and finally amitaibu created a sandbox, that I end up integrating into the project.
    Also, I managed to write another submodule, vud_field, in that process.
    For me it was clear, I advocated to remove vud_node, vud_term, and vud_comment form the project in favour of vud_field.
    From my perspective it was more beneficial: (a) vud_field provided mostly the same functionality on nodes, taxonomy terms, and comments; but also (b) provided voting on any entity, embracing D7 new APIs; and also (c) made things more maintainable.
    Sadly, the removal did not happened at that time, and that was one of the reasons why D7 version was never out of alpha status.

    Recent news

    After quite some time of inactivity in vote_up_down, this January, I started to port the module to D8, but I only started: only 4 porting commits got into the new 8.x-1.x branch.

    Then, I decided to add a GSoC project as student's suggestion to port Vote Up/Down to D8 for this year.

    In preparation, this week I have branched out D7 into two different versions 7.x-1.x and 7.x-2.x, adding respective releases to make things more clear:

    • 7.x.1-x (with 7.x-1.0-beta1 release): It still keeps all submodules, but it is not planned to be maintained for much longer anymore. I applied there all related code pending about vud_node, vud_comment, and vud_term.
    • 7.x-2.x (with 7.x-2.0 release): Instead, it only contains vud and vud_field, and it is planned to be maintained as the stable branch. Sadly there in not a complete upgrade path neither from 6.x-2.x nor from 7.x-1.x, but I added some starting code to do that on the related issue #1363928, and maybe someone would like to continue that.

    Hopefully one of the students proposing the port to Vote Up/Down to D8 gets accepted.
    It will be great to see the module active again!

    Etiquetas:
    Categories: Drupal

    Mediacurrent: Debug Drupal PHP in Vim with Vdebug

    Planet Drupal - 19 April 2017 - 3:51pm

    I know quite a few developers that love Vim but think they have to use an IDE to be able to debug their applications. In this post I will show you how to set up Vim as a Xdebug client.

    The Vdebug plugin for Vim provides a way to do debugging inside Vim using the tools that Vim provides to great advantage. As the project page says,

     

    Categories: Drupal

    Aten Design Group: Radios, Checkboxes, and Drupal’s Admin Interface

    Planet Drupal - 19 April 2017 - 3:09pm

    Custom styled form elements are a common thing to see in a design. That’s because default form styles vary visually from browser to browser and OS to OS. It makes sense that we’d want these elements styled consistently. Styling them is pretty straightforward, with the exception of select dropdowns which can be more complex. Recently, I ran into an unexpected problem when working on a site that needed a branded admin experience.

    Styling Radio and Checkbox Buttons

    There’s a simple method of styling radio buttons and checkboxes I’ve been using for a while. I first saw it from the people at Tuts+, and they provided this Pen demoing the technique. Briefly explained, we visually hide the input for our radios/checkboxes and draw a new one using :before and :after pseudo elements on the label element. CSS’ :checked selector allows us to toggle our styles based on if the input is checked or not. This technique relies on appropriately marked up inputs and labels, for example:

    <div class=”form-element”> <input type=”checkbox” id=”click-me”> <label for=”click-me”>Click Me</label> </div>

    Clicking the label (containing the fake checkbox styling) will toggle the state of the real checkbox that’s visually hidden.

    Drupal’s Admin Interface

    One thing I learned while working with some of Drupal’s admin interfaces is that they only supply the input, and not an accompanying label. This seemed especially true in tabled interfaces, where you’d check off rows of content and perform some action on the selected items. Since we’re hiding an input that doesn’t have a label to attach the visuals to, we just end up with a blank space. There were several options we had for how to address this issue.

    1. Drop the Custom Styles

    The simplest is to just rely on browser defaults for checkboxes and radios. It’s not a great option, but it is an affordable one for tight budgets.

    2. Create the Missing Labels

    This ended up being my first approach to fixing this, and became more akin to a game of Whack-a-Mole than I anticipated. After going through various preprocess functions, alters, and render functions I was still encountering inputs that were missing labels. Some I was never able to fully track down where the markup was coming from. Manually finding and fixing every missing label might be a viable solution if your website or application has only a handful of places you need to update. However this is not the most scalable solution, and if your product grows this can quickly become a financial black hole.

    3. Create the Missing Labels… with Javascript

    Instead of trying to find every place that creates a checkbox or radio on the server side, we could use Javascript to target every checkbox or radio input that is not followed by a label. From there, we just create the label element and insert it after the selected inputs. This is how that might look using jQuery, though it can also be done with Vanilla JS.

    This is great, as it solves the problem for every input in one fell swoop. One downside here is the Javascript dependency. Should your Javascript not run for any reason, you’re still left with the original problem of missing inputs. Another is page rendering. User’s might be left with a janky experience as Javascript inserts these elements into the DOM.

    4. Drop the Custom Styles… for Older Browsers

    In the end, this was the solution that won out. Using CSS Feature Queries and CSS’ appearance property, we’re able to provide styled inputs for most modern browsers and then fall back to default styles in browsers that lack the support we need. This gives us our custom styles, without the scaling problem of #2, and the Javascript dependency of #3. The downside to this solution is that all versions of Internet Explorer and Firefox will use their browser defaults.

    Firefox was a surprise to me, as the documentation says it supports appearance. However in practice what I got was a less appealing version of the browser default styles. Also surprisingly was by checking for only -webkit-appearance support, Edge still gets our custom styles applied. This all sat well with me for a working solution. Every team and project has it’s own constraints, so your mileage may vary.

    Categories: Drupal

    Pages

    Subscribe to As If Productions aggregator - Drupal