Drupal

PreviousNext: PreviousNext heads to DrupalSouth Hobart 2019

Planet Drupal - 18 November 2019 - 9:58pm

As one of the longest-running and largest Drupal events in the Asia-Pacific region, DrupalSouth is an opportunity for the greater community to come together and celebrate all things Drupal. In 2019, DrupalSouth will be making its way for the first time ever to Hobart, Tasmania, under Downunder!

by Lucy Vernon / 19 November 2019

With our team distributed throughout Australia, PreviousNext use DrupalSouth as an opportunity to get everyone together in person each year, run a team off-site, dinner and to enjoy the conference together. We're also sponsoring and mentoring at the Sprint Day on Wednesday November 27 prior to the main conference commencing. PreviousNext staff are volunteering on the event organising team and our sister company, Skpr, is sponsoring Michelle Mannering's keynote presentation on Thursday November 28.

The conference will feature both local and international speakers, including twelve sessions by PreviousNext’s team who were selected to present this year. The event program committee had no details on the applicants throughout the selection process so all sessions were chosen based on topic and content alone, with PreviousNext set to present or be involved in the following sessions:

We find DrupalSouth is a perfect opportunity to engage socially, network and mix with our region's active Drupal contributors and community members. The conference will run over two days at the Hotel Grand Chancellor in Hobart, from 28-29 November, preceded on Wednesday 27 Nov by a Code Sprint for those are keen to join in. 

Tickets are still available and please feel free to introduce yourself to any of our team throughout the event!

Tagged DrupalSouth
Categories: Drupal

DrupalEasy: DrupalEasy Podcast 222 - Heather Rocker - talking DrupalCon Minneapolis with the new DA executive director!

Planet Drupal - 18 November 2019 - 4:12pm

Direct .mp3 file download.

Heather Rocker, Drupal Association Executive Director, joins Mike Anello to talk about her background, her vision for the Drupal Association, and DrupalCon Minneapolis!

Discussion DrupalEasy News Upcoming Events Sponsors Follow us on Twitter Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Categories: Drupal

JD Does Development: GatsbyJS + Drupal: Create Custom GraphQL Schema for Empty Fields

Planet Drupal - 18 November 2019 - 12:40pm
GatsbyJS + Drupal: Create Custom GraphQL Schema for Empty Fields jflynn Mon, 11/18/2019 - 14:40 Stop me if you've heard this one...

A developer is trying to connect Drupal to Gatsby. Drupal says, "I've got a Related Content field that allows SEVEN different entity types to be referenced, but only THREE slots for content. What do you think?"

Developer says, "Sure, no problem, Drupal!"

Gatsby jumps in and says, "You better make sure that all seven of those entity types are in those three slots."

Developer and Drupal look at each other in confusion. Developer says, "Gatsby, that's not GREAT"

** Laughs go here **

What happened?

It turns out the way that Gatsby builds what it calls "nodes" is by querying the data available. This usually works perfectly, but there are occasions where all the data might not be present, so Gatsby doesn't build the nodes, or it builds the nodes, but doesn't create all of the fields.  Any optional field can fall into this if there is no content in that field on a Drupal entity, and if you're building templates for your decoupled site, then you might just want some content in that field.

NOTE: A Drupal "node" and a GraphQL "node" are not the same thing. This may take some time to sink in. It definitely did for me! For the remainder of this post I will refer to GraphQL nodes as "nodes" and Drupal nodes as "entities". Everybody got that? Good, moving on.

Because the nodes with your hypothetical content have not yet been created, or the fields on your entity don't have anything in them, Gatsby just passes right over them and acts like they don't even exist.

Commonly, you'll see something like this pop up during gatsby build or gatsby develop:

Generating development JavaScript bundle failed /var/www/gatsby/src/components/templates/homepage/index.js 56:9 error Cannot query field "field_background_media" on type "node__homepageRelationships".

This can be frustrating. And when I say "frustrating" I mean that it's table-flipping, head slamming into desk, begging for help from strangers on the street frustrating. The quick fix for this one is simple: ADD SOMETHING TO THE FIELD. In fact, you don't even have to add it to every instance of that field. You can get away with only putting some dummy content in a single entity and you'll have access to that field in Gatsby.

You could also make it a required field so that there MUST be something in it or else the author can't save. This is valid, but in the event that your project's powers-that-be decide that it should be optional, you may need another alternative. This is where GraphQL schema customization comes in.

GraphQL schema and Gatsby

First, a little primer on GraphQL schema. Outside of Gatsby, a system using GraphQL usually needs to define the schema for GraphQL nodes. Gatsby takes this out of the developer's hands and builds the schema dynamically based on the content available to it from its source, in this case gatsby-source-drupal. However, empty data in the source results in no schema in Gatsby.

Let's look at the fix for the optional image above and why it works:

In gatsby-node.js we build our schema through createPages, createPage, and GraphQL queries. This is also where we're going to place our code to help GraphQL along a little bit. This will live in a function called createSchemaCustomization that we can use to customize our GraphQL schema to prevent empty field errors from ruining our day.

The Gatsby docs outline this in the Schema Customization section, but it didn't really click there for me because the examples are based on sourcing from Markdown as opposed to Drupal or another CMS. Things finally clicked a little when I found this issue on Github that showed how to work around a similar problem when sourcing from WordPress.

Three scenarios and three solutions

Scenario 1: Empty field

This is by far the simplest scenario, but that doesn't make it simple. If you have a basic text field on a Drupal entity that does not yet have any content or at some point may not have any content, you don't want your queries to break your site. You need to tell GraphQL that the field exists and it needs to create the matching schema for it.

Here's how it's done:

exports.createSchemaCustomization = ({ actions }) => { const { createTypes } = actions const typeDefs = ` type node__homepage implements Node { field_optional_text: String ` createTypes(typeDefs) }

Now, to walk through it a bit. We're using createSchemaCustomization here and passing in actions. The actions variable is an object that contains several functions so we destructure it to only use the one we need here: createTypes.

We define our types in a GraphQL query string that we lovingly call typeDefs. The first line of the query tells which type we're going to be modifying, in this case node__homepage, and then what interface we're implementing, in this case Node. 

NOTE: If you're looking at GraphiQL to get your field and node names it may be a bit misleading. For example, in GraphiQL and in my other queries node__homepage is called as nodeHomepage. You can find out what the type name is by running a query in GraphiQL that looks like:

query MyQuery { nodeHomepage { internal { type } } }

or by exploring your definitions in GraphiQL.

Next, we add the line field_optional_text: String which is where we define our schema. This is telling GraphQL that this field should exist and it should be of the type String. If there are additional fields, Gatsby and GraphQL are smart enough to infer them so you don't have to redefine every other field on your node.

Finally, we pass our customizations into createTypes and restart our development server. No more errors!

Scenario 2: Entity reference field

Suppose we have a field for media that may not always have content. We still want our queries to work in Gatsby, but if there's only one Drupal entity of this content type and it happens to not have an image attached, then our queries are going to break, and so will our hearts. This requires a foreign key relationship because the entity itself is a node to GraphQL. 

Here's how it's done:

exports.createSchemaCustomization = ({ actions }) => { const { createTypes } = actions const typeDefs = ` type node__homepage implements Node { relationships: node__homepageRelationships } type node__homepageRelationships { field_background_media: media__image @link(from: "field_background_media___NODE") } ` createTypes(typeDefs)

Looks a little similar to the previous scenario, but there's a bit more to it. Let's look at the changes.

Instead of defining our custom schema under the type node__homepage implements Node { line, we reference our relationships field which is where all referenced nodes live. In this case, we tell GraphQL that the relationships field is of type node__homepageRelationships. This is another thing you can find using GraphiQL. 

The next section further defines our relationships field. We declare that node__homepageRelationships should have the field field_background_media of type media__image, but what's that next part? That's where our foreign key link is happening. Since field_background_image is an entity reference, it becomes a node. This line links the field to the node created from the field. On a field with only one entity type referenced, it may not be necessary to include this line, but if your media field starts allowing images AND videos, you're going to want it and you're going to eventually need to make some other updates.

Scenario 3: Related content field with multiple content types

This is the one that had me crying. I mean scream-crying. This is the widowmaker, the noisy killer, the hill to die upon. At least it WAS, but I am triumphant!

Like my horrible joke from the beginning of this post, I have a related content field that is supposed to allow pretty much any content type from Drupal, but only has three slots. I need to have queries available for each content type, but if one doesn't exist on the field, then GraphQL makes a fuss. I can't say for sure, but I've got a feeling that it also subtly insulted my upbringing somewhere behind the scenes.

Now, I'm here to save you some time and potentially broken keyboards and/or monitors.

Here's how it's done:

exports.createSchemaCustomization = ({ actions }) => { const { createTypes } = actions const typeDefs = ` union relatedContentUnion = node__article | node__basic_page | node__blog_post | node__cat_food_reviews | node__modern_art_showcase | node__simpsons_references type node__homepage implements Node { relationships: node__homepageRelationships } type node__homepageRelationships { field_related_content: [relatedContentUnion] @link(from: "field_related_content___NODE") } ` createTypes(typeDefs) }

The biggest changes here are the union and the brackets around the type. From the GraphQL docs:

Union types are very similar to interfaces, but they don't get to specify any common fields between the types.

This means that any type in the union can be returned and they don't need to have the same fields. Sounds like exactly what we need, right?

So we define our union of our six content types and create the relationship using a foreign key link. We use the node created from our field, field_related_content___NODE as our foreign reference, and we get results. However, the brackets around the union are there, and they must do something. In fact they do. They indicate that what will be returned is an array of content in this union, meaning that there will be multiple values instead of one single value returned.

Summary

This seriously took me much longer than it should have to figure out. Hopefully, you don't suffer my same fate and find this post useful. One thing to note that almost destroyed me is that there are THREE, count them 1, 2, 3, underscores between the field name and NODE in the link. _ _ _ NODE. I only put two when I was fighting this and it cost me more time than I'm willing to admit on a public forum.

Special thanks to Shane Thomas (AKA Codekarate) for helping me sort through this and being able to count to 3 better than me.

Category Development Tags Drupal Planet GatsbyJS react Drupal Comments
Categories: Drupal

CiviCRM Blog: Civicrm Entities: not just for coders

Planet Drupal - 18 November 2019 - 9:28am

In 1992, there was a little known new thing called the world wide web. By 1995, it was a "thing". Now, what exactly do those quotes do to the word "thing"? And what does this have to do with "entities"?  Queue my favorite programming joke.

Q: What are the two hardest problems in computer programming?

A: Naming things, garbage collection, and off-by-one calculations.

All of that joke is true, but it's the first problem that is the point of this blog post. Because "entity" is just a fancy word for "thing", i.e. coders have the same problem naming some "things" as everyone else does.

What is an Entity?

Just as in our vernacular usage, an "entity" is a "thing with something extra", and it's the "extra" that makes it an entity. To make it more concrete: lots of things can be entities, and in CiviCRM, all contacts, contributions, and events are entities. It's not to hard to think of a contact as a "thing", but in fact, a lot more things in CiviCRM are entities: even such abstract notions as relationships, memberships, and participants to an event. You might get carried away and guess that everything is an entity, and it's a reasonable guess, but not quite. For example, an option in a list of options is usually not an entity. You might also be getting confused at this stage about whether a specific contact is an entity or whether "Individuals" is an entity: the answer is that we use "Entity type" for "Individual", whereas a specific contact is an "entity" (of type "Individual").

Who Cares?

And here's why you should care, even if you're not a programmer. In CiviCRM, entities are a core part of the codebase, and that means that what you can do with one entity, you can often do with other entities. So understanding what is an entity, and what you can do with any entity, makes you a better user of CiviCRM.

Again, what is an entity?

If you look up the definition of entity on Wikipedia, there's a good chance you will be no further ahead than I was after reading it. Because "entities" aren't a specific thing, they are an abstraction. Just like our vernacular use of "thing", a thing becomse a "thing" when it acquires special properties, and those special properties allow us to treat them with a very useful level of abstraction that doesn't need to worry about other details. And now you know why parents often haven't a clue what their children are talking about.

For example, when the web became a "thing", we no longer had to explain what it was, it was a self-explanatory word. Analogously, an entity is a "thing" with certain properties that allows us write code about it without knowing the specifics of the entity - the entity is self-explanatory enough that we can handle it in an abstract manner.

Again, why should I care?

The best I can do is to provide some examples. Here are three that illustrate the power of the entity in civicrm.

1. Custom Fields

You probably know that you can add custom fields to contacts via the web interface in CiviCRM. But that same code works for any entity. So you can add custom fields to things like Relationships, or Recurring Contributions, or ... a surprising number of things you might not even be able to imagine uses for. Go ahead and look at the form where you add a new custom fieldset, and you'll see a long list of things that you can apply it to: those are CiviCRM's entities.

2. CSV entity importer 

Eileen's excellent extension allows you to import data into your civicrm for anything that is an entity. So for your highly customized CiviCRM for which you had to add all kinds of custom fields, you can import that content from your old CRM without even writing any custom code. My example of this, and why I'm such a big fan of this extension, was when our clients needed to import recurring contribution data from their old CRM.

3. The API and browser

CiviCRM has an API that leverages the properties of underlying entities. That means if your site has some kind of custom entity, it's automatically exposed via the API and the API browser, even if you didn't know about it, and even though that code was written before you invented your entity.

3. CiviCRM Entity in Drupal

The Drupal module "CiviCRM Entity" exposes CiviCRM's entities as Drupal entities. Drupal has it's own concept of entity, and it's compatible in concept to a CiviCRM entity. So this module provides some magic glue function allowing all of CiviCRM's entities to also be Drupal entities. And that means you get (for example), Drupal Views of any CiviCRM entity.

But we're still stuck with the hardest problems, including naming things. And off-by-one calculations.

ToolsAPIArchitectureDocumentationDrupalDrupal 8ExtensionsTips
Categories: Drupal

ladder steps

New Drupal Modules - 18 November 2019 - 8:49am
Categories: Drupal

W3 Element Prohibitions

New Drupal Modules - 18 November 2019 - 6:47am

The goal of this module is to mitigate W3 elements prohibitions, which can cause issues like this, where the layout builder administration to be broken when the layout is being edited and there is a block that adds a form such as the exposed filters of a view or any other form.

Categories: Drupal

Promet Source: A Quick Guide to WCAG Principles and Perspectives

Planet Drupal - 18 November 2019 - 6:00am
Conversations about web accessibility too often miss the bigger picture and the paramount importance of broadening our perspectives for the digital age.  For this reason, it’s extremely important to understand, before getting into the weeds of compliance, that there are multiple facets of digital accessibility. Standard expectations such as images with alternative text for those who are visually impaired or video captioning for those who are hearing impaired, account for only a small segment of what’s involved in making a site accessible. 
Categories: Drupal

Config Ignore Features

New Drupal Modules - 18 November 2019 - 4:24am

This modules is a tool to ignore all the configuration stored in feature modules while using config sync, automatically. By using this module, there are no conflicts between features and your configuration management anymore!

Lets say that you do would like to share a content type between your websites, but every time you import your changes, your content types config is broken.

Then this module is what you are looking for.

Dependencies

You will need the config_ignore and features module to be enabled.

Categories: Drupal

HybridAuth Connect

New Drupal Modules - 18 November 2019 - 3:58am
Categories: Drupal

Gábor Hojtsy: Let's automate deprecated API use removal from Drupal projects!

Planet Drupal - 18 November 2019 - 3:17am

In his State of Drupal keynote at DrupalCon Amsterdam, Dries Buytaert showed once again some tools to use to prepare for Drupal 9 including the Upgrade Status module. To me the process is even more interesting than the tools, because it is entirely different from the last upgrade. As I wrote last week, you now make a lot of incremental improvements on your existing Drupal 8 site that makes the gap to Drupal 9 significantly smaller.

It is a new mindset to look at your Drupal 8 site to improve in preparation for Drupal 9 and we have tools to identify those improvements to make. However Dries also mentioned that we are not quite there to automate those improvements. Back in May Dezső Biczó of Pronovix built out a proof of concept integration with Rector that implements a sample set of refactors, including changes for global constants and best effort solutions to some EntityManager uses, a UrlGeneratorTrait and a drupal_set_message() rector. While the extent of impact of the global constant rectors are not yet known due to limitations in our tools not finding them yet, the rest of the implemented rectors are definitely tapping into the top list of deprecated APIs.

Unfortunately slightly after he posted his blog post about the proof of concept, Dezső did not have time for this project anymore. I think this tool could be of huge help in removing deprecated API use in your projects and thus making them more modern Drupal 8 projects (while being more if not already entirely compatible with Drupal 9). However, we need contributors to cover more of the deprecated APIs, especially around file_*() and db_*() functions. If we can figure out rectors for most of the top 15 errors (and Dezső already did some of them), we could cover over half of all deprecated API use in contributed projects:

To top that off, I also think a simplytest.me style online service would be very useful to run drupal8-rector on your drupal.org project and suggest a patch to apply to remove deprecated APIs. Even better if it allows custom code to be uploaded so people can use it for that too. The more we can automate these tasks the easier the transition of Drupal 8 to 9 will be.

Submit issues and pull requests in the drupal8-rector project to improve API coverage. Look for me on Drupal slack if you get stuck and I'll try to help. I'd also love to talk to you if you want to set up an automated service. Let's do this!

Categories: Drupal

Commerce Store Override

New Drupal Modules - 18 November 2019 - 2:25am

Provides per-store overrides of Commerce content.

Categories: Drupal

Group Extras

New Drupal Modules - 18 November 2019 - 1:50am
Categories: Drupal

Group backup gid to entity

New Drupal Modules - 18 November 2019 - 1:33am
Categories: Drupal

Entity visibility preview

New Drupal Modules - 18 November 2019 - 12:42am
Categories: Drupal

Simple Stock

New Drupal Modules - 17 November 2019 - 8:47pm
Categories: Drupal

Wim Leers: DrupalCon Amsterdam 2019 keynote

Planet Drupal - 17 November 2019 - 2:34pm

All Drupal core initiatives with leads attending DrupalCon Amsterdam took part in an experimental PechaKucha-style keynote format (up to 15 slides each, 20 seconds per slide):

Drupal 8’s continuous innovation cycle resulted in amazing improvements that made today’s Drupal stand out far above Drupal 8.0.0 as originally released. Drupal core initiatives played a huge role in making that transformation happen. In this keynote, various initiative leads will take turns to highlight new capabilities, challenges they faced on the way and other stories from core development.

I represented the API-First Initiative and chose to keep it as short and powerful as possible by only using four of my five allowed minutes. I focused on the human side, with cross-company collaboration across timezones to get JSON:API into Drupal 8.7 core, how we invited community feedback to make it even better in the upcoming Drupal 8.8 release, and how the ecosystem around JSON:API is growing quickly!

It was a very interesting experience to have ten people together on stage, with nearly zero room for improvisation. I think it worked pretty well — it definitely forces a much more focused delivery! Huge thanks to Gábor Hojtsy, who was not on stage but did all the behind-the-scenes coordination.

Slides: Slides with transcriptVideo: YouTubeConference: DrupalCon AmsterdamLocation: Amsterdam, NetherlandsDate: Oct 28 2019 - 13:30Duration: 4 minutesExtra information: 

See https://drupal.kuoni-congress.info/2019/program/abstract/1001.

Attendees: 929

Categories: Drupal

1xINTERNET blog: Be the community

Planet Drupal - 17 November 2019 - 2:03pm
Be the community Adam Juran Sun, 11/17/2019 - 23:03

I mentioned on Twitter two weeks ago how fantastic DrupalCon Europe was, and after more thought it’s my favorite DrupalCon to date! Not because I got to parody Disney songs wearing Spandex (which I did), and not because I gave an impassioned session about my love of Pattern Lab integration (which I didn't this time around), but for the first time I feel like I have made a vital difference to the community.

Categories: Drupal

Your own Stack Overflow

New Drupal Modules - 17 November 2019 - 1:48pm

Coming soon...

Categories: Drupal

aleksip.net: Drupal themes and component libraries

Planet Drupal - 17 November 2019 - 9:08am
Drupal themes and component libraries aleksip Sun, 11/17/2019 - 19:08
Categories: Drupal

Koality Theme Generator

New Drupal Modules - 17 November 2019 - 6:06am

A Drupal Console Theme Generator for Drupal

To use run drupal generate:koality_theme follow the promps and you now have a theme.

Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal