Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 6 hours 29 min ago

Lullabot: Decoupled back ends in the age of brand consistency

12 July 2018 - 7:51am

It may sound surprising to hear about brand consistency from a back-end developer. This is traditionally a topic for UX and marketing experts. Nevertheless, brand consistency is a powerful trend that’s affecting how we architect content APIs.

One of the ways I contribute to the Drupal API-First Initiative, aside from all the decoupled modules, is by providing my point of view from the implementation side. Some would call that real world™ experience with client projects. This means that I need to maintain a pragmatic point of view to make sure that we can do with Drupal what clients need from us. While being vigilant on the trends affecting our industry, I have discovered that there is a strong tendency for digital projects to aim for brand consistency. How does that impact implementation?

What I mean by brand consistency

When I talk about brand consistency, I only refer to a small part of it. Picture, for a moment, the home screen of Netflix on your TV. Now picture Netflix on your browser and on the app for your phone. They all look the same, don’t they? This is intentional.

The first time I installed Netflix on my wife’s iPad I immediately knew how to use the app. It took me about a second to learn how to use a complex and powerful application on a device that was foreign to me. I am an Android person but I was able to transition from using Netflix on my phone while on the bus to my wife's iPad and from there to the living room TV. I didn’t even realize that I was doing it. Everything was seamless because all the different devices running Netflix had a consistent design and user experience.

If you are interested in the concept of brand consistency and its benefits you can learn more from actual experts on the subject. I will focus on the implications for API design.

It changes the approach to decoupled projects

For the last few years, I have been speaking at events and writing about the imperious necessity for your back end to be presentation agnostic. Consumers can have radically different data needs. You don’t want your back end to favor a particular consumer because that will lead to re-coupling, which leads to high maintenance costs for the consumers that you turned your back on.

When the UX and designs are consistent across consumers, then the statement ‘the consumers can have radically different data needs’ may no longer apply. If they really are consistent, why would the data they need be radically different? You cannot be consistent and radically different at the same time.

Many constraints, API design tips, and recommendations are based on the assumption of presentation agnosticism. While this holds true for most projects, a significant number of projects have started to require consistency across consumers. So the question is: if we no longer need to be presentation agnostic in our API design, what can we optimize given that we have a single known presentation? We made many compromises. What did we give up, and how do we get it back?

How I approached the problem

The first time that I encountered this need for unified UX across all consumers in a client project my inherent pragmatism was triggered. My brain was flooded with potential optimizations. Together with the rest of the client team, I took a breath and started analyzing this new problem space. On this occasion, the client had suggested the BFF pattern from the start. Instead of having a general-purpose API back end to serve all of your downstream consumers, you have one back end per user experience. Hence the moniker ‘Backend for Frontend’ or BFF. This was a great suggestion that we carefully analyzed and soon embraced.

What is a BFF?

Think of a BFF as a server-side service that takes care of the orchestration and processing of the different interactions with the API (or even multiple APIs or microservices) on behalf of the consumers. In short, it does what each consumer would do against your presentation agnostic API, and consolidates it on the server for presentation. The BFF produces a render-ready JSON object.

In other words, we will build a consumer in the back end, but instead of outputting HTML, CSS, and JavaScript (using the web consumer as an example) we will output a JSON document.

undefined

You can see in the code above that the shape of the JSON response is heavily influenced by the single design and the components in the frontend. This implies some rigidness on front-end differences, but we agreed that’s OK for our case. For your completely different design, the JSON output would look completely different.

How we implemented BFFs

After requirements are settled, we decide that we will have a single Backend For Frontend that will power all the consumer applications. Instead of having one BFF for each consumer, as Netflix used to do it, we will only have one. The reason is that with one we ensure brand consistency. Also, as Lee Byron puts it:

The concern of duplicating logic across different BFFs is more than just maintaining two repositories of similar code rather than one. The concern is the endless fight against accidental divergence.

Additionally, we don’t have those requirements, but the BFF is also the best place to add global restrictions like authentication, request filters, rate limits, etc.

Our team decided to implement this as a set of rigid endpoints in a Serverless [LINK] application written in NodeJS. As you can imagine, you can implement this pattern with the tools and the stack you prefer. Since this will be so specific to your project’s designs you will likely need to start from scratch.

How consumers deal with BFFs

We create this consumer in the backend in order to simplify all the possible front ends. We move the complexity of building a consumer into a central service that can be reused by all the consumers. That way we can call the consumers, dumb clients. This is because the consumers no longer need to craft complex queries (JSON API, GraphQL, or whatever else); they don’t need to aggregate 3rd party services; and they don’t need to normalize the data from the different APIs, etc. In fact, all the data is ready to render.

In our particular case, we have been able to reduce the consumers to renderers. A consumer only needs to:

  1. Process an incoming request and then determine what screen to grab from the BFF. Additionally, extract any parameters from the request, like the entity ID. In addition to that any global parameters, like the user ID from the device, are added to the parameter bag.
  2. With the name of the screen and the extracted parameters the consumer makes a single HTTP request to the BFF.
  3. The BFF responds with all the data needed for rendering in a shape ready for rendering. The consumer takes that and renders all the components.
  4. The consumer finally adds all the business logic that is exclusive of the front end on top of the rendered output. This includes ads, analytics, etc.
Pros and cons

The pros of this approach are stated throughout the document, but to summarize they are:

  • Massive simplification of the consumers. Those complex interactions with the API are in a central place, instead of having each consumer team write them, again and again, in their native language.
  • Code reuse across consumers. Bug-fixes, changing requirements, improvements, and documentation efforts apply to all consumers since much of the logic lies in the BFF now.
  • Increased performance. The backend can be optimized in numerous ways since it does not need to enable every possible design. This can mean denormalized documents in Elastic Search with the pre-computed responses, increased cache hit ratios in calls to APIs now that we control how those are made, faster server-to-server communications for 3rd party API aggregation, etc.
  • Frontend flexibility. We can ship new features faster when front ends are dumb clients and just render the BFF output. Unless we need to render new components or change the way something is rendered there are few reasons to require an app update. Bear in mind that some platforms don’t support automatic updates, and when they do not all users have them turned on. With this re-coupled pattern, we can ship new features to old consumers.

On the other hand, there are some cons:

  • Requires a dedicated back-end team. You cannot just install an API generator, like Contenta CMS, that is configured in the UI and serves a flexible JSON API with zero configuration. Now you need a dedicated backend team to build your BFF. However, chances are that your project already has a dedicated back-end team.
  • Brings back the bikeshedding. In DrupalCon Baltimore, I talked about how the JSON API module stops the bikeshedding. In this new paradigm, we are back to discussing things like the shape of the response, the names in it, how to expose these responses, etc.
  • It requires cross-consumer collaboration. This is because you want to design a BFF that works well for all current consumers and future ones. Collaboration across different teams can be a challenge depending on the organization.
To summarize

An organization that can make the compromise of a consistent design across consumers can simplify their omni-channel strategy. One way to do that is to move the complexity from several consumers to a single one, that lives in the back end.

Some organizations have used the BFF pattern successfully to achieve these goals in the past. Using this pattern, the different consumers can be simplified to dumb clients, leaving the business logic to the BFF. That, in turn, will allow for better performance, less code to maintain, and smaller time to market for new features.

Photo by Andrew Ridley on Unsplash

Categories: Drupal

Acquia Developer Center Blog: Experience Express in Lisbon: Forging the Future of Drupal Architectures and Initiatives at Drupal Developer Days

12 July 2018 - 7:47am

In Lisbon, steep slopes and sweeping vistas towering over placid waters and crowded ports characterize the topography of one of the most beautiful cities in Europe.

This year, the Portuguese capital played host to Drupal Developer Days, possibly the most important event for developers specializing in Drupal. Held at the University Institute of Lisbon, it was a conference not to be missed, with innumerable insights from Drupal core contributors and maintainers.

Tags: acquia drupal planet
Categories: Drupal

Acro Media: How to Create a Product Catalog with Search API, Solr and Facets

12 July 2018 - 7:45am

This tutorial will walk you through setting up an awesome Drupal Commerce product catalog using Search API and Solr, and then adding various ways of filtering the results (product search, sorting options and Facet categories). The end result of this guide will be a catalog that functions in the same way as our Urban Hipster Drupal Commerce demo site’s catalog. You can try it here. If you don’t already know why we use Search API, Solr and Facets for catalogs, check out this article to get up to speed.

Even though we’re going to be using products, once you understand how it works you’ll be able to apply the same method for other type of content such as a blog, videos, resources, and more. The datasource can change but the process is the same.

Let's get started! Follow along with this video or skip below for a written guide. 

What you need before starting

  1. A running Solr server (Solr 6.4+)
    This tutorial assumes you have Sor running and can make a new core.

  2. Drupal 8 installed with the following modules:

    TIP:
    Get most of what you need quickly with Commerce Kickstart. Note that you will still need to install the Facets module after getting your Kickstart package.

    • Commerce 
      composer require drupal/commerce
    • Search API 
      composer require drupal/serach_api
    • Solr
      NOTE: This module requires you're running Solr 6.4+ and PHP 7
      composer require drupal/serach_api_solr
    • Facets 
      composer require drupal/facets
Getting started
  1. Install/start Solr and add a new core that we’ll use later.

  2. Enable the Commerce, Search API, Solr and Facets modules.
Setup a basic Commerce store For this tutorial, get your site and basic store set up by doing the following:

  1. Add a product category taxonomy vocabulary that is at least 2 levels deep.
    If we use clothing as an example, we might have Men and Women as the first level, then t-shirts, shorts and shoes as the second level for each.

  2. Setup you basic Commerce store, product types and product variation types.
    If you’re new to Commerce, take a look at their documentation to get up and running quickly.

    NOTE: Make sure to add the taxonomy vocabulary you created as a ‘taxonomy reference’ field to your Product Type.

  3. Add 10 or more simple products for testing the catalog as we go.

Add a Search API server and index Search API server

Admin: Configuration > Search and metadata > Search API
Admin menu path:
/admin/config/search/search-api

  1. Click ‘Add server’.

  2. Configure the server.
    1. Name your server and enable it.
    2. Set ‘Solr’ as the server ‘Backend’.
    3. Configure the Solr connector.
      The defaults are usually fine. The main things to add are:
      • Solr connector = ‘Standard’.
      • Solr core = Whatever you named your core.
    4. Under ‘Advanced’, check ‘Retrieve result data from Solr’.
    5. Look over the remaining settings and update if you need to.
Search API index

Admin: Configuration > Search and metadata > Search API
Admin menu path:
 /admin/config/search/search-api

The index is where you set what data source is used by Search API. Eventually, you’ll also specify specific fields to be used for filtering the displayed results.

  1. Click ‘Add index’.

  2. Configure the index.
    1. Name your index.
    2. Data source should be ‘Product’
      This can be anything, but we’re creating a Commerce catalog and so we want to use the store products.
    3. Select the server you just created.
    4. Save. Don’t add any fields for now, we’ll do that later.
    5. Go to the ‘View’ tab and index your results. This will index all of the products you have added so far.
Create a View for the catalog

Admin: Structure > Views
Admin menu path:
 /admin/structure/views

The View will use the data source we’ve identified in our index and allow us to create a catalog with it, and then assign ways of filtering the catalog results (i.e. a search field and/or facets).

  1. Create a new View.
    1. View Settings, select your index.
    2. Create a page (this will become our catalog).
  2. View Display settings.
    1. Format > Show
      Set as ‘Rendered entity’, then in the settings, set your product types to use a ‘Teaser’ view mode instead of the default.

      NOTE: You may need to create this view mode if it doesn’t already exist.

      NOTE:You could alternately use Fields instead of view modes, but I like to keep my product display settings all within the product type’s display settings. Then you can potentially customize the display per product type if you have more than one.
  3. Save the view .
    These basic settings should give us our overall catalog. You can confirm by previewing the view or visiting the page you just created.
Add Fulltext datasource fields for a catalog search field

Now we’ll start setting up a Fulltext search field to let our users filter results using a product search field. The first thing we need to do is add some datasource fields to our index that the search will use.

  1. Go to your Search API Index and go to the Fields tab.

  2. Add Fulltext fields that you would like to be searchable (such as Title, SKU, Category taxonomy name, etc.).
    Here’s an example for adding the title:
    1. Click ‘Add fields’.
    2. Under the ‘Product’ heading, click ‘Add’ beside the ‘Title’ field.

      NOTE: If you’re adding a different field instead, you may need to drill down further into the field by clicking ( + ) next to the field. For example, to make a taxonomy term a searchable field, you would go to Your Vocabulary > Taxonomy Term > Name .

    3. Click ‘Done’.
    4. Set the field ‘Type’ to ‘Fulltext’.
      This is an important step as only Fulltext fields are searchable with the user-entered text search we are currently setting up.

      NOTE: Under the fields section is a ‘Data Types’ section. You can open that to read information about each available type.

    5. Optionally change the ‘Boost’ setting.
      If you have more than one Fulltext field, the boost setting allows you to give a higher priority to specific fields for when the terms are being searched.

      For example, multiple products could have a similar title, but each product would have an individual SKU. In this case, SKU could be given a higher boost than title to make sure that search results based on the SKU come back first.
  3. Next, add another field for the ‘Published’ status.

  4. Once you’ve added this field, set it’s type as ‘Boolean’.

  5. Reindex your data (from within the index view tab).
Set up the catalog search field within the catalog View

We can now set up the actual search field that our customers will use to find products, and use the datasource fields we added to our index to do this.

  1. Go to your catalog View.

  2. Under ‘Filter criteria’.
    1. Add ‘Fulltext search’ and configure its settings.
      • Check ‘Expose this filter to visitors, to allow them to change it’.
        IMPORTANT: This is what gives the user the ability to use this search field.
      • ‘Filter type to expose’, set as ‘Single filter’.
      • ‘Operator’, set as ‘Contains any of these words’.
      • ‘Filter identifier’, optionally adds an identifier into the url to identify a search term filter.
        (i.e. yoursite.com/products?your-filter-identifier=search-term)
      • Apply/save your settings.
    2. Add ‘Published’ and configure it so that it is equal to true.
      This uses the field we added to the index earlier to make sure the product is actually published. Chances are you don’t want unpublished results shown to your customers.
  3. Under ‘Sort criteria’.
    1. Add ‘Relevance’.
    2. Configure so that the order is sorted ascending.
      This will show the more relevant results first (factoring in the boost you may have applied to your index fields).
  4. Now we need to expose the search field to our customers. To do this:
    1. Open the ‘Advanced’ section of your catalog view.
    2. In the ‘Exposed Form’ area.
      • Set ‘Exposed form in block’ to ‘Yes’.
        This creates a block containing a search field that we can place on the site somewhere.
      • Set ‘Exposed form style’ to ‘Basic’ and update the settings. For now, the settings you might change are customizing the submit button text and maybe including a reset button.
  5. Add the search block to your site.
    Admin menu path: /admin/structure/block

    1. In your preferred region, click the ‘Place block’ button.
    2. Find the Views block that starts with ‘Exposed form’ and click ‘Place block’.
      Its full name will be determined by you view’s machine name and page display name (i.e. Exposed form: products-page_1).
    3. Configure the block as you see fit, and save.
  6. Test your search!
    You should now be able to see the search field on your site frontend and try it out.
Add more datasource fields for sorting options

We can optionally sort the catalog and search results with some additional sorting filters, such as sorting by Title, Price, Date added, etc. Let’s add the ability to sort our products by title with the option to choose ascending or descending order.

  1. Go to your Search API Index fields and add another 'Title' field the same as you did earlier. However, this time you want to change the field ‘Type’ to ‘String’. You should now have two Title fields added, one as ‘Fulltext’ and one as ‘String’.

    NOTE: The field type can be different depending on what field you’re adding. If you’re adding a sorting field such as Price > Number, you might use the ‘Decimal’ field type.

    TIP: I would recommend changing the Label for the new Title field to something like ‘Title for sorting’ so that it’s easier to identify later. You could even change the fulltext Title label to ‘Title for search’, just to keep them organized and easy to understand.

  2. Reindex your data (from within the index view tab).

  3. Go to your catalog View.
    1. Under ‘Sort criteria’.
      • Add the new title datasource and configure it.
        • Check ‘Expose this sort to visitors, to allow them to change it’.
          IMPORTANT: This is what gives the user the ability to use this sorting option.
        • Add a label for the filter
        • Set the initial sorting method.
      • Add any additional sorting fields if you added more.
    2. Open the settings for the ‘Exposed form style’ (within the view’s ‘Advanced’ section).
      • Check ‘Allow people to choose the sort order’.
      • Update the labels as you see fit.
    3. Save your view!
      Refresh your catalog page and you should now see sorting options available in the search block that you added earlier.

      TIP: If you DO NOT see the sorting options, this is a bug and is easily fixed. All you need to do is remove the search block and the re-add it.

      TIP: You can place this block in multiple regions of your site and hide the elements you don’t want to see with CSS. This way you can have a block with the site search and no filters in your header, and then also have another block on your catalog pages that shows the sorting filters but no search field.
Add Facets to the catalog

The filters we added earlier can only be used one at a time, however, often we want to filter the results based on a number of different options. For example, if I’m browsing an online store looking for shoes of a certain style and size, I don’t want to see everything else the store has to offer. I want to be able to go to a ‘shoe’ category, then pick the ‘type’ of shoe that I’m after, and finally pick the ‘size’ of shoe that’s relevant to me. I want to see all of the results that fit that criteria. Facets let use taxonomy (and other datasources) to achieve this.

Let’s add a Facet that uses the taxonomy vocabulary we created in the initial store setup. This will be our main catalog menu for narrowing down the product results. Each facet that is created creates a block that we can add into any region of our template.

  1. Add a Search API index fields for your taxonomy vocabulary. Set the field ‘Type’ as ‘String’.

    TIP: Like we did earlier, I would recommend renaming the label for this field to something like ‘Categories for Facet’.

  2. Reindex your data (from within the index view tab).

  3. Go to the Facets page.
    Admin: Configuration > Search and metadata > Facets
    Admin menu path:
     /admin/config/search/facets

    You should see a ‘Facet source’ available to use. When we created a View using our index, this is what added the Facet source here. Now that we have a source, we can create Facets to filter it.

  4. Click ‘Add facet’.
    1. Choose the ‘Facet source’ to use.
    2. Select the index ‘Field’ that this Facet will use (i.e. Categories for Facet, or whatever you labelled your field).
    3. Name your Facet (i.e. Categories).
  5. Configure the Facet.
    This will cover the basic settings that you will need. Start with this and then you can always play around with other settings later. Each setting has a pretty good description to help you understand what it does.
    1. Widget.
      Choose a ‘Widget’ for displaying the categories. For categories, I like to use ‘List of checkboxes’.
    2. Facet Settings.
      Check the following:
      • Transform entity ID to label.
      • Hide facet when facet source is not rendered.
      • URL alias as ‘cat’ (or whatever you like).
      • Empty facet behavior as ‘Do not display facet’.
      • Operator as ‘OR’.
      • Use hierarchy.
      • Enable parent when child gets disabled.
      • NOTE: the Facets Pretty Paths module can be used to give you nicer looking URL paths.
    3. Facet Sorting.
      Configure as you see fit. In this example, I would only check the following. These settings make sure that the taxonomy follows the same order that you have set within the vocabulary itself.
      • Sort by taxonomy term weight.
      • Sort order as ‘Ascending’.
    4. Save.
  6. Add the Facet block to your site.
    Admin: Structure > Block layout
    Admin menu path:
     /admin/structure/block

    1. In your preferred region, click the ‘Place block’ button.
    2. Find the ‘Categories’ facet block (or whatever you named it) and click ‘Place block’.
    3. Configure the block as you see fit.
    4. Save.
  7. Test your Facet!
    You should now see your Facet on the catalog page. Click the checkboxes and test out how it works!
One last thing...

The sites we've been building use the Facets Pretty Paths module for making nicer looking URLs with our catalog and filters. For a while we were plagued with a problem where, when the user selects a Facet category and then uses the sorting options, the Facets would uncheck and reset. This is obviously not good because the user is trying to sort the filtered down items, not the overall catalog. We need to be able to maintain the active facets when using the filters.

Luckily, a coworker came up with this nice little solutions that you can apply to your theme's .theme file. You just need to replace YOUR_THEME, YOUR-VIEW (i.e. products-page-1), and YOUR-PATH (i.e. products) in the code below. Ideally, this will be fixed within the module itself soon, but this will work while we wait.

/**
* Implements hook_form_alter().
*/
function YOUR_THEME_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  // Store - Product Listing view exposed form.
  if ($form['#id'] == 'views-exposed-form-YOUR-VIEW') {
    $current_path = \Drupal::request()->getRequestUri();

    // If current path is within your catalog, correct the form action path.
    if ((strpos($current_path, '/YOUR-PATH') === 0)) {
      // Fix for views using facets with pretty paths enabled.
      // Replace form action with current path to maintain active facets.
      $form['#action'] = $current_path;
    }
  }
}

Done!

There you have it! You have now created a Search API index using Solr, setup a View to display the results of the index, and then implemented 3 different ways to filter the results (search, sorting and Facets). This is the start of an awesome product catalog and you can expand on it with more datasource fields however you want. Cool!

Categories: Drupal

Evolving Web: Vote for Suzanne Dergacheva for Drupal Association Board Elections 2018

12 July 2018 - 6:45am

It’s time to vote in the Drupal Association Board election! If you have an account on drupal.org, and have logged in over the last year, you can vote here

Our co-founder Suzanne Dergacheva is running for a member-at-large position on the board. Here are three things Suzanne wants to prioritize:

1. Increasing Drupal adoption: Suzanne has trained thousands of new people in Drupal, so she understands how important good communication is to increase adoption. She wants to help the association seize opportunities for Drupal growth through more targeted and consistent communication and marketing tools.

2. Enabling Drupal shops to grow their businesses: Suzanne is organizing the first Drupal Business Summit in Montreal this year, and believes this could be a replicable model in other regions to help Drupal shops promote the value of Drupal to businesses.

3. Growing the Drupal community: Suzanne manages a diverse team, comprised of employees from 11 different countries. Through her work as a trainer, she has introduced Drupal to people throughout North America and Europe, and at Drupalcon Asia in Mumbai. She’s passionate about making Drupal accessible to more people, and believes that the association can facilitate initiatives to communicate the value that Drupal places on user experience and accessibility.

In addition to her ambitious vision for the Drupal Association, Suzanne brings impressive qualifications:

  1. She served five years on the board the McGill Young Alumni, two as president. She was treasurer of the Montreal Drupal Association for five years. 
  2. Her talks “Building Landing Pages and Layouts for Drupal 8 ” and “Creating a Great User Experience for Content Editors”, were among the most attended and best reviewed at #Drupalcon. She keynoted DrupalCamp Montreal 2018, talking about the Drupal experience.
  3. She co-founded a successful Drupal agency which is 11 years old. She lead developers, designers, project managers, and marketers on Drupal projects big and small.
  4. She has volunteered her time to various Drupal community initiatives over the last 10 years

So go vote now! And better still, share this post with your friends and colleagues in the Drupal Community.

Vote on Drupal.org

Related Posts How We Can All Improve the Drupal Experience

The best part of my job is teaching Drupal. As a Drupal trainer, I get to meet a lot of Drupalers with really different backgrounds. Some are brand-new to Drupal, some have lots of experience. Listening to them tell of their Drupal journeys, both the highlights and the low points, has given me insights into the different ways people encounter Drupal and some of the most common reasons why they love it, use it and get involved in the community (or not).

Read More about How We Can All Improve the Drupal Experience »

+ more awesome articles by Evolving Web
Categories: Drupal

Evolving Web: Drupal Association Board Elections 2018: Time To Vote

12 July 2018 - 6:45am

It’s time to vote in the Drupal Association Board election! If you have an account on drupal.org, and have logged in over the last year, you can vote here

Our co-founder Suzanne Dergacheva is running for a member-at-large position on the board. Here are three things Suzanne wants to prioritize:

1. Increasing Drupal adoption: Suzanne has trained thousands of new people in Drupal, so she understands how important good communication is to increase adoption. She wants to help the association seize opportunities for Drupal growth through more targeted and consistent communication and marketing tools.

2. Enabling Drupal shops to grow their businesses: Suzanne is organizing the first Drupal Business Summit in Montreal this year, and believes this could be a replicable model in other regions to help Drupal shops promote the value of Drupal to businesses.

3. Growing the Drupal community: Suzanne manages a diverse team, comprised of employees from 11 different countries. Through her work as a trainer, she has introduced Drupal to people throughout North America and Europe, and at Drupalcon Asia in Mumbai. She’s passionate about making Drupal accessible to more people, and believes that the association can facilitate initiatives to communicate the value that Drupal places on user experience and accessibility.

In addition to her ambitious vision for the Drupal Association, Suzanne brings impressive qualifications:

  1. She served five years on the board the McGill Young Alumni, two as president. She was treasurer of the Montreal Drupal Association for five years. 
  2. Her talks “Building Landing Pages and Layouts for Drupal 8 ” and “Creating a Great User Experience for Content Editors”, were among the most attended and best reviewed at #Drupalcon. She keynoted DrupalCamp Montreal 2018, talking about the Drupal experience.
  3. She co-founded a successful Drupal agency which is 11 years old. She lead developers, designers, project managers, and marketers on Drupal projects big and small.
  4. She has volunteered her time to various Drupal community initiatives over the last 10 years

So go vote now! And better still, share this post with your friends and colleagues in the Drupal Community.

Vote on Drupal.org

Related Posts How We Can All Improve the Drupal Experience

The best part of my job is teaching Drupal. As a Drupal trainer, I get to meet a lot of Drupalers with really different backgrounds. Some are brand-new to Drupal, some have lots of experience. Listening to them tell of their Drupal journeys, both the highlights and the low points, has given me insights into the different ways people encounter Drupal and some of the most common reasons why they love it, use it and get involved in the community (or not).

Read More about How We Can All Improve the Drupal Experience »

+ more awesome articles by Evolving Web
Categories: Drupal

Evolving Web: Why Evolving Web’s Suzanne Dergacheva Wants to Volunteer on the Drupal Association Board

12 July 2018 - 6:45am

It’s time to vote in the Drupal Association Board election! If you have an account on drupal.org, and have logged in in the last year, you can vote here

Our co-founder Suzanne Dergacheva is running for a member-at-large position on the board. Here are three things Suzanne wants to prioritize:

1. Increasing Drupal adoption: Suzanne has trained thousands of new people in Drupal, so she understands how important good communication is to increase adoption. She wants to help the association seize opportunities for Drupal growth through more targeted and consistent communication and marketing tools.

2. Enabling Drupal shops to grow their businesses: Suzanne is organizing the first Drupal Business Summit in Montreal this year, and believes this could be a replicable model in other regions to help Drupal shops promote the value of Drupal to businesses.

3. Growing the Drupal community: Suzanne manages a diverse team, comprised of employees from 11 different countries. Through her work as a trainer, she has introduced Drupal to people throughout North America and Europe, and at Drupalcon Asia in Mumbai. She’s passionate about making Drupal accessible to more people, and believes that the association can facilitate initiatives to communicate the value that Drupal places on user experience and accessibility.

In addition to her ambitious vision for the Drupal Association, Suzanne brings impressive qualifications:

  1. She served 5 years on the board the McGill Young Alumni, two as president. She was treasurer of the Montreal Drupal Association for five years. 
  2. Her talks “Building Landing Pages and Layouts for Drupal 8 ” and “Creating a Great User Experience for Content Editors”, were among the most attended and best reviewed at #Drupalcon. She keynoted DrupalCamp Montreal 2018, talking about the Drupal experience.
  3. She co-founded a successful Drupal agency which is 11 years old. She lead developers, designers, project managers, and marketers on Drupal projects big and small.
  4. She has volunteered her time to various Drupal community initiatives over the last 10 years

So go vote now! And better still, share this post with your friends and colleagues in the Drupal Community.

Vote on Drupal.org

Related Posts How We Can All Improve the Drupal Experience

The best part of my job is teaching Drupal. As a Drupal trainer, I get to meet a lot of Drupalers with really different backgrounds. Some are brand-new to Drupal, some have lots of experience. Listening to them tell of their Drupal journeys, both the highlights and the low points, has given me insights into the different ways people encounter Drupal and some of the most common reasons why they love it, use it and get involved in the community (or not).

Read More about How We Can All Improve the Drupal Experience »

+ more awesome articles by Evolving Web
Categories: Drupal

Evolving Web: What is Drupal?

12 July 2018 - 6:19am

Drupal is an open source Content Management System (CMS) which is free to download and use; it allows you to create and manage websites, intranets, and web applications without writing any code.

Why Use Drupal?

Most websites share a common set of features. They typically have navigation menus and lists of content, pages of content with nice URLs, a header with a logo, a footer with contact info, etc. At the same time, there are a lot of differences between websites. They often have a unique content structure, a customized look and feel, and customized features.

Drupal works well for websites that need those shared features. Drupal provides lots of functionality out-of-the-box that most websites need, for example:

  • Content management
  • Taxonomy for organizing content
  • Flexible navigation system
  • Comments
  • Search
  • Content listings
  • Contact forms
  • WYSIWYG Editor
  • Nice content authoring experience
  • Multilingual content & user interface
  • User management
  • Accessibility
  • Responsive design

At the same time, Drupal is really flexible, so you can customize the aspects of your website that are unique and add custom features.

By using Drupal, you can create: 
  • Corporate websites : contents types of services, workflow for publishing, corporate branding, etc.
  • Intranets: private content, custom workflow for internal processes, listings of internal contents such as internal news and meeting notes. 
  • Online directories: search tools, embedded listing, etc. 
  • Interactive websites: user accounts, multi-step form, custom javascript, decoupled front-ends, etc. 
  • Marketing portals: landing pages for SEO, mix of content and marketing material, campaign landing pages, etc.
Here is some handy Drupal terminology:
  • Node - Piece of content
  • Content type - A template for content
  • Vocabulary - A way of categorizing your content
  • View - Content listing
  • Module - Functionality that you can add to a Drupal website 
  • Theme - Defines the layout, look and feel
  • Block - Displays content, a list, menu, form, etc. on the page (often in the sidebar, header, footer)
  • Permission - A task that a user can do
  • Role - A type of user

Fun facts!

Drupal was created by Dries Buytaert in 2001

The word Drupal comes from “druppel”, which means drop in Dutch

Drupal Community is originally used for university discussions but there are now thousands of organizations using Drupal, including companies, non-profits, governments, universities to power their web presence.

As of January 2018, the Drupal community reached over 1.3 million users, including developers, designers, content writers, sponsors etc. According to statistics, there are more than 100,000 members that are actively contributing to the community. This results in tens of thousands of free modules that allow to further personalize Drupal functionality, thousands of free themes that help customize the appearance of Drupal and more than one thousand distributions that allow users to easily and efficiently set up Drupal websites.

If you would like to learn more about Drupal, we offer a large variety of trainings from beginner to advanced levels, with our team-lead, Suzanne Dergacheva. Check out Evolving Web’s “Training” section. 
 

 

+ more awesome articles by Evolving Web
Categories: Drupal

Ashday's Digital Ecosystem and Development Tips: Drupal Module Spotlight: Coffee

11 July 2018 - 2:00pm

Coffee is a magical thing. It gets you going, clarifies your thoughts, makes you feel all warm inside. I don’t know what I’d do without it. So when we consider installing the Drupal module named after this irreplaceable daily beverage, we see that it has a similar effect. It just makes things better. Am I overstating things? Probably. But I haven’t had enough coffee yet today and I need to get this blog going with some pizzazz.

Categories: Drupal

Drupal Association blog: Reaching Drupal evaluators

11 July 2018 - 1:26pm

The 2018 goal for the Drupal Association has been to grow Drupal adoption. This goal cannot be achieved without testing ideas for promoting Drupal within Drupal.org and DrupalCon, the two main channels we have to reach Drupal evaluators. We also can't do this work without your support.

We've refreshed Drupal.org's homepage and top-level menu to include a new persona-based design because developers, marketers/content-editors, and agency owners all have differing needs on their Drupal adoption journey. We're helping people start their exploration to understand and fall in love with Drupal.

The Engineering Team played a key role in the Industry Pages project—from conception to execution. The industry pages help decision makers see how Drupal achieves the vision Dries' set forth when he described Drupal as the platform for ambitious digital experiences.

If you appreciate this work, help support the Drupal Association by joining as a member. Thank you!

Become a member

Categories: Drupal

Drupal Association blog: Drupal Association Board Executive Session Announcement

11 July 2018 - 4:25am

On July 25, 2018, the Drupal Association will host their next scheduled executive session, which is a private session for the board members.

Executive Session Agenda

While the The Executive Session is a private meeting amongst board members, we want to provide insight into what the agenda topics will be.

  • Executive update from the Executive Director

  • Committee updates: nominating, revenue, finance, and governance

  • Preparation for the annual Executive Director performance review

Schedule

The schedule for Drupal Association Board Meetings is always available on the Association section of the Drupal website.

Categories: Drupal

OpenSense Labs: Checklist to Comply with ADA Accessibility in Higher Education

11 July 2018 - 12:15am
Checklist to Comply with ADA Accessibility in Higher Education Akshita Wed, 07/11/2018 - 12:45

The American Disability Act (ADA), 1990 provides provisions to secure the rights of specially-abled people. Although, when first passed, it focussed primarily on physical properties, over time it has covered digital spaces too, which means people can take a complaint to the court for discriminating and violating the ADA act. 

Accessibility is a more accepted norm when it comes to physical infrastructure, however, when accessibility translates to the digital space, industries across the web are struggling to answer. Higher education is no exception.

  “The National Association of the Deaf in 2015 slapped Harvard University and Massachusetts Institute of Technology in Massachusetts federal court, accusing them of discriminating against deaf and hard-of-hearing people” 

An absence of hard and fast rules to adhere to in the higher education sector often lead institutes to ignore the web accessibility practices. 

Exploring the Issues in Higher Ed and the ADA Compliance

Lawsuits can be avoided by following WCAG 2.0. Since web accessibility guidelines and best practices are already clear through WCAG 2.0. 

The ADA Compliance

The ADA not only covers the general non-discriminatory guidelines but also encourages organizations, institutions, and businesses to provide accommodations to people with disabilities so they can have the same level of access to services as everyone else. 

The law was amended later in 2008 to fit the conditions of modern society and include the digital space while broadening the term “disability”.

Since, ADA conforms to other state laws, including section 508 of the Rehabilitation Act and existing WCAG 2.0 guidelines, hence the term - ADA Website Compliance. In January 2017, the federal government adopted the Web Content Accessibility Guidelines, (popular as WCAG 2.0) setting the standards with A and AA level for all websites. 

The Guiding Principles to Web Accessibility - POUR

The WCAG 2.0 consists of 12 guidelines with four arching principles of POUR. These guidelines relate to one simple question: can the users with varying degree of ability ingest the content on your site?

“Just as no ramps would exclude people with a wheelchair, videos without caption exclude people who are hard of hearing.”

Accessibility in higher education should not be restricted only to lectures and videos. In the case of a flash-based campus tour, there should be alt-text for visually impaired people. Accessing content should be intuitive. Making navigation easier needs to be part of the plan. 

Perceivable
Operable
Understandable
Robust

  • Perceivable

The content needs to be presented in different ways, including assistive technologies, without losing its meaning. The easiest way to do so is by providing alt-text for non-text content. The content should be easier to see and hear. 

By no means should the multimedia content be unattainable.  In the case of Harvard and Massachusetts Institute of Technology, the content was not perceivable for the deaf and hard-of-hearing people.

Story of Harvard: Harvard and M.I.T. have extensive free materials online, distributed across platforms like Harvard@Home, MIT OpenCourseWare, YouTube, and iTunesU, edX which offers extensive massive open online courses (MOOCs), free to students around the world. 

The videos either did not include captions or were inaccurately captioned (read unintelligibly) making it inaccessible for people with hearing ability.

"Accessible" means fully and equally accessible to, and independently usable by, differently abled students and faculty members in a way that they can acquire the same information, engage in the same interactions, and enjoy the same services as sighted students and faculty with substantially equivalent ease of use.

  • Operable

This principle ensures that the content is easy to operate upon. Web accessibility issues are not synonymous with visibility issues, as is the popular myth. They are as much a problem for people with hearing disability as for a person with a neurological or cognitive disorder. 

The content on the website needs to be accessible with a keyboard for people with limited motor functions, people with color blindness, and avoiding the use of content and types that cause seizure. 

“People living with reflex epilepsy have seizures that occur in response to a specific stimulus, like flashing lights or by noises.” 
  • Understandable

Is the text readable for people with difference in visual ability? This principle ensures that the content appears and operates in a predictable way. This specifically focuses on the issues related to color contrast. 

Accessing content should be intuitive and easy. To disable the pop-up button or going back need not be a time-consuming exercise.  

Atlantic Cape Community College in 2007 was dragged to court by a visually challenged student after the campus and curriculum proved to be a challenge for him. 

  • Robust 

Any content - written or multimedia - should be future proof. Efforts should be made to maximize compatibility with current and future user tools. Before the dawn of the 21st century, screen readers were not as popular as they are 18 years later. A decade back even mobile phones were not as ubiquitous. 

Assistive technologies are advancing by leaps and bounds, and your site needs to adapt and step up with upcoming trends in hardware and software tools. In order to keep the content robust, higher ed institutes need to adhere to best practices or lose it the way University of California, Berkeley did.

“In a similar scenario in 2017, The University of California, Berkeley, in response to a Justice Department accessibility order, had two options:

1. Update existing content to comply with accessibility standards.
2. Remove more than 20,000 video and audio files from public view.

They chose the latter, the digital equivalent of boarding up the entrance to a building instead of installing a wheelchair accessible ramp.”

Checklist: Making Higher Ed Institutes ADA Compliant

In its defense, the Harvard University asked the court to propose rules “to provide much-needed guidance in this area”. This is one of the most infuriating aspects of accessibility compliance in higher education – there has been an absence of hard and fast rules to adhere to. Something that echoes the statement of Harvard. 


Now that we understand the guiding principles, we are in a better position to deliver a better user experience to all. One thing worth highlighting is - accessibility issues are easier to address before they manifest on your site, not after

“It costs significantly less to make a site accessible than it does to procure the lawyer to protect you in an accessibility claim.” 

Under WCAG 2.0 priority levels are assigned to each checkpoint based on its impact on accessibility. These levels were the following:

Priority 1: Conforming to this level will make it possible for one or more groups to access the web content. This is level A.
Priority 2: Conforming to this level will make it easy for one or more groups to access the web content. This is level AA. 
Priority 3: Conforming to this level will make it easier for most of the groups to access the web content. This is level AAA.

Drupal has been powering higher education websites. In fact, it is one of the most-sought-after CMS for higher education institutes. Read Why Drupal Is Your Best Bet For Your Educational Site

Level A Conformance 
  • Provide web pages with titles that describe the topic or purpose of the page.
     
  • Make sure it is navigated in a meaningful manner while providing the options to bypass repeating blocks of content on multiple pages.
     
  • Make sure that the purpose of each link can be determined by the link text alone unless the purpose is ambiguous to all users.
     
  • In case of an input error made by the user, provide text information specifying the item in error and the error itself.
     
  • Provide labels, guidance and instructions, and text alternatives for all non-text content. Controls or input fields must have a name describing their purpose. 
     
  • Information must be accessible to different users in multiple ways, including through assistive technologies (such as screen readers) without losing information. 
     
  • Using colors that convey visual information, distinguishing visual components, indicating actions or prompting for a response.
     
  • Users must have the ability to fully operate the website through a keyboard interface, including the ability to pause and stop any presentation, audio or adjust the volume. 
     
  • Content must not cause seizures. Avoid designing content in a way that is known to cause seizures.
     
  • Compatibility with other user software, like the ones in assistive technologies.
Level AA Conformance - other than those in level A
  • Provide captions for all live audio content. And provide audio descriptions for all pre-recorded video content.
     
  • Text content and images of text must have a contrast ratio of 4.5:1. Content that serves only design purposes have no contrast requirements.
     
  • Enable the user to resize the text up to 200 percent without any assistive technology.
     
  • Use of text over images, whenever possible.
     
  • Provide multiple ways to locate web pages.
     
  • Ensure the keyboard focus indicator visibility through all interfaces.
     
  • Components with the same functionality must be identified consistently.
     
  • Ensure the security of legal and financial data transactions by making them reversible, and giving the user an opportunity to recheck the input data and the confirmation mechanism before finalizing submission.
Level AAA Conformance - other than those in level A and AA
  • Support all pre-recorded audio content with sign language interpretation and provide extended audio descriptions for all prerecorded video content where there’s no opportunity to pause the foreground audio and provide audio descriptions.
     
  • The contrast ratio between text and images must be 7:1. However, text or images which serve only design purposes do not require contrast or alt text.
     
  • Any pre-recorded audio content must provide users with context-sensitive help. In case the audio-content is not a CAPTCHA it should either:
    • must not contain any background sounds
    • or the background sounds can be turned off, 
    • or the background sounds should be at least 20 dB lower than the pre-recorded speech content. 
       
  • Provide users with a mechanism to choose foreground and background colors. With the width of blocks of content must not exceed 80 characters or glyphs.
     
  • Line spacing must be at least 1.5 spaces within paragraphs and paragraph spacing must be at least 1.5 times larger than the line spacing.
     
  • Ensure the text can be adjusted up to 200 percent without the use of assistive technologies. The user does not have to scroll horizontally to read a line of text.
     
  • Allow users to postpone or suppress interruptions, except in the case of emergency.
     
  • Ensure the users can continue their activity without much interference or loss of data after re-authentication in case the authenticated session expires. 
     
  • Include information on the user’s location within a set of pages. Provide supplementary content for identifying definitions of unusual words or phrases, including idioms, abbreviations, and jargon.
     
  • Provide additional content when users require a more advanced education level than lower secondary education (to 9th grade) to understand the content.
     
  • Changes of web content may only be initiated by the user or the user must be provided with a mechanism to turn off such changes.

It is worth noting that web accessibility compliance may not be realistic for all websites depending on the type of content. Drop a mail at hello@opensenselabs.com and connect with us if you are planning to build a user-friendly education website. 

blog banner blog image American Disability Act ADA Web Accessibility Drupal Drupal 8 HTML Accessibility Drupal Web Accessibility WCAG Web Content Accessibility Guidelines Accessibility in Higher Education  WCAG  WCAG 2.0 Blog Type Articles Is it a good read ? On
Categories: Drupal

Agiledrop.com Blog: AGILEDROP: Developers wanted. ASAP!

10 July 2018 - 8:45pm
Meet John. He is running a business. He is a digital agency owner and a CEO and currently employs 25 people of different profiles. Account managers, designers, developers, project managers, sales & marketing people,... And the business is going well for John and his team. In fact, so good he needs more bandwidth for his development team. They are already working long hours and with recent sales push giving first results and getting two new clients on board his team will need reinforcements. Because the existing team won't be able to handle the extra workload.    What are the… READ MORE
Categories: Drupal

Drupal Association blog: Calling all Drupal Agency Leaders: Participate in the 2018 Drupal Business Survey

10 July 2018 - 8:28am

The third edition of the annual Drupal Business Survey is here. Exove and One Shoe created the survey in collaboration with Drupal Association, to gain insight of Drupal’s health, focus and latest business trends. It also gives perspective on how Drupal agencies are doing and how customers see Drupal.

Analysis of the 2017 edition of the survey can be found here, and 2016 analysis here.

We encourage all Drupal business leaders to participate in this year’s Drupal Business Survey.  

Participation is anonymous and takes only about 10 minutes. The first results will be presented at the Drupal CEO Dinner at Drupal Europe on Wednesday, September 12, 2018. Analysis and insights will officially be published on Drupal.org.

You can participate anytime now until July 31st, 2018.

The survey can be accessed here.

Categories: Drupal

Droptica: Drupal outsourcing - How to find the best team

10 July 2018 - 7:00am
Drupal is fantastic for all sorts of websites and applications. It excels especially at large, complex content projects. If you know what you are doing, you can often cut development time substantially compared to other tools made for the same purpose.  Drupal's versatility, however, is a 2-edged sword. With great flexibility, extensive API and an abundance of modules created by the community, it takes a long time to get up to speed. Often there is not enough time on a project to go through Drupal's steep learning curve.  The more experienced your team is, the more benefits of Drupal you will reap and the less technical debt you will acquire, and the more successful your project will be in the end. Looking for a Drupal team There are a few critical elements you should consider when you are looking for to outsource a Drupal project:
Categories: Drupal

Acquia Developer Center Blog: Experience Express in Utrecht: Conversational Design and Modern Front-end Approaches at Frontend United

10 July 2018 - 6:26am

With a uniquely diverse community of designers, developers, and everyone in between, Frontend United is one of the conferences I find I enjoy more and more each time I attend. And this time, in Utrecht, a wide range of designer- and developer-oriented content greeted attendees both within and well outside the Drupal universe.

Tags: acquia drupal planet
Categories: Drupal

Evolving Web: How We Can All Improve the Drupal Experience

10 July 2018 - 5:37am

The best part of my job is teaching Drupal. As a Drupal trainer, I get to meet a lot of Drupalers with really different backgrounds. Some are brand-new to Drupal, some have lots of experience. Listening to them tell of their Drupal journeys, both the highlights and the low points, has given me insights into the different ways people encounter Drupal and some of the most common reasons why they love it, use it and get involved in the community (or not).

I've recently been thinking about the Drupal community from a user experience point of view. I regularly host UI meetups for developers and designers, and I'm also volunteering on Drupal's Admin UI initiative, which is creating an accessible administrative interface based on user data and feedback. Both have taught me to empathize with others and understand why they might be feeling excited, warm and fuzzy, anxious, frustrated or curious about Drupal at any given point. It's also given me ideas about what we can all can do to improve the Drupal experience, including:

1. Participate in the community

If you think back to your own best experience with Drupal, there's a decent chance that it was a DrupalCon, DrupalCamp or another time when you had the chance to learn from other Drupalers or share your knowledge with them. It feels inspiring to mentor newcomers, help people solve problems on Drupal Slack or get advice from someone who seems to care. Let's keep it up and look for opportunities to take it further!

2. Recognize the challenges that you and others are facing

There's no point in pretending that using Drupal is always smooth sailing. Hiding the challenging parts of our experiences only makes others feel like they're alone or that they've missed something everybody else has understood. Asking new users around the world to tell me about their pain points has shown me, as just one small example, that Drupal terminology can often be intimidating. We all have our issues, and talking about them is the first step toward finding solutions for them.

3. Get involved with existing initiatives

Community members are on the job when it comes to refining certain aspects of the Drupal experience. The Promote Drupal Initiative has already enhanced Drupal.org's landing page with the persona-specific information its audience was looking for. Their next step will be devising ways to make it easier for new users to find their way into community engagement. And they're not the only ongoing project that could benefit from your time, expertise or financial support: the Out of the Box Experience Initiative, for example, is helping Drupal to make a better and more helpful first impression when it's installed by a prospective user.

4. Imagine new ways of solving problems

The beauty of being part of an open source community is that if you see a problem, you have the power to address it. If you have an idea for helping others have a better Drupal journey, why not try it out? Great user experiences encourage user-base growth and vice versa: a virtuous cycle that I'm committed to supporting.

Inspired by these ideas, I recently decided to run for a position on the Drupal Association's Board of Directors as a "director at large"---a community representative, in other words---because I would love to put my time, energy and knowledge towards growing the community and promoting Drupal to new groups and markets.  If you have an active profile on Drupal.org then you can vote in this election here any time before Friday, July 13.

For a video version of this post, here's a recording of my session on the topic at DrupalCamp Montreal:

+ more awesome articles by Evolving Web
Categories: Drupal

Droptica: Droptica: Drupal outsourcing - How to find the best team

10 July 2018 - 5:24am
Drupal is fantastic for all sorts of websites and applications. It excels especially at large, complex content projects. If you know what you are doing, you can often cut development time substantially compared to other tools made for the same purpose.  Drupal's versatility, however, is a 2-edged sword. With great flexibility, extensive API and an abundance of modules created by the community, it takes a long time to get up to speed. Often there is not enough time on a project to go through Drupal's steep learning curve.  The more experienced your team is, the more benefits of Drupal you will reap and the less technical debt you will acquire, and the more successful your project will be in the end. Looking for a Drupal team There are a few critical elements you should consider when you are looking for to outsource a Drupal project:
Categories: Drupal

Droptica: Droptica: How to use React with Drupal

10 July 2018 - 4:30am
React.js is a very popular JavaScript framework created by Facebook. It allows you to build beautiful, interactive and fast interfaces, with which users will fall in love. Drupal, on the other hand, is a fantastic CMS with you can build small, medium and huge websites.   Sometimes you want to pair the two frameworks together - offer sophisticated Drupal backend, and a slick, quick frontend based on React. That is when Drupal and React can come together. In this post, I will explore various methods of combining the technologies. Headless Drupal vs. embedded React The primary choice you have to make when using React with Drupal is whether you want to use a "headless Drupal" approach where Drupal is only in the backend and React is the only interface user ever sees or whether you just want to add a React app to the Drupal website rendered by the Drupal templating engine. Let me elaborate.
Categories: Drupal

OPTASY: Set Up a Local Drupal Site with Lando in no Time: Get Started with Docker

10 July 2018 - 4:30am
Set Up a Local Drupal Site with Lando in no Time: Get Started with Docker radu.simileanu Tue, 07/10/2018 - 11:30

Let's say that you need to spin up a new Drupal environment in... minutes. To quickly test a new patch to Drupal core, maybe, or to switch between 2 or more clients on the same day and thus to run multiple copies on several websites... In this case, how about taking the quick and easy way and set up a local Drupal site with Lando?

"What is Lando?" you might legitimately ask yourself.

A DevOps tool and Docker container-based technology enabling you to spin up all the services and tools that you need to develop a new Drupal project in no time.

"Why would I choose Lando as a method to set up a local Drupal site?"

Categories: Drupal

Wim Leers: State of JSON API (July 2018)

10 July 2018 - 3:01am

Quite a few people in the Drupal community are looking forward to see the JSON API module ship with Drupal 8 core.

Because:

  • they want to use it on their projects
  • the Admin UI & JS Modernization Initiative needs it
  • they want to see Drupal 8 ship with a more capable RESTful HTTP API
  • then Drupal will have a non-NIH (Not Invented Here) API but one that follows a widely used spec
  • it enables them to build progressively decoupled components

So where are things at?

Timeline

Let’s start with a high-level timeline:

  1. The plan (intent) to move the JSON API module into Drupal core was approved by Drupal’s product managers and a framework manager 4 months ago, on March 19, 2018!
  2. A core patch was posted on March 29 (issue #2843147). My colleague Gabe and I had already been working full time for a few months at that point to make the JSON API modules more stable: several security releases, much test coverage and so on.
  3. Some reviews followed, but mostly the issue (#2843147) just sat there. Anybody was free to provide feedback. We encouraged people to review, test and criticize the JSON API contrib module. People did: another 1000 sites started using JSON API! Rather than commenting on the core issue, they filed issues against the JSON API contrib module!
  4. Since December 2017, Gabe and I were still working on it full time, and e0ipso whenever his day job/free time allowed. Thanks to the test coverage Gabe and I had been adding, bugs were being fixed much faster than new ones were reported — and more often than not we found (long-existing) bugs before they were reported.
  5. Then 1.5 week ago, on June 28, we released JSON API 1.22, the final JSON API 1.x release. That same day, we branched the 2.x version. More about that below.
  6. The next day, on June 29, an updated core patch was posted. All feedback had been addressed!
June 29

I wrote in my comment:

Time to get this going again. Since #55, here’s what happened:

  1. Latest release at #55: JSON API 1.14
  2. Latest release today: JSON API 1.22
  3. 69 commits: ($ git log --oneline --since "March 30 2018 14:21 CET" | wc -l)
  4. Comprehensive test coverage completed (#2953318: Comprehensive JSON API integration test coverage phase 4: collections, filtering and sorting + #2953321: Comprehensive JSON API integration test coverage phase 5: nested includes and sparse field sets + #2972808: Comprehensive JSON API integration test coverage phase 6: POST/PATCH/DELETE of relationships)
  5. Getting the test coverage to that point revealed some security vulnerabilities (1.16), and many before it (1.14, 1.10 …)
  6. Ported many of the core REST improvements in the past 1.5 years to JSON API (1.15)
  7. Many, many, many bugfixes, and much, much clean-up for future maintainability (1.16, 1.17, 1.18, 1.19, 1.20, 1.21, 1.22)

That’s a lot, isn’t it? :)

But there’s more! All of the above happened on the 8.x-1.x branch. As described in #2952293: Branch next major: version 2, requiring Drupal core >=8.5 (and mentioned in #61), we have many reasons to start a 8.x-2.x branch. (That branch was created months ago, but we kept them identical for months.)
Why wait so long? Because we wanted all >6000 JSON API users to be able to gently migrate from JSON API 1.x (on Drupal ⇐8.5) to JSON API 2.x (on Drupal >=8.5). And what better way to do that than to write comprehensive test coverage, and fixing all known problems that that surfaced? That’s what we’ve been doing the past few months! This massively reduces the risk of adding JSON API to Drupal core. We outlined a plan of must-have issues before going into Drupal core: #2931785: The path for JSON API to core — and they’re all DONE as of today! Dozens of bugs have been flushed out and fixed before they ever entered core. Important: in the past 6–8 weeks we’ve noticed a steep drop in the number of bug reports and support requests that have been filed against the JSON API module!

After having been tasked with maturing core’s REST API, and finding the less-than-great state that was in when Drupal 8 shipped, and having experienced how hard it is to improve it or even just fix bugs, this was a hard requirement for me. I hope it gives core committers the same feeling of relief as it gives me, to see that JSON API will on day one be in much better shape.

The other reason why it’s in much better shape, is that the JSON API module now has no API surface other than the HTTP API! No PHP API (its sole API was dropped in the 2.x branch: #2982210: Move EntityToJsonApi service to JSON API Extras) at all, only the HTTP API as specified by http://jsonapi.org/format/.

TL;DR: JSON API in contrib today is more stable, more reliable, more feature-rich than core’s REST API. And it does so while strongly complying with the JSON API spec: it’s far less of a Drupalism than core’s REST API.

So, with pride, and with lots of sweat (no blood and no tears fortunately), @gabesullice, @e0ipso and I present you this massively improved core patch!

EDIT: P.S.: 668K bytes of the 1.0M of bytes that this patch contains are for test coverage. That’s 2/3rds!

To which e0ipso replied:

So, with pride, and with lots of sweat (no blood and no tears fortunately), @gabesullice, @e0ipso and I present you this massively improved core patch! So much pride! This was a long journey, that I walked (almost) alone for a couple of years. Then @Wim Leers and @gabesullice joined and carried this to the finish line. Such a beautiful collaboration!

:)

July 9

Then, about 12 hours ago, core release manager xjm and core framework manager effulgentsia posted a comment:

(@effulgentsia and @xjm co-authored this comment.) It’s really awesome to see the progress here on JSON API! @xjm and @effulgentsia discussed this with other core committers (@webchick, @Dries, @larowlan, @catch) and with the JSON API module maintainers. Based on what we learned in these discussions, we’ve decided to target this issue for an early feature in 8.7 rather than 8.6. Therefore, we will will set it 8.7 in a few days when we branch 8.7. Reviews and comments are still welcome in the meantime, whether in this issue, or as individual issues in the jsonapi issue queue. Feel free to stop reading this comment here, or continue reading if you want to know why it’s being bumped to 8.7. First, we want to give a huge applause for everything that everyone working on the jsonapi contrib module has done. In the last 3-4 months alone (since 8.5.0 was released and #44 was written):
  • Over 100 issues in the contrib project have been closed.
  • There are currently only 36 open issues, only 7 of which are bug reports.
  • Per #62, the remaining bug fixes require breaking backwards compatibility for users of the 1.x module, so a final 1.x release has been released, and new features and BC-breaking bug fixes are now happening in the 2.x branch.
  • Also per #62, an amazing amount of test coverage has been written and correspondingly there’s been a drop in new bug reports and support requests getting filed.
  • The module is now extremely well-documented, both in the API documentation and in the Drupal.org handbook.
Given all of the above, why not commit #70 to core now, prior to 8.6 alpha? Well,
  1. We generally prefer to commit significant new core features early in the release cycle for the minor, rather than toward the end. This means that this month and the next couple are the best time to commit 8.7.x features.
  2. To minimize the disruption to contrib, API consumers, and sites of moving a stable module from core to contrib, we’d like to have it as a stable module in 8.7.0, rather than an experimental module in 8.6.0.
  3. Per above, we’re not yet done breaking BC. The mentioned spec compliance issues still need more work.
  4. While we’re still potentially evolving the API, it’s helpful to continue having the module in contrib for faster iteration and feedback.
  5. Since the 2.x branch of JSON API was just branched, there are virtually no sites using it yet (only 23 as compared with the 6000 using 1.x). An alpha release of JSON API 2.x once we’re ready will give us some quick real-world testing of the final API that we’re targeting for core.
  6. As @lauriii pointed out, an additional advantge of allowing a bit more time for API changes is that it allows more time for the Javascript Modernization Initiative, which depends on JSON API, to help validate that JSON API includes everything we need to have a fully decoupled admin frontend within Drupal core itself. (We wouldn’t block the module addition on the other initiative, but it’s an added bonus given the other reasons to target 8.7.)
  7. While the module has reached maturity in contrib, we still need the final reviews and signoffs for the core patch. Given the quality of the contrib module this should go well, but it is a 1 MB patch (with 668K of tests, but that still means 300K+ of code to review.) :) We want to give our review of this code the attention it deserves.
None of the above aside from the last point are hard blockers to adding an experimental module to core. Users who prefer the stability of the 1.x module could continue to use it from contrib, thereby overriding the one in core. However, in the case of jsonapi, I think there’s something odd about telling site builders to experiment with the one in core, but if they want to use it in production, to downgrade to the one in contrib. I think that people who are actually interested in using jsonapi on their sites would be better off going to the contrib project page and making an explicit 1.x or 2.x decision from there. Meanwhile, we see what issues, if any, people run into when upgrading from 1.x to 2.x. When we’re ready to commit it to core, we’ll consider it at least beta stability (rather than alpha). Once again, really fantastic work here. Next

So there you have it. JSON API will not be shipping in Drupal 8.6 this fall.
The primary reason being that it’s preferred for significant new core features to land early in the release cycle, especially ones shipping as stable from the start. This also gives the Admin UI & JS Modernization Initiative more time to actually exercise many parts of JSON API’s capabilities, and in doing so validate that it’s sufficiently capable to power it.

For us as JSON API module maintainers, it keeps things easier for a little while longer: once it’s in core, it’ll be harder to iterate: more process, slower test runs, commits can only happen by core committers and not by JSON API maintainers. Ideally, we’d commit JSON API to Drupal core with zero remaining bugs and tasks, with only feature requests being left. Good news: we’re almost there already: most open issues are feature requests!

For you as JSON API users, not much changes. Just keep using https://www.drupal.org/project/jsonapi. The 2.x branch introduced some breaking changes to better comply with the JSON API spec, and also received a few new small features. But we worked hard to make sure that disruption is minimal (example 1 2 3).1
Use it, try to break it, report bugs. I’m confident you’ll have to try hard to find bugs … and yes, that’s a challenge to y’all!

  1. If you want to stay on 1.x, you can — and it’s rock solid thanks to the test coverage we added. That’s the reason we waited so long to work on the 2.x branch: because we wanted the thousands of JSON API sites to be in the best state possible, not be left behind. Additionally, the comprehensive test coverage we added in 1.x guarantees we’re aware of even subtle BC breaks in 2.x! ↩︎

Categories: Drupal

Pages