Drupal News

This is all about Drupal

  • Drupal Planet

    Acro Media: Drupal 8 to Drupal 9: The Easiest Upgrade in a Decade | Acro Media

    9 hours 34 minutes ago

    Do you know the version number of the browser you’re using? What about the Operating System version you’re using? Chances are, you have no idea what the current version you’re using of any major software. And that’s the way it should be.

    Tips for upgrading to Drupal 9
    • Make sure your version of Drupal is up-to-date.
    • Use Upgrade Status to see if your website is ready for upgrading
    • If you have custom code, use Drupal Rector to identify code that needs to be updated

    Throughout the software industry, there is a movement to more frequent, easier, updates. The reason behind more frequent updates is that everyone tends to keep software up to date and more secure, the easier and more frequent those updates come. Soon, you may not know the major or minor version of your website software, just that it is up-to-date and secure, which is the ultimate goal of any update, upgrade or version release.

    What version of Drupal am I running?

    Chances are if you’re using Drupal, you are using version 7 or 8. In June 2020, version 9 of Drupal was released and the last minor version of Drupal 8 was released. Both version 8 and 9 contain the same features and code. The only difference is that Drupal 9, or D9 as it is referred to in the industry, removed deprecated code and updated third-party dependencies.

    (Source: Drupal.org - How to prepare for Drupal 9)

    The image above shows the timeline for Drupal 8 and its version releases since 2019. The upgrade cycle in version 8 for minor releases was established to be a single release roughly twice a year. Now that Drupal 9 has been released, there will be an end-date for support for Drupal 8, but that is not scheduled until November 2, 2021. In fact, the upgrade from 8 to 9 is so painless, version 10 will be released in 2022, likely to even less fanfare, as it will also be the same as the most recent version 9.

    Upgrading between all minor versions of Drupal, including the jump to version 9 is advised, but is a much simpler process than version upgrades have been in the past. See what Drupal.org has to say about it here. However, if your website was recently created or released since 2016, it’s likely that you’re on Drupal 8, and the upgrade should be extremely straightforward and relatively painless.

    If you find yourself on version 7 of Drupal, you can absolutely upgrade straight to D9 and skip D8 altogether. The rebuild would likely take the form of an entirely new website, but the benefits of going right to D9 are two-fold: avoiding end of life issues for D8 in 2022 and jumping on a platform that will enable to you go headless, adopt the best media, personalization, translation, and content creation tool that open source has to offer.

    Why migrate to Drupal 9?

    Running end-of-life platforms come with a set of problems that over time, will end up costing your company time and money. When official support for D7 runs out in 2022 (the same time as D8), security updates, bug fixes and creation of new modules for those versions will also go away. This opens your system to being more vulnerable to cyber attacks, potential downtime and a lack of up-to-date features that your customers would expect from your web presence.

    Jumping right into a new build with D9, you benefit from having the long-term official support from the Drupal community including security releases that help protect your website from various vulnerabilities. D9 also removes outdated code and uses the new version of PHP, which is important in terms of security.

    Other reasons to upgrade to D9, from Drupal.org:

    • Easiest upgrade in a decade, and a commitment to easy upgrades in the future. Never replatform again.
    • Continuous innovation, cutting-edge new features, reaching new digital channels while strengthening our foundation in content management.
    • Dramatically easier tools, intuitive solutions that empower business users to take advantage of the power of Drupal.

    Currently, we are on the cusp of the first minor release of Drupal 9, which is planned before the end of the year. Most large ecosystem modules in Drupal have complete support for Drupal 9, including Drupal Commerce version 2.

    Tips for Upgrading to Drupal 9
    • Make sure your version of Drupal is up-to-date.
    • Use Upgrade Status to see if your website is ready for upgrading (this module will flag modules that need to be upgraded to Drupal 9).
    • If you have custom code, you can use Drupal Rector to identify code that needs to be updated and, in many cases, can be automatically upgraded.

    Still not sure that the upgrade to Drupal 9 is right for your organization? Have questions about the best way to handle upgrading your Drupal site? Our team is here to help you answer those kinds of questions. Check out our Drupal and Drupal Commerce Development page for more details on our services, or contact our experts to get started on your Drupal upgrade today.

    Josh has been creating websites since 2000, has been a Drupal community member since 2008, and is currently the Team Lead of the Investment Division at Acro Media. He spends most of his free time playing board games and yelling at his cat with his wife.

    Lucius Digital: Update OpenLucius | Major facelift for this social productivity Drupal distro

    14 hours 29 minutes ago
    Last months we had more than 300 people testing the alpha-3 version of OpenLucius: a social productivity platform -build into a Drupal distro. We interviewed them and soon came to the conclusion that the base layouts needed big improvements. It was received as 'mhew..', we agreed. So we went to work and released alpha-4 today. We implemented a complete new base theme from scratch: clean, lean, fast and Bootstrap 4 based. Goal is to leave all the room for custom branding and other design needs.

    Web Omelette: Ajax elements in Drupal form tables

    15 hours 13 minutes ago

    Maybe you have banged your head against the wall trying to figure out why if you add an Ajax button (or any other element) inside a table, it just doesn’t work. I have.

    I was building a complex form that needed to render some table rows, nicely formatted and have some operations buttons to the right to edit/delete the rows. All this via Ajax. You know when you estimate things and you go like: yeah, simple form, we render table, add buttons, Ajax, replace with text fields, Save, done. Right? Wrong. You render the table, put the Ajax buttons in the last column and BAM! Hours later, you wanna punch someone. When Drupal renders tables, it doesn’t process the #ajax definition if you pass an element in the column data key.

    Well, here’s a neat little trick to help you out in this case: #pre_render.

    What we can do is add our buttons outside the table and use a #pre_render callback to move the buttons back into the table where we want them. Because by that time, the form is processed and Drupal doesn’t really care where the buttons are. As long as everything else is correct as well.

    So here’s what a very basic buildForm() method can look like. Remember, it doesn’t do anything just ensures we can get our Ajax callback triggered.

    /** * {@inheritdoc} */ public function buildForm(array $form, FormStateInterface $form_state) { $form['#id'] = $form['#id'] ?? Html::getId('test'); $rows = []; $row = [ $this->t('Row label'), [] ]; $rows[] = $row; $form['buttons'] = [ [ '#type' => 'button', '#value' => $this->t('Edit'), '#submit' => [ [$this, 'editButtonSubmit'], ], '#executes_submit_callback' => TRUE, // Hardcoding for now as we have only one row. '#edit' => 0, '#ajax' => [ 'callback' => [$this, 'ajaxCallback'], 'wrapper' => $form['#id'], ] ], ]; $form['table'] = [ '#type' => 'table', '#rows' => $rows, '#header' => [$this->t('Title'), $this->t('Operations')], ]; $form['#pre_render'] = [ [$this, 'preRenderForm'], ]; return $form; }

    First, we ensure we have an ID on our form so we have something to replace via Ajax. Then we create a row with two columns: a simple text and an empty column (where the button should go, in fact).

    Outside the form, we create a series of buttons (1 in this case), matching literally the rows in the table. So here I hardcode the crap out of things but you’d probably loop the same loop as for generating the rows. On top of the regular Ajax shizzle, we also add a submit callback just so we can properly capture which button gets pressed. This is so that on form rebuild, we can do something with it (up to you to do that).

    Finally, we have the table element and a general form pre_render callback defined.

    And here are the two referenced callback methods:

    /** * {@inheritdoc} */ public function editButtonSubmit(array &$form, FormStateInterface $form_state) { $element = $form_state->getTriggeringElement(); $form_state->set('edit', $element['#edit']); $form_state->setRebuild(); } /** * Prerender callback for the form. * * Moves the buttons into the table. * * @param array $form * The form. * * @return array * The form. */ public function preRenderForm(array $form) { foreach (Element::children($form['buttons']) as $child) { // The 1 is the cell number where we insert the button. $form['table']['#rows'][$child][1] = [ 'data' => $form['buttons'][$child] ]; unset($form['buttons'][$child]); } return $form; }

    First we have the submit callback which stores information about the button that was pressed, as well as rebuilds the form. This allows us to manipulate the form however we want in the rebuild. And second, we have a very simple loop of the declared buttons which we move into the table. And that’s it.

    Of course, our form should implement Drupal\Core\Security\TrustedCallbackInterface and its method trustedCallbacks() so Drupal knows our pre_render callback is secure:

    /** * {@inheritdoc} */ public static function trustedCallbacks() { return ['preRenderForm']; }

    And that’s pretty much it. Now the Edit button will trigger the Ajax, rebuild the form and you are able to repurpose the row to show something else: perhaps a textfield to change the hardcoded label we did? Up to you.

    Hope this helps.

    Evolving Web: Migrating Content Translated with Entity Translation to Drupal 8/9 (Updated 2020)

    1 day 9 hours ago

    In Drupal 8 there is only one unified way of translating content to different languages. However, in Drupal 7, there were two different ways to do it:

    • Using core's Content Translation module: this will create separate nodes per language.
    • Using the contributed Entity Translation module: this maintains a single node and the translation happens at a field level.

    Entity Translation is what is closer to Drupal 8's implementation of translation. Evolving Web has written blog posts about both methods in the past: content translation and entity translation.

    However, that was a while ago, and there are updated ways to do proceed with entity translation migration. We'll go over those updated methods in this article.

    Before We Start The Problem

    Our imaginary client has provided a database dump for their Drupal 7 site containing some nodes. These nodes might have translations in English, Spanish and French, but there could also be some non-translatable nodes. We need to migrate those nodes to Drupal 8 while preserving the translations.

    Setting up the Migration Create the migration module

    We need to create a module for our migrations. In this example, we're naming it migrate_example_entity_translation. 

    We then need to add the following modules as dependencies in the module declaration:

    Create a migration group

    To group the migrations, we also need to create a migration group. To do so, we’ll create a fairly simple configuration file so that the group gets created when the module is installed. The file’s contents should be as follows:

    id: entity_translation label: Entity Translation Group source_type: Drupal 7 shared_configuration: source: key: migrate_d7Define a new database connection

    Next, you need to load the Drupal 7 database into your Drupal 8 installation. To do so, you need to define a new database connection in your settings.php file like this:

    $databases['migrate_d7']['default'] = array( 'driver' => 'mysql', 'database' => 'migrate_d7', 'username' => 'user', 'password' => 'password', 'host' => 'db', 'prefix' => '', );

    And then you can import the database dump into this new database connection using your preferred method.

    Writing the Migrations

    Next thing to do is to write the actual migrations. Per our requirements, we need to write two different migrations: one for the base nodes and one for the translations.

    Since Drupal 8.1.x, migrations are plugins that should be stored in a migrations folder inside any module. You can still make them configuration entities as part of the migrate_plus module but I personally prefer to follow the core recommendation because it's easier to develop (you can make an edit and just rebuild cache to update it).

    Write the base nodes migration

    The first migration to write is the base nodes migration. This will be just a simple migration without anything special related to entity translation.

    The full migration file will look like this:

    id: example_creature_base label: Creature base data migration_group: entity_translation migration_tags: - node - Drupal 7 source: plugin: d7_node node_type: article destination: plugin: entity:node process: type: plugin: default_value default_value: article title: title status: status langcode: language created: created changed: changed promote: promote sticky: sticky revision_log: log field_one_liner: field_one_liner body/value: body/value body/format: plugin: default_value default_value: full_htmlWrite the translations migration

    Now we should write the translations migration. We start by creating the migration file. In this case, we'll name it example_creature_translations.yml. The source section of this migration will look like this:

    source: plugin: d7_node_entity_translation node_type: article

    In the plugin, we're using d7_node_entity_translation; this is a plugin already included in core to handle this type of migration.

    The destination for this plugin will be pretty similar to the destination for the base migration. It will look like this:

    destination: plugin: entity:node translations: true destination_module: content_translation

    Now it's time to write the process section for this migration. It will be pretty similar to the base migration. You only need to keep in mind that you need to migrate two new properties: content_translation_source and content_translation_outdated. So, your process section will look like this:

    process: nid: plugin: migration_lookup migration: example_creature_base source: entity_id type: plugin: default_value default_value: article title: title status: status langcode: language created: created changed: changed promote: promote sticky: sticky revision_log: log field_one_liner: field_one_liner body/value: body/value body/format: plugin: default_value default_value: full_html content_translation_source: source content_translation_outdated: translate

    Finally you can setup migration dependencies to ensure your migrations run in the right order:

    migration_dependencies: required: - example_creature_base

    You can look at the full migration file in the code samples repo.

    Running the Migrations

    Since we have set dependencies, we can instruct Drupal to run the migration group and it will run the migrations in the right order.

    To do so, execute drush mim --group=entity_translation and the output will look like this:

    [notice] Processed 9 items (9 created, 0 updated, 0 failed, 0 ignored) - done with 'example_creature_base' [notice] Processed 9 items (9 created, 0 updated, 0 failed, 0 ignored) - done with 'example_creature_translations'

    You can also run drush ms to see current migration status:

    --------------------- ----------------------------------- -------- ------- ---------- ------------- --------------------- Group Migration ID Status Total Imported Unprocessed Last Imported --------------------- ----------------------------------- -------- ------- ---------- ------------- --------------------- Entity Translation example_creature_base Idle 9 9 0 2020-11-09 15:54:06 Entity Translation example_creature_tran Idle 9 9 0 2020-11-09 15:54:07Next Steps + more awesome articles by Evolving Web

    OpenSense Labs: REST APIs in Drupal

    1 day 14 hours ago
    REST APIs in Drupal Gurpreet Kaur Mon, 11/23/2020 - 15:02

    You must be familiar with words like intermediary, middleman and mediator. What do these words mean? Could they possibly denote a job profile? I think they can. An intermediary, a middleman and a mediator, all constitute a connection between two parties, they provide a line of communication that makes one access the other with ease; like a store manager, he allows the consumer to access the products of the manufacturer. Without him, sales would be pretty difficult to do. 

    Bringing the conversation back to the topic at hand, an API is essentially an intermediary, a middleman or a mediator. The Application Programming Interface provides access to your users and clients to the information they are seeking from you. The information provider uses an API to hand the information over to the information user through a set of definitions and protocols. 

    In decoupled Drupal, the API layer provides the connection between the separated front-end and back-end layers. Without it, decoupling would not be possible, since there won’t be a way to transmit content from the backend to the presentation layer. 

    There are quite a few APIs that perform impressive functions, but today we would only be enunciating REST API. So, let’s delve right in.

    What makes REST API important?

    REST API, RESTful API or Representational State Transfer is built on the constraints of the REST architecture. It is renowned to make development easy by supporting HTTP methods, handling errors along with other RESTful conventions. Since REST capitalises on HTTP, there isn’t a need for installing a separate library or software to capitalise REST’s design, making development all the more easy.

    A representation of the state of the resource is transferred to the requestor, when REST API is used to make a request. It could be done in numerous formats, namely JSON, HTML, XLT or your plain old text, through HTTP. 

    If you asked me what the best things about REST is, I would have to say it is its flexibility. The REST API is designed to be flexible because it is not tied to certain methods and resources. Therefore, it can handle multiple types of calls, transform structurally and return data formats as well. Such versatility makes REST competent to provide for all the diverse needs your consumers may have. 

    REST cannot be defined as a protocol or a standard, rather a set of architectural principles would be a more accurate description. These principles make an API become a RESTful API. So, let us understand these constraints to understand REST API better. 

    The Segregated Client and Server 

    This principle states that the client and the server are to be independent of each other leading to more opportunities for growth and efficiency. Since the separation of concerns would allow a mobile app to make changes without those changes affecting the server and vice-versa, the organisation would grow far more quickly and efficiently.

    The Independent Calls

    A call made using REST API is just that, one call; it has all the potential data for completing a task in and by itself. If a REST API has to be dependent on the data stored on a server for each individual call, it would not be very effective in its job. It has all the necessary data with itself, making REST API very reliable. This principle is known as the state of being stateless.

    The Cacheable Data 

    Now you would think that since REST API stores such massive amounts of data in itself, it would increase your overheads. However, this is a misconception. REST was built to work with cache, meaning it can store cacheable data. This ability helps in reducing the number of API interactions drastically leading to reduced server usage and consequently faster apps. 

    The Appropriate Interface 

    Decoupling mandates the implementation of an interface that is not tightly connected to the API providing uniformity to application development. This can be achieved by using HTTP along with URI resources, CRUD and JSON.

    The Layered System 

    REST API works with a layered system; what this means is that each server, be it security or load-balancing, is set into a hierarchy. This constraints the component behaviour so that one cannot see beyond its layer. 

    The New Code 

    Finally, there is the Code on Demand, this principle that gives you the option to transmit code or applets through the API layer and this code or applet would actually be used in the application. This principle allows you to build applications that do not just rely on their own code. However, the security concerns have made it the least used of them all.

    All of these are essentially the guiding principles of REST API, along with that they also lay emphasis on the work REST can do for you and your application; this, highlighting its importance.

    Exploring REST API in Drupal

    Now that you know the importance and principles of REST API, it is time to move one to its exploration. REST API can be explored in Drupal through a number of modules, all you have to know is where to look and what to exactly look for. For the same reason, here is the list that would make consuming REST API seem like a walk in the park.  

    Drupal Core Modules

    There are certain REST modules that are so popular that they have become a part of Drupal core. These are;

    RESTful web services

    RESTful Web Services is a module that takes advantage of Entity API to provide you the information of all entity types, be it nodes, comments, taxonomy terms or your users. Being built over the Serialization module, it gives you customisation and extension of the RESTful API. It also has the ability to expose additional resources along with adding authentication mechanisms, which can be applied to any of the resources. 

    Serialization and Serialization API

    The primary purpose of the serialization module is to de-serialize data to and from formats such as JSON and XML. You can simply call it a service provider for the same. 

    The Serialization API is based on the Symfony Serializer Component. Its numerous features have made it quite advantageous to the users. 

    • For one, it can serialize and deserialize data;
    • It helps in encoding and decoding to and from new serialization formats respectively, you can read data and also write it;
    • It can also normalize and denormalize data and set it into a new normalization format. 


    HAL is an acronym for Hypertext Application Language. This module uses its namesake to serialise entities. With features similar to the Serialization module, it is often regarded as an extension of the same. The HAL hypermedia format has the potential of being encoded in JSON as well as XML. Being a part of Drupal Core, it is the most sought after format.

    This is a module that lets you test drive as well. Yes, once it is installed and configured, you can test drive your site through the HAL browser by simply providing JSON data.

    HTTP Basic Authentication 

    You must be familiar with the term authentication, the working of HTTP Basic Auth is similar to that. What it does is takes a request, identifies the username and the password of the user and authenticates them against Drupal. It does so by implementing the HTTP Basic protocol, which essentially encodes the username and the password and adds the same in an Authorization header; and all of this done within a request. 

    It is to be noted that this module does not use an interface, it acts as a support for Drupal’s Authentication Manager. 

    The Alternates of Basic Authentication 

    Basic Auth is an important module in the REST API, therefore, certain alternatives are also available to be used in its place. 

    OAuth 1.0

    The OAuth 1.0 standards are implemented by OAuth 1.0 module to be used in Drupal. It provides a foundation to the modules that want to use the OAuth. 

    In Drupal 8, this module achieves the feat of leveraging the OAuth PECL Extension, leading to the implementation of the authentication provider

    Simple OAuth(Oauth2) & OpenID Connect

    Simple OAuth can be described as the implementation of OAuth 2.0 Authorization Framework RFC. In Drupal, it is a module that makes use of the PHP library OAuth 2.0 Server, which is a part of The League of Extraordinary Packages. Let me tell you something about this library so you know how valuable it is, it has actually become a standard for the modern PHP. With it being thoroughly tested, you can’t go wrong; still you would need to check your options at the time of deciding a project to use. 

    Coming to OpenID Connect, it comes along with OAuth 2.0, being an identity layer on top of its protocol. It helps you verify the identity of the end users along with fetching their basic profile information.

    OAuth2 JWT SSO 

    The name OAuth2 JWT SSO does clear up notions of what it actually does, all three acronyms are at work. It can work with Drupal's very own OAuth 2.0. The reason being its ability to configure Drupal so that both centralized and remote authentication services can be used. 

    Like its name suggests, it also works with JWT and SSO, which is short for Single Sign On. It can capitalise on any SSO, provided that it uses OAuth2 as its authentication framework, and JWT as its Bearer token. 

    Cookie Based Authentication

    If you have ever used a website, you would then know what a cookie actually is. Was it just today when you declined that ‘accept cookies’ request? These help a website to recognise users so that they do not have to log in again. 

    Now, web applications tend to use cookie-based authentication, which they implement differently. However, at the end of each day, they will have some cookies set up that would represent an authenticated user. A cookie is transmitted along with every request and the session is deserialized from a store. 


    More than 20,000  sites have been reported to use this very module. It is known to be fully feature-packed, its maintainers have the same thoughts. 

    Coming to its abilities, REST UI provides an interface to configure Drupal 8’s REST module. Due to its handy configuration, you won’t find a need to play with Drupal’s configuration import page. This fact not only benefits the novice Drupal users, but also expedites your configuration by a substantial time margin. You can simply install it by using the default approach, Drush or the Drupal Console. 


    REST API is pretty versatile in its features and Drupal has all the necessary modules to consume it in an optimised manner. If you had to choose a thread to hold your front and backend together, I would say that REST API would not let you down. However, that would only be possible, if you know how to capitalise it using Drupal. I hope I would have enlightened you about the same through this blog. To learn about other web services available in Drupal in addition to REST, read about GraphQL and JSON:API.

    blog banner blog image REST API JSON API GraphQL Decoupled Drupal Drupal RESTful Web Services Blog Type Articles Is it a good read ? On

    Promet Source: Texas Sees Sharp Rise in Rate of ADA Lawsuits

    2 days 4 hours ago
    As ADA Accessibility standards adjust to the digital age, websites and all digital properties need to adhere to the latest accessibility compliance standards.  Legal action in Texas pertaining to ADA web accessibility non compliance has been on a particularly sharp trajectory. In 2019, Texas saw 239 ADA Title III lawsuits, up from 196 in 2018. This represents a 21.9 percent increase in Texas, and many other states have seen similar or even greater increases in their case volume.

    Amazee Labs: A Look at the Underlying Automation of our Managed Web Maintenance Services - Pt. 2

    4 days 12 hours ago
    <img src="https://www.amazeelabs.com/sites/default/files/styles/leading_image/public/images/current-affairs/Automated-Maintenance-Blog-Part-2.png?h=994a2424&amp;itok=omrvmCBM" width="1120" height="630" alt="Amazee Labs - A Look at the Underlying Automation of our Managed Web Maintenance Services - Part 2" title="A Look at the Underlying Automation of our Managed Web Maintenance Services" class="image-style-leading-image" /> Part 2 - Web Maintenance & Automation

    OpenSense Labs: Why Is GraphQL an Important Player in Decoupled Drupal?

    4 days 17 hours ago
    Why Is GraphQL an Important Player in Decoupled Drupal? Gurpreet Kaur Fri, 11/20/2020 - 11:19

    Drupal is a renowned name when it comes to website development. The kind of features and control it allows you to have on your content is quite impressive. The traditional Drupal architecture has repeatedly proven to be valuable and now it is the time for Decoupled Drupal architecture to do the same, which it is on the path of doing. A major reason for the increasing popularity and adoption of the decoupled Drupal is the freedom to make the front-end using the technologies you like.

    Since the Decoupled Drupal architecture separates the presentation layer from the backend content, an API becomes the thread that holds the two together to work in sync. So, it is important to choose the right one for your project. While REST API and JSON: API are quite sought after, GraphQL has also emerged as a front runner. So, let us find out what exactly GraphQL is, what it can do and how it plays in the Decoupled Drupal architecture’s picture.

    Decoding GraphQL 

    GraphQL, a query language, came into being about eight years ago, however, its popularity came through in 2016, when it was made open-source. Its founder, Facebook, created a unique API because they needed a program to fetch data from the entirety of its content repository. It is a system that is easy to learn and equally easy to implement, regardless of the massive proportions of data you may have or the massive number of sources you may want to go through. 

    When I said that GraphQL is a query language, I meant just that. It is a language that will answer all your queries for data using its schema, which can easily be deployed using GraphiQL, an Integrated Development Environment. GraphQL, being a language specific for APIs, is equipped to manipulate data as well with the help of a versatile syntax. The GraphQL syntax was created in a way that it is able to outline the requirements and interactions of data to your particular needs. The shining glory of GraphQL is that you only get what you have asked for, nothing more, nothing less. This means that the application will only work towards retrieving data that is of the essence in the request. The data might have to be loaded from varying sources, but it will still be accurate and precise, succinct to the T and exactly what you sought.

    With decoupling becoming a need now more than ever and content and presentation layers segregating from each other, GraphQL becomes the answer for all data queries, essentially becoming the answer for data retrieval for your API and your web application. A query language and a runtime to fulfil every query within your existing data, GraphQL is powered to paint a complete and totally understandable description of your data using the API. Its robust developer tools have proven to make APIs faster, more flexible and extremely friendly to our developer friends. Therefore, achieving decoupling becomes extremely easy as GraphQL provides typed, implementation agnostic contracts amongst systems. 

    GraphQL vs JSON:API vs REST API

    The power and assistance of APIs have become all the more conspicuous in the decoupled world. With three prominent names taking the lead here, it becomes somewhat tricky to get to the right API conclusion. GraphQL, JSON:API and REST API, all three have their own virtues making them great at whatever they intend to do. However, it becomes almost impossible to talk about one and ignore the other two. My writing would not have been complete without a comparison of the three.

    If you look at the core functionality of these three APIs, you will realise that GraphQL and JSON: API are much more similar to each other than REST API, which is a whole other ball game compared to them. Let us look at them.

    Parameters GraphQL JSON: API REST API How much data is  retrieved?  Does not over-fetch data  Does not over-fetch data  Inundates the user with unnecessary proportions data  How is the API explored? Has best API exploration due to GraphiQL Uses a browser to explore the API  Relatively does not perform well and the navigable links are rarely available How is the schema documentation? Perfect auto-generated documentation and reliable schema Depends on OpenAPI standard and JSON:API specification only defines generic schema Depends on OpenAPI standard How do the write operations work? Write operations are tricky Write operations come with complete solutions Writes can become tedious with multiple implementations How streamlined it can be during installation and configuration? Provides numerous non-implementation specific developer tools but is low on scalability and security Provides numerous non-implementation specific developer tools and is high on scalability and security Provides numerous tools, but they require specific implementations and come with good scalability and high security GraphQL

    With GraphQL and its distinct fields of query, the developer is asked to specify each and every desired resource in these fields. You might be wondering why? The answer lies in its exactness. It is because of these explicitly mentioned desires that GraphQL never over-fetches data.

    Coming to API exploration, GraphQL takes the cake for being the simplest and most conclusive. The fact that a GraphQL query comes with suggestions that can be auto-completed justifies my earlier claim. Moreover, the results are shown alongside the query resulting in smooth feedback. Its in-house IDE, GraphiQL, also helps in generating iterations of the queries, aiding the developers even more. 

    If you told me that GraphQL specifications are more equipped at handling reads than writes, I would not object to you. Its mutations require you to create a new custom code every time. You can probably tell how much of a hassle it can be. Regardless, GraphQL can easily support bulk write operations that have already been implemented.

    In terms of scalability, GraphQL requires additional tools to capitalise on its full potential and there are certainly numerous developer tools made available, and all of them are not implementation-specific.

    JSON: API 

    The problem of over-fetching is not witnessed with JSON:API as well. Its sparse fieldsets produce an output similar to GraphQL. However, unlike GraphQL’s uncacheable requests, JSON: API can omit the sparse fieldsets when they become too long and hence, can cache even the longest requests. 

    With JSON: API, the explorations are simple as well; as simple as browsing within a web browser, which is basically what the API acts like here. From scouring through different resources to different fields and debugging, you can do all of that with your browser. Can data retrieval be simpler?

    In terms of writings, JSON: API is probably the best out of the bunch. It offers a wholesome solution for handling writes by using POST and PATCH requests. Even though bulk support is not available at the moment, it is in the works and would soon be in use.

    JSON: API is again similar to GraphQL as it also provides various developer tools that are not implementation-specific. The fact that its infrastructure resembles that of a website, requiring Varnish and CDN, makes it different from the former. 


    REST API has probably the most over-fetching system going on. Not only does it mandate multiple requests for one piece of content, it would also give you responses that are often even beyond the threshold of verbose. And the data that you end up with is so much more that you asked and needed. 

    Again, REST API is completely different from the other two in terms of data exploration. And sadly, this isn’t a good kind of different. REST API is highly dependent on an OpenAPI standard, and if you are not adhering to that, things would seem a tad bleak for you. You will not be able to trust it for an auto-generated documentation or a validatable and programmable schema. The navigation through high volumes of data seeking interactivity is not too impressive either. 

    Writing data in REST API is quite easy, almost as easy as reading it. Using POST and PATCH requests, every implementation is unique. Bulk support is not on the table. 

    REST API’s infrastructural needs also resemble that of an ordinary website encompassing Varnish or CDN. However, its additional tools, although many, mandate customisation before implementation.

    The GraphQL and Decoupled Drupal Dynamic 

    GraphQL is a language that is undergoing developments as I am writing and you will be reading, but that does not mean that it is unstable. Moreover, GraphQL is being capitalised by several Drupal websites. The exactness in responses along with the always available introspection layer makes GraphQL truly worth it.

    Let us now understand how it is the perfect answer to Decoupled Drupal by asking all the right questions or shall I say queries?

    How does Drupal fully capitalise GraphQL?

    Drupal can be rigid, it is a fact all of us know. Apart from this, Drupal can also seem to be too much with everything it has to offer. What GraphQL does is, it gives you the ability and the power to create and expose a custom schema that would eventually become the only roadway to all the data; information, operations and interactions, whatever happens within the system. And then, Drupal does not seem to be too rigid. 

    You get a GraphQL module in Drupal  which is designed around webonyx or graphql-php. What this means is that the module is basically as jam-packed with features as the actual language is with all the GraphQL specifications.

    • The module can be used as the basis for creating your very own schema by generating a custom code;
    • The module can also be used to extend the already existing schema with the use of the plugin architecture, wherein the plugin would act as the sub-module.
    • To aid development even more, GraphiQL is also included at /graphql/explorer, which acts as a user interface for you.
    • Lastly, there are built-in debugging tools that are competent to issue queries and analyse their responses and that too in real time.

    GraphQL is a powerful tool and Drupal has ensured that all its community can easily tap into its power.

    The GraphQL Twig module is the next advancement in Drupal. It was and generally is thought that GraphQL queries can only be sent over HTTP, but that isn't true. It can be, but there are other ways as well and this module personifies that. You can segregate the Twig templates from the internal structures of Drupal, so that maintenance and reuse is easier without any involvement of HTTP.

    Should we use GraphQL or JSON:API or REST in Drupal?

    Before getting into why GraphQL, we have to understand why not REST and what are its limitations. First of all, REST UI is absolutely important to set up the REST module in Drupal. Not to forget, it can be pretty arduous to configure it. In addition, the primary problem with REST is that it over fetches information, bombarding you with data you do not even need and certainly did not ask for. You might have just needed the title of an article, but the author’s user id is also included in the response list. This leads to a cycle of follow-up queries and you end up with the article’s title, link, its author’s name, his information and the entire content of the said article. Over-fetching is putting it lightly.

    Because GraphQL uses the APIs in a more simplistic way, it becomes better than REST endpoints. The former does not expose single resources with fixed data structures and links between them, rather it provides you the opportunity to request any selection of data that you may need. You can easily query multiple resources on the server side simultaneously, consequently combining the different pieces of data in one single query. Hence, your work as a front-end developer becomes as easy as pie. You could still go for REST, if you wanted, it does have its own set of merits

    Now coming to choosing between JSON: API and GraphQL, this is a more difficult choice to make. These two perform at a level parallel to each other. For instance, installing the JSON: API module is a piece of cake with absolutely no configuration required. As for GraphQL, the installation is easy as well, but there is a need for some configuration. Do you see why I said the choice was difficult?

    Where decoupling is concerned, JSON: API and GraphQL are much better than REST. Server-side configuration is not required by the clients to perform content queries. While JSON: API has the default setting of altering every client-generated query, GraphQL mandates the permissions to be held by the consumer so that he can forego any access restrictions. There is no right or wrong method here, both have the right filtering tools for decoupling and both are security for your content.

    When is the GraphQL module the most suitable?

    Only fetching the data that is asked for should be the tagline of GraphQL and that is why in scenarios where you need data retrieval, it becomes quite handy.

    • Decoupled Drupal applications, with Drupal as the content repository and a React, Angular or Ember powered front-end.
    • Mobile applications, wherein data storage is the need of the hour.
    • Internet of Things data storage.
    • If you want to retrieve the JSON data from Drupal.
    • And also if you plan to use the Twig Templates in Drupal themes.

    The GraphQL module would be perfect in all of these instances.

    Why do GraphQL and Drupal fit so well?

    GraphQL is considered to be an excellent fit for Decoupled Drupal websites, especially if they comprise entities as fields for stored data and these fields have relationships with other entities. GraphQL helps you curate queries for just the fields you need from the Article. This kind of flexibility makes it easy to restructure an object you wanted back, helping you to change the display as well. You can write queries, add or remove fields from the results and you can do all of this without writing a code on the backend.  The GraphQL module’s ability to expose every entity including pages, users and customer data makes all of this seem quite simple. So, it would be suffice to say that the decoupling experience would not be the same without GraphQL.

    Has GraphQL impacted the conventional server-client relationship?

    Traditionally, the server was the dominant in the server-client relationship, however, now the client holds more power and GraphQL has made certain of this. With it, the client need not follow everything the server imposes, it can simply enunciate its needs on a per-request basis. After the server would show the data possibilities it is equipped to fulfil, it would be extremely easy for the client to define its needs with the catalogued possibilities at the forefront. The shape of the values GraphQL API inserts and returns is every bit the same.

    On top of these, GraphQL taps into the deeply nested relational data structures, which are suitable for graph models. The abilities of GraphQL schema and query validation ensures that it can prevent distributed denial-of-service attacks, thereby preventing attempts at overloading queries. The benefits of GraphQL in Drupal are indeed far and many.

    What Will the Future Look Like?

    GraphQL is not a part of Drupal Core, being an advanced tool that is a little more complex to use. The future is not showing any signs of it becoming one either. However, there are other aspects to look forward to. GraphQL v4 for Drupal is one of the most awaited releases of the GraphQL module. It would bring along numerous improvements for the module that seems to be perpetually evolving. GraphQL schema will be in total control of Drupal developers, since schema customisation was the holy grail of this module, things are looking up and the future brighter. GraphQL and Drupal have a long way to go.

    blog banner blog image GraphQL Drupal Decoupled Drupal REST API RESTful Web Services JSON API Drupal Web Services Blog Type Articles Is it a good read ? On

    Nonprofit Drupal posts: November Drupal for Nonprofits Chat

    5 days 8 hours ago

    Our normally scheduled call to chat about all things Drupal and nonprofits will happen TODAY, Thursday, November 19, at 1pm ET / 10am PT. (Convert to your local time zone.)

    No set agenda this month, so we'll have plenty of time to discuss whatever Drupal-related thoughts are on your mind. 

    All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

    Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes

    This free call is sponsored by NTEN.org and open to everyone.

    View notes of previous months' calls.

    Mediacurrent: How to Secure Your Website: An Intro to Drupal Security

    5 days 9 hours ago

    Is Drupal’s open source platform secure?

    When deciding on the best CMS to meet your organization’s digital vision, security is often one of the top concerns. 

    Here’s the reality. ALL software (closed source, open source, or custom-developed) has the potential for security vulnerabilities. Web security is a fast and ever-changing world. What passes today as secure code may not stay the same tomorrow when new vulnerabilities surface.

    There's peace of mind in knowing not only is Drupal a proven, secure CMS but that it's also in an active state of safeguarding against attacks. 

    With proper planning, maintenance, and updating, open source software, like Drupal, can meet and even exceed the security standards of closed source. 

    - Mediacurrent’s Mark Shropshire, Senior Director of Development, quoted in an excerpt from Setting the Record Straight on Drupal Myths: Acquia eBook 

    Security and The Drupal Community

    Open source software, like Drupal, has the bonus of having thousands of experts work on a particular problem. With entire teams and methodology devoted to ensuring its steadfast reputation as a secure CMS, it's comforting to know modules and code procured from the official Drupal site are as secure as possible.

    Using Drupal means you never have to face these risks alone, let alone attempt to correct the problem by yourself. There's power in numbers when it comes to both discovering and fixing potential software flaws, and the Drupal community has those numbers.

    Dedicated Security Team

    The Drupal project has an approximately 30-person security team with a history of professionally handling security advisories. 

    Community Code Review

    One of the largest developer communities in the world, Drupal.org clocked 100,000 contributors and 1.3 million users at the time of Drupal 9’s release. Having many eyes on the source code ensures more issues are discovered and resolved. 

    Rapid Response Time

    Defined processes around reporting and resolving security issues accelerate the response time to fix vulnerabilities and release patches. 

    Core Security

    Core API tools and techniques address common security risks. Community projects such as the Guardr distribution help educate the community on best practices around Drupal security.

    The Guardr distribution was created to enhance a Drupal application's security and availability to meet enterprise security requirements.

    Proven High Standards 

    Drupal-based organizations around the world — including enterprise-level brands, major universities, government, and large non-profits — put Drupal’s high security standards to the test every day.

    Drupal Security Throughout the Website Process

    The Drupal community has built-in security measures to combat threats — reassuring for sure. To proactively protect your site, the concept of security needs to be at top of mind when campaigns are being launched, systems/applications are being integrated, or when software is deployed or updated. 


    A security-first approach means going beyond compliance to better assess risk. There are two paths to achieve this approach:

    1) Culture: Adopting a security mindset culture for your organization. 

    2) Automation: Taking on a continuous development plan that’s rooted in process automation.

    In other words, start planning for security early and often throughout the website development process. 

    Don’t wait until the project is about to launch to think about security! Explore our Guide to Open Source Security eBook for tips and processes to consider when putting together a security-first maintenance plan for your website and marking tech stack.

    Developer Best Practices 

    Here are three ways to safeguard your Drupal site: 

    1. Choose the Right Modules

    If you can dream up a feature for your site, chances are it can be found in the tens of thousands of community-contributed modules available for Drupal. With so many different options to pick from, how do you choose the most secure modules possible? Some steps to take are checking for how many sites are using the module, reviewing the issue queues, and avoiding deprecated or unsupported modules. 

    Find more criteria for module decision-making in our Guide to Drupal Module Evaluation

    2. Use Drupal APIs

    Look to Drupal APIs documentation to secure your contrib or custom code on a project. Drupal APIs have been nurtured by the community and have built-in protections for database security. If you do write new code, whether it’s a small amount or a completely new module, the Writing Secure Code for Drupal is a must-see reference guide. 

    3. Monitor Drupal Security Advisories 

    The Drupal security team posts weekly security advisories to Drupal.org.

    To keep up with security releases, you can  sign up for email or RSS notifications, follow @drupalsecurity on Twitter, or join the Drupal Slack #security-questions

    Sleep Better With a Secure Drupal Site 

    For more best practices, check out the Mediacurrent presentation Sleep Better with a Secure Drupal Site: 

    Are you ready to build a strong foundation for Drupal security but unsure where to start? There's a lot to consider in your security plan but it doesn't have to keep you up at night. Contact the Mediacurrent Security team for support. 

    Vardot: Drupal Powered Elections in Jordan

    5 days 15 hours ago
    Drupal Powered Elections in Jordan Image Firas Ghunaim Marketing Manager Thursday, November 19, 2020 - 09:58 Teaser image Drupal Powered Elections in Jordan Comments Solutions by industry Government Nonprofits and NGOs Solutions by need Enterprise CMS Drupal Managed Services On-Site SEO Related services Web Development Support and Maintenance Drupal Migration and Upgrades DevOps and Engineering Digital Marketing UI/UX Design Digital Strategy Product Varbase Vote up! 0 claps

    Nextide Blog: Medical Applications with Drupal

    6 days 3 hours ago

    In our blog post about Innovating Healthcare with Drupal, we talked about using Drupal to deliver an application that improves the healthcare experience for palliative care patients.  Our application was a resounding success.  The global COVID-19 pandemic hits and the need to keep people out of the Emergency Rooms to stop the spread of the Coronavirus suddenly becomes urgent.  To move the Drupal application out of tightly controlled pilots to a more widely distributed application requires adherence to HIPAA (USA) and PIPEDA (Canada) guidelines to safeguard patient information.  Unfortunately, the tried and tested Drupal DevOps and hosting environments we’ve become accu

    Aten Design Group: Expressive Authoring with Layout Paragraphs

    6 days 5 hours ago
    Expressive Authoring with Layout Paragraphs Justin Toupin Wed, 11/18/2020 - 11:30 Drupal User Experience The Authoring Experience Problem

    Authoring experience is a huge concern for web teams everywhere. As it should be. The ability for digital publishers to keep up with the rapidly accelerating demands of their users, and the pace of their competitors, largely depends on providing easy-to-use, expressive tools for their teams to create compelling content.

    In practice, this means that publishers need the ability to quickly produce rich digital content from a range of possible components: text, images, videos, social media assets, and so on. Authors should be able to mix various elements quickly and effortlessly, with simple controls for managing content flow and layout. Under the hood, content should be structured and predictable. We’ve written about this before: organizations cannot sacrifice structure for flexibility. They need both.

    And yet authoring experience has been a major shortcoming of Drupal, often articulated by marketing and editorial leaders as, “Drupal is too complicated for my organization.”

    Other platforms from across the entire spectrum of digital publishing systems – from Adobe Experience Manager to Wordpress, Squarespace to WiX – provide rich, intuitive tools for easily creating all kinds of digital content. What Drupal offers in terms of flexibility – powerful APIs, easily customizable structured content, and a huge range of content management features – has come at the expense of the authoring experience.

    Layout Paragraphs

    A while ago I wrote about Entity Reference with Layout (or ERL), a Drupal 8 module that combines Paragraphs with the Layout API for a more flexible, expressive authoring experience in Drupal. ERL had one concerning drawback: you had to use a special field type for referencing paragraphs. That means ERL wouldn’t “just work” with existing paragraph fields.

    Layout Paragraphs, the successor to ERL, fixes that problem. The Layout Paragraphs module combines Drupal Paragraphs with the Layout API and works seamlessly with existing paragraph reference fields.

    Video file

    The Layout Paragraphs module makes it dead simple for authors to build rich pages from a library of available components. It offers drag-and-drop controls for managing content flow and layout, and works seamlessly with existing paragraph reference fields.

    Layout Paragraphs features include:

    • Easily configure which content components, or paragraph types, are available to your authors wherever Layout Paragraphs is used.
    • A highly visual, drag-and-drop interface makes it simple to manage content flow and layout.
    • Site admins can easily configure Layout Paragraphs to support nested layouts up to 10 levels deep.
    • A “disabled bin” makes it easy to temporarily remove content elements without deleting them.
    • Layout Paragraphs works seamlessly with existing paragraph reference fields.
    • Authors can easily switch between different layouts without losing nested content.
    • Layout Paragraphs is fully customizable and works with Layout Plugins, Paragraph Behaviors, and other Drupal APIs.
    What About Layout Builder?

    While there are strong similarities between Layout Paragraphs and Layout Builder, Layout Paragraphs solves a fundamentally different problem than Layout Builder.

    Layout Builder, in Drupal core, is a powerful system for managing layouts across an entire website. With Layout Builder, site administrators and content managers can place content from virtually anywhere (including custom blocks) within specific regions of a layout. Layout Builder is extremely powerful, but doesn’t directly solve the problem I mentioned above: “Drupal is too complicated for my organization.”

    Layout Paragraphs adds a new interface for effortlessly managing content using Drupal Paragraphs. It is simple, fast, and expressive. Layout Paragraphs is a field widget, and works the same way as other Drupal fields. The Layout Paragraphs module makes it simple for publishers to create and manage rich content from a library of available components: text, images, videos, etc. Layout Paragraphs is completely focused on the authoring experience.

    Try It Out

    If you want to see Layout Paragraphs in action, simply download the module and give it a try. Setup is fast and easy. From the Layout Paragraphs module page:

    1. Make sure the Paragraphs module is installed.
    2. Download/Require (composer require drupal/layout_paragraphs) and install Layout Paragraphs.
    3. Create a new paragraph type (admin > structure > paragraph types) to use for layout sections. Your new paragraph type can have whatever fields you wish, although no fields are required for the module to work.
    4. Enable the “Layout Paragraphs” paragraph behavior for your layout section paragraph type, and select one or more layouts you wish to make available.
    5. Make sure your new layout section paragraph type is selected under “Reference Type” on the content type’s reference field edit screen by clicking “edit” for the respective field on the “Manage fields” tab.
    6. Choose “Layout Paragraphs” as the field widget type for the desired paragraph reference field under “Manage form display”.
    7. Choose “Layout Paragraphs” as the field formatter for the desired paragraph reference field under “Manage display”.
    8. That’s it. Start creating (or editing) content to see the module in action.

    If you’re using Layout Paragraphs in your projects, we’d love to hear about it. Drop a note in the comments section below, or get involved in the issue queue.

    Read This Next Justin Toupin

    Chapter Three: Drupal Backender Learns Gatsby: Core JSON:API vs GraphQL 3

    6 days 5 hours ago

    At BADCamp 2019 I attended Michael Schmid’s presentation on decoupled web site building and hosting. There, I learned about the GraphQL module that's been developed to do decoupled Drupal, instead of JSON:API. When I first started experimenting with Gatsby I decided to try it, not really knowing anything about GraphQL at the time. This made my experience trickier than it needed to be. As it turned out, all the tutorials and examples I could find for Drupal + Gatsby had query examples for gatsby_source_drupal with JSON:API. Once I got my head around GraphQL though, things were pretty slick.

    Four Kitchens: Don’t Let a Bare-Bones Backend Design Leave Your Site Editors Stranded

    6 days 5 hours ago

    From the consumer perspective, there’s never been a better time to build a website. User-friendly website platforms like Squarespace allow amateur developers to bypass complex code and apply well-designed user interfaces to their digital projects. Modern site-building tools aren’t just easy to use—they’re actually fun.

    For anyone who has managed a Drupal website, you know the same can’t be said for your platform of choice. While rich with possibilities, the default editorial interface for Drupal feels technical, confusing, and even restrictive to users without a developer background. Consequently, designers and developers too often build a beautiful website while overlooking its backend CMS.

    Drupal’s open-ended capabilities constitute a competitive advantage when it comes to developing an elegant, customer-facing website. But a lack of attention to the needs of those who maintain your website content contributes to a perception that Drupal is a developer-focused platform. By building a backend interface just as focused on your site editors as the frontend, you create a more empowering environment for internal teams. In the process, your website performs that much better as a whole.

    UX principles matter for backend design as much as the frontend

    Given Drupal’s inherent flexibilities, there are as many variations of CMS interfaces as there are websites on the platform. That uniqueness is part of what makes Drupal such a powerful tool, but it also constitutes a weakness.

    The editorial workflow for every website is different, which opens an inevitable training gap in translating your site’s capabilities to your editorial team. Plus, despite Drupal’s open-source strengths, you’ll likely need to reinvent the wheel when designing CMS improvements specific to your organization.

    For IT managers, this is a daunting situation because the broad possibilities of Drupal are often overwhelming. If you try to make changes to your interface, you can be frustrated when a seemingly easy fix requires 50 hours of development work. Too often, Drupal users will wind up working with an inefficient and confusing CMS because they’re afraid of the complexity that comes with building out a new interface.

    Fortunately, redesigning your CMS doesn’t have to be a demanding undertaking. With the right expertise, you can develop custom user interfaces with little to no coding required. Personalized content dashboards and defined roles and permissions for each user go a long way toward creating a more intuitive experience.

    Improving your backend design is often seen as an additional effort, but think of it as a baseline requirement. And, by sharing our user stories within the Drupal community, we also build a path toward improving the platform for the future.

    Use Drupal’s Views module to customize user dashboards

    One of the biggest issues with Drupal’s out-of-the-box editorial tools is that they don’t reflect the way any organization actually uses the CMS. Just as UX designers look to provide a positive experience for first-time visitors to your site, your team should aim for delivering a similarly strong first impression for those managing its content.

    By default, Drupal takes users to their profile pages upon login, which is useful to . . . almost no one. Plus, the platform’s existing terminology uses cryptic terms such as “node,” “taxonomy,” and “paragraphs” to describe various content items. From the beginning, you should remove these abstract references from your CMS. Your editorial users shouldn’t have to understand how the site is built to own its content.

    In the backend, every Drupal site has a content overview page, which shows the building blocks of your site. Offering a full list that includes cryptic timestamps and author details, this page constitutes a floodgate of information. Designing an effective CMS is as much an exercise in subtraction as addition. Whether your user’s role involves reviewing site metrics or new content, their first interaction with your CMS should display what they use most often.

    If one population of users is most interested in the last item they modified, you can transform their login screen to a custom dashboard to display those items. If another group of users works exclusively with SEO, you can create an interface that displays reports and other common tasks. Using Drupal’s Views module, dashboards like these are possible with a few clicks and minimal coding.

    By tailoring your CMS to specific user habits, you allow your website teams to find what they need and get to work faster. The most dangerous approach to backend design is to try and build one interface to rule them all.

    Listen to your users and ease frustrations with a CMS that works

    Through Drupal Views, you can modify lists of content and various actions to control how they display in your CMS. While Views provides many options to create custom interfaces, your users themselves are your organization’s most vital resource. By watching how people work on your site, you can recognize areas where your CMS is falling short.

    Even if you’ve developed tools that aimed to satisfy specific use cases, you might be surprised the way your tools are used. Through user experience testing, you’ll often find the workarounds your site editors have developed to manage the site.

    In one recent example, site editors needed to link to a site page within the CMS. Without that functionality, they would either find the URL by viewing the source code in another tab and copying its node ID number. Anyone watching these users would find their process cumbersome, time-consuming, and frustrating. Fortunately, there’s a Drupal module called Linkit that was implemented to easily eliminate this needless effort.

    There are many useful modules in the Drupal ecosystem that can enhance the out-of-the-box editorial experience. Entity Clone expedites the content creation process. Views Bulk Operations and Bulk Edit simplify routine content update tasks. Computed Field and Automatic Entity Label take the guesswork out of derived or dependent content values. Using custom form modes and Field Groups can help bring order and streamline the content creation forms.

    Most of the time, your developers don’t know what solutions teams have developed to overcome an ineffective editorial interface. And, for fear of the complexity required to create a solution, these supposed shortcuts too often go unresolved. Your backend users may not even be aware their efforts could be automated or otherwise streamlined. As a result, even the most beautiful, user-friendly website is bogged down by a poorly designed CMS.

    Once these solutions are implemented, however, you and your users enjoy a shared win. And, through sharing your efforts with the Drupal community, you and your team build a more user-friendly future for the platform as well.

    The post Don’t Let a Bare-Bones Backend Design Leave Your Site Editors Stranded appeared first on Four Kitchens.

    7 hours 6 minutes ago
    Drupal.org - aggregated feeds in category Planet Drupal
    Subscribe to Drupal Planet feed
  • Dries

    Acquia switches from Marketo to Campaign Studio (aka Mautic)

    1 week ago

    When Acquia acquired Mautic Inc (now named Acquia Campaign Studio), we believed that the world needed to move beyond closed, legacy marketing solutions like Marketo.

    At the time of the acquisition, Acquia was a Marketo user. As of November 2020, Acquia moved completely off Marketo to Campaign Studio.

    While this move probably won't come as a surprise, it still is an important milestone for us. Marketo was a critical part of Acquia's marketing operations.

    The freedom to innovate

    Our marketing team needed flexibility to experiment with new technologies. Marketo limited them to using integrations within its own ecosystem. With an Open Source solution like Acquia Campaign Studio, we took charge of our own destiny. We can now build all the integrations and customer experiences we want.

    Thinking beyond email

    Today, almost every interaction with a customer is multi-faceted. Customers may be using mobile, voice, chat or any number of other channels. Marketo still only includes email in its communications offering. With Campaign Studio, Acquia can reach customers and prospects through multichannel communications, including email, direct social messages, SMS, web notifications and more.

    Enterprise features without complexity

    Many enterprise software tools (Marketo included) lock customers into their proprietary ecosystems. Getting data out of these platforms is much harder than getting it in. This is one of the reasons why it took some time to migrate off Marketo. It feels great to take control back over our own data.

    Embracing open marketing

    Overall, an open approach to marketing will provide Acquia with many advantages. We're no longer locked into a vendor's roadmap and limited partner ecosystem. Instead, we can move quickly to create the exact solution we need to make our customers' experiences better and more personal.

    Many technology solutions shape what you can do for the customer experience. Starting today, we're letting the customer experience shape the solution.


    Who sponsors Drupal development? (2019-2020 edition)

    2 weeks 1 day ago

    For the past few years, I've examined Drupal.org's contribution data to understand how the Drupal project works. Who develops Drupal? How diverse is the Drupal community? How much of Drupal's maintenance and innovation is sponsored? Where do sponsorships come from?

    The report might be of interest even if you don't use Drupal. It provides insights into the inner workings of one of the largest Open Source projects in the world.

    This year's report shows that:

    • The recorded number of contributions increased year over year.
    • More and more contributions are sponsored, but volunteer contributions remain important to Drupal's success.
    • Drupal's maintenance and innovation depends mostly on smaller Drupal agencies and Acquia. We don't see many contributions from hosting companies, multi-platform digital agencies, system integrators or end users.
    • Drupal's contributors have become more diverse, but are still not diverse enough.

    You can also look at the 2016 report, the 2017 report, the 2018 report, and the 2019 report.

    Methodology What data did we analyze?

    We looked at all Drupal.org issues marked "closed" or "fixed" in the 12-month period from July 1, 2019 to June 30, 2020. This for Drupal core and all contributed projects, across all major versions of Drupal.

    What are Drupal.org issues?

    Each "Drupal.org issue" tracks an idea, feature request, bug report, task, or more. It's similar to "issues" in GitHub or "tickets" in Jira. See https://www.drupal.org/project/issues for the list of all issues.

    What are Drupal.org credits?

    In the spring of 2015, I proposed some ideas for how to give credit to Drupal contributors. A year later, Drupal.org added the ability for contributors to attribute their work to an organization or customer sponsor, or mark it the result of volunteer efforts.

    A screenshot of an issue comment on Drupal.org. You can see that jamadar worked on this patch as a volunteer, but also as part of his day job working for TATA Consultancy Services on behalf of their customer, Pfizer.

    Drupal.org's credit system is unique and groundbreaking within the Open Source community. It provides unprecedented insights into the inner workings of a large Open Source project. There are a few limitations with this approach, which we'll address at the end of this report.

    What is the Drupal community working on?

    In the 12-month period between July 1, 2019 and June 30, 2020, 31,153 issues were marked "closed" or "fixed", a 13% increase from the 27,522 issues in the 2018-2019 period. This averages out to 85 issues marked "closed" or "fixed" each day. This is compared to 75 issues in 2018-2019.

    In total, the Drupal community worked on 4,195 different Drupal.org projects this year compared to 3,474 projects in the 2017-2018 period — a large 20% year-over-year increase. I attribute the larger than normal growth to the Drupal 9 release.

    Time period Number of issues "fixed" or "closed" by day Number of projects worked on 2017 - 2018 67 3,229 2018 - 2019 75 3,474 2019 - 2020 85 4,195

    The majority of the credits are the result of work on contributed modules:

    Compared to the previous period, contribution credits increased across all project types:

    It is nice to see the "non-product credits" grow. More and more members in the community track credits for non-product contributions. These include organizing Drupal events, presenting at Drupal events, promoting Drupal, mentoring, and more. While some of these increases reflect new contributions, others are existing contributions that are newly reported. The fact that the credit system is becoming more accurate in recognizing more types of Open Source contributions is both important and positive.

    Who is working on Drupal?

    For this report's time period, Drupal.org's credit system received contributions from 8,303 different individuals and 1,216 different organizations. We saw a 2.5% decline in individual contributors, but a 7% increase in organizational contributors.

    Consistent with previous years, approximately 50% of individual contributors received one credit. Meanwhile, the top 30 contributors (the top 0.4%) account for 20% of the total credits. In other words, a small number of individuals do the majority of the work.

    Starting last year, I weighted each credit based on the adoption of the project the credit is attributed to. For example, each contribution credit to Drupal core is given a weight of 10 because Drupal core has about 1 million active installations. Credits to the Webform module, which has over 470,000 installations, get a weight of 4.7. And credits to Drupal's Commerce project get 0.6 points, as it is installed on around 60,000 sites.

    The idea is that these weights capture the end user impact of each contribution, but also act as a proxy for the effort required to get a change committed. Getting a change accepted in Drupal core is both more difficult and more impactful than getting a change accepted to a much smaller, contributed project.

    This weighting is far from perfect, but so is the unweighted view. For code contributions, the weighted chart may be more accurate than a purely unweighted approach. I included both charts:

    No matter how you look at the data, all these individuals put an incredible amount of time and effort into Drupal.

    It's important to recognize that most of the top contributors are sponsored by an organization. We value the organizations that sponsor these remarkable individuals. Without their support, it could be more challenging to contribute.

    How much of the work is sponsored?

    When people contribute to Drupal, they can tag their contribution as a "volunteer contribution" or a "sponsored contribution". Contributions can be marked both volunteer and sponsored at the same time (shown in jamadar's screenshot near the top of this post). This could be the case when a contributor does paid work for a customer, in addition to using unpaid time to add extra functionality or polish.

    For those credits with attribution details, 15% were "purely volunteer" (8,429 credits). This is in stark contrast to the 69% that were "purely sponsored" (37,399 credits). Put simply, roughly two-thirds of all contributions are "purely sponsored".

    This is the first time in Drupal's history that "purely volunteer" contributions stayed flat year over year. This might be related to COVID-19; coding sprints are harder to organize, people may have lost income, parents are busy home-schooling their children, people have Zoom-fatigue, and times are generally stressful. In contrast, we did see a very large increase in "purely sponsored" contributions.

    Volunteer contribution remains very important to Drupal. Volunteers contribute across all areas of the project. A lot of volunteer time and energy goes towards non-product related contributions such as event organization, mentoring, and more.

    Who is sponsoring the work?

    Now that we've established that the majority of contributions are sponsored, let's study which organizations contribute to Drupal. While 1,216 organizations contributed to Drupal, 50% of them received four credits or less. The top 30 organizations (roughly the top 2.5%) account for approximately 30% of the total credits. This means that the top 30 companies play a crucial role in the health of the Drupal project.

    Similar to the individual contributors, I've ranked organizations by both "unweighted contributions" and "weighted contributions". Unweighted scores are based solely on volume of contributions, while weighted scores also try to take into account both the effort and impact of each contribution.

    If you are an end user looking for a company to work with, these are some of the companies I'd work with first. Not only do they know Drupal well, they also help improve your investment in Drupal. If you are a Drupal developer looking for work, these are some of the companies I'd apply to first.

    A variety of different types of companies are active in Drupal's ecosystem:

    Category Description Traditional Drupal businesses Small-to-medium-sized professional services companies that primarily make money using Drupal. They typically employ fewer than 100 employees. Because they specialize in Drupal, many of these companies contribute frequently and are a huge part of our community. Examples are Third & Grove, Srijan, PreviousNext, MD Systems, etc. Digital marketing agencies Larger full-service agencies that have marketing-led practices using a variety of tools, typically including Drupal, Adobe Experience Manager, Sitecore, WordPress, etc. Many of these larger agencies employ thousands of people. Examples are Wunderman, Possible, and Mirum. System integrators Larger companies that specialize in bringing together different technologies into one solution. Example system integrators are Accenture, TATA Consultancy Services, EPAM Systems, and CI&T. Hosting companies Examples are Acquia, Pantheon, and Platform.sh, but also Rackspace or Bluehost. End users Examples are Pfizer or bio.logis Genetic Information Management GmbH.

    A few observations:

    • Most of the sponsors in the top 30 are traditional Drupal businesses with fewer than 50 employees. With the exception of Acquia, Drupal's maintenance and innovation largely depends on these small Drupal businesses.
    • The larger, multi-platform digital marketing agencies are barely contributing to Drupal. Only one digital marketing agency shows up in the top 30: Intracto. Hardly any appear in the entire list of contributing organizations. I'm frustrated that we have not yet found the right way to communicate the value of contribution to these companies. We need to incentivize these firms to contribute with the same commitment that we see from traditional Drupal businesses.
    • The only system integrator in the top 30 is CI&T. CI&T is a smaller system integrator with approximately 2,500 employees. We see various system integrators outside of the top 30, including EPAM Systems, Globant, Capgemini, Publicis Sapient, Accenture, and TATA Consultancy Services. Accenture and Wipro, despite doing quite a bit of Drupal work, did not receive any credits.
    • Various hosting companies make a lot of money with Drupal, yet only Acquia appears in the top 30 with 1,823 credits. The contribution gap between Acquia and other hosting companies remains very large. It was great to see that Pantheon tripled its contributions from 43 to 122 this period. Platform.sh earned 23 credits compared to 22 in the last period. In general, there is a persistent problem with hosting companies not contributing back.
    • We only saw two end users in the top 30 this year: Thunder (815 credits) and Pfizer (201 credits). Many end users contribute though: European Commission (290 credits), bio.logis (219 credits), Google (144), University of Waterloo (111 credits), Johnson & Johnson (93 credits), University of British Columbia (91 credits), University of Texas at Austin (74 credits), NBCUniversal (48 credits), Workday (38 credits), PayPal (17 credits), and many more.

    I often recommend end users to mandate contributions from their partners. Pfizer, for example, only works with agencies that contribute back to Drupal. The State of Georgia started doing the same; they made Open Source contribution a vendor selection criteria. If more end users took this stance, it could have a big impact on Drupal. We'd see many more digital agencies, hosting companies, and system integrators contribute to Drupal.

    While we should encourage more organizations to sponsor Drupal contributions, we should also understand and respect that some organizations can give more than others — and that some might not be able to give back at all. Our goal is not to foster an environment that demands what and how others should give back. Instead, we need to help foster an environment worthy of contribution. This is clearly laid out in Drupal's Values and Principles.

    How diverse is Drupal?

    Supporting diversity and inclusion is essential to the health and success of Drupal. The people who work on Drupal should reflect the diversity of people who use the web.

    I looked at both the gender and geographic diversity of Drupal.org contributors.

    Gender diversity

    Only 10-11% of the recorded contributions were made by contributors who do not identify as men. This is a very small improvement compared to last year. The gender imbalance in Drupal is profound. We need to continue fostering diversity and inclusion in our community.

    Two years ago I wrote a post about the privilege of free time in Open Source. It made the case that Open Source is not a meritocracy. Not everyone has equal amounts of free time to contribute. For example, research shows that women still spend more than double the time as men doing unpaid domestic work, such as housework or childcare. This makes it more difficult for women to contribute to Open Source on an unpaid, volunteer basis. Organizations capable of giving back should consider financially sponsoring individuals from underrepresented groups to contribute to Open Source.

    Compared to men, women do more sponsored work, and less volunteer work. We believe this is because men have the privilege of more free time.

    Free time being a privilege is just one of the reasons why Open Source projects suffer from a lack of diversity. Other reasons include hostile environments and unconscious biases. We should consider collecting data on other systemic issues beyond gender. The Drupal Association is currently working to update demographic data collected at DrupalCon, and beyond, with the goal of better understanding our community. Knowing more about these trends could help us close existing gaps.

    Geographic diversity

    We saw individual contributors from six continents and 117 countries. The top countries:

    The top 20 countries from which contributions originate. The data is compiled by aggregating the countries of all individual contributors behind each issue. Note that the geographical location of contributors doesn't always correspond with the origin of their sponsorship. Wim Leers, for example, works from Belgium, but his funding comes from Acquia, which has the majority of its customers in North America. Wim's contributions count towards Belgium as that is his country of residence.

    Europe contributes more than North America in both absolute and relative terms.

    Contribution credits per capita calculated as the amount of contributions per continent divided by the population of each continent. 0.001% means that one in 100,000 people contribute to Drupal. In North America, almost 4 in 100,000 people contributed to Drupal the last year.

    Asia, South America, and Africa remain big opportunities for Drupal; their combined population accounts for 6.3 billion out of 7.5 billion people in the world.

    Limitations of the credit system

    It is important to note a few of the current limitations of Drupal.org's credit system:

    • The credit system doesn't capture all code contributions. Parts of Drupal are developed on GitHub rather than Drupal.org. Contributions on GitHub usually aren't credited on Drupal.org. For example, Drush is maintained on GitHub instead of Drupal.org, and companies like Pantheon don't get credit for that work.
    • The credit system is not used by everyone. There are many ways to contribute to Drupal that are still not captured in the credit system. Technically, that work can be captured. But because using the credit system is optional, many contributors don't. For example, not all event organizers and speakers capture their work in the credit system. As a result, contributions often have incomplete or no contribution credits. Where possible, we should automatically capture credits. For example, translation efforts on https://localize.drupal.org are not currently captured in the credit system, but could be automatically.
    • The credit system doesn't accurately value complexity and quality. One person might have worked several weeks for just one credit, while another person might receive a credit for 10 minutes of work. Each year we see a few individuals and organizations trying to game the credit system. In this post, I used a basic weighting system based on project adoption. In future, we should consider refining that by looking at issue priority, patch size, number of reviews, etc. This could help incentivize people to work on larger and more important problems and save smaller issues such as coding standards improvements for new contributor sprints.

    Because of these limitations, the actual number of contributions and contributors could be much higher than what we report.

    Like Drupal itself, the Drupal.org credit system needs to continue to evolve. Starting this year, the Drupal Association, with the direction of the newly formed Contribution Recognition Committee, will start to evolve and leverage the credit system in new ways.


    Our data confirms that Drupal is a vibrant community full of contributors who are constantly evolving and improving the software. It's amazing to see that just in the last year, Drupal welcomed more than 8,000 individual contributors and over 1,200 corporate contributors. It's especially nice to see the growing number of contributions year over year.

    To grow and sustain Drupal, we should support those that contribute to Drupal and find ways to get those that are not contributing involved in our community. Improving diversity within Drupal is critical, and we should welcome any suggestions that encourage participation from a broader range of individuals and organizations.

    7 hours 6 minutes ago
    Subscribe to Dries feed