Drupal Feeds

Content Export Import

Latest Drupal Modules - Wed, 2017-08-16 11:18

Under active development.

Categories: Straight From Drupal

Amazee Labs: Extending GraphQL: Part 1 - Fields

Feeds from Drupal.org - Wed, 2017-08-16 10:36
Extending GraphQL: Part 1 - Fields

The last blog post might have left you wondering: "Plugins? It already does everything!". Or you are like one of the busy contributors and already identified a missing feature and can't wait to take the matter into your own hands (good choice).

In this and the following posts we will walk you through the extension capabilities of the GraphQL Core module and use some simple examples to show you how to solve common use cases.

Philipp Melab Wed, 08/16/2017 - 12:36 GraphQL fields

I will assume that you are already familiar with developing Drupal modules and have some basic knowledge of the Plugin API and Plugin Annotations.

The first thing you will want to do is disabling GraphQL schema and result caches. Add these parameters to your development.services.yml:

parameters: graphql.config: result_cache: false schema_cache: false

This will make sure you don't have to clear caches with every change.

As a starting point, we create an empty module called graphql_example. In the GitHub repository for this tutorial, you will find the end result as well as commits for every major step.

Diff: The module boilerplate

A simple page title field

Can't be too hard, right? We just want to be able to ask the GraphQL API what our page title is.
To do that we create a new class PageTitle in the appropriate plugin namespace Drupal\graphql_example\Plugin\GraphQL\Fields.

Let's talk this through. We've created a new derivation of FieldPluginBase, the abstract base class provided by the graphql_core module.

It already does the heavy lifting for integrating our field into the schema. It does this based on the meta information we put into the annotation:

  • id: A unique id for this plugin.
  • type: The return type GraphQL will expect.
  • name: The name we will use to invoke the field.
  • nullable: Defines if the field can return null values or not.
  • multi: Defines if the field will return a list of values.

Now, all we need to do is implement resolveValues to actually return a field value. Note that this method expects you to use the yield keyword instead of return and therefore return a generator.

Fields also can return multiple values, but the framework already handles this within GraphQL type definitions. So all we do is yield as many values as we want. For single value fields, the first one will be chosen.

So we run the first GraphQL query against our custom field.

query { pageTitle }

And the result is disappointing.

{ "data": { "pageTitle": null } }

Diff: The naive approach

The page title is always null because we extract the page title of the current page, which is the GraphQL API callback and has no title. We then need a way to tell it which page we are talking about.

Adding a path argument

Lucky us, GraphQL fields also can accept arguments. We can use them to pass the path of a page and get the title for real. To do that, we add a new annotation property called arguments. This is a map of argument names to the argument type. In our case, we added one argument with name path that expects a String value.

Any arguments will be passed into our resolveValues method with the $args parameter. So we can use the value there to ask the Drupal route matcher to resolve the route and create the proper title for this path.

Let's try again.

query { pageTitle(path: "/admin") }

Way better:

{ "data": { "pageTitle": "Administration" } }

Congratulations, MVP satisfied - you can go home now!

Diff: Using arguments

If there wasn't this itch every developer has when the engineering senses start to tingle. Last time we stumbled on this ominous route field that also takes a path argument. And this ...

query { pageTitle(path: "/node/1") route(path: "/node/1") { ... } }

... smells like a low hanging fruit. There has to be a way to make the two of them work together.

Attaching fields to types

Every GraphQL field can be attached to one or more types by adding the types property to its annotation. In fact, if the property is omitted, it will default to the Root type which is the root query type and the reason our field appeared there in the first place.

We learned that the route field returns a value of type Url. So we remove the argument definition and add a types property instead.

This means the $args parameter won't receive the path value anymore. Instead, the $value parameter will be populated with the result of the route field. And this is a Drupal Url object that we already can be sure is routed since route won't return it otherwise. With this in mind, we can make the solution even simpler.

Now we have to adapt our query since our field is nested within another.

query { route(path: "/admin") { pageTitle } }

Which also will return a nested result.

{ "data": { "route": { "pageTitle": "Administration" } } }

The price of a more complex nested result might seem high for not having to pass the same argument twice. But there's more to what we just did. By attaching the pageTitle field to the Url type, we added it wherever the type appears. Apart from the route field this also includes link fields, menu items or breadcrumbs. And potentially every future field that will return objects of type Url.
We just turned our simple example into the Swiss Army Knife (pun intended) of page title querying.

Diff: Contextual fields

I know what you are thinking. Even an achievement of this epic scale is worthless without test coverage. And you are right. Let's add some.

Adding tests

Fortunately the GraphQL module already comes with an easy to use test base class that helps us to safeguard our achievement in no time.

First, create a tests directory in the module folder. Inside that, a directory called queries that contains one file - page_title.gql - with our test query. A lot of editors already support GraphQL files with syntax highlighting and autocompletion, that's why we moved the query payload to another file.

The test itself just has to extend GraphQLFileTestBase, add the graphql_example module to the list of modules to enable and execute the query file.

Diff: Adding a test

Wrap-Up

We just created a simple field, passed arguments to it, learned how to attach it to an already existing type and finally verified our work by adding a test case. Not bad for one day's work. Next time we will have a look at Types and Interfaces, and how to use them to create fields with complex results.

Categories: Straight From Drupal

Amazee Labs: Extending GraphQL: Part 1 - Fields

Planet Drupal - Wed, 2017-08-16 10:36
Extending GraphQL: Part 1 - Fields

The last blog post might have left you wondering: "Plugins? It already does everything!". Or you are like one of the busy contributors and already identified a missing feature and can't wait to take the matter into your own hands (good choice).

In this and the following posts we will walk you through the extension capabilities of the GraphQL Core module and use some simple examples to show you how to solve common use cases.

Philipp Melab Wed, 08/16/2017 - 12:36 GraphQL fields

I will assume that you are already familiar with developing Drupal modules and have some basic knowledge of the Plugin API and Plugin Annotations.

The first thing you will want to do is disabling GraphQL schema and result caches. Add these parameters to your development.services.yml:

parameters: graphql.config: result_cache: false schema_cache: false

This will make sure you don't have to clear caches with every change.

As a starting point, we create an empty module called graphql_example. In the GitHub repository for this tutorial, you will find the end result as well as commits for every major step.

Diff: The module boilerplate

A simple page title field

Can't be too hard, right? We just want to be able to ask the GraphQL API what our page title is.
To do that we create a new class PageTitle in the appropriate plugin namespace Drupal\graphql_example\Plugin\GraphQL\Fields.

Let's talk this through. We've created a new derivation of FieldPluginBase, the abstract base class provided by the graphql_core module.

It already does the heavy lifting for integrating our field into the schema. It does this based on the meta information we put into the annotation:

  • id: A unique id for this plugin.
  • type: The return type GraphQL will expect.
  • name: The name we will use to invoke the field.
  • nullable: Defines if the field can return null values or not.
  • multi: Defines if the field will return a list of values.

Now, all we need to do is implement resolveValues to actually return a field value. Note that this method expects you to use the yield keyword instead of return and therefore return a generator.

Fields also can return multiple values, but the framework already handles this within GraphQL type definitions. So all we do is yield as many values as we want. For single value fields, the first one will be chosen.

So we run the first GraphQL query against our custom field.

query { pageTitle }

And the result is disappointing.

{ "data": { "pageTitle": null } }

Diff: The naive approach

The page title is always null because we extract the page title of the current page, which is the GraphQL API callback and has no title. We then need a way to tell it which page we are talking about.

Adding a path argument

Lucky us, GraphQL fields also can accept arguments. We can use them to pass the path of a page and get the title for real. To do that, we add a new annotation property called arguments. This is a map of argument names to the argument type. In our case, we added one argument with name path that expects a String value.

Any arguments will be passed into our resolveValues method with the $args parameter. So we can use the value there to ask the Drupal route matcher to resolve the route and create the proper title for this path.

Let's try again.

query { pageTitle(path: "/admin") }

Way better:

{ "data": { "pageTitle": "Administration" } }

Congratulations, MVP satisfied - you can go home now!

Diff: Using arguments

If there wasn't this itch every developer has when the engineering senses start to tingle. Last time we stumbled on this ominous route field that also takes a path argument. And this ...

query { pageTitle(path: "/node/1") route(path: "/node/1") { ... } }

... smells like a low hanging fruit. There has to be a way to make the two of them work together.

Attaching fields to types

Every GraphQL field can be attached to one or more types by adding the types property to its annotation. In fact, if the property is omitted, it will default to the Root type which is the root query type and the reason our field appeared there in the first place.

We learned that the route field returns a value of type Url. So we remove the argument definition and add a types property instead.

This means the $args parameter won't receive the path value anymore. Instead, the $value parameter will be populated with the result of the route field. And this is a Drupal Url object that we already can be sure is routed since route won't return it otherwise. With this in mind, we can make the solution even simpler.

Now we have to adapt our query since our field is nested within another.

query { route(path: "/admin") { pageTitle } }

Which also will return a nested result.

{ "data": { "route": { "pageTitle": "Administration" } } }

The price of a more complex nested result might seem high for not having to pass the same argument twice. But there's more to what we just did. By attaching the pageTitle field to the Url type, we added it wherever the type appears. Apart from the route field this also includes link fields, menu items or breadcrumbs. And potentially every future field that will return objects of type Url.
We just turned our simple example into the Swiss Army Knife (pun intended) of page title querying.

Diff: Contextual fields

I know what you are thinking. Even an achievement of this epic scale is worthless without test coverage. And you are right. Let's add some.

Adding tests

Fortunately the GraphQL module already comes with an easy to use test base class that helps us to safeguard our achievement in no time.

First, create a tests directory in the module folder. Inside that, a directory called queries that contains one file - page_title.gql - with our test query. A lot of editors already support GraphQL files with syntax highlighting and autocompletion, that's why we moved the query payload to another file.

The test itself just has to extend GraphQLFileTestBase, add the graphql_example module to the list of modules to enable and execute the query file.

Diff: Adding a test

Wrap-Up

We just created a simple field, passed arguments to it, learned how to attach it to an already existing type and finally verified our work by adding a test case. Not bad for one day's work. Next time we will have a look at Types and Interfaces, and how to use them to create fields with complex results.

ADCI Solutions: New employee adaptation

Planet Drupal - Wed, 2017-08-16 10:15

What makes any web development team strong? Right, it's people who are the most important part of the success. So, how to shape a great team member out of a newbie?

Here is a small note on how an integration process is set in our Drupal team. We will guide you through all the stages: from an interview to team-building events.

 

Check out if you included all essential adaptation steps into your workflow.

 

New employees adaptation

 

 

ADCI Solutions: New employee adaptation

Feeds from Drupal.org - Wed, 2017-08-16 10:15

What makes any web development team strong? Right, it's people who are the most important part of the success. So, how to shape a great team member out of a newbie?

Here is a small note on how an integration process is set in our Drupal team. We will guide you through all the stages: from an interview to team-building events.

 

Check out if you included all essential adaptation steps into your workflow.

 

New employees adaptation

 

 

Categories: Straight From Drupal

Janez Urevc: Call for help with Media source plugin porting

Feeds from Drupal.org - Wed, 2017-08-16 08:42
Call for help with Media source plugin porting slashrsm Wed, 16.08.2017 - 10:42

As you may already know Media entity module entered Drupal 8.4 as Media module earlier this year. This was the result of years of hard work in contrib and core space. While the module stayed conceptually the same we used this opportunity to clean it up and refactor some things; mostly to make APIs even easier to understand and use.

Media entity comes with the concept of so-called source plugins (also called type plugins in the past). They are responsible for everything related to a specific media type: they have knowledge about their nature, about the way they should be stored and displayed, they are aware of any business logic related to them, etc.

There were many plugins already available before Drupal core decided to adopt the module and they mostly lived as separate modules in contrib space. Since the API changed a bit during the core transition all this plugins need to be updated. The process is pretty straightforward, but the number of modules that need to be worked on is quite high. This means that we'll need quite some help from the community to do this as fast and as effectively as possible.

Here is where you come in!

Are you interested in contributing but don't know how? Are you looking for a task that is relatively simple but not completely trivial? Then the porting of media source plugins might be a really good entry point for you!

There is a meta issue that is trying to keep the overview over the porting process. You will find the list of modules and their current status in it. In order to get familiar with the changes that were introduced during the core transition you should check the relevant change record. All information that is needed for ports should be available there. If you'd rather work with examples then take a look at Media entity image and Media entity document, which were adopted to core as Image and File source plugins respectively.

When you decided which module deserves your attention check its issue queue. If there is already an issue about the porting get involved there. If there is not create one to let others know that you are working on the port. In any case make sure to add its reference to the meta overview issue. This will help us to keep the general overview over the process.

Need help?

Have you checked all the resources I mentioned above and you feel that there are still things that are not entirely clear? Come to the #drupal-media channel on IRC. We are hanging out in that channel most of the times. Our weekly meetings happen in the same channel every Wednesday at 14h UTC.

Enjoyed this post? There is more! Results of the Drupal 8 media sprint Call for Drupal 8 media ecosystem co-maintainers Presentations about various Drupal 8 media modules
Categories: Straight From Drupal

Janez Urevc: Call for help with Media source plugin porting

Planet Drupal - Wed, 2017-08-16 08:42
Call for help with Media source plugin porting slashrsm Wed, 16.08.2017 - 10:42

As you may already know Media entity module entered Drupal 8.4 as Media module earlier this year. This was the result of years of hard work in contrib and core space. While the module stayed conceptually the same we used this opportunity to clean it up and refactor some things; mostly to make APIs even easier to understand and use.

Media entity comes with the concept of so-called source plugins (also called type plugins in the past). They are responsible for everything related to a specific media type: they have knowledge about their nature, about the way they should be stored and displayed, they are aware of any business logic related to them, etc.

There were many plugins already available before Drupal core decided to adopt the module and they mostly lived as separate modules in contrib space. Since the API changed a bit during the core transition all this plugins need to be updated. The process is pretty straightforward, but the number of modules that need to be worked on is quite high. This means that we'll need quite some help from the community to do this as fast and as effectively as possible.

Here is where you come in!

Are you interested in contributing but don't know how? Are you looking for a task that is relatively simple but not completely trivial? Then the porting of media source plugins might be a really good entry point for you!

There is a meta issue that is trying to keep the overview over the porting process. You will find the list of modules and their current status in it. In order to get familiar with the changes that were introduced during the core transition you should check the relevant change record. All information that is needed for ports should be available there. If you'd rather work with examples then take a look at Media entity image and Media entity document, which were adopted to core as Image and File source plugins respectively.

When you decided which module deserves your attention check its issue queue. If there is already an issue about the porting get involved there. If there is not create one to let others know that you are working on the port. In any case make sure to add its reference to the meta overview issue. This will help us to keep the general overview over the process.

Need help?

Have you checked all the resources I mentioned above and you feel that there are still things that are not entirely clear? Come to the #drupal-media channel on IRC. We are hanging out in that channel most of the times. Our weekly meetings happen in the same channel every Wednesday at 14h UTC.

Enjoyed this post? There is more! Results of the Drupal 8 media sprint Call for Drupal 8 media ecosystem co-maintainers Presentations about various Drupal 8 media modules

Views limit

Latest Drupal Modules - Wed, 2017-08-16 02:03

This module expose the drop down of number of records which you want to display on the views result page. For example if you want to show the views result of 25, 50, 100, all etc.

Categories: Straight From Drupal

myDropWizard.com: FREE migration to Drupal 8 for 10 nonprofits

Planet Drupal - Wed, 2017-08-16 02:01

Migrating your site to Drupal 8 isn't simple or cheap. Nor is maintaining it or getting support once your new Drupal 8 site is live!

This is a problem that affects all organizations using Drupal, but it's particularly hard on smaller nonprofits.

A couple weeks ago, I wrote a super long article detailing how Drupal 8 has left many small nonprofits behind. It also proposes a possible path for fixing it!

We're building an Open Source platform for nonprofit websites built on Drupal 8 and CiviCRM, available as a SaaS with hosting and support included.

That article was primarily about why - in this article I'd like to talk about the details of how!

There's a lot to discuss, but I'll try to make this article shorter. :-)

Oh, and we're looking for 10 adventurous nonprofits to join the BETA and help build it.

If you join the BETA, we'll migrate your existing site to the new Drupal 8 & CiviCRM platform for FREE!

Read more to learn about all the details we've got worked out so far...

myDropWizard.com: FREE migration to Drupal 8 for 10 nonprofits

Feeds from Drupal.org - Wed, 2017-08-16 02:01

Migrating your site to Drupal 8 isn't simple or cheap. Nor is maintaining it or getting support once your new Drupal 8 site is live!

This is a problem that affects all organizations using Drupal, but it's particularly hard on smaller nonprofits.

A couple weeks ago, I wrote a super long article detailing how Drupal 8 has left many small nonprofits behind. It also proposes a possible path for fixing it!

We're building an Open Source platform for nonprofit websites built on Drupal 8 and CiviCRM, available as a SaaS with hosting and support included.

That article was primarily about why - in this article I'd like to talk about the details of how!

There's a lot to discuss, but I'll try to make this article shorter. :-)

Oh, and we're looking for 10 adventurous nonprofits to join the BETA and help build it.

If you join the BETA, we'll migrate your existing site to the new Drupal 8 & CiviCRM platform for FREE!

Read more to learn about all the details we've got worked out so far...

Categories: Straight From Drupal

Tameesh Biswas | Blog: Gsoc17 : Client Side File crypto : Week 11

Planet Drupal - Tue, 2017-08-15 22:16
Gsoc17 : Client Side File crypto : Week 11 Open source@IITP

This blog post summarizes the eleventh week of writing open-source code for Drupal with Google Summer of Code.

The module is finally complete with most of it’s major features. It is complete for testing and a bit more changes are to be made that have been discussed, suggested and some things that were planned and are left to implement.

tameeshb Wed, 08/16/2017 - 03:46 Tags GSoC Google Summer of Code 2017 Drupal Drupal Blog

Tameesh Biswas | Blog: Gsoc17 : Client Side File crypto : Week 11

Feeds from Drupal.org - Tue, 2017-08-15 22:16
Gsoc17 : Client Side File crypto : Week 11 Open source@IITP

This blog post summarizes the eleventh week of writing open-source code for Drupal with Google Summer of Code.

The module is finally complete with most of it’s major features. It is complete for testing and a bit more changes are to be made that have been discussed, suggested and some things that were planned and are left to implement.

tameeshb Wed, 08/16/2017 - 03:46 Tags GSoC Google Summer of Code 2017 Drupal Drupal Blog
Categories: Straight From Drupal

Pattern Labs Command

Latest Drupal Modules - Tue, 2017-08-15 21:59

Console commands for working with pattern labs

Categories: Straight From Drupal

Excel LibXL

Latest Drupal Modules - Tue, 2017-08-15 20:37

This module provides an Excel encoder via LibXL Library (commerce) for the Drupal 8 Serialization API. This enables the XLS and XLSX format to be used for data output.

Categories: Straight From Drupal

ActiveLAMP: Drupal Modules to Help Improve Your SEO

Feeds from Drupal.org - Tue, 2017-08-15 20:00

So you just finished building an awesome new website on Drupal, but now you’ve run into a new dilemma. How do optimize the site for search engines? Search engine optimization, or SEO, can be overwhelming, but don’t let that cause you to ignore certain things you can do to help drive traffic to your website. There’s nothing worse than spending countless hours to develop a web application, only to find out that users aren’t able to find your site. This can be extremely frustrating, as well as devastating if your company or business heavily relies on organic traffic.

Read more...
Categories: Straight From Drupal

ActiveLAMP: Drupal Modules to Help Improve Your SEO

Planet Drupal - Tue, 2017-08-15 20:00

So you just finished building an awesome new website on Drupal, but now you’ve run into a new dilemma. How do optimize the site for search engines? Search engine optimization, or SEO, can be overwhelming, but don’t let that cause you to ignore certain things you can do to help drive traffic to your website. There’s nothing worse than spending countless hours to develop a web application, only to find out that users aren’t able to find your site. This can be extremely frustrating, as well as devastating if your company or business heavily relies on organic traffic.

Read more...

Mediacurrent: Accessibility, Nachos, and a Responsibilities Document

Planet Drupal - Tue, 2017-08-15 19:17
Working to Build a Community Standard for Web Accessibility

I had this blog post written last week but didn’t publish because it felt wrong. It wasn’t until earlier today, when I was listening to one of my favorite public speakers, that I realized it was because I was talking at you, not to you. In truth, whenever I’ve discussed this document I keep talking about the what its purpose is and how it could bring value to our Drupal community but not why you should care.

Mediacurrent: Accessibility, Nachos, and a Responsibilities Document

Feeds from Drupal.org - Tue, 2017-08-15 19:17
Working to Build a Community Standard for Web Accessibility

I had this blog post written last week but didn’t publish because it felt wrong. It wasn’t until earlier today, when I was listening to one of my favorite public speakers, that I realized it was because I was talking at you, not to you. In truth, whenever I’ve discussed this document I keep talking about the what its purpose is and how it could bring value to our Drupal community but not why you should care.

Categories: Straight From Drupal

Pages

Subscribe to My Drupal aggregator