Drupal

MYDIGIPASS.COM Tokens

New Drupal Modules - 26 April 2017 - 9:16am

Provides tokens for fields acquired from MYDIGIPASS.COM authentication.

Requirements

https://www.drupal.org/project/mydigipass
https://www.drupal.org/project/token

Usage

Enable like any other module.
MYDIGIPASS.COM tokens will be available in all places where tokens are enabled.
For security and usability reasons, only the tokens enabled on admin/config/services/mydigipass/user_data_fields can be used.

Categories: Drupal

Video Embed URLs

New Drupal Modules - 26 April 2017 - 7:10am

Video Embed URLs creates a simple field type that allows you to embed videos from specific allowed domains.

* Road Map:
[ ] Allow for multiple domains.
[ ] Auto generate thumbnails for these videos.

Categories: Drupal

Entity Tools

New Drupal Modules - 26 April 2017 - 5:34am

Have you ever thought about this?

// Returns an array of Nodes for a content type, using the current user language. $service->getNodes('article'); // Renders a teaser. $service->getNodeView('1', 'teaser');

Ok, I want the same for terms, users, blocks, views! And btw, give me something for my links.

Features

This module does nothing on its own, it provides helpers as Services to quickly implement common programming tasks like:

Categories: Drupal

Evolving Web: Contribute by Saying #DrupalThanks at DrupalCon Baltimore

Planet Drupal - 26 April 2017 - 3:41am

Drupal and the Drupal community are driven by volunteer contributions. There are many great ways to contribute that don't involve writing a single line of code. You could report a bug, edit a documentation page, test a new Drupal 8 feature, help a beginner on a forum, or help organize a meetup. Despite this, many Drupalers are shy about diving in.

After some reflection, the Evolving Web team realized that there's one way to contribute to the community that's really simple: thanking someone who has helped you. Someone who built a module you used, helped you in the issue queue, or has done a presentation you liked. It doesn't matter if you do it privately, publicly on Twitter, or whether you're Dries or a total beginner. 

As part of Evolving Web's "Drupal Love" sponsorship at DrupalCon Baltimore, we're hoping to encourage spontaneous expressions of gratitude by handing out 1,000 flowers, with a simple request: Give this flower to someone at DrupalCon Baltimore who helped you in some way. Spread #DrupalThanks.

It will make both you and them feel great, encourage contributions, prevent burnout, and maybe even start a virtuous cycle. Thanking somebody costs nothing, yet can mean so much.

Evolving Web will be handing out several prizes to both givers and receivers of public thanks, which include a day of free Drupal Training, a subsidized trip to attend DrupalCamp Montréal this June 15-18, and flower bouquets delivered to your home or office.

To participate, just thank someone publicly on Twitter, like this:

or like this:

or like this:

Or if you'd prefer to do it offline, come by our Evolving Web's booth and tell us who you are thanking.

 

+ more awesome articles by Evolving Web
Categories: Drupal

Instagram Entity

New Drupal Modules - 26 April 2017 - 2:42am
Categories: Drupal

Floating Button Menu

New Drupal Modules - 26 April 2017 - 1:12am
Overview:

Float Button Menu animates on to the page as an expanding menu with menu items as per user choice.

  1. First step is to create menu here(admin/structure/menu).
  2. Now go to configuration -> User Interface -> Floating Button Menu Settings
  3. Select menu that you have created.
  4. Set menu color as per your choice.
  5. Save and you are done.
Categories: Drupal

User Logout Tracker

New Drupal Modules - 26 April 2017 - 1:07am

INTRODUCTION
------------

Custom module that tracks the user logout activity.

INSTALLATION
------------

* Install as you would normally install a contributed Drupal module. See:
https://drupal.org/documentation/install/modules-themes/modules-7
for further information.

CONFIGURATION
-------------

Categories: Drupal

Monolog GELF

New Drupal Modules - 26 April 2017 - 12:37am

Handler to send messages to a Graylog2 server.

Enable via services.yml

# Add to parameters section: parameter: monolog.channel_handlers: default: ['gelf'] # Add to services section: services: monolog_gelf.transport: # Choose transportation method. class: Gelf\Transport\UdpTransport # Pass connection arguments. arguments: ['<host>', <port>, <chunk_size>]
Categories: Drupal

Callout Banner

New Drupal Modules - 26 April 2017 - 12:31am
Overview

Callout banner allows you to configure and display a simple single line banner at the top of your website homepage. This banner can for example be used to promote a product on your website or alert people for nearby maintenance / website downtime.

Features

You can configure the text to show in the banner and the text, link and background color.

Requirements

There are no requirements to use this module. The visitor should have javascript enabled for the remove button to work though.

Issues

No issues so far.

Categories: Drupal

Dropsolid: Drupal 8 migration strategies

Planet Drupal - 26 April 2017 - 12:00am
26 Apr Drupal 8 migration strategies Kevin VB

Content is always one of the most important parts of a website. After all, the internet was designed for information sharing. As a result, upgrading to a new CMS implies the migration of content in some form or another. Taking this into account in the early stages is crucial when considering and preparing a CMS upgrade.
The Drupal community is very aware of content migration as a key success factor. Therefore, Drupal’s latest version (D8) has the
migrate module included in its core. This key functionality allows you to upgrade from an older Drupal version to Drupal 8, using a few simple configuration steps. Below, I will explain how this works and put forward a few alternatives for custom migrations.

 

Why should you migrate to Drupal 8?

Site speed is not only important for SEO; it also affects your visitors’ browsing time and exit rate. Drupal 8 comes with an improved caching system that makes Drupal fly - all while taking into account content modification. There are no more endless waits for caches to invalidate, thanks to the real-time cache invalidation using cache tags.
Another reason for migration is the Drupal community. Plenty of features are available to integrate in your own site for free, which in turn enables you to spend time and money on other things. The community also keeps an eye on continuous improvements to the existing code. Drupal 8 is a great example of this, with its foundations in the Symfony2 framework. Everything in D8 has been standardised in such a way that maintenance is a lot easier and time-effective.
Let there be no doubt that migrating to Drupal 8 is an excellent long-term move!

 

How exactly should I migrate to Drupal 8?

You can use the Drupal migrate module that is included in core to upgrade from an older Drupal version to Drupal 8. Make sure to install and enable required modules first.
An example: if your site uses special field types, those modules should also be installed in your new Drupal 8 website. When you’re done configuring your site, you just need to enable the following modules:

  • Migrate
  • Migrate Drupal
  • Migrate Drupal UI

This last module will direct you to a configuration page, where you can start the actual migration. Simply enter the database information from your existing Drupal site and let Drupal review the upgrade.

The review will give you a list of available upgrade paths, next to a list of modules that are currently missing. If you’re happy about the review, you can choose to start the upgrade. Drupal will start importing content, users and taxonomies into your Drupal 8 website. Be aware that a rollback mechanism through the UI of Drupal is not available at this time. Since the Drupal core migrate is built to support a certain number of cases, it is possible that your site is too complicated to import correctly with the Migrate Drupal module. Sometimes, writing a customised migration is a better approach.
 

How to write a customized migration?

In most cases, the Migrate Drupal module will result in a reinstall of your Drupal website because some parts have been imported in the wrong way. You can opt to play things safe and write the migration yourself.
Writing a migration in Drupal 8 is done with the Migrate Plus module. This module allows you to create a new Migration entity. Those entities are created in YAML.

# Migration configuration for News content. id: news_node label: News Content Type migration_group: demo_news source: plugin: news_node destination: plugin: entity:node process: type: plugin: default_value default_value: news langcode: plugin: default_value source: language_code default_value: nl title: post_title field_title: post_title path: path field_tags: plugin: migration migration: - news_terms source: tags_terms migration_dependencies: required: - news_terms

Example of a Migration entity: migrate_plus.migration.news_node.yml

Each migration entity can belong to a Migration Group entity and is defined in YAML with the key ‘migrate_group’. A whole group of migrations can be imported or rolled back at once with drush by installing the Migrate Tools module.

  • drush mi --group=”demo_news” Import all migration in group demo_news
  • drush mr --group=”demo_news” Rollback all migrations in group demo_news

 

The main key of a migration is a Drupal 8 plugin that tells the migration where the source information comes from. There are plenty of base source plugins available for Drupal 8.

  • SqlBase - in Drupal Core: lets you migrate from an SQL source.
  • URL - in Migrate Plus: lets you migrate from a URL which can return JSON, XML, SOAP.
  • CSV - in Migrate Source CSV: lets you migrate from a CSV source file.
  • Spreadsheet - in Migrate Spreadsheet: lets you migrate from a csv, xls or xlsx source file.

If this does not suffice, you can start from your own source that extends from the SourcePluginBase class.

We extended the SqlBase source for our news_node source plugin.

public function query() { $query = $this->select('post', 'p'); $query->fields('p', [ 'ID', 'post_title', 'post_name', 'post_date', ]); $query->condition('p.type', 'news'); return $query; }

Query function in news_node source.

The query function returns a Select object with the information needed during the migration. This object will be the source for our migration.
Next we need to tell the migration which fields we want to map to the migration. This is done with the fields method.

public function fields() { $fields = [ 'post_title' => $this->t('The Post Node title'), 'post_date' => $this->t('The Post creation time'), // ... ]; return $fields; }

In Drupal 7 we used prepareRow to provide field information that couldn’t be selected with a single query. In Drupal 8 this can be done with the prepareRow method. In our example we fetch a teaser image and then add the file ID and file alt to the migration source.

public function prepareRow(Row $row) { // Find related teaser attachment image. $file = $this->getTeaserImage($content_id); // Set a new property file_id. $row->setSourceProperty('file_id', $file['id']); $row->setSourceProperty('file_alt', $file['alt']); return parent::prepareRow($row); }

Add extra information to the migration in preparerow.

When we go back to the YAML confirmation of our migration entity, we see that there is also a destination key configured. In most cases this will be an entity:entity_type destination plugin. Migrate will then automatically create entities of the configured type. In our example, new nodes will be created. If needed, you can also simply create a new destination plugin, which performs extra actions during the import function.

 

The progress key in our configuration defines the field value mapping. It contains a mapping of keys and values where the key is the Drupal field name and the value is the source field name. In some cases, like ‘type’ or ‘language’, we use a default_value plugin which allows us to set the value of the field to a fixed value. In our example, we are creating new nodes of type news in Dutch.

In some cases, the source value comes from another migration. In our example the value of ‘field_tags’ comes from another migration, this is defined by using the ‘migration’ plugin and then specify the migration(s) in which the value is migrated. Whenever such migration dependent fields are presents an extra key ‘migration dependencies’ is necessary. This is an array of migrations which needs to run first.


I hope this post has helped you to provide some insight in migrating your website from D7 to D8! As always, you can reach out to me and the rest of the team via our website.

Categories: Drupal

Update Manager Enhancements

New Drupal Modules - 25 April 2017 - 4:33pm

This project aims to provide enhanced functionality to Drupal's default update manager experience.

This module currently provides:

Categories: Drupal

WallFeed

New Drupal Modules - 25 April 2017 - 1:56pm
Categories: Drupal

Todo Pago Payment for Ubercart

New Drupal Modules - 25 April 2017 - 1:38pm

This modules provides a payment method for Ubercart that allows you to use the Todo Pago Payment gateway in your Ubercart site.

Categories: Drupal

Jeff Geerling's Blog: Composer BoF at DrupalCon Baltimore

Planet Drupal - 25 April 2017 - 1:07pm

Tomorrow (Wednesday, April 25), I'm leading a Birds of a Feather (BoF) at DrupalCon Baltimore titled Managing Drupal sites with Composer (3:45 - 4:45 p.m. in room 305).

I've built four Drupal 8 websites now, and for each site, I have battle scars from working with Composer (read my Tips for Managing Drupal 8 projects with Composer). Even some of the tools that I use alongside composer—for project scaffolding, managing dependencies, patching things, etc.—have changed quite a bit over the past year.

As more and more Drupal developers adopt a Composer workflow for Drupal, we are solving some of the most painful problems.

For example:

Categories: Drupal

Twig Blocks

New Drupal Modules - 25 April 2017 - 12:54pm

Twig Blocks adds a Twig function to render blocks in Twig by passing in the block machine name.

To render a block, call the function in your Twig template:

{{ render_block('machine_name_of_your_block') }}

Categories: Drupal

Valuebound: How to add Custom JS / CSS to Drupal 7 page in theme for a better user experience

Planet Drupal - 25 April 2017 - 11:25am

Adding JS adds dynamic presentation effects to a theme for a better user experience.

In One of the project when i had been asked to display a custom error message to the User login page, when user tried with 3 or more failed attempt. On the other hand we can handle the error using form_set_error or drupal_set_message. What if we want to include that error message to be displayed on specific position.there comes add_js into picture. I have created a hook_form_alter inside that called a custom form validation. Under that custom form validation by checking the user login count, calling an js to the user page. Sleek and simple way to do the JS

Categories: Drupal

aleksip.net: Does Drupal have a minor upgrade problem?

Planet Drupal - 25 April 2017 - 10:47am
Drupal 8 has a new upgrade model, and the promise is to make upgrades easy forever. The idea behind the upgrade model is great, and has already been proven in other projects like Symfony. However, there might still be some issues that need to be solved, as demonstrated by the recent 8.3 release and the security release that followed it.
Categories: Drupal

CiviCRM Blog: New field types in CiviCRM Entity - Picking the right tool for the job!

Planet Drupal - 25 April 2017 - 10:41am

CiviCRM Entity is a contributed module for tightly integrating and extending CiviCRM with Drupal. This module exposes CiviCRM API entities as proper Drupal entity types. This is HUGE as it allows you to make CiviCRM data available within your favorite Drupal tools such as Rules, Views, and EntityReference. I’d like to present another advantage of Drupal entity types, and that is Drupal fields.

By enabling CiviCRM Entity, you can add Drupal fields and associate with CiviCRM entity types such as Contacts and Events. In fact, any of the hundreds of Drupal field types can be used with CiviCRM Entity.  You may be asking yourself, “Shouldn’t I use a CiviCRM custom field? Why would you want to use Drupal fields?” The correct answer is, you should choose the right tool for the job.

CiviCRM is great at having the business logic and infrastructure to support event registrations. CiviCRM has price sets, price fields, and custom fields for collecting information from users when they register for events, as well as the logic and structure that goes with payment processing and financial accounting. You would want to use a CiviCRM custom field to collect data for a specific user. This will be helpful because they data can be accessed via Reports.

Drupal, on the other hand, is much better at organizing and presenting content than CiviCRM. There are tons of modules that can be leveraged to give you the functionality you desire. Need a mobile responsive slideshow? Add a Drupal Image field, configure it to work with Flexslider slideshow. Images are perfect example of picking the right tool for the job. The images in the slideshow for an event is not related to any data that someone may need for reporting, so there is no point to make it a custom field in CiviCRM, so let Drupal do what it does well, store and present this kind of data.

What do I get out of the box?

When you install CiviCRM Entity, you get Drupal based view page and edit forms for all exposed entities. We will limit our examples to Events in this article, but the same applies for all entity types. You can create, update, and display CiviCRM Events, and never leave Drupal. The view page has the path “<site_root>/civicrm-event/[id]” where [id] is the event id, and <site_root> is the base url of your Drupal website. The edit form is “/civicrm-event/[id]/edit” and new events can be created at “/civicrm-event/add”.

This view page and edit form are “standard Drupal”, meaning that all fields and properties that are displayed can be managed in typical Drupal fashion.  We highly recommend installing the Display Suite (DS) module, and its submodule Display Suite Forms to take full advantage of the possibilities, as you can configure field groups, layouts, and use the provided Display Suite field formatters for many of CiviCRM’s properties. With DS Forms you can also choose to hide properties from the edit form, although you will be forced to include any API required properties.

For more information on how to add and manage fields and managing the Display with CiviCRM Entity, please continue read the full article on Skvare.com.

Download CiviCRM Entity

ToolsCiviCRMCiviEventDrupalExtensions
Categories: Drupal

Drupal is API-first, not API-only

Dries Buytaert - 25 April 2017 - 9:59am

More and more developers are choosing content-as-a-service solutions known as headless CMSes — content repositories which offer no-frills editorial interfaces and expose content APIs for consumption by an expanding array of applications. Headless CMSes share a few common traits: they lack end-user front ends, provide few to no editorial tools for display and layout, and as such leave presentational concerns almost entirely up to the front-end developer. Headless CMSes have gained popularity because:

  • A desire to separate concerns of structure and presentation so that front-end teams and back-end teams can work independently from each other.
  • Editors and marketers are looking for solutions that can serve content to a growing list of channels, including websites, back-end systems, single-page applications, native applications, and even emerging devices such as wearables, conversational interfaces, and IoT devices.

Due to this trend among developers, many are rightfully asking whether headless CMSes are challenging the market for traditional CMSes. I'm not convinced that headless CMSes as they stand today are where the CMS world in general is headed. In fact, I believe a nuanced view is needed.

In this blog post, I'll explain why Drupal has one crucial advantage that propels it beyond the emerging headless competitors: it can be an exceptional CMS for editors who need control over the presentation of their content and a rich headless CMS for developers building out large content ecosystems in a single package.

As Drupal continues to power the websites that have long been its bread and butter, it is also used more and more to serve content to other back-end systems, single-page applications, native applications, and even conversational interfaces — all at the same time.

Headless CMSes are leaving editors behind This diagram illustrates the differences between a traditional Drupal website and a headless CMS with various front ends receiving content.

Some claim that headless CMSes will replace traditional CMSes like Drupal and WordPress when it comes to content editors and marketers. I'm not so sure.

Where headless CMSes fall flat is in the areas of in-context administration and in-place editing of content. Our outside-in efforts, in contrast, aim to allow an editor to administer content and page structure in an interface alongside a live preview rather than in an interface that is completely separate from the end user experience. Some examples of this paradigm include dragging blocks directly into regions or reordering menu items and then seeing both of these changes apply live.

By their nature, headless CMSes lack full-fledged editorial experience integrated into the front ends to which they serve content. Unless they expose a content editing interface tied to each front end, in-context administration and in-place editing are impossible. In other words, to provide an editorial experience on the front end, that front end must be aware of that content editing interface — hence the necessity of coupling.

Display and layout manipulation is another area that is key to making marketers successful. One of Drupal's key features is the ability to control where content appears in a layout structure. Headless CMSes are unopinionated about display and layout settings. But just like in-place editing and in-context administration, editorial tools that enable this need to be integrated into the front end that faces the end user in order to be useful.

In addition, editors and marketers are particularly concerned about how content will look once it's published. Access to an easy end-to-end preview system, especially for unpublished content, is essential to many editors' workflows. In the headless CMS paradigm, developers have to jump through fairly significant hoops to enable seamless preview, including setting up a new API endpoint or staging environment and deploying a separate version of their application that issues requests against new paths. As a result, I believe seamless preview — without having to tap on a developer's shoulder — is still necessary.

Features like in-place editing, in-context administration, layout manipulation, and seamless but faithful preview are essential building blocks for an optimal editorial experience for content creators and marketers. For some use cases, these drawbacks are totally manageable, especially where an application needs little editorial interaction and is more developer-focused. But for content editors, headless CMSes simply don't offer the toolkits they have come to expect; they fall short where Drupal shines.

Drupal empowers both editors and application developers This diagram illustrates the differences between a coupled — but headless-enabled — Drupal website and a headless CMS with various front ends receiving content.

All of this isn't to say that headless isn't important. Headless is important, but supporting both headless and traditional approaches is one of the biggest advantages of Drupal. After all, content management systems need to serve content beyond editor-focused websites to single-page applications, native applications, and even emerging devices such as wearables, conversational interfaces, and IoT devices.

Fortunately, the ongoing API-first initiative is actively working to advance existing and new web services efforts that make using Drupal as a content service much easier and more optimal for developers. We're working on making developers of these applications more productive, whether through web services that provide a great developer experience like JSON API and GraphQL or through tooling that accelerates headless application development like the Waterwheel ecosystem.

For me, the key takeaway of this discussion is: Drupal is great for both editors and developers. But there are some caveats. For web experiences that need significant focus on the editor or assembler experience, you should use a coupled Drupal front end which gives you the ability to edit and manipulate the front end without involving a developer. For web experiences where you don't need editors to be involved, Drupal is still ideal. In an API-first approach, Drupal provides for other digital experiences that it can't explicitly support (those that aren't web-based). This keeps both options open to you.

Drupal for your site, headless Drupal for your apps This diagram illustrates the ideal architecture for Drupal, which should be leveraged as both a front end in and of itself as well as a content service for other front ends.

In this day and age, having all channels served by a single source of truth for content is important. But what architecture is optimal for this approach? While reading this you might have also experienced some déjà-vu from a blog post I wrote last year about how you should decouple Drupal, which is still solid advice nearly a year after I first posted it.

Ultimately, I recommend an architecture where Drupal is simultaneously coupled and decoupled; in short, Drupal shines when it's positioned both for editors and for application developers, because Drupal is great at both roles. In other words, your content repository should also be your public-facing website — a contiguous site with full editorial capabilities. At the same time, it should be the centerpiece for your collection of applications, which don't necessitate editorial tools but do offer your developers the experience they want. Keeping Drupal as a coupled website, while concurrently adding decoupled applications, isn't a limitation; it's an enhancement.

Conclusion

Today's goal isn't to make Drupal API-only, but rather API-first. It doesn't limit you to a coupled approach like CMSes without APIs, and it doesn't limit you to an API-only approach like Contentful and other headless CMSes. To me, that is the most important conclusion to draw from this: Drupal supports an entire spectrum of possibilities. This allows you to make the proper trade-off between optimizing for your editors and marketers, or for your developers, and to shift elsewhere on that spectrum as your needs change.

It's a spectrum that encompasses both extremes of the scenarios that a coupled approach and headless approach represent. You can use Drupal to power a single website as we have for many years. At the same time, you can use Drupal to power a long list of applications beyond a traditional website. In doing so, Drupal can be adjusted up and down along this spectrum according to the requirements of your developers and editors.

In other words, Drupal is API-first, not API-only, and rather than leave editors and marketers behind in favor of developers, it gives everyone what they need in one single package.

Special thanks to Preston So for contributions to this blog post and to Wim Leers, Ted Bowman, Chris Hamper and Matt Grill for their feedback during the writing process.

Categories: Drupal

Dries Buytaert: Drupal is API-first, not API-only

Planet Drupal - 25 April 2017 - 9:59am

More and more developers are choosing content-as-a-service solutions known as headless CMSes — content repositories which offer no-frills editorial interfaces and expose content APIs for consumption by an expanding array of applications. Headless CMSes share a few common traits: they lack end-user front ends, provide few to no editorial tools for display and layout, and as such leave presentational concerns almost entirely up to the front-end developer. Headless CMSes have gained popularity because:

  • A desire to separate concerns of structure and presentation so that front-end teams and back-end teams can work independently from each other.
  • Editors and marketers are looking for solutions that can serve content to a growing list of channels, including websites, back-end systems, single-page applications, native applications, and even emerging devices such as wearables, conversational interfaces, and IoT devices.

Due to this trend among developers, many are rightfully asking whether headless CMSes are challenging the market for traditional CMSes. I'm not convinced that headless CMSes as they stand today are where the CMS world in general is headed. In fact, I believe a nuanced view is needed.

In this blog post, I'll explain why Drupal has one crucial advantage that propels it beyond the emerging headless competitors: it can be an exceptional CMS for editors who need control over the presentation of their content and a rich headless CMS for developers building out large content ecosystems in a single package.

As Drupal continues to power the websites that have long been its bread and butter, it is also used more and more to serve content to other back-end systems, single-page applications, native applications, and even conversational interfaces — all at the same time.

Headless CMSes are leaving editors behind This diagram illustrates the differences between a traditional Drupal website and a headless CMS with various front ends receiving content.

Some claim that headless CMSes will replace traditional CMSes like Drupal and WordPress when it comes to content editors and marketers. I'm not so sure.

Where headless CMSes fall flat is in the areas of in-context administration and in-place editing of content. Our outside-in efforts, in contrast, aim to allow an editor to administer content and page structure in an interface alongside a live preview rather than in an interface that is completely separate from the end user experience. Some examples of this paradigm include dragging blocks directly into regions or reordering menu items and then seeing both of these changes apply live.

By their nature, headless CMSes lack full-fledged editorial experience integrated into the front ends to which they serve content. Unless they expose a content editing interface tied to each front end, in-context administration and in-place editing are impossible. In other words, to provide an editorial experience on the front end, that front end must be aware of that content editing interface — hence the necessity of coupling.

Display and layout manipulation is another area that is key to making marketers successful. One of Drupal's key features is the ability to control where content appears in a layout structure. Headless CMSes are unopinionated about display and layout settings. But just like in-place editing and in-context administration, editorial tools that enable this need to be integrated into the front end that faces the end user in order to be useful.

In addition, editors and marketers are particularly concerned about how content will look once it's published. Access to an easy end-to-end preview system, especially for unpublished content, is essential to many editors' workflows. In the headless CMS paradigm, developers have to jump through fairly significant hoops to enable seamless preview, including setting up a new API endpoint or staging environment and deploying a separate version of their application that issues requests against new paths. As a result, I believe seamless preview — without having to tap on a developer's shoulder — is still necessary.

Features like in-place editing, in-context administration, layout manipulation, and seamless but faithful preview are essential building blocks for an optimal editorial experience for content creators and marketers. For some use cases, these drawbacks are totally manageable, especially where an application needs little editorial interaction and is more developer-focused. But for content editors, headless CMSes simply don't offer the toolkits they have come to expect; they fall short where Drupal shines.

Drupal empowers both editors and application developers This diagram illustrates the differences between a coupled — but headless-enabled — Drupal website and a headless CMS with various front ends receiving content.

All of this isn't to say that headless isn't important. Headless is important, but supporting both headless and traditional approaches is one of the biggest advantages of Drupal. After all, content management systems need to serve content beyond editor-focused websites to single-page applications, native applications, and even emerging devices such as wearables, conversational interfaces, and IoT devices.

Fortunately, the ongoing API-first initiative is actively working to advance existing and new web services efforts that make using Drupal as a content service much easier and more optimal for developers. We're working on making developers of these applications more productive, whether through web services that provide a great developer experience like JSON API and GraphQL or through tooling that accelerates headless application development like the Waterwheel ecosystem.

For me, the key takeaway of this discussion is: Drupal is great for both editors and developers. But there are some caveats. For web experiences that need significant focus on the editor or assembler experience, you should use a coupled Drupal front end which gives you the ability to edit and manipulate the front end without involving a developer. For web experiences where you don't need editors to be involved, Drupal is still ideal. In an API-first approach, Drupal provides for other digital experiences that it can't explicitly support (those that aren't web-based). This keeps both options open to you.

Drupal for your site, headless Drupal for your apps This diagram illustrates the ideal architecture for Drupal, which should be leveraged as both a front end in and of itself as well as a content service for other front ends.

In this day and age, having all channels served by a single source of truth for content is important. But what architecture is optimal for this approach? While reading this you might have also experienced some déjà-vu from a blog post I wrote last year about how you should decouple Drupal, which is still solid advice nearly a year after I first posted it.

Ultimately, I recommend an architecture where Drupal is simultaneously coupled and decoupled; in short, Drupal shines when it's positioned both for editors and for application developers, because Drupal is great at both roles. In other words, your content repository should also be your public-facing website — a contiguous site with full editorial capabilities. At the same time, it should be the centerpiece for your collection of applications, which don't necessitate editorial tools but do offer your developers the experience they want. Keeping Drupal as a coupled website, while concurrently adding decoupled applications, isn't a limitation; it's an enhancement.

Conclusion

Today's goal isn't to make Drupal API-only, but rather API-first. It doesn't limit you to a coupled approach like CMSes without APIs, and it doesn't limit you to an API-only approach like Contentful and other headless CMSes. To me, that is the most important conclusion to draw from this: Drupal supports an entire spectrum of possibilities. This allows you to make the proper trade-off between optimizing for your editors and marketers, or for your developers, and to shift elsewhere on that spectrum as your needs change.

It's a spectrum that encompasses both extremes of the scenarios that a coupled approach and headless approach represent. You can use Drupal to power a single website as we have for many years. At the same time, you can use Drupal to power a long list of applications beyond a traditional website. In doing so, Drupal can be adjusted up and down along this spectrum according to the requirements of your developers and editors.

In other words, Drupal is API-first, not API-only, and rather than leave editors and marketers behind in favor of developers, it gives everyone what they need in one single package.

Special thanks to Preston So for contributions to this blog post and to Wim Leers, Ted Bowman, Chris Hamper and Matt Grill for their feedback during the writing process.

Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal