Drupal News

Palantir: Dynamic Content From the Edge

Main Drupal Feed - Thu, 11/14/2019 - 18:24

How to scale content delivery infrastructure by implementing Edge Side Includes in Drupal.

Developers and webmasters who oversee websites with millions of users need to provide a solution to keep their infrastructure from getting overloaded with requests. Scaling up web and database servers is one option, but it can be costly and inefficient. Instead, people have increasingly turned to a Content Delivery Network, or CDN, as a type of protective layer in front of their web and database servers.

What does a CDN do?

The CDN provides a cached layer of content close to the user, often referred to as “the edge.” When a user requests a homepage, for example, they are directed to the cached static version of that page on the CDN rather than overloading the web server or accessing the database, thereby scaling content delivery.

Illustrating scaled content deliver supporting millions of requests while only passing on a small percentage of those requests to a web server, which in turn makes even fewer requests to a database server.

The CDN serves static content. So, what happens when web content is updated? There are a few different options here:

  • The cache can be programmed to expire after a certain number of hours or days.
  • Cache entries can be proactively purged when updates are made.
  • Changes to individual page content can be fetched as each page is requested by a user.

More problematic, however, are the changes that affect each and every page. For example, a global banner or a menu often changes the header or footer. This is where our recent work with Edge Side Includes comes in.

Edge Side Includes

Edge Side Includes (ESI) is both a web standard and an XML-based language that enables the dynamic generation of HTML pages at “the edge”. We recently worked with one client to solve the problem: How can we enable our cached content to remain fresh even after we make updates to some of the global parts?

We used Drupal to solve this problem by generating and rendering this global content as ESI fragments. These ESI fragments could then be included by all of our client’s web properties by using ESI include statements, regardless of how they were built.

Illustrating pseudocode of static markup on a web page, where each web page must include that markup and therefore each page must be retrieved from cache, the web server, and may require a shorter cached lifetime.Illustrating pseudocode of ESI includes and their corresponding ESI fragments indicating that now each web page may be able to have a longer cache lifetime since the ESI fragments are referenced and can have their own cache lifetime.How ESI Works

For our client, we developed a way to render ESI fragments in Drupal that included page parts (specifically the header and footer) on non-Drupal sites so that when those page parts change in Drupal, the non-Drupal sites get those changes automatically. To accomplish this, at the cache layer we have all of these pages that have unique page content and then the same content on each page for including the header and the footer.

Using ESI fragments, if a request is made for a page, the first thing that happens is a request for the header content, and then for the cached footer content. Now if something in the header is changed, only one page needs to be updated.

Drupal and Edge Side Includes

The use case that we solved here was specifically for the header and the footer, but our client wanted to have similar branding across all of their web properties, and they wanted it to be governed by the content management that's done with Drupal. Drupal can do this by rendering the actual ESI fragments at two different endpoints.

Our custom module defines two routes, one for the header and one for the footer. Our controller maps to both of those routes and returns an empty render. Then, in the dot module files, we made sure that we're only including the sort of meta tags that we need and the libraries that we want. In our theme, we have special templates for the ESI fragments. We also made sure that we leveraged some of the core functionality by still going through the render API.

We're rendering blocks, we're rendering menus, we're using libraries, and we're respecting cache tags.

Illustrating the breakdown of responsibilities between Drupal modules (route definition, controller creation, page attachment alters), themes (templates, library definition), and core (render process for various entities, libraries, and cache api).

Our client developed page templates that use business logic to set whatever variables might be needed to deliver their page content, adding our ESI include statements to actually grab the header and the footer content. They’re hosting all of their non-Drupal pages on a server that will provide this ESI service. Our client also determines the cache lifetime, both for their page templates and for the ESI fragments that Drupal's actually hosting.

Illustrating the breakdown of responsibilities for ESI implementers/consumers (business logic, variables parameters for fragments, page templates with variables and includes) and service providers (cache lifetime configuration, ESI fragment routes, ESI service / hosting).Personalization Through ESI

So, what’s next for Drupal and ESI? Another implementation that we're using in Drupal with ESI is a content model where a URL can reference internal or external endpoints and then include content from a URL that references static assets. This is CSS that we can include for personalization. This will allow us to do things like get data from Google tag manager or from Marketo or Mailchimp or a similar platform and make some decisions about the route, which could be a view page. Then, we could dynamically write the ESI include source based on the content they want to render personalized. We’ll let you know as we progress!

Development Drupal

Palantir: Dynamic Content From the Edge

Main Drupal Feed - Thu, 11/14/2019 - 18:24

How to scale content delivery infrastructure by implementing Edge Side Includes in Drupal.

Developers and webmasters who oversee websites with millions of users need to provide a solution to keep their infrastructure from getting overloaded with requests. Scaling up web and database servers is one option, but it can be costly and inefficient. Instead, people have increasingly turned to a Content Delivery Network, or CDN, as a type of protective layer in front of their web and database servers.

What does a CDN do?

The CDN provides a cached layer of content close to the user, often referred to as “the edge.” When a user requests a homepage, for example, they are directed to the cached static version of that page on the CDN rather than overloading the web server or accessing the database, thereby scaling content delivery.

Illustrating scaled content deliver supporting millions of requests while only passing on a small percentage of those requests to a web server, which in turn makes even fewer requests to a database server.

The CDN serves static content. So, what happens when web content is updated? There are a few different options here:

  • The cache can be programmed to expire after a certain number of hours or days.
  • Cache entries can be proactively purged when updates are made.
  • Changes to individual page content can be fetched as each page is requested by a user.

More problematic, however, are the changes that affect each and every page. For example, a global banner or a menu often changes the header or footer. This is where our recent work with Edge Side Includes comes in.

Edge Side Includes

Edge Side Includes (ESI) is both a web standard and an XML-based language that enables the dynamic generation of HTML pages at “the edge”. We recently worked with one client to solve the problem: How can we enable our cached content to remain fresh even after we make updates to some of the global parts?

We used Drupal to solve this problem by generating and rendering this global content as ESI fragments. These ESI fragments could then be included by all of our client’s web properties by using ESI include statements, regardless of how they were built.

Illustrating pseudocode of static markup on a web page, where each web page must include that markup and therefore each page must be retrieved from cache, the web server, and may require a shorter cached lifetime.Illustrating pseudocode of ESI includes and their corresponding ESI fragments indicating that now each web page may be able to have a longer cache lifetime since the ESI fragments are referenced and can have their own cache lifetime.How ESI Works

For our client, we developed a way to render ESI fragments in Drupal that included page parts (specifically the header and footer) on non-Drupal sites so that when those page parts change in Drupal, the non-Drupal sites get those changes automatically. To accomplish this, at the cache layer we have all of these pages that have unique page content and then the same content on each page for including the header and the footer.

Using ESI fragments, if a request is made for a page, the first thing that happens is a request for the header content, and then for the cached footer content. Now if something in the header is changed, only one page needs to be updated.

Drupal and Edge Side Includes

The use case that we solved here was specifically for the header and the footer, but our client wanted to have similar branding across all of their web properties, and they wanted it to be governed by the content management that's done with Drupal. Drupal can do this by rendering the actual ESI fragments at two different endpoints.

Our custom module defines two routes, one for the header and one for the footer. Our controller maps to both of those routes and returns an empty render. Then, in the dot module files, we made sure that we're only including the sort of meta tags that we need and the libraries that we want. In our theme, we have special templates for the ESI fragments. We also made sure that we leveraged some of the core functionality by still going through the render API.

We're rendering blocks, we're rendering menus, we're using libraries, and we're respecting cache tags.

Illustrating the breakdown of responsibilities between Drupal modules (route definition, controller creation, page attachment alters), themes (templates, library definition), and core (render process for various entities, libraries, and cache api).

Our client developed page templates that use business logic to set whatever variables might be needed to deliver their page content, adding our ESI include statements to actually grab the header and the footer content. They’re hosting all of their non-Drupal pages on a server that will provide this ESI service. Our client also determines the cache lifetime, both for their page templates and for the ESI fragments that Drupal's actually hosting.

Illustrating the breakdown of responsibilities for ESI implementers/consumers (business logic, variables parameters for fragments, page templates with variables and includes) and service providers (cache lifetime configuration, ESI fragment routes, ESI service / hosting).Personalization Through ESI

So, what’s next for Drupal and ESI? Another implementation that we're using in Drupal with ESI is a content model where a URL can reference internal or external endpoints and then include content from a URL that references static assets. This is CSS that we can include for personalization. This will allow us to do things like get data from Google tag manager or from Marketo or Mailchimp or a similar platform and make some decisions about the route, which could be a view page. Then, we could dynamically write the ESI include source based on the content they want to render personalized. We’ll let you know as we progress!

Development Drupal

Palantir: Dynamic Content From the Edge

Main Drupal Feed - Thu, 11/14/2019 - 18:24

How to scale content delivery infrastructure by implementing Edge Side Includes in Drupal.

Developers and webmasters who oversee websites with millions of users need to provide a solution to keep their infrastructure from getting overloaded with requests. Scaling up web and database servers is one option, but it can be costly and inefficient. Instead, people have increasingly turned to a Content Delivery Network, or CDN, as a type of protective layer in front of their web and database servers.

What does a CDN do?

The CDN provides a cached layer of content close to the user, often referred to as “the edge.” When a user requests a homepage, for example, they are directed to the cached static version of that page on the CDN rather than overloading the web server or accessing the database, thereby scaling content delivery.

Illustrating scaled content deliver supporting millions of requests while only passing on a small percentage of those requests to a web server, which in turn makes even fewer requests to a database server.

The CDN serves static content. So, what happens when web content is updated? There are a few different options here:

  • The cache can be programmed to expire after a certain number of hours or days.
  • Cache entries can be proactively purged when updates are made.
  • Changes to individual page content can be fetched as each page is requested by a user.

More problematic, however, are the changes that affect each and every page. For example, a global banner or a menu often changes the header or footer. This is where our recent work with Edge Side Includes comes in.

Edge Side Includes

Edge Side Includes (ESI) is both a web standard and an XML-based language that enables the dynamic generation of HTML pages at “the edge”. We recently worked with one client to solve the problem: How can we enable our cached content to remain fresh even after we make updates to some of the global parts?

We used Drupal to solve this problem by generating and rendering this global content as ESI fragments. These ESI fragments could then be included by all of our client’s web properties by using ESI include statements, regardless of how they were built.

Illustrating pseudocode of static markup on a web page, where each web page must include that markup and therefore each page must be retrieved from cache, the web server, and may require a shorter cached lifetime.Illustrating pseudocode of ESI includes and their corresponding ESI fragments indicating that now each web page may be able to have a longer cache lifetime since the ESI fragments are referenced and can have their own cache lifetime.How ESI Works

For our client, we developed a way to render ESI fragments in Drupal that included page parts (specifically the header and footer) on non-Drupal sites so that when those page parts change in Drupal, the non-Drupal sites get those changes automatically. To accomplish this, at the cache layer we have all of these pages that have unique page content and then the same content on each page for including the header and the footer.

Using ESI fragments, if a request is made for a page, the first thing that happens is a request for the header content, and then for the cached footer content. Now if something in the header is changed, only one page needs to be updated.

Drupal and Edge Side Includes

The use case that we solved here was specifically for the header and the footer, but our client wanted to have similar branding across all of their web properties, and they wanted it to be governed by the content management that's done with Drupal. Drupal can do this by rendering the actual ESI fragments at two different endpoints.

Our custom module defines two routes, one for the header and one for the footer. Our controller maps to both of those routes and returns an empty render. Then, in the dot module files, we made sure that we're only including the sort of meta tags that we need and the libraries that we want. In our theme, we have special templates for the ESI fragments. We also made sure that we leveraged some of the core functionality by still going through the render API.

We're rendering blocks, we're rendering menus, we're using libraries, and we're respecting cache tags.

Illustrating the breakdown of responsibilities between Drupal modules (route definition, controller creation, page attachment alters), themes (templates, library definition), and core (render process for various entities, libraries, and cache api).

Our client developed page templates that use business logic to set whatever variables might be needed to deliver their page content, adding our ESI include statements to actually grab the header and the footer content. They’re hosting all of their non-Drupal pages on a server that will provide this ESI service. Our client also determines the cache lifetime, both for their page templates and for the ESI fragments that Drupal's actually hosting.

Illustrating the breakdown of responsibilities for ESI implementers/consumers (business logic, variables parameters for fragments, page templates with variables and includes) and service providers (cache lifetime configuration, ESI fragment routes, ESI service / hosting).Personalization Through ESI

So, what’s next for Drupal and ESI? Another implementation that we're using in Drupal with ESI is a content model where a URL can reference internal or external endpoints and then include content from a URL that references static assets. This is CSS that we can include for personalization. This will allow us to do things like get data from Google tag manager or from Marketo or Mailchimp or a similar platform and make some decisions about the route, which could be a view page. Then, we could dynamically write the ESI include source based on the content they want to render personalized. We’ll let you know as we progress!

Development Drupal

Palantir: OSCON 2019: Open@Amazon

Main Drupal Feed - Thu, 11/14/2019 - 18:24
July 16th, 2019 Oregon Convention Center, Portland, Oregon Open@Amazon (official site)

Open source looks very different now compared to 20 years ago, and with such a vast community of developers, it is difficult to define the exact role of a “good” open source citizen.

Palantir is thrilled to be participating in Keeping Open Source Open -- a panel including CEO, Tiffany Farriss for a spirited discussion on open source strategy and the future of open source.

Other panelists include Zaheda Bhorat (Amazon Web Services) and Matt Asay (Adobe). The panel will air some of the strongest opinions on Twitter.

  • Time: 1:30 PM - 2:20 PM
  • Location: F150/151

 

Palantir: Decoupled Days 2019

Main Drupal Feed - Thu, 11/14/2019 - 18:24
July 17 - 18, 2019 John Jay College of Criminal Justice, New York City, New York Decoupled Days (Official Site)

Our team is so enthusiastic to participate in the third iteration of Decoupled Days. Palantir is excited to sponsor this year’s event and continue to share our insights into Content Management Systems.

Content Modeling for Decoupled Drupal

Join Senior Engineer and Technical Architect Dan Montgomery for a session on content modeling. He’ll break down:

  • How a master content model can enable scalable growth
  • How to create a standardized structure for content
  • How Drupal can function as a content repository that serves other products

You’ll walk away with an understanding of how to develop architecture and structures that are scalable for future, unknown endpoints.

  • Date: Thursday, July 18
  • Time: 9:00am
  • Location: Room 

Palantir: How to Scale Through Design Systems

Main Drupal Feed - Thu, 11/14/2019 - 18:24

A design system gives you a “lego box” of components that you can use to create consistent, beautiful interfaces.

Design System artifacts go by many names - Living Style Guides, Pattern Libraries, UI Libraries, and just plain Design Systems. The core idea is to give digital teams greater flexibility and control over their website. Instead of having to decide exactly what all pages should look like in one big redesign and then sticking with those templates until the next redesign, a design system gives you a “lego box” of components the team can use to create consistent, beautiful interfaces. Component-based design is how you SCALE.

At Palantir we build content management systems, so we’ve named our design system artifact a “style guide” in a nod to the editorial space.

Our style guides are organized into three sections:

  1. 'Design Elements' which are the very basic building blocks for the website.
  2. 'Components' which combine design elements into working pieces of code that serve a defined purpose.
  3. 'Page Templates' which combine the elements and components into page templates that are used to display the content at destination URLs.

But how do we help our clients determine what the list of elements, components and page templates should be?

How to Identify Elements for Your Design System

In this post I’ll walk through how we worked with the University of Miami Health System to create a style guide that enabled the marketing team to build a consistent, branded experience for a system with 1,200 doctors and scientists, three primary locations, and multiple local clinics.

1. Start by generating a list of your most important types of content.

Why are people coming to your site? What content helps them complete the task they are there to do? This content list is ground zero for component ideation: how can design support and elevate the information your site delivers?

The list of content serving user needs is your starting point for components. In addition, we can use this list to identify a few page templates right off the bat:

  • Home page
  • Treatment landing page
  • Search page
  • Listing page: Search results, news, classes
  • Clinical trials landing page
  • Clinical trial detail page
  • Location landing page
  • Appointment landing page
  • Appointment detail page
  • Basic page (About us, contact us, general information)

This is just the start of the UHealth style guide; we ultimately created about 80 components and 17 page templates. But it gives you a sense of how we tackled the challenge!

2. Sort your list of important types of content into groups by similarities.

Visitors should be able to scan your website for the information they need, and distinctive component designs help them differentiate content without having to read every word. In addition, being rigorous about consistently using components for specific kinds of information creates predictable interfaces, and predictable interfaces are easy for your visitors to use.

In this step, you should audit the design and photo assets you have available now, and assess your capacity to create them going forward. If, for example, you have a limited photo library and no graphic artist on staff, you’ll want to choose a set of components that don’t heavily rely on photos and graphics.

In this example, we have three component types: News, Events/Classes, and a Simple Success story.

  1. News Component: This component has no images. This is largely about content management; UHealth publishes a lot of news, and they didn’t want to create a bottleneck in their publishing schedule by requiring each story to have a digital-ready photo.
  2. Events/Classes Component: This component has an option for images or a pattern. Because UHealth wants visitors to take action on this content by signing up, we wanted these to have an eye-catching image. Requiring a photo introduces a potential bottleneck in publishing, so we also gave them the option to make the image a pattern or graphic.
  3. Simple success story: This is the most visually complex component because successful health narratives are an important element of UHealth’s content strategy. We were able to create a complex component here because there’s a smaller number of success stories compared to news stories or classes and events. That means the marketing team can dedicate significant time and resources to making the content for this component as effective as possible.
3. Now that you’ve sorted your list by content, do a cross-check for functionality.

Unlike paper publications, websites are built to enable actions like searching, subscribing, and making appointments. Your component set should include interfaces for your functionality.

Some simple and common functions for the UHealth site included searching for a treatment by letter, map blocks, and step forms.

In a more complex example, the Sylvester Cancer Center included a dynamic “Find a lab” functionality that was powered by a database. We designed the template around the limitations of the data set powering the feature, rather than ideating the ideal interface. Search is another feature that benefits from planning during the design phase.

For example, these components for a side bar location search and a full screen location search require carefully structured databases to support them. The design and technical teams must be in alignment on the capacity and limits of the functionality underlying the interface.

4. Differentiate components by brand.

UHealth is an enormous health care system, and there are several centers of excellence within the system that have their own logos and distinct content strategies. As a result, we created several components that were differentiated by brand.

In this example, you see navigation interfaces that are different by brand and language. Incorporating the differentiated logos for the core UHealth system and the Centers of Excellence is fairly straightforward. But as you can see the Sylvester Center also has three additional top nav options: Cancer treatments, Research, and For Healthcare Professionals.

That content change necessitated a different nav bar - you can see that it’s longer. We also created a component for the nav in Spanish, because sometimes in other languages you find that the menu labels are different lengths and need to be adjusted for. In this case, they didn’t, but we kept it as a reference for the site builders.

5. Review the list: can you combine any components?

Your overall goal should be creating the smallest possible set of components. Depending on the complexity and variety of your content and functionality, this might be a set of 100 components or it might be just 20. The UHealth Design System has about 80 components, and another 17 page templates.

The key is that each of the components does a specific job and is visually differentiated from components that do different jobs. You want clear visual differences that signal clear content differences to your audience, and you don’t want your web team spending time trying to parse minor differences - that’s not how you scale!

In my experience, the biggest stumbling block to creating a streamlined list of components is stakeholders asking for maximum flexibility and control. I’ve found the best way to manage this challenge is to provide stakeholders with the option to differentiate their fiefdoms through content rather than components.

In this example, we have the exact same component featuring different images, which allows for two widely different experiences. You can also enable minor differentiation within a component: maybe you can leave off a sub-head, or allow for two buttons instead of one.

6. Start building your design system and stay flexible.

The list you generated here will get you 80% of the way there, but as you proceed with designing and building your design system, you will almost certainly uncover new component needs. When you do, first double-check that you can’t use an existing component. This can be a little tricky, because of course content can essentially be displayed any way you want.

At Palantir, we solve for this challenge by building our Style Guide components with real content. This approach solves for a few key challenges with building a design system:

  1. Showing the “why” of a component. Each component is designed for a specific type of content - news, classes, header, testimonial, directory, etc. This consistency is critical for scaling design: the goal is to create consistent interfaces to create ease of use for your visitors. By building our Style Guides with real content, we document the thought process behind creating a specific component.
  2. Consistency. Digital teams change and grow. We use content in our Style Guide to show your digital team how each component should be used, even if they weren’t a part of the original design process.
  3. Capturing User Testing. Some of our components, like menus, are heavily user-tested to ensure that we’re creating intuitive interfaces. By building the components with the tested content in place, we’re capturing that research and ensuring it goes forward in the design.
  4. Identifying gaps. If you’ve got a piece of content or functionality that you think needs a new component, you can check your assumptions against the Style Guide. Does the content you’re working with actually fit within an existing pattern, or is it really new? If it is, add it to the project backlog!
Outcomes

The most important takeaway here is that design systems let your web team scale. Through the use of design systems, your digital team can generate gorgeous, consistent and branded pages as new needs arise.

But don’t take our word for it! Tauffyt Aguilar, the Executive Director of Digital Solutions for Miller School of Medicine and UHealth, describes the impact of their new design system:

“One of the major improvements is Marketing’s ability to maintain and grow their site moving forward. Previously each page was designed and developed individually. The ability to create or edit pages using various elements and components of the Design System is a significant improvement in the turnaround time and efficiency for the Marketing department.”

My favorite example of a new page constructed with the UHealth design system is this gorgeous interface for the Sports Medicine Institute.

The Sports Medicine audience has unique needs and interests: they are professional and amateur athletes who need to get back in the game. The UHealth team used basic components plus an attention-grabbing image to create this interface for finding experts by issue.

And ultimately, that’s Palantir’s goal: your digital team should have the tools to create gorgeous, effective websites.

Content Strategy Design Industries Healthcare

Palantir: Leading Patient Engagement Solutions Company

Main Drupal Feed - Thu, 11/14/2019 - 18:24

Content modeling as a practical foundation for future scalability in Drupal.

Content modeling as a practical foundation for future scalability On

Palantir recently partnered with a patient engagement solutions company that specializes in delivering patient and physician education to deliver improved health outcomes and an enhanced patient experience. They have an extensive library of patient education content that they use to build education playlists which are delivered to more than 51,000 physician offices, 1,000 hospitals, and 140,000 healthcare providers - and they are still growing.

The company is in the process of completely overhauling their technical stack so that they can rapidly scale up the number of products they use to deliver their patient education library. Currently, every piece of content needs to be entered separately for each product it can be delivered on, which forces the content teams to work in silos. In addition, because they use a dozen different taxonomies and doing so correctly requires a high level of context and nuance, any tagging of content can only be done at the manager level or above. The company partnered with Palantir.net to remove these bottlenecks and plan for future scalability.

Key Outcome

Palantir teamed up with this patient engagement solutions company to develop a master content model that:

  • Captures key content types and their relationships
  • Creates a standardized structure for content, including fields that enable serving content variations based on end-point devices and localization
  • Incorporates a taxonomy that enables content admins to quickly filter and select content relevant to their needs and device
Enabling Scalable Growth

The company’s content library is only getting larger over time, so the core need driving the master content model is to enable scalable growth. Specifically, that means a future state where:

  • New products can be added and old products deprecated without restructuring content. 
  • Content filtering can scale up for new product capabilities, languages, and specialties without having to be fundamentally reworked. 
  • Clients using the taxonomy find it intuitive and require minimal specific training to create and amend their own patient education playlists. 

These principles guided our recommendations for the content model and taxonomy.

Content Model

Our client’s content model is currently organized by the end product that content is delivered through - for example, a waiting room screen vs. an interactive exam room touchscreen. This approach requires the digital team to enter the same piece of content multiple times.

To streamline this process for the team, we recommended a master content model that is organized by the purpose of the content, including the mindset of the audience and the high-level strategy for delivering value with that content.

For example, a “highlight” is a small piece of content intended to engage the audience and draw them into deeper exploration, while a “quiz” is a test of knowledge of a particular topic as training or entertainment.

This approach allows the company to separate the content types from products, which in turn makes them easier to scale. For example, this wireframe shows how a single piece of quiz content can be delivered on a range of endpoint devices depending on which fields that device uses. This approach allows us to show how a quiz might be delivered on a voice device, which is a product the company does not yet support, but could in the future.

“Our content is tailored to different audiences with different endpoints. Palantir took the initiative to not only learn about all of our content paths, but to also learn how our content managers interact with it on a daily basis. We’ve relied heavily on their expertise, especially for taxonomy, and they delivered.”

Executive Vice President, Content & Creative

Taxonomy

The company’s taxonomy has 12 separate vocabularies, and using them to construct meaningful content playlists requires a deep understanding of both the content and the audience. Existing content has been tagged based on both the information it contains and based on the patients to whom it would be relevant.

For example, a significant proportion of cardiology patients are affected by diabetes, so a piece of content titled "Healthy Eating with Diabetes" would be tagged with both "Diabetes" and "Cardiology". Additionally, many tags have subtle differences in how they are used — when do you use "cardiology" vs. "cardiovascular conditions"? "OB/GYN" vs. "Women's Health"?

This system requires that everyone managing the content — from content creators to healthcare providers and staff selecting content to appear in their medical practice — understand the full set of terms and the nuance of how they are applied in order to tag content consistently.

Our goal was to develop a taxonomy that can be used to filter content effectively without requiring deep platform-specific context and nuance.

Our guiding principles were to:

  • Tag based on the information in the content.
  • Use terms that are meaningful to a general audience.
  • Use combinations of tags to provide granularity.
  • Avoid duplicate information that is available as properties of the content

We ultimately recommended a set of eight vocabularies. Two of them are based on company-specific business processes, and the remaining six are standards-based so that any practitioner can use them. By using combinations of terms, users can create playlists that are balanced in terms of educational and editorial content.

For example, in our recommended taxonomy, relevant content is tagged as referencing diabetes, so that the person building the playlist can still construct effective content playlists, without needing to carry in their head the nuance that many cardiology patients are also diabetic.

Moving Forward With Next Steps

This content modeling engagement spanned 9 weeks, and the Palantir team delivered:

  • A high-level content model identifying the core content types and their relationships
  • A set of global content fields that all content types in the model should have
  • A field level content model for the four most important content types
  • A new taxonomy approach based on internal user testing
  • A Drupal Demo code base showing how the content types and taxonomy can be built in Drupal 8

 

In the future, the company’s ultimate goal for the platform is to scale their engagement offerings with new content and new technology. With our purpose-driven content model and refined taxonomy, the company can scale their business by breaking down internal content silos and making tagging and filtering content consistent and predictable for their internal team and eventually, their customers. Palantir’s master content modeling work forms a practical foundation for the company’s radical re-platforming work.

Creating a purpose-driven content model and refined taxonomy

TEN7 Blog's Drupal Posts: What We Learned Last Month #2

Main Drupal Feed - Thu, 11/14/2019 - 17:24

As part of being a distributed company, we've found that using Know Your Team on a regular basis helps us communicate outside of projects and tasks and deadlines. Every Friday we respond to the question “What’s something you figured out this week?” and here we’re collating our best of.

NUMBER 2–OCTOBER 2019 Chris

I learned how to work with json arrays to store and manage data efficiently in a database field.

heykarthikwithu: Drupal core SimpleTest module is deprecated

Main Drupal Feed - Thu, 11/14/2019 - 05:44
Drupal core SimpleTest module is deprecated

The SimpleTest module has been deprecated in Drupal 8, and will be removed in Drupal 9. Production sites should never have SimpleTest module installed since it is a tool for development only.

karthikkumardk Thursday, 14 November 2019 - 11:14:32 IST

myDropWizard.com: What happens when the Drupal Security Team marks a module as unsupported?

Main Drupal Feed - Thu, 11/14/2019 - 02:44

You may have noticed that today the Drupal Security Team marked 16 modules as unsupported, due to the module maintainer not fixing a reported security vulnerability after a sufficiently long period of time.

Among those modules, there were a few very popular ones like Admininistration Views and Nodequeue, which have have reported ~118k and ~40k sites using them, respectively.

Everytime a popular module is unsupported, there's a certain amount of panic and uncertainty, so I wanted to address that in this article, both for the Drupal community at large and for our customers in particular, because we promise to deploy security updates the same day they are released.

Read more to see our perspective!

PreviousNext: PreviousNext's Open Source Contribution Policies and Initiatives for the Drupal Community

Main Drupal Feed - Thu, 11/14/2019 - 02:03

PreviousNext builds open source digital platforms for large scale customers, primarily based on Drupal and hosted using Kubernetes, two of the world’s biggest open source projects. With our business reliant on the success of these open source projects, our company is committed to contributing where we can in relation to our relatively small size. We get a lot of questions about how we do this, so are happy to share our policies so that other organisations might adopt similar approaches.

by Owen Lansbury / 14 November 2019

We learned early on in the formation of PreviousNext that developers who are passionate and engaged in open source projects usually make great team members, so wanted to create a work environment where they could sustain this involvement. 

The first step was to determine how much billable work on client projects our developers needed to achieve in order for PreviousNext to be profitable and sustainable. The figure we settled on was 80%, or 32 hrs per week of billable hours of a full time week as the baseline. Team members then self manage their availability to fulfil their billable hours and can direct up to 20% of their remaining paid availability to code contribution or other community volunteering activities. 

From a project management perspective, our team members are not allowed to be scheduled on billable work more than 80% of their time, which is then factored into our Agile sprint planning and communicated to clients. If certain team members contribute more billable hours in a given week, this just accelerates how many tickets we can complete in a Sprint.

If individual team members aren’t involved or interested in contribution, we expect their billable hours rate to be higher in line with more traditional companies. We don’t mandate that team members use their 20% time for contribution, but find that the majority do due to the benefits it gives them outside their roles. 

These benefits include:

  • Learning and maintaining best-practice development skills based on peer review by other talented developers in the global community.
  • Developing leadership and communication skills with diverse and distributed co-contributors from many different cultures and backgrounds.
  • Staying close to and often being at the forefront of new initiatives in Drupal, whether it be as a core code contributor or maintaining key modules that get used by hundreds of thousands of people. For example, the Video Embed Field that Sam Becker co-maintains is used on 123,487 websites and has been downloaded a staggering 1,697,895 times at the time of publishing. That's some useful code!  
  • Developing close working relationships with many experienced and talented developers outside PreviousNext. In addition to providing mentoring and training for our team, these relationships pay dividends when we can open communication channels with people responsible for specific code within the Drupal ecosystem.
  • Building their own profiles within the community and being considered trusted developers in their own right by demonstrating a proven track record. After all, it's demonstrated work rather than the CV that matters most. This often leads to being selected to provide expert talks at conferences and obviously makes them highly desirable employees should they ever move on from PreviousNext.
  • If our team members do get selected as speakers at international Drupal events, PreviousNext funds their full attendance costs and treats their time away as normal paid hours.
  • Working on non-client work on issues that interest them, such as emerging technologies, proof of concepts, or just an itch they need to scratch. We never direct team members that they should be working on specific issues in their contribution time.

All of these individual benefits provide clear advantages to PreviousNext as a company, ensuring our team maintains an extremely high degree of experience and elevating our company’s profile through Drupal’s contribution credit system. This has resulted in PreviousNext being consistently ranked in the top 5 companies globally that contribute code to Drupal off the back of over 1,000 hours of annual code contribution.

In addition to this 20% contribution time, we also ensure that most new modules we author or patch during client projects are open sourced. Our clients are aware that billable time during sprints will go towards this and that they will also receive contribution credit on Drupal.org as the sponsor of the contributions. The benefits to clients of this approach include:

  • Open sourced modules they use and contribute to will be maintained by many other people in the Drupal community. This ensures a higher degree of code stability and security and means that if PreviousNext ceases to be engaged the modules can continue to be maintained either by a new vendor, their internal team or the community at large.
  • Clients can point to their own contribution credits as evidence of being committed Drupal community supporters in their own right. This can be used as a key element in recruitment if they start hiring their own internal Drupal developers.

Beyond code contributions, PreviousNext provides paid time to volunteer on organising Drupal events, sit on community committees, run free training sessions and organise code sprints. This is then backed by our financial contributions to sponsoring events and the Drupal Association itself.

None of this is rocket science, but as a company reliant on open source software we view these contribution policies and initiatives as a key pillar in ensuring PreviousNext's market profile is maintained and the Drupal ecosystem for our business to operate in remains healthy. 

We're always happy to share insights into how your own organisation might adopt similar approaches, so please get in touch if you'd like to know more.

Tagged Drupal Community, Core contribution

Tag1 Consulting: A Deep Dive Into Yjs Part 2- Tag1 Team Talk #005

Main Drupal Feed - Wed, 11/13/2019 - 22:28
Description Yjs, one of the most powerful and robust frameworks for real-time collaborative editing, enables developers to add shared editing capabilities to any application with relatively little effort. In order to make it so easy to use and extend Yjs, the framework abstracts all the complexities, many moving pieces, and deep technical concepts involved in empowering offline first, peer to peer, real time collaboration. In this Tag1 Team Talk, we continue our deep dive into Yjs with the founder and project lead of this collaborative editing framework to learn more about how it enables not only collaborative text editing but also collaborative drawing, collaborative 3D modeling, and other compelling use cases. In particular, we focus on the three core features that make up any great collaborative editing application: awareness, offline editing, and versioning with change histories. Join Kevin Jahns (Real-Time Collaboration Systems Lead at Tag1 Consulting and Founder and Project Lead of Yjs), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1 Consulting), Michael Meyers (Managing Director at Tag1 Consulting), and moderator Preston So (Contributing Editor at Tag1 Consulting and Principal Product Manager at Gatsby) for the second part of our deep dive series on Yjs directly from its... Read more jgilbert Wed, 11/13/2019 - 14:28

Manifesto: Making Drupal easier for beginners

Main Drupal Feed - Wed, 11/13/2019 - 12:18

Drupal is doing well.    The past few years (since Drupal 8 has been released), has seen the stability, power and (most importantly) the usage of Drupal increase. This is thanks to the hard work of all the organisations who support and enhance the CMS on a daily basis, whether that’s dedicating their time to. Continue reading...

The post Making Drupal easier for beginners appeared first on Manifesto.

Drupal core announcements: Drupal 7 roadmap and release schedule published, plus PHP 7.3 compatibility!

Main Drupal Feed - Fri, 11/08/2019 - 14:43

The Drupal 7 maintainers have published a new D7 roadmap and release schedule:

https://www.drupal.org/core/drupal7-roadmap-release-schedule

There is also a new proposed D7 contributor / maintainer workflow issue:

https://www.drupal.org/project/drupal/issues/3093258

Finally, we're pleased to announce that the 7.x branch's core tests now pass in PHP 7.3!

Feedback is welcome, and thank you very much to all of the many D7 contributors!

Mediacurrent: 5 Reasons Why You Should Consider a GraphQL Server

Main Drupal Feed - Fri, 11/08/2019 - 13:24
What is GraphQL?

If you are a frontend web developer you have probably heard of GraphQL or maybe you have even used it, but what is it? GraphQL is a query language for APIs that allows you to write queries that define the data you receive. No more emailing the backend team to update an endpoint for your application. The client developer defines the data returned in the request.

What is a GraphQL Server/API?

A GraphQL server is a server-side implementation of the GraphQL spec. In other words, a GraphQL server exposes your data as a GraphQL API that your client applications can query for data. These clients could be a single page application, a CMS like Drupal, a mobile app, or almost anything. For example, say you have a MySQL database and you want to expose the content to a React application. You could create a GraphQL server that will allow our React application to query the database indirectly through the GraphQL server.

Why would you consider a GraphQL API? 1. You need an API for your applications

At Mediacurrent, we have been building decoupled static web sites using GatsbyJS. But sometimes we also need some components with dynamic data. You need an API for that and our front-end team was already using GraphQL in Gatsby. Or maybe you might develop a mobile app and need a reliable and fast way to get data from your legacy database. You can use GraphQL to expose only the data you need for your new app but at the same time give your client app developers the ability to control what data they get back from the API.

2. You need data normalization

For our purposes as developers data normalization is simply the process of structuring our data to remove redundancy and create relationships between our data. Data normalization is something database designers think about but developers and software architects should consider as well.

One of the biggest mistakes I’ve seen in my years building web applications is the pattern of including too much business logic in application components. These days, it is not unusual to require data from multiple applications, public REST APIs as well as databases. There is often duplication across these systems and the relationships are rarely clear to the development team. Creating components that require data from multiple systems can be a challenging task. Not only do you have to make multiple queries to retrieve the data, but you also need to combine it in your component. It’s a good pattern to normalize the data outside of your components so that your client application’s components can be as simple and easy to maintain as possible. This is an area where GraphQL shines. You define your data’s types and the relationships between your data in a schema. This is what allows your client applications to query data from multiple data sources in a single request.

3. You love your client application developers

A well-built GraphQL server will avoid these issues that are common with REST APIs.

  • Over-fetching - receiving more data than you need.
  • Under-fetching - not receiving all the data you need.
  • Dependent requests - requiring a series of requests to get the data you need.
  • Multiple round trips - needing to wait for multiple requests to resolve before you can continue.


Over-fetching

In a perfect would we would only fetch the data we need. If you have ever worked with a REST API you will likely know what I mean here. Your client application developers may only need a user’s name but it is likely that when they request the name using the REST endpoint they will get much more data back from the API. GraphQL allows the client to specify the data returned in the request. This means a smaller payload delivered over the web which will only help your app be more performant.

Under-fetching, dependent requests, and multiple round trips

Another scenario is under-fetching. If you need a user’s name and the last three projects they were active on, you probably need to make two HTTP requests to your REST API. With GraphQL relationships, you can get this data back in a single request. No more callbacks and waiting on multiple endpoints to resolve. Get all your data in one request. Now you are avoiding multiple requests, dependent requests, and multiple round trips to get the data for your app’s components.


GraphQL single request to multiple data sources.

Self documenting

The type based schema that GraphQL provides creates the structure to build powerful tools like Graphiql, an in-browser IDE for exploring GraphQL.

This schema also allows for what I would call a self documenting API. GraphQL playground is an example of the power of the GraphQL schema. It takes this schema and creates documentation as well as an IDE like Graphiql. When you update your schema, your documentation is automatically updated as well as the IDE. That’s a huge win!


You can try out a demo of the GraphQL Playground on graphqlbin.com.

4. GraphQL can replace your legacy REST API

It can be challenging to maintain versions of a REST API. Requirements change. You need to add new fields or maybe you want to delete fields from your database. Due to the requirements for backward compatibility your API has to continue supporting these old requirements. Maybe you have an old Android mobile app that relies on your REST endpoints. Maybe you have a Salesforce integration that you don’t have time to update. Most organizations can’t update all their applications at once so you can’t just turn off your old REST API. A GraphQL server can act as a middleware between your old REST API and your new applications. Then as you update your other client apps that use the REST API’s you can update them to work with your new GraphQL API. Once all of your clients are no longer using the REST endpoints you can replace the REST API fully with the GraphQL API.

5. You’re tired of maintaining old versions of your REST API

GraphQL has the @deprecated annotation that you can add to your schema to let clients know that a field should no longer be used. This is much easier to maintain than multiple versions of a REST API.

Which server should you use?

Check out GraphQL.org’s list of servers. There are projects in C# / .NET, Clojure, Elixir, Erlang, Go, Groovy, Java, JavaScript, PHP, Python, Scala, and even Ruby. My choice is the Apollo Server project. It has great documentation and provides a self documenting API for your team that is enjoyable to use. If you use Drupal there is the Graphql module that adds a GraphQL API to your site.

I hope I’ve sparked your interest in GraphQL and building a GraphQL server API. At Mediacurrent, we have seen how powerful this tool can be for solving complex application and data problems and we’d love to talk with you about it. Hit us up in the comments.

Agiledrop.com Blog: Our blog posts from October 2019

Main Drupal Feed - Fri, 11/08/2019 - 10:14

Each month, we do a roundup of all the blog posts we wrote in the previous month. So, no need to worry if you missed some of our posts from October - here’s an overview of all of them!

READ MORE

heykarthikwithu: Drupal JSON:API GET, POST, PATCH and DELETE Samples

Main Drupal Feed - Fri, 11/08/2019 - 09:44
Drupal JSON:API GET, POST, PATCH and DELETE Samples

The API that the JSON:API module makes available is centered on Drupal's entity types and bundles. Every bundle receives its own, unique URL path, which all follow a shared pattern.

karthikkumardk Friday, 08 November 2019 - 15:15:10 IST

Consensus Enterprises: Lando and Drumkit for Drupal 8 Localdev

Main Drupal Feed - Thu, 11/07/2019 - 23:06
Over the last 2 or 3 years, the Drupal community has been converging around a solid set of Docker-based workflows to manage local development environments, and there are a number of worthy tools that make life easier. My personal favourite is Lando, not only because of the Star Wars geekery, but also because it makes easy things easy and hard things possible (a lot like Drupal). I appreciate that a “standard” Lando config file is only a few lines long, but that it’s relatively easy to configure and customize a much more complex setup by simply adding the appropriate lines to the config.

Drupal blog: State of Drupal presentation (October 2019)

Main Drupal Feed - Thu, 11/07/2019 - 22:24

This blog has been re-posted and edited with permission from Dries Buytaert's blog.

DrupalCon Amsterdam Driesnote presentation

Last week, many Drupalists came together for Drupalcon Amsterdam.

As a matter of tradition, I presented my State of Drupal keynote. You can watch a recording of my keynote (starting at 20:44 minutes), or download a copy of my slides (149 MB).

Drupal 8 innovation update

I kicked off my keynote with an update on Drupal 8. Drupal 8.8 is expected to ship on December 4th, and will come with many exciting improvements.

Drupal 8.7 shipped with a Media Library to allow editors to reuse images, videos and other media assets. In Drupal 8.8, Media Library has been marked as stable, and features a way to easily embed media assets using a WYSIWYG text editor.

I'm even more proud to say that Drupal has never looked better, nor been more accessible. I showed our progress on Claro, a new administration UI for Drupal. Once Claro is stable, Drupal will look more modern and appealing out-of-the-box.

The Composer Initiative has also made significant progress. Drupal 8.8 will be the first Drupal release with proper, official support for Composer out-of-the-box. Composer helps solve the problem of Drupal being difficult to install and update. With Composer, developers can update Drupal in one step, as Composer will take care of updating all the dependencies (e.g. third party code).

What is better than one-step updates? Zero-step updates. We also showed progress on the Automated Updates Initiative.

Finally, Drupal 8.8 marks significant progress with our API-first Initiative, with several new improvements to JSON:API support in the contributed space, including an interactive query builder called JSON:API Explorer. This work solidifies Drupal's leadership position as a leading headless or decoupled solution.

Drupal 9 will be the easiest major update

Next, I gave an update on Drupal 9, as we're just eight months from the target release date. We have been working hard to make Drupal 9 the easiest major update in the last decade. In my keynote at 42:25, I showed how to upgrade your site to Drupal 9.0.0's development release.

Drupal 9 product strategy

I am proud of all the progress we made on Drupal 8. Nevertheless, it's also time to start thinking about our strategic priorities for Drupal 9. With that in mind, I proposed four strategic tracks for Drupal 9 (and three initial initiatives):

Strategic track 1: reduce cost and effort

Users want site development to be low-cost and zero-maintenance. As a result, we'll need to continue to focus on initiatives such as automated updates, configuration management, and more.

Strategic track 2: prioritizing the beginner experience

As we saw in a survey Acqua's UX team conducted, most people have a relatively poor initial impression of Drupal, though if they stick with Drupal long enough, their impression of Drupal grows significantly over time. This unlike any of its competitors, whose impression decreases as experience is gained. Drupal 9 should focus on attracting new users, and decreasing beginners' barriers to entry so they can fall in love with Drupal much sooner.

Beginners struggle with Drupal while experts love Drupal.

Drupal's sentiment curve goes in the opposite direction of WordPress', AEM's and Sitecore's. This presents both a big challenge and opportunity for Drupal.

We also officially launched the first initiative on this track; a new front-end theme for Drupal called "Olivero". This new default theme will give new users a much better first impression of Drupal, as well as reflect the modern backend that Drupal sports under the hood.

Strategic track 3: drive the Open Web

As you may know, 1 out of 40 websites run on Drupal. With that comes a responsibility to help drive the future of the Open Web. By 2022-2025, 4 billion new people will join the internet. We want all people to have access to the open web, and as a result should focus on accessibility, inclusiveness, security, privacy, and interoperability.

Strategic track 4: be the best structured data engine

We've already seen the beginnings of a content explosion, and will experience 300 billion new devices coming online by 2030. By continuing to make Drupal a better and better content repository with a flexible API, we'll be ready for a future with more content, more integrations, more devices, and more channels.

Over the next six months, we'll be opening up these proposed tracks to the community for discussion, and introducing surveys to define the 10 inaugural initiatives for Drupal 9. So far the feedback at DrupalCon Amsterdam has been very positive, but I'm looking forward to much more feedback!

Growing sponsored contributions

In a previous blog post, Balancing Makers and Takers to scale and sustain Open Source, I covered a number of topics related to organizational contribution. Around 1:19:44, my keynote goes into more details, including interviews with several prominent business owners and corporate contributors in the Drupal community.

You can find the different interview snippet belows:

  • Baddy Sonja Breidert, co-founder of 1xINTERNET, on why it is important to help convert Takers become Makers.
  • Tiffany Farriss, CEO of Palantir, on what it would take for her organization to contribute substantially more to Drupal.
  • Mike Lamb, Vice President of Global Digital Platforms at Pfizer, announcing that we are establishing the Contribution Recognition Committee to govern and improve Drupal's contribution credit system.
Thank you

Thank you to everyone who attended Drupalcon Amsterdam and contributed to the event's success. I'm always amazed by the vibrant community that makes Drupal so unique. I'm proud to showcase the impressive work of contributors in my presentations, and congratulate all of the hardworking people that are crucial to building Drupal 8 and 9 behind the scenes. I'm excited to continue to celebrate our work and friendships at future events.

Thanks to the 641 individuals who worked on Drupal 8.8 so far.

Thanks to the 243 different individuals who contributed to Drupal 8.8 to date.

Drupal blog: State of Drupal presentation (October 2019)

Main Drupal Feed - Thu, 11/07/2019 - 22:24

This blog has been re-posted and edited with permission from Dries Buytaert's blog.

DrupalCon Amsterdam Driesnote presentation

Last week, many Drupalists came together for Drupalcon Amsterdam.

As a matter of tradition, I presented my State of Drupal keynote. You can watch a recording of my keynote (starting at 20:44 minutes), or download a copy of my slides (149 MB).

Drupal 8 innovation update

I kicked off my keynote with an update on Drupal 8. Drupal 8.8 is expected to ship on December 4th, and will come with many exciting improvements.

Drupal 8.7 shipped with a Media Library to allow editors to reuse images, videos and other media assets. In Drupal 8.8, Media Library has been marked as stable, and features a way to easily embed media assets using a WYSIWYG text editor.

I'm even more proud to say that Drupal has never looked better, nor been more accessible. I showed our progress on Claro, a new administration UI for Drupal. Once Claro is stable, Drupal will look more modern and appealing out-of-the-box.

The Composer Initiative has also made significant progress. Drupal 8.8 will be the first Drupal release with proper, official support for Composer out-of-the-box. Composer helps solve the problem of Drupal being difficult to install and update. With Composer, developers can update Drupal in one step, as Composer will take care of updating all the dependencies (e.g. third party code).

What is better than one-step updates? Zero-step updates. We also showed progress on the Automated Updates Initiative.

Finally, Drupal 8.8 marks significant progress with our API-first Initiative, with several new improvements to JSON:API support in the contributed space, including an interactive query builder called JSON:API Explorer. This work solidifies Drupal's leadership position as a leading headless or decoupled solution.

Drupal 9 will be the easiest major update

Next, I gave an update on Drupal 9, as we're just eight months from the target release date. We have been working hard to make Drupal 9 the easiest major update in the last decade. In my keynote at 42:25, I showed how to upgrade your site to Drupal 9.0.0's development release.

Drupal 9 product strategy

I am proud of all the progress we made on Drupal 8. Nevertheless, it's also time to start thinking about our strategic priorities for Drupal 9. With that in mind, I proposed four strategic tracks for Drupal 9 (and three initial initiatives):

Strategic track 1: reduce cost and effort

Users want site development to be low-cost and zero-maintenance. As a result, we'll need to continue to focus on initiatives such as automated updates, configuration management, and more.

Strategic track 2: prioritizing the beginner experience

As we saw in a survey Acqua's UX team conducted, most people have a relatively poor initial impression of Drupal, though if they stick with Drupal long enough, their impression of Drupal grows significantly over time. This unlike any of its competitors, whose impression decreases as experience is gained. Drupal 9 should focus on attracting new users, and decreasing beginners' barriers to entry so they can fall in love with Drupal much sooner.

Beginners struggle with Drupal while experts love Drupal.

Drupal's sentiment curve goes in the opposite direction of WordPress', AEM's and Sitecore's. This presents both a big challenge and opportunity for Drupal.

We also officially launched the first initiative on this track; a new front-end theme for Drupal called "Olivero". This new default theme will give new users a much better first impression of Drupal, as well as reflect the modern backend that Drupal sports under the hood.

Strategic track 3: drive the Open Web

As you may know, 1 out of 40 websites run on Drupal. With that comes a responsibility to help drive the future of the Open Web. By 2022-2025, 4 billion new people will join the internet. We want all people to have access to the open web, and as a result should focus on accessibility, inclusiveness, security, privacy, and interoperability.

Strategic track 4: be the best structured data engine

We've already seen the beginnings of a content explosion, and will experience 300 billion new devices coming online by 2030. By continuing to make Drupal a better and better content repository with a flexible API, we'll be ready for a future with more content, more integrations, more devices, and more channels.

Over the next six months, we'll be opening up these proposed tracks to the community for discussion, and introducing surveys to define the 10 inaugural initiatives for Drupal 9. So far the feedback at DrupalCon Amsterdam has been very positive, but I'm looking forward to much more feedback!

Growing sponsored contributions

In a previous blog post, Balancing Makers and Takers to scale and sustain Open Source, I covered a number of topics related to organizational contribution. Around 1:19:44, my keynote goes into more details, including interviews with several prominent business owners and corporate contributors in the Drupal community.

You can find the different interview snippet belows:

  • Baddy Sonja Breidert, co-founder of 1xINTERNET, on why it is important to help convert Takers become Makers.
  • Tiffany Farriss, CEO of Palantir, on what it would take for her organization to contribute substantially more to Drupal.
  • Mike Lamb, Vice President of Global Digital Platforms at Pfizer, announcing that we are establishing the Contribution Recognition Committee to govern and improve Drupal's contribution credit system.
Thank you

Thank you to everyone who attended Drupalcon Amsterdam and contributed to the event's success. I'm always amazed by the vibrant community that makes Drupal so unique. I'm proud to showcase the impressive work of contributors in my presentations, and congratulate all of the hardworking people that are crucial to building Drupal 8 and 9 behind the scenes. I'm excited to continue to celebrate our work and friendships at future events.

Thanks to the 641 individuals who worked on Drupal 8.8 so far.

Thanks to the 243 different individuals who contributed to Drupal 8.8 to date.

Pages