Drupal

Drupal core - Layout Initiative

New Drupal Modules - 14 May 2018 - 11:00am

This is a project for tracking issue credits for the Drupal Layout Initiative.

We're in #layouts in Drupal Slack, where we have weekly text-only meetings on Tuesdays at 13:00 Eastern time, 10:00 Pacific, 17:00 UTC. Please DM @tim.plunkett if you'd like to add an item to the meeting agenda.

See this issue for more information.

Categories: Drupal

Chapter Three: Introducing React Comments

Planet Drupal - 14 May 2018 - 10:57am

Commenting system giant Disqus powers reader conversations on millions of sites, including large publishers like Rolling Stone and the Atlantic. So when Disqus quietly introduced ads into their free plans last year, there was some understandable frustration.

Why did @disqus just add a bunch of ads to my site without my permission? https://t.co/CzXTTuGs67 pic.twitter.com/y2QbFFzM8U

— Harry Campbell (@TheRideshareGuy) February 1, 2017

 

Categories: Drupal

Node Export i18n

New Drupal Modules - 14 May 2018 - 10:51am

This module extends the Node Export functionality and introduces some language localization export/import values specifically when using this module in conjunction with Entity Translations module.

For whatever reason, this combination exists and with 1 node representing several translations, it means we are missing certain values on export.

For instance:

Categories: Drupal

Webform Translation Plus

New Drupal Modules - 14 May 2018 - 10:34am

This module is to fix a few things in webform_translation without having to drastically alter the parent module and permit these options to be ignored if need be. *** Should the maintainer of the module wish these patched in, I would be willing to discuss what would be needed. ***

Categories: Drupal

Exploring Tuscany by car

Dries Buytaert - 14 May 2018 - 10:20am

We spent the weekend exploring Tuscany by car. Each day we drove through vineyards, hilltop towns and medieval cities on narrow, winding roads that often turned into unpaved backroads. Wanting to get the most out of the trip, we stopped from time to time to take in the amazing views and eat pecorino cheese.

Categories: Drupal

CTI Digital: NWDUG Drupal Contribution Sprints

Planet Drupal - 14 May 2018 - 9:48am

Last weekend I attended my first ever Drupal Sprint organised by NWDUG.

Categories: Drupal

CTI Digital: NWDUG Drupal Contribution Sprints

Planet Drupal - 14 May 2018 - 9:48am

Last weekend I attended my first ever Drupal Sprint organised by NWDUG.

Categories: Drupal

Drupal Association blog: Progress and Next Steps for Governance of the Drupal Community

Planet Drupal - 14 May 2018 - 7:39am

One of the things I love the most about my new role as Community Liaison at the Drupal Association is being able to facilitate discussion amongst all the different parts of our Drupal Community. I have extraordinary privilege of access to bring people together and help work through difficult problems.

The governance of the Drupal project has evolved along with the project itself for the last 17 years. I’m determined in 2018 to help facilitate the next steps in evolving the governance for our growing, active community.

2017 - A Year of Listening

Since DrupalCon Baltimore, the Drupal Community has:

  • Held a number of in-person consultations at DrupalCon Baltimore around the general subject of project governance

  • Ran a series of online video conversations, facilitated by the Drupal Association

  • Ran a series of text-based online conversations, facilitated by members of our community across a number of time zones

  • Gathered for a Governance Round Table at DrupalCon Nashville.

This has all led to a significant amount of feedback.

Whilst I highly recommend reading the original blog post about online governance feedback sessions for a full analysis, there was clearly a need for better clarity, communications, distributing leadership, and evolving governance.

2018 - A Year of Taking Action

There are many things happening in 2018 but I want to concentrate for now on two important activities; how we continue to develop our Values and how we can continue to develop Governance of our community.

So, why am I separating “Values” and “Governance”, surely they are connected? Well, they are connected, but they are also quite different and it is clear we need to define the difference within our community.

In the context of the Drupal Community:

  • “Values” describe the culture and behaviors expected of members of the Drupal community to uphold.

  • “Governance” describes the processes and structure of interaction and decision-making that help deliver the Project’s purpose whilst upholding the Values we agree to work by.

Values What’s happened?

Quoting Dries:

Over the course of the last five months, I have tried to capture our fundamental Values & Principles. Based on more than seventeen years of leading and growing the Drupal project, I tried to articulate what I know are "fundamental truths": the culture and behaviors members of our community uphold, how we optimize technical and non-technical decision making, and the attributes shared by successful contributors and leaders in the Drupal project. 

Capturing our Values & Principles as accurately as I could was challenging work. I spent many hours writing, rewriting, and discarding them, and I consulted numerous people in the process. After a lot of consideration, I ended up with five value statements, supported by eleven detailed principles.”

The first draft of the Values & Principles was announced to the community at DrupalCon Nashville.

What’s next?

Now that we have the first release of the Values & Principles, we need a process to assist and advise Dries as he updates the Values & Principles. After hearing community feedback, Dries will charter a committee to serve this role. A forthcoming blog post will describe the committee and its charter in more detail.

Community Governance What’s happened?

At DrupalCon Nashville, many useful discussions happened on governance structure and processes.

  • A Drupal Association Board Meeting, with invited community members, met to talk with existing governance groups to find out what is working and not working. We realized that governance of the Drupal Community is large and it is difficult to understand all of the parts. We began to see here a possibility for further action.

  • The Community Conversation, “Governance Retrospective”, helped us to see that improving communications throughout the community is hugely important.

  • The Round Table Discussion, around community governance, brought together Dries, staff of the Drupal Association and Drupal Association Board, representatives of many of our current community working groups, representatives of other interested groups in the community and other community members. This group looked at both Values & Principles but also looked into how we are currently governed as a community and how can improve that.

All these things lead to one of the very best things of the DrupalCon experience; the “hallway track”. More and more throughout DrupalCon Nashville, ideas were formed and people stepped forward to communicate with each other, about how we can improve our governance. This happens all the time when we discuss the code of Drupal; I’m very excited to see it happening in other aspects of our project, too.

What’s next?

A structured approach is needed to ensure all in our community understand how decisions are being made and could have input. Speaking with a number of those involved in many of the discussions above, a consensus developed that we can start putting something into action to address the issues raised. Dries, as Project Lead, has agreed that:

  • A small Governance Task Force would be created for a fixed period of time to work on and propose the following:

    • What groups form the governance of the Drupal community right now?

    • What changes could be made to governance of the Drupal community?

    • How we could improve communication and issue escalation between groups in the community?

  • Task Force membership would be made up of a small group consisting of:

    • Adam Bergstein

    • David Hernandez

    • Megan Sanicki

    • Rachel Lawson

  • This Task Force would discuss whether or not it is beneficial to form a more permanent Governance Working Group, to handle escalated issues from other Working Groups that can be handled without escalation to the Project Lead.

  • This Task Force will propose a structure, processes needed to run this new structure, charters, etc. by end of July 2018 to the Project Lead for approval.

The Governance Task Force begins work immediately. The Charter under which we will work is attached.

I will help to facilitate reporting back regularly as we progress. I look forward to 2018 showing progress on both of these initiatives.

I am, as always, very happy to chat through things - please say hello!

File attachments:  Governance Task Force Charter.pdf
Categories: Drupal

Paragraphs Class

New Drupal Modules - 14 May 2018 - 6:43am
Overview

The Paragraphs Class module adds a Paragraphs Behaviors field "CSS class" onto paragraph items. This allows a content manager add specific CSS class to any specific paragraphs using UI.

Paragraphs Class module works only with Paragraphs EXPERIMENTAL Widget.

Requirements
Categories: Drupal

Custom List

New Drupal Modules - 14 May 2018 - 6:19am
Categories: Drupal

OpenSense Labs: Drupal and GDPR: Everything You Need to Know

Planet Drupal - 14 May 2018 - 5:41am
Drupal and GDPR: Everything You Need to Know Akshita Mon, 05/14/2018 - 18:11

A lot has been written in and around the EU’s new data privacy compliance - General Data Protection Regulation. As we near 25th May, the search around GDPR compliance is breaking the internet. 

Categories: Drupal

Azure Entity Moderation

New Drupal Modules - 14 May 2018 - 5:11am

Provides automatic entity moderation field that uses Azure Text Analytics API to fetch results of sentiment analysis for the selected entity fields and display the analysis result s using 3 different possible formatters:

Categories: Drupal

ComputerMinds.co.uk: Got a config schema error on saving a view?

Planet Drupal - 14 May 2018 - 4:15am

We ran into an obscure error recently, when saving a view that used a custom views plugin. It was supposed to be a very simple extension to core's bundle (content type) filter:

InvalidArgumentException: The configuration property display.default.display_options.filters.bundle.value.article doesn't exist. in Drupal\Core\Config\Schema\ArrayElement->get() (line 76 of [...]/core/lib/Drupal/Core/Config/Schema/ArrayElement.php).

Several contrib projects ran into this issue too: Drupal Commerce, Search API and Webform Views integration. There's even a core issue that looked relevant... but it turned out to be a simple, if perhaps surprising fix. If you ever run into it, it will have a different property (i.e. due to whichever plugin or default value are used).

Our filter was little more than a simple subclass of \Drupal\views\Plugin\views\filter\Bundle, declared for a specific entity type in a very ordinary hook_views_data() (which had even been autogenerated by Drupal Console, so we were fairly confident the problem wasn't there). It just tailored the options form a little to work well for the entity type.

Views plugins all have their own configuration schema - for example, the bundle filter is declared in views.filter.schema.yml to use the 'in_operator', because multiple bundles can be selected for it. When we subclass such a plugin, we do not automatically get to inherit the configuration schema (as that is not part of the PHP class or even its annotation). (Perhaps core could be 'fixed' to recognise this situation ... but there are more important things to work on!)

The solution is to simply copy the schema from the plugin we've extended - in our case, that was 'views.filter.bundle', found in core's 'views.filter.schema.yml' file within views' config/schema sub-directory. Wherever it is, it's probably named 'views.PLUGIN.ID', where 'PLUGIN' is the type of your plugin (e.g. field, filter, area), and 'ID' is the ID in the class annotation of the class your plugin extends. We pasted the schema into our own schema file - which can be named something like /config/schema/mymodule.schema.yml, within our module's directory:

# Replace 'mymodule_special_type' with the ID in your plugin's annotation. views.filter.mymodule_special_type: type: views.filter.in_operator label: 'Customised type selector'

Once that file is in place correctly, I expect you just need to rebuild caches and/or the container for Drupal to happy again. Re-save the form, the error is gone :-)

Configuration schemas should normally help development by catching errors, but as I've written before, an incorrect schema can make things surprisingly difficult. I hope someone else finds this article solves their problem so it doesn't take them as long to figure out! I haven't used it, but it's possible that the Configuration inspector project could help you identify issues otherwise.

Categories: Drupal

Amazee Labs: Progressive Decoupling 2: A How To Guide

Planet Drupal - 14 May 2018 - 3:52am
Progressive Decoupling 2: A How To Guide

In this series we take a closer look at progressive decoupling in Drupal 8. We go through the project setup, check the tools and libraries and discuss potential applications. The first post of the series showed some new features that made it into JavaScript in the last few years. This time let’s see how to use it in a project.

Blazej Owczarczyk Mon, 05/14/2018 - 12:52

JavaScript transpilation has been added to Drupal core in 8.4.0. The Core JS contribution workflow has been described in the change record Drupal core now using ES6 for JavaScript development. Unfortunately, the scripts mentioned there cannot be used to transpile contrib code yet. There’s an ongoing discussion about that in Use ES6 for contrib and custom JavaScript development. So we need to wait for that to be solved, right?

Not really. It turns out that it is enough to place the package.json file from core/ two levels up in the directory tree (in case of a composer project) and adjust paths to scripts to enjoy modern JS in contrib and custom code. With this file in the repository root we can run

to install dependencies, and we’re good to go with ES6.

will start the watcher, which monitors all .es6.js files and transpiles them to their .js counterparts whenever a change is detected.

The scripts can be invoked in one of 4 ways

To commit or not to commit?

Is it fine to commit the output (.js) files? That depends on the nature of the code. If it’s a contrib module / theme it’s best to do so. Target users shouldn’t be forced to transpile themselves and the build process of Drupal modules is not adjustable at the time off writing this post.

Source maps

Contrib modules would most likely provide just the optimized code (without source maps). The committed source .es6.js files can be used to overwrite the output files with dev features enabled for individual environments if needed.

Custom code

The choice here depends on the hosting platform. If it supports adjusting the build process based on the environment, then the .js files don’t have to be committed at all. The source files are enough and the compilation can be done before each deployment. Source maps can be used for dev and prod should get the optimized build. This is how it looks like in an .amazee.io.yml file for instance:

As with every artifact, ruling out the compiled versions of js files from the repository makes the development process smoother, mainly by reducing conflicts. On the other hand, it doesn’t have to be a big problem if the team is small enough.

Example

Here’s a recipe for adding an example ES6 library to a theme.

  1. Add this package.json file the root of your project
  2. Install dependencies
  3. Start the file watcher
  4. Add a library definition to package_name.libraries.yml in your module or theme.
  5. Create the index file (js/mylib/index.es6.js)
  6. Save the file and check the terminal window with the file watcher, js/mylib/index.es6.js should be mentioned there and the compiled version - index.js - should be created next to the source file. The library is now ready to be used in a module or theme.

    That’s it for setting up ES6 in a project. In the next post we’ll take a look at polyfills, talk about the fetch API and a see how to use async functions - the undeniable game changer from ES8.

    If you want to learn more about Drupal libraries check these out

    Categories: Drupal

    Components Extras

    New Drupal Modules - 14 May 2018 - 2:25am

    Provides a Drupal 8 render element to use Twig components (from the Components module) in render arrays.

    Categories: Drupal

    Amazee Labs: Amazeenar #1 - GraphQL & Twig

    Planet Drupal - 13 May 2018 - 11:57pm
    Amazeenar #1 - GraphQL & Twig

    “Absolutely incredible!” - just one quote from our first Amazeenar in which we explore the power of GraphQL Twig. Decoupling Drupal is the future, however, it may be a big leap to learn a whole new development stack. With GraphQL Twig, we can take baby steps with a soft-decoupled approach by writing GraphQL inside our Twig templates.

    Daniel Lemon Mon, 05/14/2018 - 08:57

    On Friday 11th May, Amazee Labs hosted its first Amazeenar - a live video training session presented by Philipp Melab who demonstrated some of the capabilities of GraphQL with the Drupal module GraphQL Twig.

    We started the webinar while a crowd joined live from over 13 countries around the world, including Belgium, Brazil, Canada, South Africa, and as far east as Thailand.

    It felt exciting to have a community of enthusiastic people connecting from so many different locations across the globe. This once again reinforced that Drupal is really about coming for the code and staying for the community.

    Philipp dove into the talk by giving us a quick introduction to GraphQL, with an example query for us to better understand the concept:

    query { node:nodeById(id: "1") { title:entityLabel related:relatedNodes { title:entityLabel } } }

    Running this example GraphQL query would give us the following JSON response:

    { “node”: { “title”: “Article A”, “related” { { “title”: “Article B” }, { “title”: “Article C” } } } }

    Inversion of control

    Philipp then explained the need for decoupling, providing us with a good overview of the fundamental differences between standard Drupal and Decoupled Drupal, in which the control moves from a push approach to a pull approach.

    React is great, but the inversion of control is crucial.

    Enable the template to define its data requirements, allow's us to achieve a clear data flow with significantly increased readability and maintainability. The GraphQL Twig module allows us to add GraphQL queries to any Twig template, which is then processed during rendering and used to populate the template with data.

    Philipp entertained the audience with a live working demo in which, together, we learnt how to enhance the default “powered by Drupal” block to pull in the username of user 1. He then blew our minds with an additional surprise - pulling in the current number of open bug issues for Drupal Core via the GraphQL XML submodule.

    Catchup

    Did you miss the webinar? Don’t fret; we recorded everything!

    Amazee Labs would like to thank everyone who attended the live session, we enjoyed being able to share this with you, and we look forward to hosting another Amazeenar shortly.

    Categories: Drupal

    HTTP client error status

    New Drupal Modules - 13 May 2018 - 1:03pm

    Provides a Condition plugin, checking the status code for 401, 403 and 404 client errors. This can be used by any modules that use the Condition plugins, such as core Block system.

    One simple use case would be to display a block on a 403 or 404 Page.

    Categories: Drupal

    Content Translation Redirect

    New Drupal Modules - 13 May 2018 - 9:12am

    This module will be useful if you need to redirect users from pages of non-existent translations of the content entity to a page with the original language.

    It is important that the user will be redirected only if the entity translation URL is different from the entity URL in the original language. Also, do not forget that the entity must be translatable.

    Categories: Drupal

    ThinkShout: Preparing for the GDPR

    Planet Drupal - 13 May 2018 - 5:00am
    “We’ve recently updated our privacy policy.”

    If you’ve ever given your email address to an online store, entity, social media platform or done just about anything online, then you’ve probably received the above notice in your inbox from those entities with increasing regularity over the last month or two.

    Most of these notices are related to the European Union’s General Data Protection Regulations (GDPR) that are going into effect later this month on May 25, 2018.

    To be clear, we at ThinkShout are not lawyers and we strongly encourage our clients and anyone collecting user information in some way, shape, or form to seek legal counsel for your own specific obligations related to the GDPR. Here’s how we’re viewing the regulations and what actions we are taking at ThinkShout.

    The big picture

    The regulations apply specifically to organizations that collect or process data associated with EU citizens. The overall intent is to give EU citizens control over how their own data is collected and used. The stick that’s being wielded to enforce the regulations is the possibility of fines of up to €20 million or 4% of an organization’s global annual revenue (whichever is greater). Charitable organizations are not exempted from these penalties, however it’s likely that the steep fines will be for recurring or significant privacy issues and that the focus will be on fixing any issues that are discovered. There are questions about enforceability (particularly in the USA) that will likely need to be settled in court, but many of the regulations reflect smart privacy practices regardless of the penalties. All the chatter and hand wringing about the GDPR has led to a fast growing industry of businesses offering compliance audits, consulting and technical solutions to the regulations. Some of the vendors offering these services are legitimate, while many are simply designed to sell products or services based on embellished fears.

    The principles of the GDPR can be broadly summed up as protecting personal data by allowing individuals to choose what data they allow to be collected, how that data is used or processed, and gives them control over that data even after it’s been collected. The UK’s Information Commissioner’s Office provides an easy to read guide to the GDPR that goes into detail on the various provisions while the EU provides a more graphical explanation. That last link might be more palatable for the visual learners reading this.

    Portion of the EU’s graphical explanation of GDPR - full explanation can be found here.

    Does the GDPR apply to you and your users?

    In short, probably. While compliance is technically only needed when handling data for EU citizens, discerning who is and isn’t a EU citizen can be difficult, and compliance in many cases isn’t all that cumbersome.

    Documentation and communication are two of the key areas of responsibility.

    Start with an audit of the data you collect from users, the data you collect from other sources and what is done with that data. Note that this isn’t just about new data but also any data already in your various systems (website, Salesforce, spreadsheets, etc.). Once you know what user information you have and why you have it, communicate that information to both your staff and your users by updating your privacy notices, and emailing constituents with that now famous subject line, “We’ve recently updated our privacy policy.”

    Document how your data handling processes are shared with new staff. It’s also a good idea to revise privacy policies written by lawyers to be “concise, transparent, intelligible and easily accessible” and should further be “written in clear plain language.”

    Here’s an example of good privacy notices and requests for consent.

    Basically, ensure that the general population (who did not attend law school) can easily understand the language.

    Processing must be allowed under a lawful basis.

    Any processing of personal data must be supported by both the need to process that data as well as a lawful basis. Out of the eight lawful bases that the GDPR defines, consent, legal obligation and legitimate interest appear to be the most likely to be cited in the work of our clients. For consent to apply, it must be active (opt-in), current, specific and revocable.

    Legal obligation covers data needed for accounting or other legal audit trails. Legitimate interest is less defined, but addresses situations where the usage of the data can be reasonably expected, has minimal privacy impact and there is strong justification for the processing of the data. Using a user’s email address on an account they created to send them a link to reset their password might be an example of legitimate interest as a lawful basis.

    Individuals have defined rights to the protection and usage of their data.
    1. The right to be informed: privacy notices, accurate opt-in information, etc.
    2. The right of access: ability to see any data you have on an individual.
    3. The right to rectification: ability to correct any errors in the data you have - allowing users to update their own profiles covers much of this right.
    4. The right to erasure: ability to request data be removed. This is not all encompassing, nor does it need to be automated. Data needed for legal or other legitimate needs can be retained.
    5. The right to restrict processing: ability to request that their data not be processed but also not deleted.
    6. The right to data portability: ability to request a machine readable export of their data.
    7. The right to object: ability to opt out of marketing, processing based on legitimate interest or processing for research or statistical purposes. The process for opting out must be clearly explained in the privacy notice and at the point of first communication.
    8. Rights in relation to automated decision making and profiling: If you collect data to profile individuals for behavior tracking or marketing purposes then additional regulations apply.
    What about cookies?

    Cookies aren’t specifically called out in the GDPR, however some of the provisions can apply to them. Some experts recommend altering the site behavior to prevent cookies from being created until after the user has provided and the site has recorded consent. Several services seek to provide paid services that support this approach, although altering the code on your site is generally necessary to use them correctly. A few Drupal modules and WordPress plugins also seek to provide this functionality. It is expected that in 2019 the revised e-Privacy Directive will shift some or all of the obligations for managing consent related to cookies to the browser application.

    Recommendations

    We’re recommending that all our clients take the following steps to ensure compliance:

    • Evaluate your organization’s legal needs related to the GDPR. Consulting with your own counsel is recommended.
    • Appoint an internal person to take responsibility for data protection in your organization. While the GDPR includes provisions for appointing a Data Protection Officer (DPO), it’s specifically for public authorities and organizations whose core business is tracking behavior or processing criminal data. Appointing a staff person will help avoid a diffusion of responsibility regarding data security.
    • Audit your data collection and processing (here’s a sample template):
      • What is being held already and what is being collected?
      • Is there data being collected or stored that isn’t needed?
      • How is the collected data is used within the organization?
      • Is there a legal basis for the different pieces of personal data being collected?
      • If consent is the legal basis, is the consent active (opt-in), granular and recent?
    • Review and revise privacy notices and cookie policies to be clearly written and comprehensive. Be sure to include information about third-party data collection (Google Analytics, AddThis, Facebook, etc). Here’s a privacy notice checklist to get you started.
    • Document processes for handling user requests as well as security breaches. Your organization has a month to respond to an individual’s request for export, access, or deletion of their data. In most cases this will currently be a manual process although there is working happening in both the Drupal and WordPress communities to make these request easier to accommodate. If there is a data breach, the GDPR states that the regulating agency must be notified within 72-hours. A good starting point is the Security Breach Response Plan Toolkit.
    • Evaluate if changes to your website (beyond the privacy/cookie notices) are necessary. Consider specifically:
      • Is Google Analytics configured properly? Ensure IP anonymization is enabled, data retention settings are correct and that no personal information is being tracked (check page urls, titles, etc.).
      • What third-party scripts or pixel trackers are included?
      • How is consent being collected in newsletter signup forms?
      • How is consent being collected in user registration forms?
      • Any other places that user data could be collected?
    What’s next for us?

    Like most agencies, we’re continuing to learn more about the GDPR and the implications for our clients. We are working in partnership with them to help them understand and implement changes that might be needed on their sites or their internal processes. Internally we’re providing additional training on the principles of privacy by design to our team. In terms of our open source work we’ll be incorporating MailChimp’s GDPR consent forms into the Drupal MailChimp modules as soon as the functionality is available in their API. We see opportunities for including functionality related to subject access requests (export, deletion, etc) and consent tracking in our RedHen CRM suite of modules as well.

    Bottom line is: this is something we all need to be cognizant of; it’s not solely an EU issue. We’ll continue to keep a close eye on this as GDPR gets rolled out – and there are many resources out there at your disposal (and within this blog post). You can be sure to get the latest from us on this and other digital trends by signing up for our newsletter and following us on twitter. Good luck!

    Categories: Drupal

    CiviCRM User

    New Drupal Modules - 13 May 2018 - 3:40am

    Operations on Drupal User entities based on a CiviCRM data source. Useful when the process of creating users is not delegated to Drupal (existing CiviCRM Contacts, frontend User registration disabled, ...).

    Creates, updates or blocks Drupal Users from CiviCRM Contacts.

    These operations are optionally based on a condition that can be

    • a CiviCRM Tag applied to the Contact (e.g. "Has a Drupal user account")
    • a CiviCRM Group.
    Categories: Drupal

    Pages

    Subscribe to As If Productions aggregator - Drupal