How to stay out of SPAM folder? Setting up PTR, SPF, DKIM under Exim Submitted by admin on Sat, 11/11/2017 - 23:39

In the previous article, we covered teaching your Drupal installation to send mail to users. But that is only half the battle, now we need to make sure the mail we send hits Inbox and not Spam folder. This article describes some options you have that offer relevant solutions. Unfortunately, no one can guarantee 100% inbox hits, but keeping the amount of mail filtered to Spam to a minimum is quite possible.

Tags

• Drupal Planet

I am pleased to announce that Francesco Placella (plach) has accepted our invitation to be a Drupal 8 provisional framework manager.

Based in Venice, Italy, Francesco has been contributing to core since 2009. During the Drupal 7 lifecycle he was mainly active in the multilingual area, revamping the language negotiation and content translation subsystems. His initial contributions were really well received:

As well as some great progress on the code front, another major success of the virtual sprint was bringing in some significant new contributors. A highlight here would be Francesco Placella, who is playing a lead role in the work on translatable fields. [...] Drupal needs more contributors like Francesco, and if this sprint has helped him find his place in Drupal development that in itself is a major gain for the community.

After being appointed a maintainer for Drupal core's Language system and the Content translation module, Francesco joined the Drupal 8 Multilingual Initiative, soon becoming one of its most active contributors. Mainly focused on the content translation aspects, he gradually became heavily involved in the entity and field systems, with foundational work on the form and storage subsystems.

Francesco was also very active in the Drupal 8 Accelerate program, which had the goal of fixing all the outstanding critical bugs that were blocking the release of Drupal 8.0.0. This gave him the opportunity to expand his activity also in many other areas, with a particular focus on Views performance. Drupal 8.0.0 was eventually released and Francesco took a break to look after his newborn son.

Francesco showed up again at DrupalCon Vienna and we thought it would be a good time to ask him to become a framework manager. He gladly accepted, so please join me in welcoming him to the core committer team.

Drupal developers have been shouting node id numbers across tables at sprints for almost 15 years now. The Drupal Association has added some shortcuts and friendly urls for issues to make this a little easier.

Shortcuts

The first shortcut we added is a searchbar feature. If you enter any node id in the search bar you'll be automatically redirected to that node. This works for more than just issues!

The second shortcut we added is a quick url pattern for finding issues. If you know your node id, just type:

https://drupal.org/i/<node-id>

 and you're there!

Friendly-Urls

We've implemented a new friendly url pattern on Drupal.org to make the canonical urls more sensible and search engine friendly.

Project pages: https://drupal.org/project/drupal

Issue Queue: https://drupal.org/project/issues/drupal

Specific Issue: https://drupal.org/project/issues/drupal/2922626

This new pattern should be backfilled to all issues by the beginning of next week.

And of course, if you have old bookmarks linked, you can still get there by going to: https://drupal.org/node/<node-id>

These are small, but powerful improvements that should make the lives of everyone who contributes to the Drupal project easier.

This blog has been re-posted with permission from Dries Buytaert's blog. Please leave your comments on the original post.

In my blog post, "A plan for media management in Drupal 8", I talked about some of the challenges with media in Drupal, the hopes of end users of Drupal, and the plan that the team working on the Media Initiative was targeting for future versions of Drupal 8. That blog post is one year old today. Since that time we released both Drupal 8.3 and Drupal 8.4, and Drupal 8.5 development is in full swing. In other words, it's time for an update on this initiative's progress and next steps.

8.4: a Media API in core

Drupal 8.4 introduced a new Media API to core. For site builders, this means that Drupal 8.4 ships with the new Media module (albeit still hidden from the UI, pending necessary user experience improvements), which is an adaptation of the contributed Media Entity module. The new Media module provides a "base media entity". Having a "base media entity" means that all media assets — local images, PDF documents, YouTube videos, tweets, and so on — are revisable, extendable (fieldable), translatable and much more. It allows all media to be treated in a common way, regardless of where the media resource itself is stored. For end users, this translates into a more cohesive content authoring experience; you can use consistent tools for managing images, videos, and other media rather than different interfaces for each media type.

8.4+: porting contributed modules to the new Media API

The contributed Media Entity module was a "foundational module" used by a large number of other contributed modules. It enables Drupal to integrate with Pinterest, Vimeo, Instagram, Twitter and much more. The next step is for all of these modules to adopt the new Media module in core. The required changes are laid out in the API change record, and typically only require a couple of hours to complete. The sooner these modules are updated, the sooner Drupal's rich media ecosystem can start benefitting from the new API in Drupal core. This is a great opportunity for intermediate contributors to pitch in.

8.5+: add support for remote video in core

As proof of the power of the new Media API, the team is hoping to bring in support for remote video using the oEmbed format. This allows content authors to easily add e.g. YouTube videos to their posts. This has been a long-standing gap in Drupal's out-of-the-box media and asset handling, and would be a nice win.

8.6+: a Media Library in core

The top two requested features for the content creator persona are richer image and media integration and digital asset management.

The results of the State of Drupal 2016 survey show the importance of the Media Initiative for content authors.

With a Media Library content authors can select pre-existing media from a library and easily embed it in their posts. Having a Media Library in core would be very impactful for content authors as it helps with both these feature requests.

During the 8.4 development cycle, a lot of great work was done to prototype the Media Library discussed in my previous Media Initiative blog post. I was able to show that progress in my DrupalCon Vienna keynote:

The Media Library work uses the new Media API in core. Now that the new Media API landed in Drupal 8.4 we can start focusing more on the Media Library. Due to bandwidth constraints, we don't think the Media Library will be ready in time for the Drupal 8.5 release. If you want to help contribute time or funding to the development of the Media Library, have a look at the roadmap of the Media Initiative or let me know and I'll get you in touch with the team behind the Media Initiative.

Special thanks to Angie Byron for contributions to this blog post and to Janez Urevc, Sean Blommaert, Marcos Cano Miranda, Adam G-H and Gábor Hojtsy for their feedback during the writing process.

In my blog post, "A plan for media management in Drupal 8", I talked about some of the challenges with media in Drupal, the hopes of end users of Drupal, and the plan that the team working on the Media Initiative was targeting for future versions of Drupal 8. That blog post is one year old today. Since that time we released both Drupal 8.3 and Drupal 8.4, and Drupal 8.5 development is in full swing. In other words, it's time for an update on this initiative's progress and next steps.

8.4: a Media API in core

Drupal 8.4 introduced a new Media API to core. For site builders, this means that Drupal 8.4 ships with the new Media module (albeit still hidden from the UI, pending necessary user experience improvements), which is an adaptation of the contributed Media Entity module. The new Media module provides a "base media entity". Having a "base media entity" means that all media assets — local images, PDF documents, YouTube videos, tweets, and so on — are revisable, extendable (fieldable), translatable and much more. It allows all media to be treated in a common way, regardless of where the media resource itself is stored. For end users, this translates into a more cohesive content authoring experience; you can use consistent tools for managing images, videos, and other media rather than different interfaces for each media type.

8.4+: porting contributed modules to the new Media API

The contributed Media Entity module was a "foundational module" used by a large number of other contributed modules. It enables Drupal to integrate with Pinterest, Vimeo, Instagram, Twitter and much more. The next step is for all of these modules to adopt the new Media module in core. The required changes are laid out in the API change record, and typically only require a couple of hours to complete. The sooner these modules are updated, the sooner Drupal's rich media ecosystem can start benefitting from the new API in Drupal core. This is a great opportunity for intermediate contributors to pitch in.

8.5+: add support for remote video in core

As proof of the power of the new Media API, the team is hoping to bring in support for remote video using the oEmbed format. This allows content authors to easily add e.g. YouTube videos to their posts. This has been a long-standing gap in Drupal's out-of-the-box media and asset handling, and would be a nice win.

8.6+: a Media Library in core

The top two requested features for the content creator persona are richer image and media integration and digital asset management.

The results of the State of Drupal 2016 survey show the importance of the Media Initiative for content authors.

With a Media Library content authors can select pre-existing media from a library and easily embed it in their posts. Having a Media Library in core would be very impactful for content authors as it helps with both these feature requests.

During the 8.4 development cycle, a lot of great work was done to prototype the Media Library discussed in my previous Media Initiative blog post. I was able to show that progress in my DrupalCon Vienna keynote:

The Media Library work uses the new Media API in core. Now that the new Media API landed in Drupal 8.4 we can start focusing more on the Media Library. Due to bandwidth constraints, we don't think the Media Library will be ready in time for the Drupal 8.5 release. If you want to help contribute time or funding to the development of the Media Library, have a look at the roadmap of the Media Initiative or let me know and I'll get you in touch with the team behind the Media Initiative.

Special thanks to Angie Byron for contributions to this blog post and to Janez Urevc, Sean Blommaert, Marcos Cano Miranda, Adam G-H and Gábor Hojtsy for their feedback during the writing process.

I always look forward to unconferences. It’s their unpredictability and element of surprise that I enjoy, you never quite know what the day will bring. I love the edgy feel, the lower barrier to entry, and that it’s OK to fluff your words or try something new. Sensing the nerves of the ones who unexpectedly present for the first time, witnessing how energising their experience is, discovering a topic or theme for the first time, or taking the mic because you feel inspired by others are all reasons I’m drawn to attend and why CTI Digital was proud to be one of the sponsors.

The North West Drupal User Group Unconference last weekend was no exception in terms of inclusivity and our Drupal team were there in force.

Drupal Website Accessibility, Part 1: The problem, and why it matters… Drupal Website Accessibility, Part 1: The problem, and why it matters… "The power of the Web is in its universality.  Access by everyone regardless of disability is an essential aspect." - Sir Tim Berners-Lee, W3C, Director and Inventor of the World Wide Web In the coming weeks, I’ll be taking a look into one...

This article was originally posted on the Capgemini Engineering blog

There's a certain inescapable truth that people who work with technology need to face. As time goes by, the knowledge we’ve gained almost inevitably becomes obsolete. If we specialise in something, how do we deal with the fact that our specialism, which may even have been cutting edge technology that we were pioneering, eventually becomes a legacy system? As Ellen Ullman put it, "The corollary of constant change is ignorance ... we computer experts barely know what we are doing."

Front end developers are very familiar with this feeling, confronted so frequently with the dizzying pace of change in the world of JavaScript frameworks. Once upon a time, I was very proud of my ability to make CSS layouts work in IE7. Now all those tricks and hacks are little more than worthless trivia, perhaps less valuable than actual trivia. At least knowing who scored the winner in the 1973 FA Cup final might help in a pub quiz - I can't imagine that being able to prefix properties with an asterisk will ever come in handy, but it's taking up storage space in my brain. Now that CSS grid is becoming widespread, everything I've learned about floats (and even flexbox) is becoming less and less useful. There are even some people (although I'm not one of them) who would say that CSS itself no longer has value. Similarly, jQuery is already on its way to joining YUI and MooTools in the graveyard of things I used to know about, and experienced members of the Drupal community have recently been coming to terms with the fact that in order for the technology to progress, we'll have to unlearn some of our old ways.

It isn't just true for technology. London taxi drivers are finding that their hard-earned Knowledge is being made obsolete by satnav, and before too long, the skill of driving will itself have gone the way of basket weaving or being able to pilot a horse-drawn buggy - something that might still be interesting for the enthusiast, but isn’t relevant to most people’s lives.

Confronted with the unpleasant reality that our hard-learned skills are becoming outdated, what's the appropriate response? Do we follow the example of the Luddites and rage against the evolution of the machines? It's easy to fall victim to the sunk costs fallacy, and ego provides a strong temptation to hang on to our guru status, even if we're experts in an area that is no longer useful. If you're a big fish in a shrinking pond, you may need to be careful that your pond doesn't dry up entirely. Besides, do you really want to work on legacy systems? Having said that, if your legacy system is still mission-critical somewhere, and migrating away would be a big job, there's good money to be made - just ask the people working on COBOL.

I think there's a healthier way of looking at this. With the internet acting as a repository of knowledge, and calculators at our fingertips, education is evolving. There's no longer much value in memorising times tables, or knowing the date of the battle of Culloden. As my colleague Sarah Saunders has written, you're never too old to learn, but the value of learning things is greater than the value of the facts or skills that we learn - the meta-skill of learning is the really useful thing. Then again, I would say that, having done a philosophy degree.

For example, the time and effort I put into learning French and German at school doesn’t currently seem like a worthwhile investment, when I think about how frequently I use those languages. But I would never say that it was a waste of time. When I lived in Tokyo, having learned other languages definitely helped when it came to learning Japanese. Then again, these days I don’t often spend any time in Japan or with Japanese people, so the current value of that effort seems low. But do I regret spending that effort? Not a bit. It helped me to make the most of my life in Japan, and besides, it was interesting.

Two of the most compelling conference talks I've heard in the last few years touched on this theme from different directions. Andrew Clarke and Patrick Yua both emphasised the importance of focussing on the underlying principles, rather than chasing whatever the current new hotness might be. Designers and developers can learn something from Yves Saint Laurent: "Fashions fade, style is eternal".

We need to recognise that things will always keep changing. Perhaps we could help ourselves to acknowledge the impermanence of our skills by saying some kind of ceremonial goodbye to them. I have an absurd vision of a Viking funeral, where a blazing longboat sails away full of old O'Reilly books. We may not need to go that far, but we do need to remind ourselves that what we've learned has served us well, even if that knowledge is no longer directly applicable. A knowledge funeral could be an opportunity to mourn for the passing of a skill into obsolescence, and to celebrate the value of learning.

Image source: wikimedia

Tags:  learning development psychology Capgemini Drupal All tags

The Entity Class Formatter is a nifty little module which allows editors to place classes on to entities, allowing their look and feel to be altered in the theme layer or with other modules such as Look and Modifiers. It is now available for Drupal 8.

Entity Class Modifier is a humble little module, however, it does open up a lot of possibilities. The most obvious is to use the theme layer to provide styles for the class which has been applied. This makes it possible for the “designer” at design time to can some different styles to pick from. It is however, possible to use the module in a more flexible way and combine it with Modifiers and Looks.

Once a class has been defined and added to a field, a “Look Mapping” can be defined, associating the class with a set of Modifiers. The site builder or skilled editor can then go in and define any number of Modifiers which will be fired with the class.

For example - a “my-awesome-class” class could be created which is wired into a “field_my_awesome” set of Modifiers. The Modifiers could include a blue linear gradient with white text overlay with generous padding. All of this configuration happens in the UI after deploy. It is a very flexible and powerful system. The system can be configured after deployment and adapted to the styles you wish to apply.

Basic use of Entity Class Formatter

The use of the module is very easy. We can for example define our own class on the article.

The first thing we need to do is to enable the module. Once installation is complete we can go and add our custom field. In this little tutorial we will basically add the class onto the article content type. So go to Structure > Content types > Article > Manage fields and add new text field. We can name the field simply "Class" and save it. As we keep everything in default we can save it on the next page too.

 

Now the last thing we need to do to make it work is set the Entity Class on the field in Manage display page. Go to Structure > Content types > Article > Manage display and change the format to "Entity Class". There's no need to any other manipulation with field because it won't render any values which would be visible to the visitor of the page.

 

That's it! No we can go to create an article (Content > Add content > Article). Input class to our field...

... voila, class is there!

Similar but different

There are a couple of modules out there which are similar but are different enough for them not to be totally suited to our requirements.

Classy Paragraphs, available in Drupal 8, has been influential in the Paragraphs ecosystem and has opened the way for creative designs. It was intended to apply to Paragraphs only and is quite structured in the way classes are applied through a custom field type. The Entity Class Formatter module is more flexible in that it has been designed to apply to all entity types. It can also handle a variety of field types (text, select lists, entity references) and is able to adapt to the data at hand. So, Entity Class Formatter has a similar aim - it is just somewhat more generic.

Field Formatter CSS Class, available in Drupal 7, also uses a field formatter approach to applying the class to the entity. It does have more complexity than this module because it deals with several layers of nesting. The Entity Class Formatter is very simple and only applies to the parent entity of the field.

Entity Class Formatter was inspired by Classy Paragraphs (thanks) and is supported by the team at Morpht.

Nowadays business in a complex and dynamic environment. Because of its uncertainness, it's never too late to listen to a good lecture. If you have missed any session from DrupalCon Vienna, let us highlight some of them to you.    Co-operative Drupal: Growth & Sustainability through Worker Ownership Finn Lewis, Technical Director of Agile Collective Ltd   There is an increasing number of worker-owned Drupal companies. So there are more and more sectors looking for effective and customizable software solutions, so it's a good time to start or grow Drupal's business, which is not… READ MORE

Ah, the config system. Crown jewel of Drupal 8, amirite?

Well, yeah, it’s fantastic and flexible (as is most of Drupal). But if you have advanced use cases — such as building a system that alters config dynamically — there are traps you should know about.

Tags: acquia drupal planet

BADCamp is a delightful mix of networking and educational opportunities. Along with connecting with former acquaintances and meeting new people, I attended two really informative trainings. Here’s my recap:

Optional config weirdness in Drupal 8 phenaproxima Thu, 11/09/2017 - 12:55

This post was originally published on Medium.

Ah, the config system. Crown jewel of Drupal 8, amirite?

Well, yeah, it’s fantastic and flexible (as is most of Drupal). But if you have advanced use cases — such as building a system that alters config dynamically — there are traps you should know about.

Config is normally a fairly static thing. Your module/theme/profile (“extension” from here on out) has some configuration in its config/install sub-directory, and when the extension is installed, that config is imported. Once it’s imported, that config is owned by your site and you can change it in any way you see fit.

That’s the simplest, and most common, use case in a nutshell. Let’s talk about some other ones.

Optional config

In some extensions’ config directory, you will see an ‘optional’ directory alongside ‘install’. If you look in there, you see…some YAML files. What’s all this, then?

Optional config is normal config, but it’s treated differently. When an extension is installed, each piece of optional config it provides is analyzed, then imported only if all of its dependencies are fulfilled. A piece of config can declare, for example, that it depends on a view called ‘content’. That’d be expressed thusly in code:

dependencies:
  config:
    - views.view.content

If that piece of config is optional, then it will only be imported if, well, a view called ‘content’ exists in the system. That view might have been shipped with another extension, or maybe you created it manually. It makes no difference. As long as a view called ‘content’ is present, any optional config that depends on it will be imported as well.

Neat, yes? This comes in quite handy for something like Lightning, which allows you to create an install profile which “extends” Lightning, yet only installs some of Lightning’s components. Optional config allows us to ship config that might be imported, depending on what parts of Lightning you have chosen to install. Hooray for flexibility!

Optional config whilst installing Drupal

But wait, there’s more.

When you’re doing a full site installation (i.e., install.php or drush site-install), optional config is treated a little bit differently. In such a case, all extensions are installed as normal, but their optional config is ignored initially. Then, at the end of the installation process1, once all extensions are installed (and their default config has been imported), all2 the optional config is imported in a single batch.

I don’t think this is documented anywhere, but it can have major ramifications. Consider this piece of code — let’s say it’s part of a module called fubar, which provides some default config and some optional config. This hook will be invoked while fubar is being installed, but after its default config has been imported:

<?php
/**
 * Implements hook_install().
 */
function fubar_install() {
  $view = entity_load('view', 'fubar_view');
  $view->setDescription('The force will be with you, always.');
  $view->save();
}

fubar_view is optional config, so will entity_load() return a view entity, or will it return NULL? What do you think?

The maddening answer is it depends. It depends on when fubar is being installed. If Drupal is already installed, and you’re just adding fubar to your site, then $view will be a view entity, because the optional config will be imported before hook_install() is invoked. But if you’re installing fubar as part of a full site install — as part of an installation profile, say — $view is going to be NULL, because optional config is imported in a single batch at the end of the installation process, long after all hook_install() implementations have been invoked.

Yeah, it’s a WTF, but it’s a justifiable one: trying to resolve the dependencies of optional config during Drupal’s install process would probably have been a colossal, NP-complete nightmare.

Dynamically altering optional config

So let’s say you need to make dynamic alterations to optional config. You can’t do it in hook_install(), because you can’t be sure that the config will even exist in there. How can you do it?

The easiest thing is not to make assumptions about when the config will be available, but simply react when it is. If the optional config you’re trying to alter is an entity of some sort, then you can simply use entity hooks! Continuing our fubar example, you could add this to fubar.module:

<?php

use Drupal\views\ViewEntityInterface;

/**
 * Implements hook_ENTITY_TYPE_presave().
 */
function fubar_view_presave(ViewEntityInterface $view) {
  if ($view->isNew() && $view->id() == 'fubar_view') {
    $view->setDescription('Do, or do not. There is no try.');
  }
}

This ensures that fubar_view will contain timeless Yoda wisdom, regardless of whether fubar_view was imported while installing Drupal. If fubar_view is created at the end of the installation process, no problem — the hook will catch it and set the description. On the other hand, if fubar_view is installed during drush pm-enable fubar, the hook will…catch it and set the description. It works either way. It’s fine to dynamically alter optional config, but don’t assume it will be available in hook_install(). Simply react to its life cycle as you would react to any other entity’s. Enjoy!

Moar things for your brain

• hook_install() can never assume the presence of optional config…but it can assume the presence of default config (i.e., the stuff in the config/install directories). That is always imported before hook_install() is invoked.
• In fact, you can never depend on the presence of optional config. That’s why it’s optional: it might exist, and it might not. That’s its nature! Remember this, and code defensively.
• The config_rewrite module, though useful, can throw a monkey wrench into this. Due to the way it works, it might create config entities, even optional ones, before hook_install() is invoked. Even during the Drupal installation process. Beware! (They are, however, working to fix this.)
• The config system is well-documented. Start here and here. This post is only one of tons of other blog posts about config in D8.
• This blog post came about because of this Lightning issue. So hats off to Messrs. mortenson and balsama.
• Thanks to dawehner for reviewing this post for technical accuracy.
• “NP-complete”, as I understand it, is CompSci-ese for “unbelievably hard to solve”. Linking to the Wikipedia article makes me seem smarter than I really am.

1 The reason this happens at the end is because any number of things could be changing during installation (who knows what evil lurks in hook_install()? Not even the Shadow knows), and and trying to solve multiple dependency chains while everything is changing around you is like trying to build multiple castles on a swamp. (Only one person has ever accomplished it.) Don't think about this stuff too much, or it will melt your brain.

2 “All”, in this case, means “all the optional config with fulfilled dependencies,” not all-all.

GraphQL for Drupalers - the basics

GraphQL is becoming more and more popular every day. Now that we have a beta release of the GraphQL module (mainly sponsored and developed by Amazee Labs) it's easy to turn Drupal into a first-class GraphQL server. This is the new GraphQL series in which we'll describe the features that are new in beta and provide a detailed overview of the integration with Drupal's entity and field systems.

Blazej Owczarczyk Thu, 11/09/2017 - 17:25

This is the new GraphQL series about the new features that are in beta (published 2 weeks ago) and how they are connected with Drupal out of the box

The modules

Let's start with the modules we need. Recently there were quite a few changes in this field. In alpha we had:

• graphql - The main module laying the foundations for exposing data using Drupal plugins.
• graphql_core - which exposed Drupal core data - the info about entity types and bundles, but not fields
• graphql_content - which handled field exposition with the view modes
• other auxiliary modules (e.g., graphql_boolean graphql_entity_reference) that provided behaviours for specific field types

In beta, the structure has changed. Now the default schema exposes all the Drupal fields and (content) entities in raw form, using the typed data. Thanks to that GraphQL became a zero-configuration plug and play module. We just need to enable graphql and graphql_core (the only two modules that are shipped with the package now) and we're good to go.

NOTE: The other modules are still available in case you need them, they're just not part of the core package anymore. graphql_legacy is where most of the field modules went. Besides that, there are graphql_views  which lets us expose views, the promising graphql_twig that allows using GraphQL queries without a decoupled setup and a few more. All of the modules are listed in the drupal-graphql organization page on GitHub.

The Explorer

After enabling graphql and graphql_core we can go ahead and test it with GraphiQL; an interactive tool that lets you run queries, see results in real time and preview all the available fields along with arguments and return types. It also provides query validation, autocompletes suggestions and keyboard shortcuts. Thus, it's a kind of an IDE. The explorer is connected with the schema. We can find it next to the Default Schema under: Configuration -> Web services -> GraphQL -> Schemas or using the direct path - graphql/explorer.

This is how it looks. On the left, there is a query box with a comment describing the tool and listing the keyboard shortcuts. Results show up in the box on the right. To run the query we can use the «play» button at the top, or the keyboard shortcut (Ctrl-Enter). One more important piece is the < Docs button in the upper right corner. This is where we can see all the available elements. Let's go ahead and click it.

The only thing we can start with is the query field which is of type RootQuery. Clicking on the type shows a list of available sub-fields, including userById, which looks like this:

This field takes two arguments: an id (which is a string) and a language (which can be set to any language enabled on the site) and is of type User. Clicking on the type brings up a list of fields on a user. The name is a string:

Strings are scalars (which means they don't have subfields) so we can finish our simple query here. It will look like this:

and (after running it with Ctrl-enter) the response is what we'd expect

The GraphQL explorer (or GraphiQL) gives us the ability to easily write and debug every GraphQL query. That's a feature that's hard to overestimate so getting familiar with it is a good starting point to understanding how GraphQL works in general and how we can get our Drupal data out of it.

The Voyager

Voyager is another schema introspection tool, a visual one this time. It draws a chart of all the types and field in the system and presents it in a nice way. It can be found next to The Explorer under: Configuration -> Web services -> GraphQL -> Schemas or using the direct path - graphql/voyager.

That's it for this post. In the next one, we'll see some examples of retrieving data from Drupal fields.

 

Want to customize the default block that comes with the book module?  Here’s a way to do it without writing custom code by using Views and the Views Tree module.

Read More

Planning for Drupal 9 and Beyond

Justin’s recent post about the product approach and Drupal's new release cycle got me thinking about what upgrading to Drupal 9 will really look like from a more technical standpoint. There's already lots of information out there explaining this new feature. I think there are some misconceptions about what it means for Drupal projects though, so let’s take a little look under the hood.

Background

To understand what the process of updating to Drupal 9 might look like, you'll need to know a few background terms. If you already know what "semver" and "deprecation" mean for a software project, you can skip ahead to "Preparing for Drupal 9".

Drupal now follows semantic versioning. Semantic versioning—semver for short—is a format for assigning numbers to releases. This number signals a promise about the compatibility and/or stability of a release. A semver tag has three parts, a major version number, a minor version number and a patch version number, all separated by periods. For example, a recent version of Drupal was tagged 8.4.0. For this release, the major version number was 8; the minor version number is 4; the patch number is 0. A common misconception is to think that after 8.0.9, one must have 8.1.0, but it’s perfectly acceptable to have a release number like 8.0.107.

What do major, minor and patch mean? We'll look at each from least to most significant.

A patch release signifies a fix.

They are usually composed of small, isolated fixes. When Drupal is on version 8.4.0 and releases version 8.4.1, this indicates that it is a patch release. It means, "nothing in your code needs to change, we just fixed some bugs". These might be security fixes, so you should update to these releases as soon as possible.

A minor release signifies new features and deprecations.

These are my favorite. They're the ones filled with all the sunshine and rainbows. A minor release adds new features and code to Drupal. This might mean an experimental module becomes stable as the Workflow module did in 8.4.0 or—my personal favorite—a new experimental module, like JSON API, might be added to Core. A minor release is an opportunity for Drupal's maintainers to clean things up, to keep Drupal fresh and to ensure Drupal keeps up with the needs of modern applications. It's also an opportunity to deprecate parts of Drupal Core. A deprecation is when a part of Drupal Core gets moved to the graveyard. It will be maintained for security fixes and bugs, but you shouldn't use that part of Drupal any more. It's usually an indication that there are new, better APIs or best-practices you should follow. A minor release says, "we've made things better, we've cleaned stuff up, and we didn't break your stuff yet."

The graveyard of deprecated APIs

A major release signifies incompatible changes.

They can be a cause for celebration or an ominous cloud on the horizon. They're a critical event in Drupal's lifecycle. A major release is a signal that says "Warning: Your Stuff Might Break!" In some software, it might mean you need to rebuild your project. In Drupal 8 and beyond, thankfully, this shouldn't be the case. The maintainers have made a promise that says, "if you're not using deprecated code, you can update without rebuilding." In the past, like from Drupal 6 to Drupal 7, that wasn't the case and things definitely broke.

Preparing for Drupal 9

So, you know what a deprecation is, and what a major version release means. You know that the promise of Drupal's new release cycle is "if you're not using deprecated code, you can update without breaking things." But did you catch the caveat? If you're not using deprecated code. It's here that I believe the most misconceptions lie. I believe that many have confused this promise to mean that projects can be updated to Drupal 9 without a hitch. That the upgrade will be relatively routine.

The truth is that it's really up to you to make it routine and not something to fear.

How you approach your Drupal software project means that this major event in Drupal's lifecycle can be either a midlife crisis or a coming-of-age.

I said earlier that all the sunshine and rainbows are in the minor version releases. That's because you get all the goodies for free. Underneath the hood though, you need to be aware of what's being deprecated. Every time something is deprecated, a little technical debt is added to your project. You should pay that debt as soon as possible. A deprecation is a warning that the code underneath is going to disappear in Drupal 9. It's a warning to module maintainers and project developers that they need to update code that relies upon that newly deprecated API.

This reality is another point in the product approach's favor, as we alluded to in our earlier post. By making an ongoing investment in your project, you can address these deprecations as they happen so that when you're ready to upgrade to Drupal 9, it will be as painless as any other update.

The Prettiest Rainbows Come After a Little Rain

A select few sites will be able to proudly announce their upgrades to Drupal 9 the day it's released or soon after. Many won’t be able to move so quickly.

Knowing that Drupal 9 will break things relying on deprecated code and knowing that many modules won’t have been updated ahead of the release (such is life in open source), many sites will have to be patient. How patient depends on whether they’ve made an ongoing investment in their platform and kept up with deprecations in their custom code. They’ll be able to upgrade even faster if they have been model citizens in the Drupal community by reporting—and hopefully fixing—contrib dependencies on deprecated code too.

So, is this just like every other major Drupal release? Absolutely not! Gone forever are the days of completely rebuilding your site with every major update. Gone are the days of needing to migrate your own content to your own site. What this means is that you’ll just have to sit inside and wait or go play in the rain, fixing some bugs and updating some outdated dependencies, before you get to enjoy the Drupal 9 rainbow.

Here are some helpful links to stay up to date with deprecations:

• Drupal Core documentation on what constitutes a deprecation.
• A super useful list of what's being added, changed and removed in Drupal Core. I check this regularly.
• A twitter bot that tweets items from the list above.
• A somewhat dense list of deprecated code in Drupal Core

The Webform Mass Email module has now been ported to Drupal 8. Time to get emailing :)

The Webform module has long been a powerhouse for Drupal site builders, providing a flexible solution to one of the central problems of web development: collecting user data, storing it and notifying users when content is added. the Webform module has been extended in many directions, supporting ancillary workflows and use cases.

One such use case is sending a mass email to all subscribers to a Webform. This can be handy for when users are signing up to an event or have registered their interest in a topic. The Webform Mass Email module fills this gap.

The module works as follows

When installed, Webform Mass Email module adds a new sub-tab called "Mass Email" under all Webform's "Results" tab (next to "Submissions", "Download" and "Clear") and one settings sub-tab called "Mass Emails" under global Webform "Configuration" tab (next to "Exporters", "Libraries" and "Advanced").

1. Site builder navigates to the "Mass Emails" tab and set base module settings once.
   • "Cron time" - How much time is being spent per cron run (in seconds).
   • "Allow sending as HTML" - If checked, all emails are processed as HTML formatted.
   • "Log emails" - Should the emails be logged to the system log at admin/reports/dblog?
2. The site builder can then assign "Send Webform Mass Email" permission for roles which are able to send mass emails.
3. Anyone with this permission can then navigate to the "Mass Email" sub-tab of any Webform and send messages.
   • "Email field" - The field that is going to be used as the recipient's email address.
   • "Subject" - Message subject for your email.
   • "Body" - Message text for your email.
4. After you hit the "Send emails" button, messages are inserted into queue and sent when cron is running.

The module has now been ported to Drupal 8 and is being supported by the team at Morpht. Check it out and let us know what you think.
 

09 Nov James & Jenny, our toolbox for faster Drupal development Nick Vanpraet Tech Drupal 8

Be aware, this is a longread with extensive value. Only read this if you are ready to uncover our Dropsolid team's exciting dev tool and platform secrets!

 

James & Jenny might sound more like a comedy double act or the protagonists of an long-forgotten tale, but they are in fact very much alive and kicking. They are the names we gave to the platforms that we developed in-house to spin up environments faster and get work done more efficiently. How? Read on!

 

In practice

Whenever we want to spin up a new server, start a new project or even create a new testing environment, we still rely on our infrastructure team. A while ago we managed to automate our build pipeline with some smart configuration of Jenkins, an open source piece of software. Combined with a permission system, we are already able to let technical clients or consultants participate in the development process of a site by triggering a build of an environment. We decided to call this home-coded piece of software James, our in-house Drupal Cloud Butler. However, this UI was very cluttered and it was easy to break the chain. Maintenance-wise, it wasn’t the friendliest system either. James 0.1 was very helpful, but needed polishing.

Behind the scenes we started building a proper platform that was designed to supersede this existing system and take over the creation of new servers, projects and environments by adding a layer on top of this - a layer that could talk to Jenkins and would be able to execute Ansible playbooks through a managed system via RabbitMQ. You could see this as James 0.2. This version of James only has one account and isn’t built with a great many permissions in mind. Its purpose is very simple: get stuff done. This means we still can’t let clients or internal staff create new environments on James directly or set up new projects. But we’d really like to.

This is why we’re currently also investing heavily in the further development of Jenny, the site-spinning machine. Jenny’s aim is to be a user-friendly layer on top of James and it consists of of two parts: a loosely decoupled Angular application consuming a Drupal 8 backend exposed through a REST API, which in turn talks to James through its REST API. Because Jenny makes sure only calls that are allowed go through to James, James can stay focused on functionality without having to add a ton of logic to make sure the request is valid. If the person who wants that new environment isn’t allowed to request one, Jenny won’t ask James to set it up in the first place.

 

How it works

 

A Jenny user will be able to create a new organization, and within that organization create new projects or clone existing ones. These projects can be housed on our servers or on external hosting (with or without VPN, Firewalls or anything else that’s required). They’ll be able to create new environments, archive entire projects or just a single environment, build, back up, restore, sync across environments, log in to an environment’s site, etc. It will even contain information about the health of the servers and also provide analytics about the sites themselves.

Now, because single-person organisations are rather non-existent, that user will be able to add other users to their organization and give them different permissions based on their actual role within the company. A marketeer doesn’t need to know the health of a feature-testing environment, and a developer has little use in seeing analytics about the live environment.

The goal of this permission system is to provide the client enough options that they can restrict a developer from archiving live but allow them to create a new testing environment and get all needed information and access for that environment. On a sidenote: these aren’t standard Drupal permissions, because those are for members within an organization, and a single user can be a part of many organizations and have different permissions for each one.

 

End-to-end

But all these layers have to be able to talk to each other before any of that can happen. JennyA(ngular) has to talk to JennyB(ackend), JennyB then has to make sure the request is valid and talk to James. And whatever information James returns, has to be checked by JennyB, stored in the database if needed, and then transformed into a message that JennyA can do something with.

To make sure we can actually pull this off, we created the following test case:

How do we trigger a build of an environment in Jenkins from JennyA, and how do we show the build log from Jenkins in JennyA?

JennyA: build the page, get project and environment info from JennyB, create a button and send request to API. How this process happens exactly, will be explained in a different post.

JennyB

For this REST resource we need two entities: Project and Environment.
We create some new permissions (defined as options in an OrgRole entity) for our Environment entity type:

• Create environment
• Edit environment
• Delete environment
• Archive environment
• View environment
• View archived environment
• Build environment

Next to this, we build a custom EntityAccessControlHandler that checks these custom permissions. An AccessControlHandler must have two methods: checkAccess() and checkCreateAccess(). In both we want to make sure Drupal’s normal permissions (which for this entity we reduce to simply ‘manage project environment entities’) still rule supreme, so superadmins can debug everything. Which is why both access checks start with a normal, bog-standard $account->hasPermission() check.

if ($account->hasPermission('administer project environment entities')) {
 return AccessResult::allowed();
}

But then we have to add some extra logic to make sure the user is allowed to do whatever it is they’re attempting to do. For that we grab that user’s currently active Membership. A Membership is a simple entity that combines a user, an organization, and an OrgRole entity which says what permissions the user has within that organization. For non-Create access we first check if this user is even a part of the same organization as the entity they’re trying to save.

// Get the organization for this project environment
$organization = $entity->getProject()->getOrganization();
// Check that the active membership and the attached organization match
$accessResult = Membership::checkIfAccountIsPartOfCorrectOrganization($organization, $account);
if ($accessResult->isForbidden()) {
 return $accessResult;
}

For brevity’s sake, I won’t explain how exactly checkIfAccountIsPartOfCorrectOrganization does its checks. But it returns an AccessResultInterface object and does exactly what it says on the tin. It also includes a reason for forbidding access, so we can more easily debug problems. You can just add a string to the creation of an AccessResult or use $accessResult->setReason() and you can then grab it using $accessResult->getReason(). Take note: only forbidden and neutral implement that method. Make sure the result implements the AccessResultReasonInterface before calling either method.

if ($accessResult instanceof AccessResultReasonInterface) {
 $accessResult->getReason();
}

We use this extensively with our unit testing, so we know exactly why something fails.
Assuming our test passes, we can finally check if this user has the correct permissions.

$entityOrganizationMembership = User::load($account->id())->getActiveMembership();

switch ($operation) {
 case 'view':
   if (!$entity->isActive()) {
     return $this->allowedIf($entityOrganizationMembership->hasPermission('view archived project environment'), 'member does not have "view archived project environment" permission');
   }
   return $this->allowedIf($entityOrganizationMembership->hasPermission('view project environment'), 'member does not have "view project environment" permission');
 case 'update':
 case 'delete':
 case 'archive':
 case 'build':
   return $this->allowedIf($entityOrganizationMembership->hasPermission($operation . ' project environment'), 'member does not have "' . $operation . ' project environment" permission');
}

// Unknown operation, no opinion.
return AccessResult::neutral('No operation matches found for operation: ' . $operation);

As you might have noticed, normally when you load a User you don’t get a getActiveMembership() method. But we extended the base Drupal User class and added it there. We also set that new class as the default class for the User entity, which is actually very easy:

function hook_entity_type_build(&$entity_types) {
 if (isset($entity_types['user'])) {
   $entity_types['user']->setClass('Drupal\my_module\Entity\User);
 }
}

Now loading a user returns an instance of our own class.

For createAccess() things get trickier, because at that point the entity doesn’t exist yet.This makes it impossible to check if it’s part of the correct organization (or in this case, the correct project, which is in turn part of an organization). So here we’ll have to also implement a field level Constraint on the related project field. This article explains how to create a field level Constraint.

In this Constraint we can do our Membership::checkIfAccountIsPartOfCorrectOrganization check and be sure nobody will be able to save an environment to a project for an organization they are not a part of, regardless if they are creating one or saving one (somehow having bypassed our access check). To make doubly sure, we also set the $validationRequired property on our Environment class to true. This way entities will always demand to be validated first. If they are not, or they have errors, an exception will be thrown.

Now we can finally build our rest resource. Since a Jenkins build doesn’t exist as a custom entity within JennyB (yet), we create a custom REST resource. We use Drupal console for this and set the canonical path to “/api/project_environment/{project_environment}/build/{id}” and the “create” path to “/api/project_environment/{project_environment}/build”. We then create another resource and set that one’s canonical to “/api/project_environment/{project_environment}/build”, the same as our first resource’s “create” path. This way, when you POST to that path you trigger a new build and when you GET you receive a list of all builds for that environment. We have to split this off into two resources, because each resource can only use each method once.

We generate these resources using Drupal console. But before we can begin with our logic proper, we have to make sure the ProjectEnvironment entity gets automatically loaded. For this we need to extend the routes method from the parent class.

public function routes() {
 $collection = parent::routes();
 // add our paramconverter to all routes in the collection
 // if we could only add options to a few routes, we would have
 // to loop over $collection->all() and add them to specific ones.
 // Internally, that is exactly what the addOptions method does anyway
 $options['parameters']['project_environment'] = [
   'type' => 'entity:project_environment',
   'converter' => 'paramconverter.entity'
 ];
 $collection->addOptions($options);
 return $collection;
}

In the routes method you can add or remove options and requirements to your heart’s content. Whatever you can normally do in a routes.yml file, you can also do here. We've explained this in more detail in this blog post.

Let’s take a closer look at our create path. First we’ll need to make sure the user is allowed to build. Luckily thanks to our custom access handler this is very easy.

// check if user can build
$entity_access = $projectEnvironment->access('build', NULL, TRUE);
if (!$entity_access->isAllowed()) {
 // if it’s not allowed, we know it’s a forbidden or neutral response which implements the Reason interface.
 throw new AccessDeniedHttpException($entity_access->getReason());
}

Now we can ask James to trigger the build.

// Talk to James
$data['key'] = self::VALIDATION_KEY;
$url = self::API_URL . '/project/' . $projectEnvironment->getProject()
   ->getRemoteProjectID() . '/environment/' . $projectEnvironment->getRemoteEnvironmentID() . '/build';
$response = $this->httpClient->request('POST', $url, array('json' => $data));
$responseData = json_decode($response->getBody()->getContents(), TRUE);

For this test we use a simple key that James uses for authentication and build the URL in our REST resource. Eventually this part will be moved to a library and the code might look something like this:

$remoteProjectID = $projectEnvironment->getProject()->getRemoteProjectID();
$remoteEnvironmentID = $projectEnvironment->getRemoteEnvironmentID();
$response = $this->jamesConnection->triggerNewBuild($remoteProjectID, $remoteEnvironmentID, $data);
$responseData = json_decode($response->getBody()->getContents(), TRUE);

We check the data we get back and if everything has gone well, we can update our local ProjectEnvironment entity with the new currently deployed branch.

if ($response->getStatusCode() == 200 && $data['key'] !== $projectEnvironment->getCurrentlyDeployedBranch()) {
 // Everything went fine, so also update the $projectEnvironment to reflect what
 // the currently deployed branch is
 $projectEnvironment->setCurrentlyDeployedBranch($data['branch']);

 // validate the entity
 $violations = $projectEnvironment->validate();
 foreach ($violations as $violation) {
   $errors[] = $violation->getMessage();
 }
 if (isset($errors)) {
   throw new BadRequestHttpException("Entity save validation errors: " . implode("\n", $errors));
 }

 // save it
 $projectEnvironment->save();
}

Running validate is necessary, because we set the $validationRequired property to TRUE for our entity type. If something goes wrong, including our custom Constraints, we throw a Bad Request exception and output the validation errors.

Then we simply return what James gave us.

return new ResourceResponse($responseData, $response->getStatusCode());

On James’ end, it’s mostly the same but instead of checking custom access handlers, we (for now) just validate the key. And James in turn calls Jenkins’ API. This will also change, and James will hand off the build trigger to RabbitMQ. But for the purpose of this test, we communicate with Jenkins directly.

James then returns the ID of the newly triggered build to JennyB, who returns it to JennyA. JennyA then uses that ID to call JennyB’s canonical Build route with the given ID until success or failure has occurred.

 

Curious to read more interesting Drupal-related tidbits? Check out the rest of our blog. Or simply stay up to date every three months and subscribe to our newsletter!

You need a website. You need to send an e-mail newsletter. You need to track (potential) volunteers, donors, or customers. You could use Drupal, Mailchimp and HubSpot. Or you could do it all in Drupal.

We've been using the tools above in our own organization, and we continue to use them. Yet, we've been toying with the idea of moving more of our daily usage to a more Drupal based solution. I'll try to outline some of the pros and cons of each approach. I think you'll see for many organizations the Drupal solution could end-up on the winning side of the decision!

The Heavyweight Single Purpose Tools

We've used a number of we based services at myDropWizard to help keep sales, projects, and customer communication on track.

I'll outline just a few that we use that are very popular. that would make for a good comparison with a Drupal solution.

MailChimp

Currently, we use MailChimp for newsletters. I think MailChimp is a champion product with low prices and great features. MailChimp is probably the most used email newsletter platform, so it's strengths are well known.

Marketing Automation, Meet Drupal Marketing Automation, Meet Drupal Andy Mead Wed, 11/08/2017 - 13:06

Oh, hi there. I’d be lying if I said I wasn’t expecting you. This is a blog after all. And supposedly people read these things, which is, supposedly, why you’re here. So pull up a seat (if you’re not already sitting) and I’ll tell you why Drupal is a great partner for Marketing Automation.

Ah, Marketing Automation. (Hereafter MA, because why read 7 syllables when you can read 2?) It’s arguably the most hyped business technology of the last decade or so, spoken about in hushed tones, as though simply subscribing to a platform will print money for you. Sadly that’s not the truth. But when used properly with digital strategy, it’s pretty good at what it does: capturing latent demand and turning it into sales. The tricky part is the modifying clause that opened the last sentence, “when used properly.”

What to expect from Marketing Automation?

Marketing Automation tools and platforms these days come loaded with bells and whistles: from custom reporting engines to fancy drag-n-drop campaign UIs, and WYSIWYGs that let marketers build digital assets like landing pages and emails. And yet, despite all that fanciness, it’s still really hard to do Marketing Automation right. Why? Well, leaving aside strategic questions (a massive topic on its own), my own experience with MA always left me wanting two things - expressibility and scalability.

Drupal + Marketing Automation

While publishing workflows in Marketing Automation, tools have improved over the years. They still can’t compete with a CMS; particularly one as powerful as Drupal. Drupal empowers users to express content in terms that go far beyond simple landing pages.

In fact, Drupal is used today for just about anything you can imagine, from powering Fortune 500 marketing websites to running weather.com and acting as the backbone of custom web applications. What’s possible with Drupal is really up to you. Just ask the guy who built it.

So, fine. Drupal is great and everything. But how does it help your marketing? Well, because Drupal is so flexible, you can integrate it with almost anything:  like Google Analytics, Pardot, Marketo, Eloqua, Salesforce, and on, and on, and on. In a quickly changing technology landscape that’s an incredible strength because it acts as the nervous system for your marketing technology stack.

“Marketing technology stack?” Yeah, I don’t like business jargon, either. But, it’s a helpful way to think about digital marketing tools. Because they are just that: tools with strengths and weaknesses. You probably wouldn’t use a screwdriver to drive a nail into the wall. Sure, you could, but there’s a better tool for the job: a hammer. Likewise, your MA platform could power all your digital assets, but there’s a better tool for that job, too: Drupal.

The right tools for the job

In my experience, organizing these tools around their strengths brings better results. And here at Elevated Third, we’ve done that by connecting Drupal to Marketing Automation platforms like Pardot, Marketo, and SharpSpring; using it as the front end for services that are powering marketing programs. And moreover, MA is only a piece of that puzzle. Want to use something like HotJar? Drupal is happy to.

Open source means flexibility 

So where does this flexibility come from? Drupal is Open Source Software and there’s a massive developer community that improves it daily. Probably the strength of open source software is its flexibility.

You don’t like the way something works? Easy. Let’s change it.

Is something broken? No problem, let’s fix it.

Got a new problem that off-the-shelf solutions don’t solve? Well, then, let’s built a solution for it.

Is Drupal the right tool for every job? I’d be lying (again) if I said it was. But it’s the right tool for jobs that require unique, flexible solutions. And it could be the right tool for your job, too. If you are curious, let's talk.