Mar 08 2020
Mar 08

In combination with the FacetAPI module, which allows you to easily configure a block or a pane with facet links, we created a page displaying search results containing contact type content and a facets block on the left hand side to narrow down those results.

One of the struggles with FacetAPI are the URLs of the individual facets. While Drupal turns the ugly GET 'q' parameter into a clean URLs, FacetAPI just concatenates any extra query parameters which leads to Real Ugly Paths. The FacetAPI Pretty Paths module tries to change that by rewriting those into human friendly URLs.

Our challenge involved altering the paths generated by the facets, but with a slight twist.

Due to the projects architecture, we were forced to replace the full view mode of a node of the bundle type "contact" with a single search result based on the nid of the visited node. This was a cheap way to avoid duplicating functionality and wasting precious time. We used the CTools custom page manager to take over the node/% page and added a variant which is triggered by a selection rule based on the bundle type. The variant itself doesn't use the panels renderer but redirects the visitor to the Solr page passing the nid as an extra argument with the URL. This resulted in a path like this: /contacts?contact=1234.

With this snippet, the contact query parameter is passed to Solr which yields the exact result we need.

/**
 * Implements hook_apachesolr_query_alter().
 */
function myproject_apachesolr_query_alter($query) {
  if (!empty($_GET['contact'])) {
    $query->addFilter('entity_id', $_GET['contact']);
  }
}

The result page with our single search result still contains facets in a sidebar. Moreover, the URLs of those facets looked like this: /contacts?contact=1234&f[0]=im_field_myfield..... Now we faced a new problem. The ?contact=1234 part was conflicting with the rest of the search query. This resulted in an empty result page, whenever our single search result, node 1234, didn't match with the rest of the search query! So, we had to alter the paths of the individual facets, to make them look like this: /contacts?f[0]=im_field_myfield.

This is how I approached the problem.

If you look carefully in the API documentation, you won't find any hooks that allow you to directly alter the URLs of the facets. Gutting the FacetAPI module is quite daunting. I started looking for undocumented hooks, but quickly abandoned that approach. Then, I realised that FacetAPI Pretty Paths actually does what we wanted: alter the paths of the facets to make them look, well, pretty! I just had to figure out how it worked and emulate its behaviour in our own module.

Turns out that most of the facet generating functionality is contained in a set of adaptable, loosely coupled, extensible classes registered as CTools plugin handlers. Great! This means that I just had to find the relevant class and override those methods with our custom logic while extending.

Facet URLs are generated by classes extending the abstract FacetapiUrlProcessor class. The FacetapiUrlProcessorStandard extends and implements the base class and already does all of the heavy lifting, so I decided to take it from there. I just had to create a new class, implement the right methods and register it as a plugin. In the folder of my custom module, I created a new folder plugins/facetapi containing a new file called url_processor_myproject.inc. This is my class:

/**
 * @file
 * A custom URL processor for cancer.
 */

/**
 * Extension of FacetapiUrlProcessor.
 */
class FacetapiUrlProcessorMyProject extends FacetapiUrlProcessorStandard {

  /**
   * Overrides FacetapiUrlProcessorStandard::normalizeParams().
   *
   * Strips the "q" and "page" variables from the params array.
   * Custom: Strips the 'contact' variable from the params array too
   */
  public function normalizeParams(array $params, $filter_key = 'f') {
    return drupal_get_query_parameters($params, array('q', 'page', 'contact'));
  }

}

I registered my new URL Processor by implementing hook_facetapi_url_processors in the myproject.module file.

**
 * Implements hook_facetapi_url_processors().
 */
function myproject_facetapi_url_processors() {
  return array(
    'myproject' => array(
      'handler' => array(
        'label' => t('MyProject'),
        'class' => 'FacetapiUrlProcessorMyProject',
      ),
    ),
  );
}

I also included the .inc file in the myproject.info file:

files[] = plugins/facetapi/url_processor_myproject.inc

Now I had a new registered URL Processor handler. But I still needed to hook it up with the correct Solr searcher on which the FacetAPI relies to generate facets. hook_facetapi_searcher_info_alter allows you to override the searcher definition and tell the searcher to use your new custom URL processor rather than the standard URL processor. This is the implementation in myproject.module:

/**
 * Implements hook_facetapi_search_info().
 */
function myproject_facetapi_searcher_info_alter(array &$searcher_info) {
  foreach ($searcher_info as &$info) {
    $info['url processor'] = 'myproject';
  }
}

After clearing the cache, the correct path was generated per facet. Great! Of course, the paths still don't look pretty and contain those way too visible and way too ugly query parameters. We could enable the FacetAPI Pretty Path module, but by implementing our own URL processor, FacetAPI Pretty Paths will cause a conflict since the searcher uses either one or the other class. Not both. One way to solve this problem would be to extend the FacetapiUrlProcessorPrettyPaths class, since it is derived from the same FacetapiUrlProcessorStandard base class, and override its normalizeParams() method.

But that's another story.

Mar 08 2020
Mar 08

It was a pleasure to present "Decoupled Drupal with Flutter" at Florida Drupalcamp 2020. I want to thank the organizers, volunteers, attendees, presenters, and sponsors for making this camp so successful. I have wanted to attend this camp for a number of years and so happy to make it finally!

Flutter is a Google-developed open source UI toolkit for building amazing, natively compiled applications for mobile, web, and desktop from one codebase. Flutter is user and developer-focused around four vision pillars: beautiful, fast, productive, and open. While it is best known for helping launch mobile native apps, such as the official Hamilton app, it is now being used for building native desktop and web applications.

Below you will find the video for my talk and slide deck:

[embedded content]

Related code repositories:

Mar 06 2020
Mar 06

Book cover: Local Web Development with DDEV ExplainedLocal Web Development with DDEV Explained, by Mike Anello, now available on amazon.com!

Looking to move to a professional local development environment? Learn how to use DDEV for your everyday development work with numerous step-by-step examples including installing DDEV, getting an existing Drupal site up-and-running, adding a Solr container, and everyday DDEV commands and workflows.

Only $5.99 for a digital copy and $9.99 for the dead tree edition - pick up your copy today!

Mar 06 2020
Mar 06

The mission of the Community Working Group (CWG) is to foster a friendly and welcoming community for the Drupal project and to uphold the Drupal Code of Conduct. 

- https://www.drupal.org/community/cwg 

As the Drupal Community Working Group (CWG) moves into its seventh year, we have been thinking a lot about how we can evolve it to better serve the changing needs of the Drupal Community. 

At the moment, the four members of the CWG split our time between reactive issues (conflict resolution and Code of Conduct enforcement) and proactive issues (community health resources, workshops). While the work is often emotionally taxing, it is also often extremely rewarding. We believe the proactive work has a large impact on the community, but our time is often filled with reacting to issues in the community. 

To this end, we have been working with Tara King (sparklingrobots) on identifying new CWG roles, mainly focused on proactive tasks. These new roles will not play a part in conflict resolution matters and will not receive access to any incident reports or other confidential information that has been shared with the group, with the exception of subject matter experts, who may see some limited information when brought in to consult on specific cases. These new roles are designed for individuals to help provide insight and expertise into how we can better support and grow our community.

It is important to note that all CWG members must abide by the CWG Code of Ethics, regardless of if they consult on conflict resolution or Code of Conduct enforcement cases or not.

The list of new CWG roles follows below. In some cases, we have already reached out to individuals to fill some of the roles. Full details about the roles can be found on the Community Working Group's Community Health Team page.

  • Community health - develops and produces community health initiatives like workshops and tweaks to drupal.org processes.
  • Community event support - assists Drupal community events with Code of Conduct template, playbooks, and other resources. It is our hope that this role be filled by members of the newly established Drupal Event Organizers Group. 
  • Subject matter experts - includes individuals with knowledge of specific geographic, industry, and mental health areas. In some cases, subject matters experts will be provided with limited information about specific conflict resolution issues they have been brought in to assist with.
  • Ambassadors - coordinators between the CWG and other groups, including the Drupal Association, other open source projects, Drupal.org maintainers, and Diversity and Inclusion.

We are strong believers that the more proactive work we do, the stronger and healthier our community will be and the less reactive work we will have. 

If you, or someone you know, are interested in any of the new roles, please drop us a line at drupal-cwg [at] drupal.org. Include your name, drupal.org username and which role (or roles) you are interested in. 
 

Mar 06 2020
Mar 06

There’s one thing that can give you better positions in Google, more visitors, and increased conversions in the same “package.” This thing is an improved website speed. Today, we will discuss what helps you achieve this on a Drupal 8 site.

Drupal is able to power even content-heavy websites — and stay light! The 8th version has plenty of tricks in this realm, some of which were newly-introduced in it (like the BigPipe module) and have gained the respect of many developers. So let’s begin our tour on the ways to improve website speed in Drupal 8.

Great ways to improve website speed in Drupal 8

These tips approach website speed optimization from different angles to create the perfect picture. Their choice may depend on the site, so consider ordering Drupal 8 performance audit from our experts. However, the very common and popular ones are as follows.

Drupal 8 caching opportunities

Caching is a known technique to improve website speed. It allows you to store the copies of web pages to serve them quickly to browsers and avoid server overhead. The main great news is that the D8 core comes packed with robust built-in caching tools:

The Internal Page Cache

The Internal Page Cache core module improves website speed for anonymous users, serving your web pages to them very fast. It does not work with dynamic content for anonymous users (e.g. a shopping cart).

The Internal Dynamic Page Cache

The Internal Dynamic Page Cache core module does the caching to improve speed both for anonymous and authenticated users. It caches your web pages excluding the personalized parts and turns the latter into placeholders.

The BigPipe

The BigPipe core module was initially created by Facebook to handle dynamic pages with high speed. It loads the unpersonalized page elements first and dynamic ones next so users can quickly start interacting with the site. Drupal’s creator Dries Buytaert demonstrated how it can improve website speed.

BigPipe nodule demonstration

Cacheability metadata

Cacheability metadata in D8 allows for flexible handling of the cache. This data can be provided by all things that are renderable (or used to determine what to render). Here are three 3 properties in cacheability metadata:

  • cache tags allow you to refresh the cache when something changes (based on some entity data or configuration values)
  • cache contexts allow you to show different content depending on some context (user role, permissions, URL, etc.)
  • cache max-age determines how long the item should be cached (0 for uncacheable ones), which makes it great for time-sensitive caching scenarios

Caching in Drupal 8 Views

There are fine-grained caching settings offered by modules that deal with content display (such as the core Views module, the contributed Panels module, etc.) For example, the Views allows you to configure tag-based and time-based caching in Advanced settings.

Caching in Drupal 8 Views

Bandwidth optimization: CSS/JS aggregation in Drupal 8

A useful way to improve website speed in Drupal 8 is to aggregate your CSS and JavaScript files. This reduces the number of HTTP requests needed for the page to load, as well as the amount of data transferred. Out-of-the-box, D8 offers two options here enabled by default at /admin/config/development/performance.

Contributed modules like the AdvAgg (Advanced CSS/JS Aggregation). It comes with a bunch of submodules such as Advanced Aggregates, Advanced Aggregates CDN, Advanced Aggregates CSS/JS Validator, Advanced Aggregates External Minifier, Advanced Aggregates Minify CSS, and many more. They fit every purpose and scenario when you want to improve website speed.

CSS/JS aggregation in Drupal 8

Responsive image styles in Drupal 8

Image optimization is an essential task for anyone who wants to improve website speed. Drupal has a built-in system of image styles to trim images (crop, scale, etc.) to fit every display mode. Moreover, D8 allows you to provide responsive images that will look optimal on every device. In addition to providing user-friendly experiences to your audience, this technique improves website speed because there is no need to load large images on mobiles.

The Responsive Image and Breakpoint module in the core enables you to set up breakpoints in a theme’s or a specific module’s YAML file. According to them, respective image versions will be shown to different resolution devices. See a detailed guide on responsive web design in Drupal 8.

Responsive image styles in Drupal 8

Lazy loading for better performance in Drupal 8

Using the lazy loading technique with images, videos, or other media, is widely popular. Its aim is to save resources and improve website speed. Lazy loading allows you to only load the media that are in the current user’s viewport.

In D8, lazy loading can be applied with the help contributed modules where one of the most popular is the Lazy-load and the Image Lazyloader.

Using the latest version of PHP to improve website speed

Since PHP improves with each new version, it’s reasonable to use keep it updated on your website’s server. It will make your site’s code cleaner and more efficient, so it’s a great way to improve your website speed. The current PHP version supported by D8 is PHP 7.3. Our Drupal support experts are always ready to help you with it.

Cleaning up the unnecessary modules

As it has been in all times, you will greatly improve your site speed by disabling the unused modules or replacing the heavy ones with better alternatives. In D8, this has become much easier since plenty of great modules (or similar capabilities) have been moved into core.

For example, the Drupal creators strive to make the core Layout Builder the one and only module for all layout-related purposes, replacing the very popular contributed ones like Panels, Panelizer, Display Suite, etc. The new Media handling system also eliminates the need for a bunch of contributed modules. Further examples abound.

That said, to improve your website speed, it’s great to update to the latest D8 version, discover its capabilities, make an audit of modules no longer in need, and configure the new ones so they meet your needs. You can also entrust this to our Drupal development team.

Integration with JavaScript frameworks

JavaScript frameworks (React, Vue, Angular, Gatsby, and many more) are known for their exceptional capabilities in high loading speed. They also help you create interactive interfaces that users love.

Today, it’s a trend to integrate them into D8 sites. Roughly speaking, there are two key ways for doing this:

  • headless, or decoupled setup where Drupal serves as a backend sending data via an API to a frontend application on React (or other JS framework)
  • creating separate interactive elements and embedding them into your particular website’s pages handled by Drupal.

There are numerous libraries, starter kits, and source plugins from the JavaScript framework creators in this sphere.

However, the best news is that D8 is built on an API-first principle and has enhanced integration capabilities. The core modules such as HAL, HTTP Basic Authentication, JSON:API, RESTful Web Services, and Serialization that do everything to provide the perfect data sharing in the right format. There are also very nice contributed modules, for example: 

  • REST UI that provides a user interface for managing the core REST resources
  • GraphQL that allows you to manage queries using the GraphQL query language
  • Subrequests that groups sets of requests together to improve website speed
  • RELAXed Web Services provides a generic RESTful API for all nodes and extends the core REST capabilities

Our experts can improve your website speed

We have reviewed the common ways to improve website speed in Drupal 8. There are plenty of other tools out there and steps that can be made based on your site’s review. Ask our Drupal support specialists to give your site an extra performance boost that your business will notice!

Mar 05 2020
Mar 05

One of the most common questions in our training is how to add custom CSS or Javascript to a Drupal site.

The best solution, of course, is to add it to the theme (preferably a sub-theme); however many times site builders and editors don't have access to the codebase of a Drupal site.

To accomplish this, you can use the Asset Injector module.  This module combines CSS Injector and JS Injector from Drupal 7 into one.

Let's get started...

1. Install and enable the Asset Injector module.

Head over to https://www.drupal.org/project/asset_injector and either download the latest recommended version of the project (usually with a green background) or right-click on the .tar or .zip file and copy the location.

Asset Injector Download

Install the Asset Injector module:

  • Click Extend.
  • Click Install New Module.
    • If you copied the URL from the project page, paste it into the "Install from a URL" field and click Install.
    • If you downloaded the module, click on the "choose file" button, select the file and click Install.

After the installation is done:

  • Click Enable Newly Added Modules link. 
  • Check Asset Injector in the Development section.

Install Asset Injector

  •  Scroll down and click "Install".

2. Add Custom CSS

  • Go to Configuration > Development > Asset Injector

Asset Injector

  • Click CSS Injector.
  • Click "Add CSS Injector"
  • Enter a label.
  • Enter CSS code.  No need to add <style> </style>.

CSS in Asset Injector

If you click Save Now using the example above, every H1 tag (page titles etc.) will be red in color.

You can limit where this CSS is applied!  Assets can be restricted by: 

  • Content Type
  • Theme
  • Node ID
  • User Role

Note:  These settings can be combined, requiring all or just one of them for the condition to be applied under, "Condition Requirements".

Asset Injector Conditions

  • Click Save if you made any changes
  • Click Back to Site to review the update!

3. Adding Javascript

Adding Javascript is essentially the same process as above.

  • Go to Configuration > Development > Asset Injector > JS Injector and click "Add JS Injector".

JS Injector

  • Enter a label.
  • Enter JS code.
  • Select any of the Advanced Options required.
  • Select any conditions (they are the same as CSS Injector).
  • Click Save. 

Note: These configurations use the Drupal 8 Entity API and therefore, all configurations are held in the database. This means they are exportable using Configuration Synchronization or custom module installs using yml files.  This is great for multi-site installations where each site may have a few minor differences.

Also, at the time of this writing, the module does not work well with asset overrides, be it in settings.php, from the language system or other contributed modules. 

Summary

You don't need to be a themer to add some CSS or Javascript to your Drupal 8 website.  The Asset Injector module is a helpful addition for any site builder.


About the author

Rod holds two masters degrees and has been training people how to do "things" for over 25 years. Originally from Australia, he grew up in Canada and now resides just outside Cincinnati, Ohio.
Mar 05 2020
Mar 05

It's 2020, and there is hardly any business not impacted by digital disruption. While the paradigm is still in its infancy, it’s expected to accelerate for every industry and company across the globe, including education. 

In an effort to reposition itself around a more relevant, albeit rapidly evolving, technology-driven student-crowd, the education institutes end up getting it tough. To keep up with the expectations for deeper and more advanced digital services, institutes find themselves in a flux to re-invent - what and how they operate by embracing the right technology.

Higher education institutes have it tough managing different software vendors, keeping the systems up and running with the latest upgrades while also providing a coherent and advanced digital experience

Higher-ed institutes need to come to life online in a way that stands out from their peers, if they are to face up to the intensely fierce competition in education.

What is an Educational Institute’s Digital Ecosystem Like? 

Intricate. 

An average higher education institution now would not have anything less than 10 enterprise software excluding the smaller support systems, making it one of the most complex digital ecosystem. 

Departments and societies, in order to quickly distribute a lot of information to different stakeholders, often work around with software that works best for them. Eventually, an array of web content management tools are implemented. 

Managing these WCMS tools, building relationships with different software vendors, keep the systems up and running with the latest upgrades while also providing a coherent and advanced digital experience for students and faculty.

An average higher education institution now would not have anything less than 10 enterprise software excluding the smaller support systems, making it one of the most complex digital ecosystem

Imagine once, how difficult and costly it is for the educational institutes to manage and build relationships with all those >10 different software vendors, keep the systems up and running with the latest upgrades while also providing a coherent and advanced digital experience for students and faculty.

What options do higher ed institutes have, then? 

Can Drupal Help Higher-Ed Institutes?

Drupal is the most widely used content management system in higher education. Over 70% of higher education institutions rely on Drupal to drive their digital strategy. It is the preferred CMS for higher education because it provides the most flexibility for creating and managing various kinds of content to suit the needs of many different groups and audiences. Offering a powerful content management system along with collaboration of multiple authors, it comes to be the top choice for a university website. 

 

Serving different needs of different departments with multisite and easy integration

With numerous departments constituting a university, Drupal’s multisite feature helps departments and branches to have a seperate site built for each of them, over the same Drupal installation, enabling each of the branches to manage their own website.

You can effectively store content for every website and easily share content with the help of the Domain Access module. Also managing complex architecture of the website as well as various sections for prospective students, current students, alumni, faculty, and staff becomes much easier. Whether it is handling thousands of users, along with numerous content types, Drupal makes it much easier with reduced page loading time.

Centralized? Decentralized? Just easy user access control 

There is always a need to keep a check on how data is accessed and by whom. Different user roles in a university will need to interact with the system differently. Professors, students, and administration staff need different permissions for creating and editing website content based on their roles. With Drupal, it’s easier to manage out-of-the-box offered user roles, and contributed user access modules which help you to configure roles and permissions on the site.

Multilingual Functionality

With students all across the globe accessing the university website, Drupal makes it easy with its modules to translate the website as per the preference for any international student to scroll through the website and read content in the language of their choice. Drupal 8 comes with 4 multilingual modules in core for easy translation and offers a choice of 100+ language options.

An easy and better creation process 

Drupal offers an easy to use workflow management module, to get almost anyone to publish content and keep the website up-to-date. This process helps to keep the website up-to-date with any recent changes. The modules allow you to type content directly into a text editor in Drupal and preview it before publishing.

Universities often need to categorize content in various ways to make a website handy to use. Drupal comes with a taxonomy system which helps in categorising your content  and eases website content access. It simplifies the site navigation process by understanding the context of the entire content with tags. Learn how to easily add tags with Drupal taxonomy in 9 easy easy steps.

Responsive and Scalable 

With many people preferring to read content on the go, Drupal sites are built to be responsive and are mobile friendly. An already optimized content proves to be a huge time and money saver. 

It’s also highly scalable and easily extends as the higher education institutions grow with increased number of student enrollments. 

Secured Websites

Education websites usually consist of sensitive information such as student’s family details, contact numbers etc. By using Drupal, you need not worry about any loss or theft of data as updating the website regularly for security patches keeps it secured. 

The fact that top institutions like Harvard University, Stanford Law School, Duke University, Brown University, Rutgers University, University of Oxford, University of Prince Edward Island, Karlstad University, Zaman University, Bentley University, Uncommon Schools, University of Waterloo, and Yale have their websites built on Drupal, it proves to be a testimonial for secured websites.

Reaching the right audience with SEO friendly features

Drupal ensures the website is SEO friendly and boosts search rankings in search engines with its search website optimization modules. With Drupal, you can manually set SEO friendly URLs without additional effort (or let the Pathauto module do it for you). With its powerful taxonomy system, you can categorize your website content and automatically create page titles and meta tags, which are important elements of SEO-friendly websites. Since Google's content analysis algorithms classify web pages based on fresh content, Drupal can help you keep your website updated so as to boost your website ranking. 

It remains a powerful cost-effective solution, with its round the clock community support through forums and discussions, offering numerous other benefits, at no additional costs. 

Robust and flexible governance and permissions capabilities

Higher education websites have various departments supporting the development and maintenance of the entire website content. Drupal’s higher level of security and site-governance tools offers great benefits by facilitating the entire process of managing sections and establishing simple processes for approving content changes. Site administrators within departments can customize the site’s workflow to suit their specific needs by leveraging Drupal’s highly flexible permission system. This overall benefits the teams by removing bottlenecks in the site editing process and fastens content editing, without letting them make changes to the design.

Evaluating accessibility tools

Higher education institution websites aim to offer a user-friendly experience to every potential student. It is important for such websites to adhere to compliance guidelines and be accessible to every visitor. Drupal, with the help of its robust tools, makes it easier to design websites which ensures the highest level of accessibility. 

One such Drupal distribution it offers is OpenEDU, which offers a built-in accessibility checker. It ensures website issues are discovered and addressed in real time.

 

Are you thinking of building a website for your higher education institution and can’t decide whether to opt for Drupal or not? Contact us today. Together we will understand your vision for your university website and how Drupal fits best to enhance your digital presence. 

Mar 05 2020
Mar 05

We’re back with an overview of the top Drupal-related blog posts from last month. Here are some of our favorite reads from February, have a look.

Drupal contribution culture - your opinions, experience and perspectives matter

The Drupal community is one where contribution to the project is really well curated, with contribution credits for those giving back. Recently, this system has been reinforced with Drupal’s introduction of the Contribution Recognition Committee

The first post on our list for February, published on the Drupal Association’s blog by its CTO Tim Lehnen, is a plea by Paul Johnson and other Committee members to the community to help out the project by completing a survey (found in the post). 

This survey is part of their ongoing efforts to collect as much feedback from different areas of the community as possible. If you’re contributing to Drupal in any other way than with code, they’re especially interested in hearing your thoughts - so, check out the post and take the survey now!

Read more

Webform module now supports variants, which can be used for A/B tests, segmentation, and personalization

The second post, written by Jacob Rockowitz, is an update to the Webform module which he maintains, understandably one of the most widely used modules in the Drupal community.

The post is centered around how to personalize a webform to specific audiences through A/B testing and segmentation. Currently, this is achieved out-of-the-box by creating two different instances of the form, then directing the user to the right one. 

However, Jacob has developed a more elegant solution: using variants of a single webform. Site builders are able to add a Variant element to their webform, which they can then use to manage the variants. After successful A/B testing, they can apply the winning variant to a master webform.

Read more

1x2020 Digital Trends

While not strictly a Drupal-specific post, this next one by Baddý Sonja Breidert of 1xINTERNET is still relevant enough for Drupal that we decided to include it. In it, Baddý lists the top digital trends they expect to see in 2020. 

Here’s a quick overview of what these trends are: contextual experiences; integration of commerce and content; speed and performance; providing a great marketer and editor experience with Drupal; headless, decoupled, microservices and micro frontends; design systems; consolidation and reusability; web analytics and customer data; AI and machine learning. 

Among other areas that have been and will continue to be relevant, Baddý lists accessibility, security, privacy and DevOps. 

Read more

Off to the digital experience races: The second CMS war is officially here

We continue with another post that isn’t exactly 100% Drupal, as it concerns web content and digital experience management in general - Preston So’s excellent post on the second CMS war which began in a way with the introduction of headless/decoupled. 

Following Gartner’s retirement of its Magic Quadrant for web content management in favor of the recent digital experience platform, we’ll now have to consider the user experience of different personas than just in the web era. This coincides with the second browser war, which was itself also focused on user experience.

According to Preston, the most important factor in digital experience management is in fact presentation management. Balancing the site builder and developer experience will be crucial to figuring this out.

Read more

Growing the Drupal Community in 2020

Fifth on our list for February, this post by Evolving Web’s Suzanne Dergacheva is concerned with - you guessed it - growing the Drupal community in 2020. 

The target audience for this initiative are people outside the Drupalverse; this ranges from decision makers choosing the most appropriate technology for their project, to people who use Drupal but aren’t actively involved in the community, and people who are just starting out with Drupal.

The ways to achieve getting more people into the community differ depending on a specific person’s “Drupal journey”, but the end goal for all is to get them to feel empowered by Drupal, start actively participating in the community and maybe even join the Drupal Association. 

Read more

5 Reasons to Choose Drupal as a Scalable CMS

In the next post we’d like to highlight, Andrew Brisebois of Acro Media provides 5 reasons why you should go with Drupal if you need a scalable CMS solution. Its powerful out-of-the-box multilingual capabilities make it ideal for spreading into international markets and it allows you to incorporate pretty much any feature you need.

On top of that, it’s also widely regarded as a very security-focused CMS and is known for its high integrability with third-party applications. It’s supported by a strong open-source community and, due to its API-first approach, it can be used as a headless CMS with a front-end framework of choice used for presentation, making it a solid future-proof solution.

Read more

Managing Media Assets using Core Media in Drupal 8

Another thing Drupal is known for in the CMS sphere is its streamlined handling of Media entities. This is what the next post by Ivan Zugec of WebWash is about: it’s a combination of a text and video tutorial on how to manage Media assets using core Media in Drupal 8. 

Ivan begins the post with some history of Media in Drupal 8. What follows is the tutorial of using the Media core module: creating Media assets, using the Media field and the Media Library, embedding Media into the Editor, and creating a custom Media type. He finishes with a practical example of embedding an Instagram image in Drupal.

Read more

A Sure-Fire Migration Approach to Drupal 8

Finally, we have a post by Matt Davis of Third and Grove detailing a well thought-out migration to Drupal 8. In it, he offers some great tips for getting the most out of your migration without putting in excessive amounts of effort.

Matt’s first tip is to not migrate the configuration, but to instead focus on the content and rebuild the structure manually. For a better overview of what needs migrating, he recommends using a spreadsheet. 

Additionally, you should make sure you understand the reasons behind certain choices, with the aim of optimizing the newly built site. And, of course, the site has to be editor-friendly, so you should work with content editors to also improve their experience. Lastly, he suggests performing a technical audit before setting about on the migration.

Read more

This concludes our recap of February’s top Drupal blog posts. If you like what you’ve read, check out the rest of our blog and make sure to stay tuned for more upcoming content!
 

Mar 04 2020
Mar 04

The process of auditing a website for ADA accessibility compliance, as described by the W3C(R) Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0  falls into two essential categories: automated and manual. The automated part of the process is relatively straightforward. It’s simply a matter of leveraging the right tools for diagnosing non compliance with WCAG 2.1. The next and indispensable step tends to be open-ended and undefined. 

The WCAG-EM is the definitive to the evaluation process.

[WCAG-EM documentation]... is intended for people who are experienced in evaluating accessibility using WCAG 2.0 and its supporting resources. It provides guidance on good practice in defining the evaluation scope, exploring the target website, selecting representative samples from websites where it is not feasible to evaluate all content, auditing the selected samples, and reporting the evaluation findings. It is primarily designed for evaluating existing websites, for example, to learn about them and to monitor their level of accessibility. It can also be useful during earlier design and development stages of websites. 

The process is very well defined and W3C(r) provides a sample reporting tool for audits. 
 
We, at Promet Source like to tinker and apply small changes, without deviating from the process to improve the report and make it easier to use and read. Our version of the Website Accessibility Evaluation Report Generator is Google Doc based, provides an executive summary, a simple dashboard of results and is FREE! This template from Promet reflects WCAG 2.1 guidelines, and designed  for use by accessibility analysts and developers to detect errors missed by automated testing.

As a part of our commitment to advancing inclusivity and web experiences that are accessible to a full range of differently abled web users, we are making this tool available to all.
 

Small preview of the tool

 

Why Manual Accessibility Testing Matters

Manual accessibility testing goes deeper and wider than automated scans. It includes:

  • Keyboard testing
  • Color contrast testing
  • Screen reader testing
  • Link testing
  • Tables and forms testing
  • Cognitive testing
  • Mobile testing

The types of non-compliance issues, which are detected by manual testing tend to have the greatest likelihood of exposing site owners to ADA accessibility lawsuits.
 
Keep in mind that diagnosing a website for accessibility and fixing any noncompliance issues that are uncovered is not a one-size-fits-all endeavor. 

Every site has a distinct set of strengths and challenges, and in the current environment, the stakes are high for getting it right. That’s why we at Promet Source believe that tapping the expertise of a Certified Professional in Accessibility Core Competencies (CPACC) is the most efficient and effective path for bringing a site into compliance. We follow a distinct WCAG 2.1 auditing and remediation process that consists of a series of value-added steps in a specific order.  

Circle process graphic depicting web accessibility testing

 

Value-Added Elements

There is a high degree of added value that occurs during and following an accessibility audit. The education, consultation, and opportunity to dig deep and deconstruct aspects of a site that no longer serve the organizational mission fuels a better and wiser team of developers and content editors. For a number of reasons, web accessibility also enhances SEO.
 
In the current climate, websites are highly dynamic and serve as the primary point of engagement for customers and constituents. Constantly evolving sites call for an ongoing focus on accessibility, and an acknowledgement that staff turnover can erode the education, expertise, and commitment to accessibility that is in place at the conclusion of an audit. 
 
For this reason, a bi-annual or annual audit is a highly recommended best practice. 

Interested in kicking off a conversation about auditing your site for accessibility? Contact us today.
 

Mar 04 2020
Mar 04

Promet Named Acquia Growth Partner of the Year Award AND the Most Wins of the Year for 2019 in the Americas

Recognized Based on Business Performance

We are pleased to announce today that Promet Source has been selected for two Acquia Awards for Growth Partner of the Year Award AND the Most Wins of the Year for 2019, given for its superlative performance during the past year. Promet is being honored with overall business growth and having the most client wins with Acquia.

“We delivered measurable results by leveraging Acquia's Lift platform, which facilitated website personalization that served to optimize customer experiences,” said Andy Kurcharski, CEO at Promet Source. “We leveraged Acquia Site Factory, along with Acquia's entire, client-centered suite of products, enabled successful client partnerships and brand-building migrations that drove high-performance, personalized, and expectation-exceeding websites.”

Acquia recognized 15 partners across five global regions based on their overall revenue performance, overall growth with Acquia, and number of new customers secured last year.

“Promet Source is to be commended. 2019 was an incredible year for Acquia and our partners, with demand for our world-class digital experience solutions driving significant growth,” said Joe Wykes, SVP, global channels and sales, at Acquia. “2020 promises to be another amazing year, and together we’ll help our customers set the bar for delivering impactful customer experiences across channels.”

Leaders in digital experience delivery, Acquia partners support the world’s leading brands in facilitating amazing customer experiences. A full list of Acquia Partner Award winners can be seen here. 

Contact Promet today to explore how a partnership with Promet and Acquia can produce a high-performance, personalized, and expectation-exceeding website for your organization.

Promet Source Winner: Public Sector Growth Partner of the Year by Acquia
 

Promet Source Winner: Public Sector Most Wins of the Year by Acquia

Mar 04 2020
Mar 04

Monday night before the "Super Tuesday" primary, I'm searching for "does the bernie sanders app help you offer rides to polls to people" and finding no answer. (It does not.)

All I found was Lyft offering ride codes to for a handful of non-partisan non-profits to distribute. If Lyft can realize that simple physical access to vote is a barrier that affects different groups of people unequally and cite the facts about youth not voting, it surely came up on the Bernie Sanders Slack.

Yet in this highly online-connected campaign, some of the basic steps to winning (asking everyone: Do you have a plan to vote? Do you need help getting to the polls?) didn't make it into the official app, nor in any public side efforts.

There are a huge number of thoughtful, dedicated people working on the Bernie Sanders campaign (and in other political campaigns), but as in every movement I've witnessed I'm convinced that not all the best ideas are bubbling up.  This is especially true for communities like Drupal where even the idea of shared goals, let alone the mechanism for identifying and realizing them, can seem to disappear when you look for them directly.

Even when a goal is simple (get this one person elected president) the tactics are likely to need to be varied and complex.

This is vastly more true when we're talking about a movement. Even in a presidential campaign like for Sanders, the the goals behind the goal—health care, living wages, lots more jobs for everyone because we're putting people to work reversing global warming—are many, multifaceted, and cannot possibly be achieved only through electing someone, even to an office like the United State's imperial presidency.

After getting over my personal hangup of asking people for something without having at least the barest offer of help (a ride to go vote), I did start texting a few people to encourage them to vote. But as I texted my brother in New York, I'm still bummed we're organizing in the context of political campaigns, instead of having huge movements that, as an afterthought, choose our politicians.

I'm not making (or necessarily opposing) the argument that electoral organizing distracts from more important grassroots organizing.

I have gotten involved with a local solidarity network which focuses on direct action to help people with immediate problems— frequently a dozen people helping just one person or a few people at a time win livable spaces from landlords (or get security deposits back), or get stolen wages from an employer.

This sort of deep organizing—really only medium deep, but it's using available resources to nearly their maximum capacity—does not have the breadth of the typical mayoral campaign.

We need breadth as well as depth. There are many problems that can't be solved on a case by case basis. Although the type of organizing local solidarity networks engage in builds the capacity to take on bigger problems, it doesn't necessarily scale fast enough, or have clear mechanisms to translate built power and solidarity in one area to others.

The question of translating power built in one sphere to another is even more pressing for the election campaigns.

It's no secret, as Frank Chapman of the National Alliance Against Racist and Political Repression reminded people in Minneapolis when he visited from Chicago, that you build political power by going door to door and finding supporters.

What would our political movements be able to do if we didn't have to redo all the grunt work every time?

Or if people weren't canvassed only by campaigns (electoral or otherwise), but asked about their needs?

There are enough people who give a damn.

We could build immensely powerful movements from the ground up, if we had a way to agree how shared resources of movements—including communication channels—would be controlled.

To be a movement for, among other things, democracy, we need to be democratic ourselves. The DSA is probably farthest along in reach and democratic mechanisms, and so a natural place to join.

We need better technology to coordinate to achieve justice, liberty, and better lives for all. I don't mean merely a better canvassing app.

We need approaches and tools that let us share power. Then we can truly build power together.

A positive spin on this extremely spun election: media coverage has meant a ton but advertising has not. And the national, corporate media (which, if for instance you haven't checked who owns your local newspaper, if you even have one, is nearly all of the news media) is the sworn enemy to economic fairness and equal political power. No one with resources should put a cent into our enemies pockets by buying ads, especially when it doesn't even work.

It's a perfect opportunity to build institutions that work for us, rather than pouring resources and energy into institutions that are getting us killed.

We can build a communication network through which we collectively decide what we want, and then figure out how to coordinate to get it— whether it's electing someone or holding politicians or businesses accountable with direct action or forming ourselves into a giant cooperative corporation to negotiate as workers and buyers more equally with the huge corporations we deal with on a day-to-day basis.

If you're in the position to connect us to campaigns, cooperatives, parties, or other organizations who see a need for communication tools controlled by all the people in an organization or movement, where the ideas and control of resources can build from below, please contact Agaric.

Mar 04 2020
Mar 04

DrupalCon - Be Human, Think Digital.

Drupal is one of the largest free software projects in the world. It powers thousands of websites, many of them for community groups, nonprofits and other grassroots organizations.  

As a cooperative distributed across three countries, we're using DrupalCon as a unique opportunity to meet face to face with ourselves and others in the community. Our focus, as usual, is to work with others to make Drupal work for grassroots movements.

In a time where people power is more important than ever, it's critical that groups have communication tools that supports those efforts. Drupal comes equipped with powerful tools like multilingual support, flexible content modeling, and a modular design.

NonProfit Summit

May 19th 9-4pm, $150 (lunch and coffee provided)

Clayton is one of the co-organizers of the NonProfit Summit and it's on pace to be one of the best. Now running for many years, the schedule has been fine tuned to the needs of nonprofit and activist technologists with a combination of panels, breakout discussions and lightning talks.

Register for the summit.

Making the Move to Drupal 8

Drupal 7 end of life is coming in 2021 and many sites are still on Drupal 7. The move to 8 can be challenging, so we're offering two trainings and one session on the topic.

Drupal 8 Content Migrations Training

May 19th 9-4pm, $500 (lunch and coffee provided)

Back by popular demand is our training to teach community members how to move content into Drupal using the Migrate API. Participants will

  • Learn to run migrations from the user interface and the command line with Drush.
  • Import data from CSV and JSON files.
  • Transform the data to populate taxonomy, date, image, file, and address fields.
  • Get content into Paragraphs.
  • Learn to debug migrations.

The only prerequisite is a basic understanding of nodes, content types and fields. We will work hands-on through step by step examples, with four trainers on hand to assist people and answer specific questions participants have.

Last year's training sold out and we expect the same this year, so be sure to sign up sooner than later.

Register for the Drupal 8 content migrations training.

Upgrading to Drupal 8 Using the Migrate API Training

After giving our Drupal 8 Content Migrations training several times last year, we learned there is also a need for a training that is specifically for those upgrading from Drupal 6/7 to Drupal 8.

In this training, participants will

  • Understand the different approaches to upgrading your site to Drupal 8 using the Migrate API.
  • Revise site architecture and map configuration from previous site to the new one (content types, fields, etc).
  • Learn how to migrate data into media entities and paragraphs.
  • Learn how to migrate data from modules that do not offer automated upgrade paths.

While the content migration training is at an Intermediate level, this training is advanced. You should be familiar with source, process and destination plugins; how the process pipeline works; and how to execute migrations from the command line via Drush. This is a great training for experienced Drupalers looking to upgrade Drupal sites, including those that will undergo changes to their information architecture.

Register for the Upgrading to Drupal 8 Using the Migrate API training.

If Drupal migrations work is a big part of your work, the two trainings are intentionally complimentary and is a good opportunity to level up in this domain.

Drupal Migrations for Non-Coders Session

There is a growing collection of resources on migrating to Drupal 8, but most of it is focused on professional Drupal developers. However, there are many organizations with staff who are technical, but not day-to-day coders. This is particularly common in nonprofits where people where many hats. If that describes you, we encourage you to join us.

The specific day and time hasn't been set, but you can still add it to your schedule.

Add Drupal migration for non-coders to your schedule.

Grassroots Drupal Birds of a Feather

Each year we lead or join in on a BoF with others working with grassroots groups. We'll be doing the same, so keep an eye out for that in the schedule.

It's also great to grab coffee, have a hallway conversation, scheme over lunch and hang out at after parties with kindred spirits. Reach out to us at [email protected] if you're going to DrupalCon and want to meet up!

Mar 04 2020
Mar 04

Table of Contents

Inspirations for Claro
--Finding inspiration in many places
--Honoring Seven's legacy
Claro's current state
--A new future for Views UI?
The origins of Claro's design
--Keeping Claro's redesign lean
Conclusion

Across Drupal's storied history, perhaps the most noticeable — and visible — changes in the CMS's evolution have come from the redesigns of the administrative interface that underpin every user's interaction with the Drupal editorial experience. Now, with the release of the Claro administration theme, which replaces the Seven theme and focuses on content author and site builder use cases, Drupal has reached another important inflection point in the history of its user experience. Claro is a theme that prizes accessibility, usability, and Drupal's legacy of extensibility.

This author (Preston So, Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) had the privilege of moderating a wide-ranging conversation about Claro on a Tag1 Team Talks episode with Cristina Chumillas (Claro maintainer and Front-End Developer at Lullabot) and colleagues Fabian Franz (Senior Technical Architect and Performance Lead at Tag1) and Michael Meyers (Managing Director at Tag1). In this multi-part blog series, we traverse the trajectory of Claro from its origins to its current state and dig into its design and development processes to learn more about how this administration theme came to be. In this second installment, we focus on the inspiration behind and execution of Claro's design.

Inspirations for Claro

If you are unfamiliar with the Claro administration theme for Drupal 8, I highly recommend returning to the first installment in this blog series to learn more about Claro itself, its origins, and its goals to better understand the rest of this blog post. In this section, we explore some of the sources of inspiration for Claro and how modern interaction patterns underlined the urgency of a refresh for Drupal's vaunted administration interface.

Finding inspiration in many places

Roughly one year ago, during the beginning stages of the Claro development process, the team expressed an ambitious vision. At the time, Claro's architects were primarily focused on the content author persona. Cristina Chumillas recalls during our conversation that "ideally for a content author, you should have a drag-and-drop interface" or something snazzy that would not only match modern expectations but also convey a sense of futuristic panache. The team worked towards an interface that approximated some of the patterns found in WordPress Gutenberg, as they were finding considerable inspiration in that project.

However, the obstacle Drupal presents is that reaching a certain threshold of impressive transitions and other expectations of interactive user experiences requires considerable JavaScript. In addition, the notion of substituting Drupal's entire administration interface with a dynamic JavaScript application was not feasible. As a result, the team took a step back to reconsider the technical options available to them — at the same time Gutenberg's accessibility fiasco occurred — and determined that a better choice was to release something sooner so that users could experiment with it rather than wait for foundations that may never be stable.

Honoring Seven's legacy

Another important consideration that lent urgency to the endeavor was the need to refresh at least some of the color scheme utilized in Drupal's user interface, as this was the source of some comments about the aesthetic outdatedness of the Seven theme. In the end, Claro is comprised of what Cristina calls a "grown-up" version of Seven with color changes, all of which was made possible over the course of many months with the help of many volunteers.

All in all, the change in Claro's vision away from reinventing the wheel for Drupal's front end allowed for a more realistic and achievable end result to emerge in order to replace the Drupal user interface in a more sustainable fashion. Because Claro is ultimately based on the same stylesheet as Seven, the key advantage that Claro has over a solution such as a JavaScript application is that stability is not a concern.

Claro's current state

Claro is a beta theme in Drupal 8.8, and in several releases, it is slated to become a stable core theme. As Cristina states in our Tag1 Team Talks episode, Claro is perfectly usable at this very moment, and there are several Drupal sites in production already making use of it on their own administration layers. The good news about the widening adoption of and interest in the Claro administration theme is that there is growing momentum for larger-scale modifications to many more interfaces than were touched initially.

A new future for Views UI?

One of the chief examples of this momentum is strong interest in updating Views UI, which remains one of the most frequent user interfaces that Drupal users come in contact with. But as with all projects, Claro had the constraint of time and scope, and the team was loath to deem the stability of a redesigned Views UI a showstopper for a stable release of Claro. This situation would have led, Cristina argues, to a never-ending initiative without a finish line in sight.

Claro: Existing Views UI Cristina states during our webinar that eventually, the vision is to reach the place where all of Drupal's user interfaces have been redesigned from their previous Seven incarnations, from which point several other initiatives will kick off. But Cristina also rightfully adds that anointing an initiative with the responsibility of refreshing an administration interface cannot place every conceivable user interface under that umbrella if there is any hope of releasing a finished product within five years.

During our discussion, Fabian joined Cristina in recommending a strategy in which iterative initiatives that focus on regularly introducing small amounts of new features is the most sustainable form of initiative coordination. After all, at some point we must all decide that we are finished and there is no more to be done. In fact, the Claro team originally envisioned adding a new user role and even adding a second dashboard for content authors with draggable blocks, but questions quickly spiraled out of control, with suggestions for modifying the entire layout of Drupal's administration interface. Cristina admits that many portions of Drupal's administration layer will require initiatives in their own right in order to handle the inevitable demands that a redesign of a complex user interface will bring.

The origins of Claro's design

The initial ideas for the design of the Claro administration theme emerged almost from the beginning, as Cristina recalls during our Tag1 Team Talks episode. During those first discussions, it became readily apparent that any new administration theme had to look sufficiently different enough from Seven such that the vast majority of Drupal users would immediately spot the difference. But Claro's redesign had many limitations, including in Drupal's own brand: It was considered anathema to Drupal's brand identity to change the color scheme to one involving red and green that didn't reflect Drupal's color consistency.

Keeping Claro's redesign lean

Claro: Manage form display While the Claro team had sought lighter and more vivid colors for Claro and looked for inspiration in sources like Material Design and other design systems available online, they also understood that they could not reinvent the wheel with a revolutionary design, not only due to technical considerations but also aesthetic concerns. After all, administration interfaces are not intended to be the center of attention; Cristina efficiently defines the optimal administration interface as "something that works and that people understand."

Because of this sentiment across the team, Claro's architects decided to eschew fancy buttons and fieldsets, such as one particular interaction pattern in which a text field would change its outline color and display an underline to add dynamism to the page. During the first accessibility review, however, the consensus was that an overly "fancy" design was not appropriate for all users and that sticking to basic design principles was a better approach. Trying to keep things focused and tight, the Claro team sought a brighter look, initially employing a neon blue that was eventually darkened due to accessibility concerns. In the end, most of Claro's design elements came together based on inspiration from other designs already in the wild, and the team did their utmost to adhere to known patterns.

Conclusion

With the new Claro administration theme, Drupal 8 joins the growing list of content management systems that have revamped their look and feel for their most important users: the site builders and content authors that use the CMS on a daily basis. Claro demonstrates the sort of scrutiny on personas that also suggests substantial attention paid to the needs of all users, whether that entails accessibility, usability, or extensibility. And thanks to the give-and-take that characterizes accessibility reviews and design sprints, Claro emerged from its development with an efficient design that recalls many known patterns and is therefore a familiar and eminently learnable interface.

In this blog post, we discovered some of the inspiration that Claro built upon to produce its subtle and modern design. We also discussed some of the motivations that led to some of Claro's design decisions, including the choice to eschew a neon blue color and simplification of interactions with text fields in order to limit unnecessary distractions. In the third installment of this multi-part blog series about Claro, we spotlight some of the accessibility considerations that went into Claro's design and development, among other topics.

Special thanks to Cristina Chumillas, Fabian Franz, and Michael Meyers for their feedback during the writing process.

Photo by Aaron Greenwood on Unsplash

Mar 04 2020
Mar 04

Historically, upgrading to a new major version of Drupal has been a time-consuming and expensive process involving first building an entirely new website in Drupal (content modeling, module installation, setting configuration, creating a new theme), and then creating a detailed process to migrate content from the previous Drupal website.

Then Drupal 8 came along five years ago with a new promise: Making Drupal upgrades easy forever.

Here’s how it works: Minor versions (8.1, 8.2, 8.3, etc) are being released every 6 months. They include bug fixes, new features, and API improvements. Some APIs may also get deprecated between minor versions. Major versions (9.0, 10.0, 11.0, etc) are being released when external dependencies (Symfony 3, etc.) have reached end-of-life and new versions are needed that would break backwards compatibility.

Major versions are similar to a minor version release, with two distinctions:

  1. Updates to external dependencies (new PHP version, new Symfony version, etc)
  2. Removing all parts of the API that have been marked as deprecated for this major version.

Assuming the environment is compatible, a website that doesn’t have any deprecated API calls in its modules / themes / custom code can be upgraded to the next major version as easily as a minor version upgrade.

Chart: Drupal 9.0 API = Drupal 8.9 API minus deprecated parts plus third party dependencies updatedDrupal 9 guide on Drupal.org

Getting your Drupal 8 site ready for Drupal 9

To remove deprecated code today, you would:

  1. Upgrade all contrib modules/themes to the latest version available
  2. Run drupal-check or Upgrade Status to get a list of all deprecations in your project
  3. For each project in the report, check its corresponding drupal.org page to see if it has Drupal 9 plans that would point to the issue summarizing Drupal 9 readiness plans and efforts.
  4. Apply the patches that are already available.
  5. Run drupal-check or Upgrade Status again to get the list of all the rest of the deprecations that are left in your project
  6. For every deprecation found:
    1. Search for documentation (Upgrade Status module help to find them)
    2. Manually fix the code

The current way of fixing deprecated API use involves a lot of manual and repetitive work. If one type of deprecation appears multiple times in your code, you will need to figure out how to fix it for each occurrence.

Chart: All drupal.org project errors by fixabilityAll Drupal.org project errors by fixability

There are approximately 33,000 occurrences of deprecated code in all contributed modules today. That’s a lot of repetitive manual work to get ready for Drupal 9!

The light at the end of the tunnel

While Googling various topics regarding Drupal upgrades, I stumbled upon a proof of concept called Drupal 8 Rector, by Dezső Biczó at Pronovix. I discovered the brilliant tool that powered it, called Rector.

What is Rector?

Rector automates PHP code upgrades.
Rector understands PHP which allows complex edge cases.

Rector PHP, by @VotrubaT, is one of the most useful projects that PHP developers overlook. It automates the upgrade and refactoring of your code (e.g. upgrades your Symfony 3 app to Symfony 4). @symfony_en

How does Rector work?

  1. Parses PHP code into an abstract syntax tree (AST)
  2. Runs  a set of upgrade rules
  3. Saves all changes back to a PHP file

What can Rector already do?

  • Rename classes, methods, properties, namespaces or constants
  • Upgrade code from PHP 5.3 to PHP 7.4
  • Upgrade code from Symfony 3 Symfony 4

Drupal 8 Rector was the missing bridge to enable automated code upgrades from Drupal 8 to 9. While Dezső unfortunately did not have time to continue working on it any more, the tremendous potential value was clear. Palantir was very interested in taking it further and making development for it easier, as we saw this as a tool that could save us time (and avoid creating new bugs) when manually fixing modules that our clients will need for Drupal 9. So we started cleaning up the repository, pared it down to its essentials and published under a new name, Drupal-Rector

What is Drupal-Rector?

A set of Rector rules. Each rule upgrades code for a deprecated API use in Drupal.

When can I start using Drupal-Rector?

Today! Just go to https://github.com/palantirnet/drupal-rector or run

composer require palantirnet/drupal-rector --dev

Image of terminal window running composer command for drupal-rector

What's the status of Drupal-Rector?

It has one Rector rule so far that fixes only one deprecation: `drupal_set_message` (Originally implemented by Dezső in the proof of concept, thank you!) This depreciation alone occurs over 8,000 times in various contributed modules and it roughly accounts for a quarter of all deprecated API uses!

https://dev.acquia.com/drupal9/deprecation_status/graphs

Our immediate goal 

Is to create Rector rules for the 15 most popular deprecations. Those 15 rules will cover 50% of all Drupal deprecations!

What are potential future goals?

We are exploring the possibility of Drupal.org integration, which would allow Drupal-Rector to be run on drupal.org projects and automatically create issues with patches. The ultimate situation would be if each API change came with a new rector rule, so projects can stay evergreen without much manual effort as the rules would be executed on them continually. 

Help us make it a better tool!

See https://github.com/palantirnet/drupal-rector. Issues are maintained on drupal.org at https://drupal.org/project/rector. We also plan to be leading contribution activities at upcoming Drupal events, including:

  • MidCamp in Chicago on March 18-21, 2020
  • DrupalCon in Minneapolis on May 18-22, 2020

We hope to see you there!

Additional Resources:

Special thanks to Jennifer Shaal, Adam Bergstein, Dan Montgomery, Gábor Hojtsy, AmyJune Hineline and George DeMet for their contributions to this post.

Mar 04 2020
Mar 04

If you've ever received an email or SMS from a UK Government service then chances are it's been sent from the Gov Notify platform. Gov Notify is a great example of a platform-oriented approach to government - by using this shared platform instead of building their own notification system, delivery teams can focus their work higher up the value chain, delivering services that meet user needs.

Gov Notify itself is built on open source technologies, but is also released as open source, meaning other organisations and governments can host their own Notify platform and benefit from subsequent feature and security releases.

So, as maintainer of the Gov Notify Drupal module it was great to see that the governments of both Australia and Canada have adopted Notify to enable service teams to deliver messages to their users. Because it re-uses much of the same underlying codebase as the UK Government's Notify platform, this made adapting the Gov Notify Drupal module straightforward. Out-of-the-box the module now works with the UK, Australia and Canada's Notify platforms, enabling public sector delivery teams working with Drupal in those countries to concentrate on user-needs driven service delivery rather than API integration.

You can find the Gov Notify Drupal module at https://www.drupal.org/project/govuk_notify with installation and configuration docs at https://www.drupal.org/docs/8/modules/govuk-notify/installation

Thanks go out to Jonathan Ingram (Australia's Digital Transformation Agency) and Bryan Willey (Canada Digital Service team) who provided test accounts and advice whilst integrating with their platforms.

I'm Andrew - a Tech Architect and Agile Delivery Consultant. Find out more about the services I offer here

Mar 04 2020
Mar 04

Technology has never failed to be a game-changer for any business that is striving to succeed online, especially eCommerce, which has become ubiquitous.

Given this, there are both high-cost enterprise software solutions as well as inexpensive SaaS options that offer ready-to-go eCommerce solutions. However, irrespective of whichever solution you choose, both types of solutions bring liabilities and risk for your business with them since they lock your business with agreement. Seldom, a deep dependency arises on a single vendor to provide scalable solutions and remain relevant in this fast-paced world of technology.

That's where Drupal Commerce comes in. 

It is a great open-source framework that brings a modern touch to online business and allows merchants to pick those features only that are crucial for their business. Centarro Toolbox, a new addition, is a collection of support packages enriches the Drupal Commerce project.

This blog will focus on Centarro’s existence, features to benefit commerce alongside Drupal Commerce’s capabilities.

And that’s how Centarro came into the community-

Centarro logo

 

 Post the inception of Commerce Guys (now called Centarro) in 2009, it developed two effective tools: Drupal Commerce and Platform.sh.

3 years down the line, Centarro Toolbox was launched to deliver more engagement for the next generation of Drupal Commerce users. This toolbox is a collection of SaaS products and extends support to packages that enhance any Drupal Commerce site. 

Growing up to more than fifty thousand merchants and processing billions in transactions per year, change has been at the center of eCommerce from the journey of Commerce guys to Centarro. In fact, it’s new products, support, and service offerings make their expertise accessible to even more teams to help them accommodate change and progress with ease.

Know What Centarro Has To Offer-

It encompasses its three owned SaaS tools aimed to boost any Drupal Commerce site. The features offer update automation, code quality monitoring, and a sales and analytics dashboard that offers deep insights on customers’ profiles, interests, and a lot more to merchants.

  1. Quality Monitor

Quality Monitor ensures an aggressive analysis of your codebase to discover problems in the development stage instead of deploying it for production.

It gives you intimation on necessary code updates and inadequate API usage.

Centarro’s static code analysis tool helps all the Drupal sites become Drupal 9 ready as Drupal Check. It continuously strives to expand its own library of rules to detect problems specific to Drupal Commerce.

 2.   Update Assistant

Update Assistant automatically connects your site to Drupal core, module and library updates. It traces the security release feeds to ensure that you remain updated as soon as these updates are available and email you as well when updates get implied.

Once hosting platforms qualify, the assistant creates a QA-ready staging environment where you can swiftly review updates before deploying.

Compatible with both Drupal 7 & 8 based sites.

 3.   Centarro Insights

Centarro insights provide a 360-degree overview of the sales and analytics dashboard that embeds right into the backend of Drupal Commerce. 

Built with third-party storage and analytics libraries, it doesn’t demand any maintenance - simply install the connector module and you are all set to go!

Its features include sales graphs and reports, conversion rate tracking and funnel reports, and channel-based analysis. New features appear on your site right after they are available.

What Happened to Drupal Commerce?

Drupal Commerce is employed for creating eCommerce websites and applications with various needs and sizes.  At its essence, it executes strict development benchmarks and leverages the greatest features of Drupal.

Drupal logo in shopping cart

Simply put, Drupal Commerce is built keeping in mind a framework mindset, focusing on what enterprises can create from it. Similar to a fundamental commerce system, it emphasizes developers and site builders, who can build custom eCommerce solutions as needed. It helps-

  • Built on an enterprise CMS

Drupal Commerce caters to all the needs of small and enterprise-level organizations indistinguishably. Apart from lending the support that enterprise-level online businesses need, it also offers a robust connection between eCommerce capabilities and the content part. Given this, it facilitates anyone in the team to keep the site up & running up-to-date and equipped for your customers.

  • Easy to install with Commerce Kickstart

Drupal remains mindful of its version 7 users so that they can install Drupal Commerce hassle-free through Commerce Kickstart - another tool built by Centarro. Commerce Kickstart comprises of the out-of-the-box demo facility for Drupal Commerce, replete with all the must-haves of eCommerce features.

On the other hand, Drupal 8 users can install Commerce Kickstart through Composer.

  • Meets every basic eCommerce need

Installing Drupal Commerce through Commerce Kickstart is remunerative for enterprises as it instantly equips your site with the essential built-in configurations and modules to get your eCommerce store from the flat and keep it running.

Further, the demo facility in Commerce Kickstart helps in eliminating weeks of development time by rolling out a sample eCommerce site that you can engage with and easily fine-tune it to cover your needs.

  • Flexibility for customization

Since some business needs can be unique depending on the business nature, Drupal Commerce comes as a right fit that enables flexible design, both as a modular and configurable system, to help the system acclimate the sales of physical products as well as online-only content. Likewise, it supports subscription-based business models, among others.

  • Extensibility with modules

Drupal Commerce provides enterprises’ eCommerce stores the liberty to modify and improve its functionality by installing the desired modules. Additionally, Drupal community members also fortify the development of contributed modules to enhance the power and flexibility of Drupal-powered sites, as well as your Drupal Commerce store.

Some features like shipping can be added through the Commerce Shipping module, or for say, subscription-based billing functionality can be achieved with Commerce Recurring.  Similarly, you can add more depending on your requirements.

  • Ample security for your online store

Adding various modules and functionalities to your site for engaging customers fails at a point when you as an enterprise, are not well-equipped to keep yours and your customers’ details secure.

Fortunately, Centaroo gives due importance to security and so, has been developed keeping the same in mind.

Furthermore, if you keep Drupal Commerce up-to-date, your site is able to fix the regular bugs and patches necessary to safeguard it from potential threats. 

Wrapping-up

Centarro is a powerful toolbox that can bring significant benefits to eCommerce business owners with its complete overview of the sales and analytics dashboard. Further, Drupal Commerce facilitates enterprises to leverage those features only which meets their requirements in today’s online business, thus making up for an efficient way to keep the business rock and roll!

Need help with setting up your commerce store?  Drop us a line and our experts will be in touch.

Mar 04 2020
Mar 04

Since 2017, WordPress has had a really great WYSIWYG editor in the Gutenberg plugin. But the Drupal community hasn't yet reached consensus on the best approach to the content management system's (CMS) editorial experience. But a strong new option appeared when, with a lot of community effort, Gutenberg was integrated with Drupal.

Previously, there were two main approaches to content creation in Drupal 8:

  • In the Paragraph-based approach, content is assembled out of entities called paragraphs. Currently, approximately 100,000 websites use the Paragraphs module (according to Drupal).
  • The Layout-Builder approach uses an editorial tool shipped with Drupal 8.5. It is still undergoing improvements, but it is the next strong contender because it is really well integrated with the Drupal core. Stats on usage are not available since Layout Builder is part of Drupal.

At the end of 2018, the Drupal community, lead by Fronkom (a Norwegian digital agency strongly focused on open source solutions), ported the WordPress Gutenberg project as a contributed module into Drupal. Let's take a look at how Gutenberg works in Drupal (including some cool Drupal-specific integrations).

Installation

Installing the Gutenberg module is as straightforward as installing any Drupal module, and it has good installation documentation.

Configuration

Gutenberg is integrated into Drupal's default content-entity creation workflow. You can use it on any of the content types you choose, provided that the content type has at least one text area field, which is where the Gutenberg editor's output will be saved.

To enable the Gutenberg project on a content type in Drupal, you have to navigate to its settings: Structure > Content types and, from the dropdown next to the content type where you want to use Gutenberg, click Edit.

In the form that appears, scroll down and select the Gutenberg experience tab on the left, where you can find the settings described below. Select the Enable Gutenberg experience box.

Template

This is one of the cool features that is not available in WordPress out of the box. It enables you to define a template for a new page in a JSON structure. This will pre-populate all newly created articles with dummy placeholder content, which will help editors structure content correctly. In the screenshot above, I added a heading and a paragraph. Note that any double-quotes have to be escaped.

Template lock

This setting allows you to define whether users are allowed to delete the placeholder content, add new blocks, or just edit the existing, pre-populated content.

Allowed Gutenberg and Drupal blocks

This is another super-cool feature on the Drupal side of Gutenberg. Drupal allows users to create various types of blocks to design a page. For example, you could create a block with a list of the five latest blog posts, the most recent comments, or a form to collect users' emails.

Gutenberg's deep integration with Drupal allows users to select which Drupal blocks are available to users while they are editing (e.g., limit embeds to YouTube) and use blocks as inline content. This is a very handy feature that allows granular control of the user experience.

There's not much to choose from in a blank Drupal installation, but a live site usually has many blocks that provide various functionalities. In the screenshot below, the Search form Drupal block is selected.

After you finish the configuration, hit Save content type.

Publishing content with Drupal Gutenberg

When Gutenberg is enabled for a content type, it takes over most of the editorial experience.

In the main window, you can see the dummy placeholder content I added in the Template configuration above.

Drupal-specific options

On the right-hand side, there are a few fields and settings that Drupal provides. For example, the Title field is a required separate field in Drupal, and therefore it is not on the main Gutenberg screen.

Underneath the Title, there are additional settings that can vary, depending on the modules installed and options set up in Drupal. You can see Revision log messages, Menu settings, Comment settings, and a place to add a URL alias.

Typically, Drupal content types are composed of several text fields, such as tags, categories, checkboxes, image fields for teasers, etc. When you enable Gutenberg for a content type, these additional fields are available in the More settings tab.

You can now add your content—it works the same as it does in WordPress Gutenberg, with the additional option to add Drupal blocks.

In the screenshot below, you can see what happens when I add some text to replace the placeholder text, a search block from Drupal, a title, tags, and a custom URL alias.

After you hit Save, your content will be published.

And that is it. It works like a charm!

Working together for better software experiences

Gutenberg in Drupal works well. It is an alternative option that allows editors to control the look and feel of their websites down to the tiniest details. Adoption is growing well, with over 1,000 installations as of this writing and 50 new ones every month. The Drupal integration adds other cool features like fine-grained permissions, placeholder content, and the ability to include Drupal blocks inline, which aren't available in the WordPress plugin.

It is great to see the communities of two separate projects working together to achieve the common goal of giving people better software.

Mar 03 2020
Mar 03

Web accessibility is ingrained in Drupal’s values and principles. Starting with Drupal 7, the web accessibility initiative has progressed to great extents through Drupal 8. Why is website accessibility so significant? How does Drupal 8 ensure website accessibility? Let’s dive in to answer all your questions.

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect. - Tim Berners Lee, Inventor of World Wide Web.

The internet as we know it today is 11315 days old! Originally conceived to meet the demand for automatic information sharing between scientists in universities and institutes around the world, the internet today is an integral part of more than 3 Billion people in the world. For various reasons ranging from social networking to collecting information for projects, internet today is arguably the most powerful resource known to mankind.

Over the years, the boom in chat-bot and machine learning applications has led to businesses crafting their online presence in the form of websites and using artificial intelligence for a better customer experience. This is not surprising, given the fact that in recent years, chat or messaging has taken over social media to be the "go-to" option for users who want to contact a business.

But have you ever stopped to think, can everyone access the web?

It is 2018 and I wonder, why is web accessibility still less, well, accessible? As a business, the competitive market pushes you to reach as many people as you can to promote your brand. More the barriers lower the chances of reaching potential customers. This basically is the concept behind web accessibility: to eliminate the barriers the audience face.

What is Web Accessibility?

Generally, people refer web accessibility with screen readers or visual disabilities. However, the range of topics that it covers is vast and includes more than that. For example, having an appropriate screen contrast for a person to see the screen on a sunny day is a use case for someone with a normal vision rather than for someone with a disability.

The World Wide Web Consortium has introduced some guidelines to achieve certain levels of accessibility to ensure that a website is as useful as possible. Published in 1999 as version 1.0 and later in 2008 as version 2.0, the WCAG 2.0 is generally accepted as the standard to measure when talking about web accessibility and the information you present to a user.
 

web_accessibility

The Importance of Web Accessibility

With the internet's growing importance in people's life, if what you want to convey (your content basically) is not easily accessible to everyone, you’re turning away your audience before they even get to the door. For example, something as simple as a broken hand or a temporary blindness can make it difficult to navigate the web.

While the fact that web accessibility is not only for those with disabilities is quite resonant, businesses need to know that the flexible and responsive design of a fully accessible website is a benefit to everyone. Web accessibility standards are built to promote inclusion and Drupal is setting a benchmark when it comes to supporting and fostering inclusion.

importance_of_web_accessibility

How does Drupal help?

Drupal CMS, a web based SaaS provides the ability to organize a manage an organization's web content in a systematic manner. The guidelines of the World Wide Web Consortium are divided into two - ATAG 2.0 that addresses the authoring tools and the WCAG 2.0 which addresses the web content and is widely used by developers and accessibility evaluation tools. Drupal CMS, as a platform, has been built to adhere to both the guidelines. While the accessibility initiative started with Drupal 7, Drupal 8, addresses some of the best accessibility features.

Drupal 8 Accessibility Features and Modules

The most advanced version of Drupal allows your website to be far more likely to be accessible, to assistive technologies and the users who depend on them, than ever before. Drupal 8 extends accessibility with various core and contributed modules. 

Better Contrast

Poor contrast level is often cited as the most commonly overlooked feature by the developers. However, in Drupal 8, the core themes have higher contrasts, thanks to the Drupal's accessibility maintainers. With improved contrasts, users suffering from colour-blindness can easily websites. Also, this feature is an added advantage when visiting a website under bright sunlight in a portable device like a mobile phone or a tab.

Forms

Errors while filling forms is one of the most common factors that affect the user interface. With the new standards, identifying these errors becomes much easier. By using a better form validation error verbiage, Drupal 8 provides an option to turn on this feature that improves accessibility related to the display of form errors. For example, a visually impaired person can now easily identify what errors he might have made when filling in a web form.

Buttons instead of links

A common practice among many website owners is to use anchor texts as "call to action" instead of buttons. From a semantic standpoint, it is more logical to use a button rather than anchor texts as these user interface elements are action oriented. Thus, Drupal 8 has called for this measure to use buttons rather than links. This new standard set by Drupal 8 can be handled without becoming heavily dependent on WAI-ARIA that can be useful in identifying the purpose of some elements.

Other Drupal 8 Accessibility Features 

Alt text (Alternative text) usually refers to the words that are used to describe a particular image. Though not visible or rendered on the page, these alt texts are used by tools like screen readers and is a great asset to web accessibility. This feature which is set to ‘required’ by default in Drupal 8 helps visually impaired audience to know what the image is all about with the help of the text.

TabbingManager is a feature that constrains tabbing and guides non-visual users to important “tabbable” page elements. This is useful for users who prefer to use the Tab key on the keyboard rather than the mouse.

The Aural Alerts feature is a Javascript function that passes an assertive or a polite message/instruction to the aural users if there are any changes made on the page (which would otherwise go unnoticed on screen readers).

Layout Builder Module

Layout builder is one of the most powerful and popular Drupal 8 modules that is widely used by content builders. It offers easy and powerful page-building capabilities allowing site builders to build custom pages, create and override reusable templates, granular customizations and much more. It has been stable since the release of Drupal 8.7 and is in core. 

As part as Drupal’s commitment to inclusion and accessibility, Layout Builder meets all the guidelines set in the WCAG 2.0 AA (needed to meet the AA level of the Web Content Accessibility Guidelines). Only once it passed the “accessibility gate”, the module was released as a stable version. And this was a commitment that was made and duly fulfilled by the Drupal community.

CKEditor Accessibility Checker Module

The CKEditor Accessibility Checker module is a contributed Drupal 8 module that allows you to test the accessibility level of the content within the CKEditor. It not only detects the problem areas in website accessibility; it also helps you solve them for better accessibility conformation. It leverages the Accessibility Checker plugin from CKEditor.com to perform these functionalities.

ckeditor_moduleImage Source: Drupal.org

SiteImprove Module

Siteimprove is a Drupal 8 contributed module that provides a plugin to connect your Drupal website to the Siteimprove intelligence platform. Siteimprove is a Digital Presence Optimization software that provide amazing insights that can not only help in improving web accessibility compliance but also helps improve website traffic, content quality, performance and more.

Text Resize Module

This is a contributed Drupal module for web accessibility and is widely used in Drupal 7 and Drupal 8 projects. It allows users to increase or decrease the font size of a web page with a click of a button. It helps visually impaired users to a great extent as they are able to adjust the size of the text that suits their eyesight.

text_resize_module Image Source : Drupal.org


 

The Future of Web Accessibility in Drupal

Over the years, Drupal has taken some great steps forward to achieve web accessibility through several of its major releases and is one of the leading implementations of the web accessibility standards. With web accessibility being one of the major factors contributing to the user interface and the ability of a business to reach the maximum audience, several strategic initiatives for Drupal core is sure to shape the future of how people interact with a website. Some of the noteworthy ones include:

  • Application-like interfaces and various UI interactions that are presented without full-page refreshes: sliding panels, autofocus, live result filters, drag-and-drop, pop-up success messages, live previews, wizard-like progress steps, and role impersonation.
  • Automated testing using headless browser drivers.
  • Supporting more interaction modes, such as MS Windows' high-contrast mode, and speech-driven control.
  • End-user testing for accessibility
  • The theme component library initiative which involves much refactoring of how Drupal produces output.
Mar 03 2020
xjm
Mar 03

This week is the first target release window for the Drupal 9 beta.

We’ve made significant progress on the beta requirements during the last couple of months thanks to the tremendous amount of work by the community. Based on the outstanding tasks in the meta issue, we are close to completing beta requirements, but not close enough to release it this week.

When will Drupal 9.0.0-beta1 be released?

Given how close we are to completing the beta requirements, we are considering releasing the beta in mid-March if the requirements are complete by March 13. If we do release the beta in 1-2 weeks, Drupal 9.0.0 will still be scheduled for release on June 3, 2020. We will make a final announcement by March 16 about whether there will be a June release.

If any must-have issues remain unresolved by March 13, we will move the beta target window to the first week of May, and Drupal 9.0.0 will be scheduled for August 3, 2020.

This does not affect the expected release date of Drupal 8.9.0 (scheduled for June 3, 2020) nor that of Drupal 9.1.0 (planned for December 2, 2020). The Drupal 8 and 7 end-of-life is also still November 2021.

We need your help to meet the beta deadline, whether it is March 13 or April 28! Drupal 9 readiness meetings are every Monday at 7pm UTC in the #d9readiness channel on https://drupal.org/slack. Help us with the issues below.

Current status and issues left for Drupal 9.0.0-beta1

Dependency updates

All PHP dependencies (Symfony, Laminas, Twig) have been updated to the versions we intend to use for Drupal 9.0.0, although we will continue to keep up to date with bugfix releases.

Nearly all JavaScript and CSS dependencies have been updated, with just two issues to go:
jQuery Cookie (needs review and testing from JavaScript developers!) and Normalize.css (RTBC and awaiting committer review).

Upgrade paths

In addition to deprecations, we are improving and simplifying in-place updates with update.php to ensure the Drupal 8 to 9 update is smooth and reliable. Four issues remain and could use additional help from experienced contributors:

We are also ensuring that all known critical Drupal 8 upgrade path bugs that may prevent updates from older Drupal 8 versions are fixed in 8.8 and 8.9. Only three remain. These technically difficult issues are critical for Drupal's data integrity:

Platform requirement changes

Drupal 9 has already raised the minimum PHP version to 7.3. We also want to increase MySQL, PostgreSQL, and SQLite requirements. This includes:

  • MySQL, MariaDB, and Percona (required prior to beta1)
  • PostgreSQL (Beta deadline; help needed! If you use Postgres, document what versions are available from your hosting provider.)
  • SQLite (Might be completed during the beta phase)

Drupal 9 base theme API

We want to add an up-to-date Drupal 9 version of the 'Stable' base theme. This issue and the related issues to decouple core themes from Drupal 8 base themes could use review and feedback from theme contributors.

Once all the above issues are complete, Drupal 9 is beta-ready. That means that we will have completed all of the significant code changes we intend to make, and that it should be possible to test updates of real sites against it if contributed and custom code has been ported. Site owners can use the Upgrade Status module to check the Drupal 9 readiness of their modules and themes; see the guide on updating to Drupal 9 for more information.

Other issues to complete prior to final release of Drupal 9

There is a second category of issues that we want to complete before Drupal 9.0.0 is released. Since we have fixed release windows, these also need to be either complete or close to completion, especially for the first beta window, since this gives the shortest amount of time to finish them.

Complete migrations for multilingual content so that all Drupal 7 sites can migrate before Drupal 7 reaches EOL.

Drupal.org and Drupal core should be able to fully handle contributed projects that are compatible with both 8.x and 9.x and not assume core compatibility based on the version or branch name. This requirement spans multiple projects and areas including project listings, the Composer façade, update.xml from Drupal.org, and localization files. Most of the minimum required changes for Drupal core and Drupal.org are already complete; however, there remains one outstanding core regression related to module compatibility as well as a number of followup issues.

Finally, Drupal 9 currently relies on Node.js 8 for transpiling and linting frontend assets. This is core-developer-facing only so we may raise the Node.js requirement after beta.

Mar 03 2020
xjm
Mar 03

This week is the first target release window for the Drupal 9 beta.

We’ve made significant progress on the beta requirements during the last couple of months thanks to the tremendous amount of work by the community. Based on the outstanding tasks in the meta issue, we are close to completing beta requirements, but not close enough to release it this week.

When will Drupal 9.0.0-beta1 be released?

Given how close we are to completing the beta requirements, we are considering releasing the beta in mid-March if the requirements are complete by March 13. If we do release the beta in 1-2 weeks, Drupal 9.0.0 will still be scheduled for release on June 3, 2020. We will make a final announcement by March 16 about whether there will be a June release.

If any must-have issues remain unresolved by March 13, we will move the beta target window to the first week of May, and Drupal 9.0.0 will be scheduled for August 3, 2020.

This does not affect the expected release date of Drupal 8.9.0 (scheduled for June 3, 2020) nor that of Drupal 9.1.0 (planned for December 2, 2020). The Drupal 8 and 7 end-of-life is also still November 2021.

We need your help to meet the beta deadline, whether it is March 13 or April 28! Drupal 9 readiness meetings are every Monday at 7pm UTC in the #d9readiness channel on https://drupal.org/slack. Help us with the issues below.

Current status and issues left for Drupal 9.0.0-beta1

Dependency updates

All PHP dependencies (Symfony, Laminas, Twig) have been updated to the versions we intend to use for Drupal 9.0.0, although we will continue to keep up to date with bugfix releases.

Nearly all JavaScript and CSS dependencies have been updated, with just two issues to go:
jQuery Cookie (needs review and testing from JavaScript developers!) and Normalize.css (RTBC and awaiting committer review).

Upgrade paths

In addition to deprecations, we are improving and simplifying in-place updates with update.php to ensure the Drupal 8 to 9 update is smooth and reliable. Four issues remain and could use additional help from experienced contributors:

We are also ensuring that all known critical Drupal 8 upgrade path bugs that may prevent updates from older Drupal 8 versions are fixed in 8.8 and 8.9. Only three remain. These technically difficult issues are critical for Drupal's data integrity:

Platform requirement changes

Drupal 9 has already raised the minimum PHP version to 7.3. We also want to increase MySQL, PostgreSQL, and SQLite requirements. This includes:

  • MySQL, MariaDB, and Percona (required prior to beta1)
  • PostgreSQL (Beta deadline; help needed! If you use Postgres, document what versions are available from your hosting provider.)
  • SQLite (Might be completed during the beta phase)

Drupal 9 base theme API

We want to add an up-to-date Drupal 9 version of the 'Stable' base theme. This issue and the related issues to decouple core themes from Drupal 8 base themes could use review and feedback from theme contributors.

Once all the above issues are complete, Drupal 9 is beta-ready. That means that we will have completed all of the significant code changes we intend to make, and that it should be possible to test updates of real sites against it if contributed and custom code has been ported. Site owners can use the Upgrade Status module to check the Drupal 9 readiness of their modules and themes; see the guide on updating to Drupal 9 for more information.

Other issues to complete prior to final release of Drupal 9

There is a second category of issues that we want to complete before Drupal 9.0.0 is released. Since we have fixed release windows, these also need to be either complete or close to completion, especially for the first beta window, since this gives the shortest amount of time to finish them.

Complete migrations for multilingual content so that all Drupal 7 sites can migrate before Drupal 7 reaches EOL.

Drupal.org and Drupal core should be able to fully handle contributed projects that are compatible with both 8.x and 9.x and not assume core compatibility based on the version or branch name. This requirement spans multiple projects and areas including project listings, the Composer façade, update.xml from Drupal.org, and localization files. Most of the minimum required changes for Drupal core and Drupal.org are already complete; however, there remains one outstanding core regression related to module compatibility as well as a number of followup issues.

Finally, Drupal 9 currently relies on Node.js 8 for transpiling and linting frontend assets. This is core-developer-facing only so we may raise the Node.js requirement after beta.

Mar 03 2020
Mar 03

If you have made a couple of migrations for Drupal 8, you might have encountered the fact that some time you actually forgot something, or maybe your migration actually had a bug? But you already launched the site, so doing a new migration is out of the question. What do you do? Well, an update hook can save your day.

So, you might go ahead and write that update hook. And this update hook might want to do some queries in the old database. How do you then write mysql queries to the databse you have defined as the migrate database? After I first discovered this, I find myself searching for the code snippets where I did do this, so I decided to instead put this in a blog post as a reference for myself.

A pretty common way of having your databases defined in such cases would be like this:

$databases['default']['default'] = array (
  'database' => 'my_database',
  'username' => 'user',
  'password' => 'pass',
  'prefix' => '',
  'host' => 'localhost',
  'port' => '',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
);
$databases['migrate']['default'] = array (
  'database' => 'my_old_database',
  'username' => 'user',
  'password' => 'pass',
  'prefix' => '',
  'host' => 'localhost',
  'port' => '',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
);

What we want to do in our update hook is to get the connection information for the one in the ‘migrate’ key, so we can do queries in the migrate database. And we want to do it properly, right? Not just hardcode credentials and use any old sql client?

So what I usually do is this:

// The 2 arguments should correspond to the database target and key. The key in
// our example is 'migrate' and the target is 'default'.
/** @var \Drupal\Core\Database\Connection $db */
$db = \Drupal\Core\Database\Database::getConnection('default', 'migrate');
// Db is now a connection, the same as you would get if you would use the
// service "database". You can proceed to call methods on it like this:
$gifs = $db->select('file_managed', 'fm')
  ->fields('fm')
  ->condition('fm.filemime', 'image/gif')
  ->execute();
foreach ($gifs as $gif) {
  // Do something with the gif.
}

If you find yourself using this a lot, you can also create a service for it. You can use this pattern to define the service:

my_module.migrate_db:
  class: Drupal\Core\Database\Connection
  factory: Drupal\Core\Database\Database::getConnection
  # The 2 arguments should correspond to the database target and key. The key
  # in our example is 'migrate' and the target is 'default'.
  arguments: [default, migrate]

And then you can use it like this:

/** @var \Drupal\Core\Database\Connection $db */
$db = \Drupal::service('my_module.migrate_db');
// Db is now a connection, the same as you would get if you would use the
// service "database". You can proceed to call methods on it like this:
$gifs = $db->select('file_managed', 'fm')
  ->fields('fm')
  ->condition('fm.filemime', 'image/gif')
  ->execute();
foreach ($gifs as $gif) {
  // Do something with the gif.
}

So that is 2 ways you can get the connection for your migrate database. Hope that helps someone out there!

To celebrate, lets have a look at an animated gif called “database”.

Mar 03 2020
Mar 03

Jira is the Agile project management software that we use to help us to plan, manage and release our projects.  It’s brilliant as we can integrate agile software development with test case management and track our projects each step of the way.

We’ve managed to effectively streamline our processes by using Jira as it helps us to break down a project into Epics, User Stories and Tasks and our clients find it really straightforward to use.  But we want to make sure that our clients are getting the most from Jira so we’ve put our heads together to come up with a list of our top tips and tricks.

Woman working at computer

1. Drag and Drop

Rather than right-clicking on a ticket and selecting ‘send to (sprint x, Backlog)’, simply drag and drop the ticket to where it needs to be.  This will save you lots of time and it helps you to drag the tickets into a priority order at the same time. 

2. Use Keyboard Shortcuts

There are so many handy keyboard shortcuts within Jira and you can view the list here.  Our favourite is the ‘Quick Search’ shortcut, which you can find by simply pressing ‘/’ on your keyboard! 

3. Click on the Photo Bubbles

Within the Backlog or Active Sprint view, you can click on the photo bubbles to filter the list of tickets by assignee.  This is handy if you want to see, at a glance, which tickets are assigned to you and don’t want to have to scroll through the whole list.

4. Open and Close the Sidebar

If you use a laptop with a small screen like the majority of the Microserve team, you’ll like this tip! In the left-hand menu, hover and click on the ‘collapse’ arrow and this will close the sidebar.  Hover and click again and it opens once more.  This is super useful when you’re viewing tickets and need some more space to read the details properly.

5. Obtain a URL for a ticket

If you want a simple way to obtain a URL for a ticket, follow these steps!  Click on a ticket to either view or open it in another tab and find the ticket number at the top left of the screen.  Hover over the ticket number and a small copy icon should appear.  Click on this and paste it - sorted!

We hope that these top tips will help you to use Jira more effectively by making it easier to log new tickets, track existing work and know who’s assigned to which ticket.
 

Mar 02 2020
Mar 02

As of Drupal 8.7, the Media and Media Library modules can be enabled and used out-of-box. Below, you'll find a quick tutorial on enabling and using these features.

out-of-box before media and media library

In the past there were two different ways to add an image to a page.

  1. An image could be added via a field, with the developer given control over its size and placement:
     

    Image field before media library
  2. An image could be added via the WYSIWYG editor, with the editor given some control over its size and placement:
     

    Image field upload choices screen

A very straightforward process, but these images could not be reused, as they were not part of a reusable media library.

reusing uploaded media Before Drupal 8.7

Overcoming image placement limitations in prior versions of Drupal required the use of several modules, a lot of configuration, and time. Sites could be set up to reference a media library that allowed editors to select and reuse images that had previously been uploaded, which we explained here.

This was a great time to be alive.

What is available with Media Library

Enabling the Media and Media Library modules extends a site's image functionality. First, ensure that the Media and Media Library core modules are enabled. 

Enable media library in drupal

A media entity reference field must be used with the Media Library. It will not work with a regular image field out-of-box.

Image field on manage display page

On the Manage form display page, select "Media library" widget. 

Media library widget on manage display page

On the "Node Add" and "Node Edit" forms, you’ll see the below difference between a regular image field and a field connected to the media library.

Media library field on node edit

Click on “Add media” and you’ll see a popup with the ability to add a new image to the library or to select an image that is already in the library.

Media field grid

With a simple configuration of the field, if multiple media types are allowed in the field, you’ll see vertical tabs for each media type.

Media grid with multiple media types

WYSIWYG configuration

The WYSIWYG editor requires a few steps when configuring the media library for a specific text format. First, a new icon will appear with a musical note overlapping the image icon. This should be added to the active toolbar and the regular image icon should be moved to the available buttons.

wysiwyg toolbar configuration

Under “Enabled filters,” enable “Embed media."  Under the filter settings, vertical tab settings can be chosen for media types and view modes. Once that configuration is saved, you’ll see on a WYSIWYG editor that you have the same popup dialog for adding a new image to the media library, or selecting an already-uploaded image.

wysiwyg media configuration

Once you are on a "Node Add or "Node Edit" page with a WYSIWYG element, you’ll see the media button (image icon plus musical note).

Media button on wysiwyg editor

Clicking on the media button brings up the same, familiar popup that we saw earlier from the image field:

media library grid

This article is an update to a previous explainer from last year. 

Mar 02 2020
Mar 02

At Droptica, we attach great importance to proper onboarding of new employees, particularly by getting them started with Drupal. We also want to give people who do not know the system a chance to get to know it in a structured and easy manner after they join our team.

As a future developer working for Drupal agency, you will get an opportunity to take part in a structured training course with a specific scope. The duration of the course is always adapted to the skills of our new hires, but it usually takes anywhere from three to five weeks.

Drupal agency which will take care of you

Throughout the course, you will be mentored by a Project Manager and Lead Drupal Developers. You will also get a special project set up in JIRA for you, along with a number of tasks to complete. The Project Manager will take care of the training process and meetings, while our developers with extensive Drupal experience will keep tabs on your tasks and give you a helping hand should the need ever arise.

Never used Docker before? No problem!

You will start your Drupal training by configuring your working environment. You will get a PHPStorm license, as well as the necessary permissions, so you can use the same tools as we do.

During your training, you will have an opportunity to learn the ropes of various tools, such as GIT, Docker and Jenkins, as well as using them under Linux You will learn how to build a website locally in your working environment, and you will get a chance to showcase your PHP coding skills, as well as try your hand at styling pages based on the provided designs.

In the further part of the training, you will learn how to update modules, explore XDEBUG and get to know the ins and outs of the Bootstrap library. You will come across Drupal 7 and 8 since we work for clients who want to keep the previous version of that CMS on their websites.

SCRUM – discover one of the world’s most popular ways of working 

Our company prides itself on its agile model – we often employ SCRUM and its various elements in our projects. We want you to feel as if you’re already on a project while you’re training.

During your Drupal training course, you will get to know a wide variety of elements of this model first-hand – as much as the form of the course allows you to experience. During the so-called week-long Sprint, you will get to take part in a number of events.

These include meetings, such as the Daily Scrum, Sprint Planning, Sprint Retrospective and Demo (which replaces and simplifies the Sprint Review for the purpose of the training).

The Daily Scrum is a meeting with a maximum of 15 minutes, and it takes place every day. During this meeting, the developer talks about what they have done since yesterday, what they are going to do that day and whether they need help with anything, or if something is blocking them from moving forward with their tasks. The remaining meetings are only held once a week.

Sprint Planning enables us to define the scope of work to be done in the week to come. It kicks off the new Sprint by setting the tasks, which will be displayed on the Active dashboard in JIRA.

The Sprint Retrospective is a much longer meeting, during which we delve deeper into the course of the training and talk about how we can improve our collaboration and the process, based on last week’s experiences. All of this is very important to us, and we will be happy to listen to your feedback on your training.

The Demo is a perfect opportunity for you to present the results of your work was done throughout the week.

Getting better together

Based on the feedback from previous participants of our Drupal training course, we are constantly working to help new employees learn Drupal and our tools in the most effective way.

Here’s what one of our developers, who has been working with us for several months now, has to say about it:

Jakub Wozniak speaking

Our goal is to build elite and certified teams, specialised in Drupal.

We are currently focusing our efforts on growing our team, so we encourage you to apply for the job listings that can be found on our career page. You can learn the Drupal ropes, too!
 

Feb 28 2020
Feb 28

High-quality content is a huge business booster. However, its creation takes time and effort. You will need to publish content regularly in order to keep your website fresh, maintain your SEO rankings, and keep your audience engaged.

Luckily, there are ways and tools to facilitate regular content production. Consider, for example, the idea of scheduled publishing on your website. We will discuss its benefits here and take a look at a great scheduling tool — the Scheduler module for Drupal websites.

The idea of scheduled publishing for your website

Scheduled publishing means that you or your content creators will be able to:

  • have content automatically published at predefined dates and times
  • have content automatically deleted at predefined dates and times

Scheduled publishing benefits and use cases

Scheduling tools can make your publishing workflows better organized, more flexible, and time-saving. Here is how:

  • You can quickly post plenty of content in advance with no need to stay tied to the PC. Your content can be scheduled to appear on non-working hours, weekends, special dates, during your vacation or business trip, etc.
  • With scheduling tools, you don’t have to worry about the outdated content clean-up — you can just schedule it for deletion in advance, based on how long it is relevant.
  • Scheduling helps you automatically run marketing campaigns with specific start and end dates. They can be tied to your product launches, holidays, seasons, etc.

Marketing campaigns based on holidays

The Scheduler module for scheduled publishing in Drupal 8

The Scheduler module does its job of publishing and unpublishing your Drupal nodes perfectly. It can work, for example, as a future blog post scheduler for your website. The module has overall 1,250,000 downloads irrespective of the version, which proves how popular scheduling is. Let’s take a closer look at what it offers in the Drupal 8 branch.

The Scheduler module installation

The Scheduler comes with a submodule — the Scheduler Rules Integration. If you enable it as well, your scheduled publishing can reach an especially high level (based on particular conditions via the Rules Drupal module). Let’s keep it simple this time and discuss the classic scheduled publishing only.

Scheduler Drupal module installation

Enabling scheduled publishing & unpublishing for a content type

You will need to go to the necessary content type (article, news, gallery, product, etc.) and enable the scheduling feature for it in Structure — Content types — [Your content type] — Edit. Check the boxes for enabling scheduled publishing and unpublishing.

More options will now be available. Among the most interesting ones are:

  • changing the node creation time to match the scheduled publishing time — this will make your Drupal content look fresher making
  • making scheduled publishing required — this will make sure your editors don’t forget to schedule the nodes

Enabling scheduled publishing & unpublishing for a content type with the Drupal Scheduler module

On the same tab, you can specify the scheduling layout — a vertical tab or a separate fieldset. This is how it will appear to your editors.

The date-only format as an option for the Scheduler

To facilitate scheduled publishing, you can choose to make only the date schedulable. Your editors will not have to regularly enter the exact time. The time will be a default, but they will be able to change it if needed. The date-only option is a general one and can be enabled at Configuration — Content authoring — Scheduler.

Date-only format with the Drupal Scheduler module

Scheduling your Drupal 8 content to be published or unpublished

Now let’s see how the scheduled publishing looks during your Drupal node creation. To the right of the node editing form, there is now the “Scheduling options” tab. Enter the publishing and unpublishing date and time or leave either of them blank if you do not need them. The time is tied to your website’s time zone.

Scheduling your Drupal 8 content to be published or unpublished

We have scheduled the post “Congrats on the first day of spring!” for March 1, 2020, at 7.00 AM. It should appear on March 1 and disappear the next day.

Content scheduled for publishing in Drupal

You now also have a “Scheduled” tab that shows all your nodes that are currently scheduled for publishing or unpublishing.

Scheduled content tab from the Drupal Scheduler module

Lightweight Cron as the Scheduler task manager

What if the time has come but your scheduled articles or other nodes have not yet appeared? This means that the Cron hasn’t yet run. The Drupal Scheduler module relies on the Cron for the automatic publishing and unpublishing of your nodes at regular, preconfigured intervals. Every time the Cron runs and discovers the scheduled nodes, it publishes or unpublishes them.

You can choose to use the Lightweight Cron created specifically for the Scheduler. It allows you to make more granular settings as to the frequency of running the Scheduler tasks and avoid overloading the Drupal Cron.

The Lightweight Cron settings are found at Configuration — Content authoring — Scheduler. You can run it at any minute on-demand with one button to see the due tasks immediately completed. You can also make granular frequency settings in the Crontab tool on your website’s server. Contact our Drupal support team at any time for help.

Lightweight Cron as the Scheduler task manager

Set up scheduled publishing with us!

Does the scheduled publishing idea look interesting to you? Or maybe you would like to try other ways and tools for easy Drupal content workflows? Drupal 8 now offers plenty of options in this area, some of which are included in the Drupal core of the recent versions.

For scheduled publishing or any other Drupal website feature, you can always rely on our Drupal development and support experts!

Feb 28 2020
Feb 28

Agiledrop is highlighting active Drupal community members through a series of interviews. Now you get a chance to learn more about the people behind Drupal projects.

Our latest interview features Amitai Burstein, co-owner and CTO of Israeli Drupal agency Gizra. Give it a read and get an insight into how the nature of Drupal contributions has evolved and how great it is to meet members of the community in person.

1. Please tell us a little about yourself. How do you participate in the Drupal community and what do you do professionally?

My name is Amitai Burstein (@amitaibu). I’ve been using Drupal for more than thirteen years, and I am the co-owner of Gizra, my company that celebrated its ten year anniversary not long ago.

I’ve been with Drupal for quite a long time, ever since 4.6. Back then, I didn't know how to code and I started as an enthusiastic site-builder. After some time I realized I needed some basic code, so I started learning by reading online books, and following Drupal issues.

Nowadays, I would say that in the Drupal world I’m mostly known for my contributed modules, such as Organic Groups (OG), RESTful, The Message Stack, Entity Reference, etc.

2. When did you first come across Drupal? What convinced you to stay, the software or the community, and why?

Thirteen years ago, I and who would later be my colleague, Brice, worked in the textile industry. Like many others, we had an idea for a startup. I can already tell you the end: that startup failed. Miserably.

We were trying to build a service that would cater to the textile industry, specifically for pattern makers - the people who are making patterns for garments.

Our goal was to be some kind of GitHub for the textile industry. This is what got me to look for a CMS. At the time Joomla was a big player, there was Drupal, and many many other options. When I came across Drupal it was evident that there was a big community around it and there were tons of modules (at the time I thought that was a good sign, but nowadays I don't think that having tons of modules is necessarily a good mark of quality.)

There was a friendly enough community, there were the modules I was able to start picking things up with, and as many a story goes, two years after starting with Drupal, I found myself at my first DrupalCon. It was DrupalCon Paris, and for me everything has changed since then.

After meeting the real people behind the nicknames in the issue queue I knew I was in the right place. Furthermore, it was at this DrupalCon Moshe Weitzman, the original author of the Organic Groups module, offered me to take ownership of OG. So that was definitely a big crossroad in my professional life.

3. What impact has Drupal made on you? Is there a particular moment you remember?

I think there were quite a few different moments that I remember, and a lot of them indeed revolved around conferences - meeting fago, the author of the Rules module (in the early days it was still called workflow-ng!), as well as klausi, Earl Miles, Moshe Weitzman, Wim Leers, Dries, Daniel Wehner, Peter Wolanin, webchick, bojanz, Dick Olsson, Josh Koenig, Stella Power and the list can go on.

Over a couple of days, I've met many different people that I had so much respect for just from reading their code. Meeting them face to face was so much better! 

With that said, I don't think I chose Drupal for the sole reason of a friendly community. I think Drupal itself - the software, even at 4.6, already delivered what it was promising. 

4. How do you explain what Drupal is to other, non-Drupal people?

I kind of don’t. I used to try and explain, but when people ask me what I do, I typically don’t go into the details of what Drupal is. If they insist, then I explain very quickly, in two sentences, what a CMS is, but I don’t go into detail about what Drupal is. 

In fact, the longer I’ve been in the tech world, the less technical I go. I do feel that my own technical capabilities are growing constantly, and I’m still learning and touching a lot of code on a daily basis, but I find that the technical stuff is usually not the interesting stuff. 

5. How did you see Drupal evolving over the years? What do you think the future will bring?

I definitely see changes on the technological side - getting off the island and starting to use more from other PHP projects, using more advanced patterns, and more integrations with JS frameworks for the frontend. 

The biggest change I've seen in the past five years is how Drupal has shifted from people contributing code in their free time into more paid work by different organizations.

This is something I felt myself, how I transitioned from spending my evenings on the couch coding for my learning experience and for my enjoyment, to nowadays where I’m doing it more as “this is my day job”. Contributing code in my spare time is something I hardly do, as I invest my time in other interests.

6. What are some of the contributions to open source code or to the community that you are most proud of?

I’m pretty proud of the different modules that I've already mentioned before. I'm also quite proud of the presentations I gave, starting with DrupalCon Copenhagen almost ten years ago. In a way I think it helped shape the expectations a bit we as a community have of presenters.

I’m not suggesting that my presentations changed the way people are presenting at Drupal events, but I feel that it showed a different way of doing presentations which is not necessarily very linear and with boring bullet points. Presentations can and should be more joyful.

7. Is there an initiative or a project in the Drupal space that you would like to promote or highlight?

I think one of the more interesting projects that I enjoy using in my day-to-day work is the JSON:API module, which is now part of core. It's really well documented, it works great, and it makes our RESTful servers fun to work with. Also, as a Mateu and Wim Leers fan boy, I'm always happy to learn from their work!

8. Is there anything else that excites you beyond Drupal? Either a new technology or a personal endeavor. 

Most things in my life excite me beyond Drupal. I love spending time with my family and friends, as well as working out. Working out every day fills me with a lot of joy (although quite painful), and makes sure that my work-life balance is even more balanced than it was before.

A technological aspect that I’ve been excited about for almost five years, is Elm - a language that compiles to JS. For me, like choosing Drupal, it's one of the best decisions that we’ve made. It’s a wonderful language to work with, and we build better products with it.

Last thing I want to highlight, which I felt went quite unnoticed in the community, was a blog post about Organic Groups and Group module - Organic Groups in 4 voices

It started as a post by Pieter Frenssen, Maarten Segers and myself - the maintainers of Organic Groups. But then I realized that a more interesting and more complete post would also include Kristiaan Van den Eynde, who is the Group module maintainer.

It’s a post that doesn't try to "sell" a module, but rather give a fuller perspective of the "story" and the people behind it, and of their thoughts and emotions. Which checkbox to hit is a bit boring and outdates quickly. How one felt, struggled, and in the end grew from the experience never gets old.
 

Feb 28 2020
Feb 28
  • Core Modules: These modules are installed in all the Drupal installation packages; you can say that they are the basic (core) modules necessary for the site designing task, like handling the accounts of the users, providing menus for navigation.
  • Contributed Modules: This module can be downloaded from the official Drupal.org site.
  • Custom Modules: Custom modules are pretty self-explanatory – they’re explicitly coded for individual projects.

So here, we try to list out some of the modules from a Pandora of modules that can be used on the go for your web development, in a hassle-free way.

Read More - Move on to Drupal 8, Be Ready for Drupal 9!

Feb 28 2020
Feb 28

Last Updated March 7, 2020

This article is a summary of the state of Drupal 9 along with lists of key dates, ways to contribute, and other resources. If I missed any important information or there's a mistake, please contact me via email or, more reliably, via Twitter, and I'll try to update the post quickly.

In this article, I will cover:

What's Special About Drupal 9?

Drupal 9 is obviously the "major version" after Drupal 8, but there is something particularly special about Drupal 9. Where previous major versions have often departed wildly from their predecessors (looking at you Drupal 8!), Drupal 9.0 will be functionally equivalent to the final minor version of Drupal 8. The exact final minor version number will depend on when Drupal 9.0 is ready.

According to the Drupal.org D9 docs:

"Drupal 9 will be a cleaned-up version of Drupal 8. It will be the same as the last Drupal 8 minor version with our own deprecated code removed and third-party dependencies updated."

This is good news as it makes updating from Drupal 8 to Drupal 9 much, much easier than for previous major version updates. To see a video of updating a simple site, check out the DrupalCon Amsterdam Driesnote starting at around 43:10 minutes. And, to get a really nice overview of the Drupal 9 release, I highly recommend looking at the D9 slides created by Gábor Hojtsy. As an added bonus, these slides have been made available for anyone to present at any event around the world.

Illustration of Drupal 8 on same "release track" as Drupal 9 compared to older versions of Drupal via drupal.org/docs/9/how-drupal-9-is-made-and-what-is-included Illustration of Drupal 8 on same "release track" as Drupal 9 compared to older versions of Drupal via drupal.org/docs/9/how-drupal-9-is-made-and-what-is-included

Deprecation & Third-Party Dependency Updates

The two areas that need to be addressed to make Drupal 9 a reality are 1) removing deprecated code, and 2) updating third-party dependencies.

Deprecated code is old code that has been replaced with new code while the old code remains to ensure backward compatibility. With deprecated code, the intention is always to remove it at some point. Any code that relies on deprecated code will obviously break once the deprecated code is removed. Thus, Drupal core and contributed projects that want to support the Drupal 9 version need references to all deprecated code removed. There are already a number of issues open to fix these outlined in the stats section later.

Drupal 8 leverages many third-party software libraries including CKEditor 4, jQuery UI 3.2, Twig 1, and Symfony 3. Since Drupal exposes third-party APIs, when these APIs change, it affects Drupal's backward compatibility. Drupal only breaks backward compatibility in major version updates.

For Drupal 9, some key third-party libraries will be updated and some won't be updated to their most recent major releases. Because CKEditor 5 has changed the editor architecture significantly and CKEditor 4 is supported until 2023, CKEditor 5 will be updated in Drupal 10 and will be optional in Drupal 9. On the other hand, the jQuery UI dependency is being phased out, so only a subset of the library will be available in Drupal 9. On the front-end, Twig 1 will be updated to Twig 2.

The most pressing lifecycle impact is that Symfony 3 has an end of life in November 2021. Drupal 9 will use Symfony 4.4 which was recently released. To give ample time to update Drupal 8 sites, the D9 planned release date is June 3, 2020. If that date slips, the backup plan is to release Drupal 9 by the end of 2020. See the estimated dates below.

Symfony releases calendar via symfony.com/releases Symfony releases calendar via symfony.com/releases 

Recent Stats

Here are some approximate Drupal stats based on recent data. Note: Some drupal.org issues aren't tagged "properly" so there may be other issues not represented below.

Modules:

Themes:

Contributed Project D9 Issues: "Drupal 9 compatibility" tag

  • Open: 788+
  • Fixed/Closed: 738+

Core D9 Issues: "Drupal 9" tag and 8.x version, or 9.0.x-dev version

  • Open: 447+
  • Fixed/Closed: 566+

Top 200 Modules D9 Status

  • From DrupalCon Amsterdam Driesnote
    • Ready Now: 32 (16%)
    • Pretty Close: 100 (50%)
    • Needs Work: 68 (34%)
  • As of March 7, 2020 from Drupal 9 Deprecation Status
    • No Problems Found: 50 (25%)
    • All Problems Fixable Now: 33 (16.5%)
    • Some Problems Fixable Now: 79 (39.5%)
    • Needs Manual Review: 30 (15%)
    • Only Problems Fixable Later: 2 (1%)
    • No Results: 6 (3%)
Graph of top 200 modules' D9 status from https://dev.acquia.com/drupal9/deprecation_status Graph of top 200 modules' D9 status from dev.acquia.com/drupal9/deprecation_status

Core Usage: 1,044,972

  • 5.x: 509
  • 6.x: 36,187
  • 7.x: 706,978
  • 8.0.x to 8.8.x: 301,243
    • 8.0.x: 1,328
    • 8.1.x: 1,992
    • 8.2.x: 3,786
    • 8.3.x: 7,374
    • 8.4.x: 5,380
    • 8.5.x: 19,424
    • 8.6.x: 39,472
    • 8.7.x: 88,386
    • 8.8.x: 134,101
  • 8.9.x: 54 (may be inaccurately reported in the usage tracker)
  • 9.x: 0

Builtwith Usage

Drupal 8 usage via trends.builtwith.com/cms/Drupal-8 Drupal 8 usage via trends.builtwith.com/cms/Drupal-8

Key Dates

Future dates are estimated and are based on major and minor releases. The releases are happening every 6 months on the first Wednesday of the month. Additional dates are available in the release cycle documentation.

Quarterly timeline of Drupal 9 releases and Drupal 7 & 8 end of life via https://www.drupal.org/docs/9/drupal-9-release-date-and-what-it-means Quarterly timeline of Drupal 9 releases and Drupal 7 & 8 end of life via drupal.org/docs/9/drupal-9-release-date-and-what-it-means

Pre D9 Release

D9 Release

  • Beta Requirements Done by March 13, 2020
    • Mar 2020: 8.9.0-beta1 & 9.0.0-beta1 Releases
    • May 2020: 8.9.0-rc1 & 9.0.0-rc1 Releases
    • Jun 2020: 8.9.0 & 9.0.0 Releases
       
  • Beta Requirements Done by April 28, 2020
    • Apr 2020: 8.9.0-alpha1 Release
    • May 2020: 9.0.0-beta1 Release
    • Jun 2020: 8.9.0 Release
    • Aug 2020: 9.0.0 Release
       
  • Beta Requirements Done by August 31, 2020
    • Apr 2020: 8.9.0-alpha1 Release
    • Jun 2020: 8.9.0 Release
    • Aug 2020: 9.0.0-beta1 Release
    • Dec 2020: 9.0.0 Release

Post D9 Release

Drupal 10 Release!

Drupal 9 Coordinators

Lots of people are working on Drupal 9, but here are the coordinators from the D9 initiative page.

Drupal 9 Coordinators via drupal.org/about/strategic-initiatives/drupal9 Drupal 9 Coordinators via drupal.org/about/strategic-initiatives/drupal9

Gábor Hojtsy

Jess (xjm)

Nathaniel Catchpole (catch)

Ryan Aslett (mixologic)

Checking Status

Drupal 9 is always changing, so here are some ways to keep in the loop.

Twitter

Even if you don't have your own Twitter account you can check these accounts for regular Drupal 9 updates.

Twitter account @DropIsMoving maintained by @webchick and @gaborhojtsy at twitter.com/dropismoving Twitter account @DropIsMoving maintained by @webchick and @gaborhojtsy at twitter.com/dropismoving

Meetings

Drupal 9 readiness meetings generally happen every 2 weeks on Mondays so you can join the meeting (in Slack) or check the meeting notes afterward.

Kanban Board & Issue Queues

  • Tag: Drupal 9 Compatibility (Contributed Projects)
  • Tag: Drupal 9 (Core)
  • Branch: Drupal 9.0.x-dev (Core)

Ways to Contribute

There are many ways to contribute to Drupal 9. Remember, you don't have to be a coder to help out! Here are some ideas:

Tag issues for removing deprecated code

There was some previous confusion as to what tags to use for issues related to removing deprecated code in preparation for Drupal 9. People used many tags including "Drupal 9", "Drupal 9 compatibility", "Drupal 9 readiness", "D9Readiness", "D9 port", "D9 upgrade path", "Drupal 9 Deprecated Code Report", and "Drupal 9 Deprecated Code Report and dependency injection issues".

After a discussion in November in the Slack #d9readiness channel with Gábor Hojtsy, we've clarified the tags that should be used. Please avoid using other tags and use the following, so that it is easier to find issues to work on. At that time, I went through many issues to update their tags to match these guidelines. There are likely some that were missed, so if you see issues that aren't tagged or are using different tags, please update them. When making new issues, keep these in mind as well.

  • "Drupal 9" - This is for core issues for D8 versions as it was used before the D9 branch was available. For changes happening on the D9 branch, this tag is unnecessary.
  • "Drupal 9 compatibility" - This is for contributed project issues.
Issues tagged with "Drupal 9 compatibility" in drupal.org issue queue Issues tagged with "Drupal 9 compatibility" in drupal.org issue queue

Create issues for deprecated code

There are lots of contributed D8 projects that can be updated. Check the issue queue first to make sure the project doesn't have an issue created already. Then you can use the deprecation checking tools to see if there are issues. If there aren't deprecation problems, it's still good to create an issue and then mark it as fixed so it's clear that the code has been checked.

When creating new Drupal 9 issues for contributed projects, please use the "Drupal 9 compatibility" tag rather than other D9 tags that are listed above. When creating new Drupal *core* issues, you don't have to tag them as long as you're using the 9.0.x-dev or 9.1.x-dev for the version. If you have a Drupal 8 issue that needs to be tagged for D9, use the "Drupal 9" tag.

Create, review, and/or test patches to fix deprecated code

You can search for issues using the Kanban boards and issue queues (see above). If you know how to create patches, many of the updates are straightforward. The issues should have a report of what is deprecated and needs updating. If not, use the deprecation checking tools. If you don't know how to create patches, but can review code, you can review existing patches to make sure they fixed the deprecations correctly.

Help with stabilizing experimental Drupal 8 core code

There are some experimental projects that need finalizing before 8.9 so they will make it into D9 as stable. Here are some issues that you can help with to make that happen.

Modules:

Themes:

Participate in strategic core initiatives

There are always strategic core initiatives in progress, and there are some exciting ones for Drupal 9 that could use your help. If you have ideas for other initiatives, discuss your ideas in the #contribute Slack channel.

In addition, there are some active D8 initiatives that will benefit Drupal 9. Some are more active than others. Check out the issue queues for activity:

Training, Speaking, or Mentoring at Events

Spread the word about Drupal 9 by going to local, regional, or international events. Check out Drupical to find Drupal-specific events, but also consider going beyond these into the wider tech world to help with Drupal adoption. If you like speaking at events, Gábor Hojtsy has provided "State of Drupal 9" slides for anyone to use. If you find any mistakes or have suggestions, leave comments on the slides. For contribution sprints, you can mentor other community members and help them work on Drupal 9 issues.

Additional Resources

There are many Drupal 9 resources available, but here are some to start with:

And Remember…

"The big deal about Drupal 9 is … that it should not be a big deal." -Dries

p.s. A big thank you to Lindsey Gemmill for her review and painstaking formatting of this post! And thanks to Gábor Hojtsy for reviewing and providing feedback and more resources.

Last Updated March 7, 2020

  • MARCH 7, 2020: Updated mostly based on feedback from Gábor Hojtsy
    • Added more links to resources section
    • Updated the top 200 modules' D9 status data
    • Adjusted key dates alpha and beta info
    • Updated link to last D9 readiness meeting
    • Added some images so this isn't just a wall of text :)
Feb 27 2020
Feb 27

Seems like every day this month I've answered the same question: Why should I use Drupal instead of WordPress? And this is the answer I've come up with. They are entirely different applications, about as different as Microsoft Word is from Microsoft Excel.

WordPress is first and foremost a blogging tool, and it has become widely adopted by designers who are trying to make pretty-looking sites. There's no shortage of beautiful WordPress sites, and if what you need is a relatively simple marketing site with rich content, it's a great tool.

Drupal, on the other hand, is more like a general purpose database tool that can be skinned to look great, but that's not its strength. Much like Excel, it's great for managing lots of items that have the same characteristics. And it's built to work extremely well for this purpose -- managing scads of information.

If you're making a flyer for a yard sale, you wouldn't necessarily pick Excel -- Word is quick and easy to make something like that, and you can pull in all sorts of designs, paste it all in and make something that looks pretty good. You can make a table to show the differences between a couple products, but if you have hundreds of products you start to run into problems.

You can create a bunch of comparisons in Word. There's a full blown macro system built in -- you can certainly do most of what you can do in Excel using Word -- but that doesn't mean it's a good idea!

Wait a minute. WordPress is a CMS, and has a database!

Yes, WordPress calls itself a "content management system." And it has the basic architecture necessary for a publishing workflow. There's an API for creating different post types, adding custom fields, and all the same stuff that Drupal can do.

But... There is no user interface for creating these fields in WordPress core -- you either need to get one of many different (usually proprietary) add-on plugins, or have a developer write code to set up these post types.

In contrast, creating new content types, adding fields, and adding relationships between content types is all in Drupal core, and is the fundamental starting point for building a new Drupal site.

In WordPress, your first decision is typically to pick a theme, and a lot of themes come with a bunch of extra functionality that help you actually build the site. In Drupal, your first decision is how to organize your content -- the theme can be tacked on towards the end of the process, and easily changed at any point.

But everybody says to use WordPress! Are they wrong?

It's not wrong to use Word -- it's a matter of choosing the right tool for the job. Are you creating a brochure? That's way easier to do in Word than Excel. Are you trying to keep track of who has registered for an event? You can do it in Word, but if you do it in Excel you can add filters and calculated columns to keep track of which registrations have been paid, and which you need to collect payment at the door.

You might well be able to find a plugin to help you to do this in Word -- but now suddenly it's not really Word you're using to do your registrations, it's some obscure plugin -- whereas tabulating data is the essence of what Excel does.

That's exactly the difference between WordPress and Drupal -- when you get beyond the core layout, blogging, and basic site functionality that comes with Word, you are suddenly in plugin land, and the core functionality is no longer shared by tens of millions of WordPress users -- only by the other users of that specific plugin.

And when you need a different plugin for different functionality, you need to cross your fingers that it doesn't blow up your site, have some weird conflict.

Drupal is built for this kind of integration of different kinds of things. Need to show events by date? Add a calendar. Need to show them by location? Add a map, and set up geolocation. Need to charge for them? Add commerce. Want your users to rate them? Add a voting module. Everything works together in Drupal, and builds upon everything else -- instead of being one-off islands of functionality that may or may not work with the other things you need.

Ok, I lied. Drupal isn't like Excel, it's more like Access.

A lot more people are familiar with Excel than Access, because it's useful in so many different situations. Access is more of a general purpose database -- compared to Excel, it's a bit harder to prototype things in, but way more powerful. In the 1990s and early 2000s, Access (and competitors like Filemaker Pro) were popular tools to build out entire business operation systems for many small businesses and non-profits.

This is exactly the kind of thing Drupal can do extremely well. It's even organized the same way -- it's really not hard to take an Access database and port everything in it over to Drupal -- and bring the entire application to the web, make it available to your mobile devices, tablets, remote workers, etc. The same business analysis skills even apply. For a huge number of scenarios, most of the work is that of an administrator -- you only really need to bring in a developer to make it look good, or add automation.

Drupal is not "just" a CMS -- it's a general purpose database system you can use to revolutionize your entire business operations. And it can be your website, too! This is particularly useful if you want to remove barriers to how you interact with your customers, organize your internal business processes, or automate some painstaking operational task.

If you would like to learn more about how to make your business run better using Drupal or similar technology, give us a call! We'd be happy to explore some ideas with you.

Feb 27 2020
Feb 27

Table of contents

Anxieties and aspirations for decoupled Drupal
--Overly different front-end worlds
--Web Components for better encapsulation
--The age-old debate: Decouple Drupal itself?
What’s next for decoupled Drupal?
--Security remains a competitive advantage
--An approach for dynamic components
--Further in the future: A more real-time Drupal
Conclusion

As another decade comes to a close in Drupal’s long and storied history, one important trend has the potential to present amazing — or unsettling, depending on how you look at it — opportunities and shifts in the Drupal ecosystem. That trend is decoupled Drupal. Nowadays, there is no limit to the content prolifically produced by the community about the topic, whether it’s in the form of a comprehensive book on the subject or a conference focused on the theme. Today, decoupled Drupal implementations seem, at best, to be a door presenting new approaches and ideas, and, at worst, here to stay for good without proper consideration for potential externalities.

On one of the latest Tag1 Team Talks episodes, we gathered four insider experts on decoupled Drupal, including yours truly (Preston So, Editor in Chief at Tag1 and author of Decoupled Drupal in Practice), Sebastian Siemssen (Senior Architect and Lead React Developer at Tag1 and maintainer of the GraphQL module), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), and Michael Meyers (Managing Director at Tag1). Over the course of the wide-ranging discussion, we revealed some of our reminiscences, misgivings, and hopes about decoupled Drupal in the years to come.

What trajectory will decoupled Drupal take over the coming decade? In the second part of this two-part blog series, we take a closer look at how decoupled Drupal has already revolutionized how we think about key features in Drupal with Fabian and Sebastian looking to reshape how Drupal renders markup and dynamic components and all of us highlighting security as one of decoupled Drupal’s competitive advantages.

Anxieties and aspirations for decoupled Drupal

One of the subjects we focused our attention on was our feelings on the current state of decoupled Drupal and how it is impacting the way we implement Drupal architectures today. Fabian, in particular, has mixed feelings about decoupled Drupal at present. While decoupled Drupal confers significant advantages, as we saw in the previous blog post, it also can lead to skepticism about the disadvantages it introduces. I wrote about the risks and rewards of decoupled Drupal back in 2016, and many of these pros and cons still resonate deeply today.

The loss of administrative features that are present in Drupal’s presentation layer but absent from decoupled front ends is an important rationale for many who believe monolithic architectures remain wholly viable. For instance, Fabian cited as evidence a recent Tag1 project that leveraged a decoupled Drupal architecture but also required some reinvention of the wheel to reimplement contextual links, a key front-end Drupal feature, in the decoupled presentation layer. Nonetheless, decoupled Drupal remains an excellent choice for mobile applications, digital signage, and even conversational interfaces.

Overly different front-end worlds

One of the issues with decoupled Drupal is the fact that developers are attempting to solve problems that, according to Fabian, should be solved within Drupal itself.

As Fabian argues in our recent webinar, “One of the mistakes we made in core is that we are mixing data and presentation within our render trees and entities.” The fact that the experience of React developers differs so substantially from Drupal theme developers further highlights this issue.

Web Components for better encapsulation

At DrupalCon Amsterdam, Fabian presented a session about Web Components that proposed a path forward to narrow the gap between front-end developers who are pursuing new paradigms such as React and Drupal developers who wish to implement components in Drupal front ends. Web Components are compelling because they provide for better-encapsulated code but still allow for data to come from any source, including Drupal.

In Fabian’s view, Drupal needs to do much more to bridge the gap between new front-end ecosystems and Drupal, together with a finely tuned developer experience that doesn’t require significant new learning but does allow for better closeness between the front end and the back end. For Fabian, it is essential that the Drupal community scrutinize some of the approaches to componentization found in JavaScript ecosystems.

The age-old debate: Decouple Drupal itself?

Sebastian argues that spitting the back end and front end of Drupal more at the kernel level is the right approach. There is significant weight in Drupal’s codebase that presents challenges not only for the administrative interface that many Drupal users work with on a daily basis but also the API layer within Drupal.

In fact, one of the original goals of the Web Services and Context Core Initiative (WSCCI), whose trajectory I cover extensively in Decoupled Drupal in Practice, was to recast core as a slim kernel that provides low-level functionality completely isolated from user interface components.

What’s next for decoupled Drupal?

So what’s next for decoupled Drupal? How will we as practitioners modify the approaches we take and the paradigms we utilize as decoupled Drupal continues to gain steam across the community? For this, I requested help from Fabian and Sebastian to offer their perspectives on some of the possible directions that decoupled Drupal might take as we traverse new territory.

Security remains a competitive advantage

One of the more enticing elements of decoupled Drupal is the fact that it can facilitate favorable security outcomes. Thanks to the rapidly evolving advantages offered by new JAMstack (JAM stands for JavaScript, APIs, and markup) and serverless approaches, security can become much less of a concern in decoupled architectures.

With a content server like that provided by Drupal, argues Fabian, we can feasibly implement JAMstack architectures that yield static HTML pages as the end result rather than dynamic applications with potential security vulnerabilities or, worse yet, a monolithic architecture that means an attacker could gain access to the entire Drupal system from end to end by exploiting a front-end weakness. After all, static HTML is completely secure, as there is no executable code. For Fabian, this is one of the most important and often overlooked advantages of the decoupled Drupal approach.

An approach for dynamic components

These innovations in the front-end development landscape comprise some of the rationales that Fabian cites for taking a closer look at the JavaScript community and how they handle encapsulated components. The crucial missing piece in any JavaScript implementation is sourcing data — and this is an area that Drupal can improve.

Sebastian agrees that decoupling data from internal Drupal objects like fields and entities could resolve many issues in Drupal, but he also argues that one of the key disadvantages of Drupal in its current conception is its push-based model. As an illustration of this, when Drupal fulfills a request, it executes a massive processing engine to pull data from sources and feed them into a rendering engine.

He goes on to argue that reversing Drupal’s render pipeline approach and pulling data from graphs (e.g. through GraphQL) as the template engine needs it, just in time, would allow Drupal to evolve to a more modern, pull-based approach. To Sebastian, this pull-based mechanism is precisely what an API-first architecture promises, and he cites recent innovations surrounding GraphQL in Twig as the initial steps toward this exciting vision.

Further in the future: A more real-time Drupal

One of the areas that has long fascinated me is the potential for Drupal to evolve into a more real-time system that confers significant advantages when it comes to dynamic components. Fabian argues that Web Components are a key step on the road to real-time Drupal, and a “components everywhere” approach could allow for this to occur. With a component-based approach, the only additional step necessary would be a Node.js server that updates components whenever data sees updates as well.

For all of Drupal’s benefits, real-time capabilities remain elusive. As Sebastian rightly states, real-time approaches are largely infeasible in PHP. After all, real-time data is something that Drupal is ill-equipped to handle itself; any real-time functionality needs to be handled on top of Drupal in a non-PHP layer. One option that Sebastian suggests is the combination of a Node.js server, Drupal’s PHP environment, and Redis, which would facilitate a push-based approach. Saving in Drupal could send a notification to a PubSub environment such as Redis or Kafka, and a Node.js microservice could update the client through a WebSocket.

Though this would mean forwarding Drupal’s APIs to a Node.js environment, fortunately, there are several ways to approach this in a way that keep Drupal’s benefits such as granular caching in Drupal 8, which is provided through the cache tag system. And the closer the data source is to an API like that built in GraphQL, more can be done to optimize the database queries and caching. Fortunately, GraphQL comes with WebSocket and subscription support, and it would be a compelling choice given the ongoing work in the GraphQL specification to send GraphQL queries and subscriptions in the same response.

Conclusion

Thanks to decoupled Drupal, the Drupal community is in the midst of a renaissance that is revolutionizing the way we think about the front end of Drupal while simultaneously challenging our long-held assumptions about how Drupal should look and operate. While this is a testament to Drupal’s considerable longevity, it also presents obstacles if we wish to guarantee the future of Drupal for the coming decade. Fortunately, owing to the vast amount of resources surrounding decoupled Drupal, including the book Decoupled Drupal in Practice and even a conference dedicated to the subject, more and more discussion around the topic will yield significant fruit for the promising future of Drupal.

While no one can prognosticate how decoupled Drupal will look in 2030, at the end of this current decade, we can certainly see that the story of decoupled Drupal is only just getting started. I strongly encourage you to check out our recent Tag1 Team Talks episode to learn more about what could influence Drupal’s trajectory substantially in the coming years. I, for one, believe that though we have come a long way, we still have much distance to cover and much thinking to do in order to prepare for a more decoupled Drupal. Nevertheless, the solutions recommended by Fabian and Sebastian excite me just as much as I hope they have inspired our readers too.

Special thanks to Fabian Franz, Michael Meyers, and Sebastian Siemssen for their feedback during the writing process.

Photo by Jesse Bowser on Unsplash

Feb 27 2020
Feb 27

You’re having trouble keeping up with demand and need a more powerful and robust website platform.

As business problems go, that’s a great one to have. Especially for enterprise-grade organizations and government entities. The question is: Which website platform is best?

To help you make informed decisions about your platform choice, we’re sharing a look at what Acquia has to offer. In this post, you’ll learn what Acquia is and how it works, who should consider using the platform and who should not. Then you’ll read our thoughts on what should be top of mind when selecting a platform.

Full disclosure: Mobomo is an Acquia partner organization, meaning we help clients make the most of their Acquia technology and services. Far from being a hard sell, however, this post aims solely to provide expert analysis and an honest assessment of the company and its products.

What Acquia Is and How It Works

Acquia is considered a digital experience platform (DXP), which is a collection or suite of products that work in concert to manage and optimize the user’s digital experience. These products can include a CRM, analytics, commerce applications, content management and more.

In its industry report on DXPs, Magic Quadrant for Digital Experience Platforms, Gartner defines a digital experience platform as “an integrated set of core technologies that support the composition, management, delivery and optimization of contextualized digital experiences…Leaders have ample ability to support a variety of DXP use cases and consistently meet customers’ needs over substantial periods. Leaders have delivered significant product innovation in pursuit of DXP requirements and have been successful in selling to new customers across industries.”

Organizations use DXPs to build, deploy and improve websites, portals, mobile and other digital experiences. They combine and coordinate applications, including content management, search and navigation, personalization, integration and aggregation, collaboration, workflow, analytics, mobile and multichannel support.

Acquia is one of the major players in this space, and the only one designed solely for Drupal.

Acquia co-founder Dries Buytaert was in graduate school in 2000 when he created the first Drupal content management framework. Buytaert and Jay Batson then established Acquia in 2007 to provide infrastructure, support and services to enterprise organizations that use Drupal.

Features and Benefits of Acquia

Acquia initially offered managed cloud hosting and fine-tuned services for Drupal. It has since expanded on its Drupal foundation to offer a complete DXP, including but not limited to:

  • Acquia Cloud: Provides Drupal hosting, development tools, hosting services and enterprise grade security.
  • Acquia Lightning: An open source Drupal 8 distribution with preselected modules and configuration to help developers build sites and run them on Acquia Cloud.
  • Acquia Digital Asset Management: A cloud-based digital asset management tool and central library for Drupal sites.
  • Acquia Commerce Manager: Provides a secure and flexible platform for content-rich experiential commerce.
  • Mautic: A marketing automation platform that enables organizations to send and personalize multi-channel communications at scale.
  • Acquia Journey: An omnichannel tool that allows marketers to listen and learn from customers to craft a sequence of personalized touchpoints and trigger what they will see next.

Additionally, Acquia provides comprehensive logging, performance metrics, security and Drupal application insights, and uptime alerts organizations need to monitor and optimize applications.

The Acquia platform also shines in its security capabilities, supporting strict compliance programs such as FedRAMP, HIPAA, and PCI, among others. Acquia customers can also internally manage teams at scale with advanced teams and permissions capabilities.

And they’re running with the big dogs. Other DXP companies assessed in the Gartner Magic Quadrants report include Adobe, IBM, Salesforce, Liferay, SAP, Adobe, Microsoft and Oracle.

In that report, Gartner cited Acquia’s key strengths as follows:

  • Acquia Experience Cloud offers a wide array of capabilities well-suited to support the B2C use case. Some clients also use it for B2B and B2E use cases.
  • The open-source community behind Acquia, which is the main contributor to the underlying Drupal WCM system, is highly active and well-supported by the vendor.
  • Acquia’s partner ecosystem continues to grow, offering choices to clients looking for expertise in specific verticals and availability in specific regions.

Who Should Consider Acquia

In a nutshell, Acquia is a good fit for enterprise-grade clients and government entities needing a comprehensive and powerful platform that optimizes the entire user experience while integrating data from multiple sources to support decision-making. Organizations that deploy and manage multiple websites will find Acquia particularly helpful.

One glance at Acquia’s customer page crystalizes the scope and scale of organizations they serve. Brands using Acquia include Wendy’s, ConAgra Brands, University of Virginia, City of Rancho Cucamonga in California and Australia’s Department of the Environment and Energy.

According to Website Planet, what sets Acquia apart is their foundation in the open-source Drupal content management framework. Unlike many of their competitors, Acquia allows customers to buy resources and features individually rather than purchasing entire pre-made packages. This can be particularly appealing to organizations who already have a couple of strong individual solutions in place that they want to integrate into their DXP, such as this reviewer in the manufacturing industry:

“A few things drove me to this solution: Decoupled architecture that allowed me to build a completely distributed digital landscape while keeping central control, The Open Platform concept that allowed me to build my own integrations and connect different components of my existing Martech stack without always using the “default” provided options and the comfort/security of relying on a cloud-based solution with full service support on top.

For e-commerce website owners, Acquia’s packages provide a PCI DSS compliant solution that can easily scale to accommodate extensive product catalogs, large transaction volumes and surges in traffic. Acquia’s proprietary e-commerce manager integrates the various content, commerceand user interfaces, allowing you to provide seamless experiences to your customers through a single system.”

Who Should Not Consider Acquia

Acquia is best suited for organizations with both the need for such a powerful suite of tools and the development expertise to easily implement and manage it. Beginners and small businesses lacking the requisite knowledge of programming and Drupal are likely better off with a different provider.

For those who develop their website through an agency, you’ll want to double-check that they will provide developers experienced with Drupal 8. If you do develop in-house, make sure your developers have strong familiarity with it.

Additionally, Acquia’s power comes at a price: Its price point may put it out of reach for small-to-medium businesses.

Acquia: Our Takeaway

As with any other significant investment, the best choice for your organization boils down to your wants and needs of you, the consumer. Keep these points in mind assessing how well Acquia matches up with your master list of must-haves.

  • Determine your desired business outcome. Think about what you’re after in terms of improving the business. What does each DXP offer and can you make the most of every feature you’re paying for?
  • Know your stack. Document your current technology architecture: what do you have, who uses it, for what and how is it connected?
  • Determine use cases. Who will use your technology and how will it make them productive?
  • Prepare your people. Your personnel play a massive role in assembling your digital experience technology stack. Don’t set yourself up to spend time and money on a platform that doesn’t get adopted or used to its potential.

By conducting a thorough assessment of your organization’s needs, capabilities, and goals, you can readily determine whether Acquia is the best fit to help you provide an amazing digital experience for your audience.

Contact us today and find out how Mobomo can help you make the most of Acquia.

Feb 27 2020
Feb 27

Still running your website on Drupal 7 (or 6)? It’s about time to migrate to Drupal 8!

We have written extensively about why you should migrate to Drupal 8 if you’re still on Drupal 7 (or 6). Although, one of our most favorite (and significant) reasons to migrate to Drupal 8 is that … Drupal 9 is coming! And if you want to enjoy the benefits of Drupal 9, it is recommended you migrate your website to Drupal 8 first. We could argue that you should move to Drupal 8 now because there’s not enough time once Drupal 9 is here (June 2020) and Drupal 7’s EOL (Nov 2021). But you could claim that you can opt for an LTS (long term support) instead! Fair enough. Except that apart from spending more money in engaging an LTS service provider, you are also losing out on the rich benefits that Drupal 8 has to offer. Some things may seem difficult but are necessary for a stronger and a simpler future.  

Once on Drupal 8, you don’t have to “migrate” anymore – only a simple “upgrade” from Drupal 8.9 to 9, and then 9.9 to 10 and so on, will do. Migrating from Drupal 7 to Drupal 8 is not always easy and straightforward; I agree. Following a process helps but you might still face some challenges during the migration, especially if your Drupal 7 website’s content model is considerably complex. Let’s take you through a step-by-step migration from Drupal 7 to Drupal 8 with challenges that you might face. And our recommendations on how to overcome them.

Drupal 8 Migrate – Assumptions and Preparations

“To be prepared is half the victory”, said Spanish novelist Miguel De Cervantes. A Drupal 8 migrate can get complicated but if you have spent enough time in planning the migration, the challenges won’t surprise you. Drupal 8’s adoption of many modern development standards like Symfony, Twig, PHP 7, etc. have led to this complete rebuild but it also calls for more powerful, robust and flexible digital experiences. Listed out are a few pre-conditions that you should remember before you begin –

  • Update your Drupal 7 website to the latest version available. This will help in cleaner automatic upgrades of some of the modules that have direct upgrade paths.
  • Make sure you have access to the Drupal 7 website’s database and files (public and private).
  • Create a backup of the Drupal 7 website and use this backup for the Drupal 8 migration. It is not recommended to migrate a live functional website although the migration itself does not make any modifications to the source.
  • Download a fresh installation of Drupal 8 from here and enable the core Migrate modules the we discussed above. And remember, it MUST be fresh! Any configurations made or content created will be overwritten when an upgrade is performed.
  • There is no direct upgrade path from Drupal 7 to Drupal 8 (unlike in previous version upgrades). Familiarize yourself with Drupal 8’s migration system. The three modules that are in core –Drupal 8 Migrate module, Drupal 8 Migrate Drupal module and Drupal 8 Migrate Drupal UI module. 
  • Make your migration choice – will you use Drush (which gives you granular control) or will you go with the browser user interface (easier but less control)?
  • Know your source. The Drupal 8 migration system’s flexibility allows content to be extracted and loaded from older versions of Drupal and various other sources like CSV, XML, JSON, MYSQL, etc.
  • Perform a thorough content audit to identify content that you need to migrate. Discard unused and irrelevant content to avoid spending time and effort in migrating them.

The Migration Process (Step by Step)

  • Observe and Plan

Identify the content types and content structure of the existing site and document the observations. This includes content types, field types, blocks, taxonomies, etc. Prepare a plan on what you need to migrate and what needs to be merged, based on these observations. Analyze the views and other site configurations and catalog them so it is easier to replicate them in Drupal 8.

  • Create a modules checklist of your Drupal 7 website

With this checklist you should be able to identify modules that you still need, or if there is a Drupal 8 version of that module, or if the module has now moved to Drupal 8 Core (like the Media module). Not all Drupal 7 modules can be automatically migrated to Drupal 8. Some Drupal 7 modules may have merged their functionality into a single Drupal 8 module. And some Drupal 7 modules may have separated their features into two or more Drupal 8 modules. It is always better to analyze such cases to be sure there is no data loss!

     Expert Recommendation – Use a module like the Drupal Migrate UI to identify the Drupal 7 modules and their corresponding Drupal 8 module (if available or not).

drupal-7-to-8-migration

No module version available for Drupal 8? For example, the ImageField module in Drupal 7 does not have a corresponding D8 module. We might have to find best suitable alternative available for this in Drupal 8. Of course, we have the Drupal 8 core Media module. However, we will have to develop custom scripts migrate the image data.

Expert Recommendation – If you have just inherited a D7 website and have no idea about the customizations made to the modules OR If you have made customizations yourself and need to find them, we recommend you to use the Hacked! module. This module will go through the list of modules available on the site and the changes/customizations done to each module. 

Expert Recommendations – 

  1. Template files(.tpl) in Drupal 7 should be written rewritten using twig files, which is part of symphony 2 framework.
  2. Make sure you rewrite your custom modules that follow symphony standards.
  • Implementing the Migration 

The most awaited and significant step has arrived. As discussed earlier, there are two ways of migrating your Drupal 7 data to Drupal 8 -

  1. Running a migration with the Drupal UI
  2. Running a migration with the Drush

The latter is recommended as it is more efficient, can be incorporated into shell scripts, and has clearer error messages. 

Based on the catalog of the content and the extracted data you need to build the migration scripts where you map the content type attributes of Drupal 7 with the newly built content type attributes of Drupal 8.

Drupal UI Method

Leveraging the Migrate UI Drupal 8 module, you can start by visiting the /upgrade path of the Drupal 8 website. The upgrade review page will show you a list of modules in your Drupal 7 site that can and cannot be automatically migrated to Drupal 8. For modules that have their functionalities in another D8 module but not exactly the same (like the AddressField module in D7 is now Address module in D8), you will need to install and enable the corresponding D8 module and restart the migration process. Based on the catalog of the content and the extracted data you need to build the migration scripts where you map the content type attributes of Drupal 7 with the newly built content type attributes of Drupal 8. Next you can go ahead with importing the data from a data source.

Drush Method –

Are you comfortable using terminal? If so, you should opt for the Drush method for migration. It provides a set of commands for the process of data migration with better status messages. Check out this tutorial if you’re looking for a step by step procedure migration using Drush commands. Never used Drush before? This guide will help you understand the basics of Drush with a list of useful commands for migration.

You might run into some conflicts now. Make sure you have checked for known issues in Drupal . org and how to fix them. Once fixed, you can now run the Migration process that gives continuous logs/feedback of the actions taken. Lastly, check the logs for any errors, fix them and you are good to go!

Expert Recommendation – Wait! Once you have the content created, never overlook the SEO/page views. We need the content to have the same URL paths. Do not forget to take care of migrating the URL aliases, meta tags information of the content from the old Drupal 7 site.

There are very rare times when you would run into zero issues during a Drupal 7 to Drupal 8 migrate. Once the migration is completed, a regression testing of the configuration and content freshly imported to identify any potential bugs or issues, is absolutely necessary.


Challenges and (more Expert) Recommendations

  • Many Drupal 7 contributed modules have better versions of themselves in Drupal 8 and some have been deprecated. For example, the Field Collection module, which is used for grouping fields in Drupal 7 is soon to be deprecated. This module’s functionality has been added to the Paragraphs module and Entity Reference Revision module in Drupal 8. The Drupal 8 Paragraphs module provides immense flexibility to Content editors/authors to create seamless forms and structures. If you need to migrate the Field Collection module and map it to the Paragraphs module (D8), you will need to write custom plugins to map the content between Field Collection fields to Paragraph fields. Or if you still want to continue migrating the Field Collection module even in Drupal 8, this field mapping can be handled by available Core migrate plugins. 
  • Do you use Panels for creating your landing pages like Home page, Dashboard, etc.? Even if you only need to place a block in the home page? Layout builder to the rescue! Layout Builder in Drupal 8 makes it easier for a content editor to customize a landing page. Let’s make best use of the features of Drupal 8. To migrate from Panels to Layout builder, you will need to write some custom migration plugins.
  • While migrating users, we will have to maintain the passwords as well so that the user does not have to recreate the password on the new site. Passwords are hashed content. So, you must find the hash type algorithm that is used in the source site. Next. write a process to validate the migrated password with the rehashed password using the same algorithm.
  • When running a migration, you may exhaust your system resources which may cause your migration to stop. Thanks to highwater marks, you can run the migration again and it should pick up from where it left off.
  • The widely used Features module in Drupal 7 now has almost become obsolete after the Configuration Management took over all the Features functionality and more in Drupal 8. Although the Features module is available in Drupal 8 as well, it is highly recommended to leverage Drupal 8’s Configuration Management system. It is not only simpler to work with, it is easy to export between environments, it uses YAML file formats instead of PHP – which is a more readable and proper data format.
  • Facing problems with your migration? There are several ways to report failures and get help -            - Drupal Upgrade Issue Queue
            - Module issue queue if you find a bug or exception with a core/contributed module
            - The #drupal-migrate IRC channel on Freenode
            - The #migration channel on Drupal Slack
            - Hire a Drupal Expert
Feb 27 2020
Feb 27

Understanding that integrations can balloon the complexity of a project, you may be asking yourself: why do it this way? That’s a valid question!

Why Integrate? Why not consolidate?

With all the potential complexity surrounding an integration, it may be worth it to ask the question: is there an alternative option?

There are three main factors to consider when looking at the value of a potential integration:

  1. Where does the data live / who owns the data?
  2. What business logic or outcomes do we need from the data?
  3. Does the data need to be exposed to any other systems apart from the one integration we’re considering?

Often, the balance of integrating versus bringing an external service “in-house” (or into the platform) comes down to these three factors.

Data Ownership / Storage

It may well be that you cannot bring an external system into your platform natively (forcing an integration) because you don’t own the data you want to integrate with. This might be the case with any paid access to a database like a list of service providers or tweets. Someone else owns that data but allows you to expose it (or use it) on your site. You cannot bring that data into your platform natively, requiring you to go and fetch it from them.

Sometimes data ownership issues get complicated, too: just because your organization collects the data doesn’t necessarily mean you own it. This is sometimes the case with proprietary systems. Your organization may have fed the data into their system, but part of your license assigns them ownership of your data after you’ve submitted it. It is important to understand who owns the data you’re integrating with and where it ultimately can and cannot be stored.

Business Logic

Integrations usually bring with them some meaningful experience: either data to enhance some functionality or some processing of information for an outcome. For some examples, you could think here of a commenting platform that is used widely: having an account with that commenting platform may enable you to comment on many different sites on the Internet rather than needing to create an account on each site. Or, a small ecommerce site may integrate with a credit card processor that you’re already familiar with, so you can trust when you click “Buy now” and are taken to a familiar checkout experience, that the retailer is using solid technology to handle your private financial information.

In both of these examples, the meaningful outcome of interacting with this data isn’t owned by the platform itself: it is business logic that is owned by another company. The service you’re getting by integrating with them is that data transformation. The credit card processor takes a credit card number and turns that into a deposit in your bank account. The commenting platform stores all of the comments, their approval status, and who made them, so you don’t have to. Drawing bright lines around this functionality and understanding what the processes are that you’re relying on is key to understanding how hard or easy it may be to bring a particular piece of business logic to your platform, rather than outsourcing it.

Data Exposure

A system that makes the right data available to the right people at the right time can be difficult to set up and maintain! Even if you own your own data and you can replicate the business logic you need to perform on the data, you still need to evaluate whether or not other systems apart from yours rely on that information to be available in a particular format. If there are other such systems, then you’ll need to make the data available from your platform if you choose to bring that integration “in-house.”

This might mean setting up and hosting an API yourself. It might mean moving a database behind your corporate VPN. It might mean needing to comply with data protection regulations that you didn’t have to worry about before (like HIPAA or GDPR).

It is certainly possible to do (and sometimes it is very beneficial), but it does require careful examination of the whole system.

How to plan an integration

With all that context, let’s set up a scenario: you’ve been asked to plan an integration. Your company is planning to start selling widget online and would like to use a third-party shopping cart and credit card processing. How do you start planning for this discrete but complex set of integrations?

Define the Benefits

Like most plans, it helps to start by defining your desired end state. When this integration is done, what will your users be able to do? Will there be a new button on your website? Ten new buttons? Text entry fields? What is the value or benefit to the customer?

Write it down!

Put All the Cards on the Table

Next, investigate what information will flow through the system. Document it in as much detail as you can. Will there be products? If so, they probably have lots of data with them (prices, quantities, sizes, availability, etc). What about users? What is a user (a username/password combo? An email address? A shipping address and credit card)? Try to be as specific as you can be about both the data and the composition of the data you’re going to be working with. (If you’re integrating with a good third-party system, they may already have documentation about the data and data composition that you can use.)

Draw a Flowchart

An example information flowchart.A simplified view of the flow of information through a system. This documents requests that can happen, storage locations, and data transformations to make the system complete. This documents five integrations that are codependent.

Once you have a good understanding of both the outcomes you’re aiming for and the pieces you have, you can start to line up the pieces sequentially in the order they’ll be used/consumed by the systems. Block out areas for where there will be business logic or transformations (these typically slot in right before storage, before display, or after initial read).

As you go through this process, make sure you write down your questions. If you don’t know what data looks like at some point during the process, note it! That is an area that could drive up complexity (or you might be able to discover the answer to that question and disambiguate the system a little more).

Your flowchart will drive your understanding of the complexity of the integration and now it’ll be a whole lot less ambiguous, too!

Conclusion

Integrations can be scary! They’re inherently complex: you’re dealing with data transportation, information ownership, data models, business logic, user experience, and display logic. Until you have a good framework for breaking down that complexity into some core component pieces, it can be really hard to wrap your head around how they all fit together.

By taking this approach, we at Palantir are able to estimate the complexity of particular integrations quickly during both our sales estimating and project planning phases of our projects.

Integration by Christer licensed under CC BY-NC-ND 2.0.

Feb 27 2020
Feb 27

The Pulse of the profession 2020 report revealed that nearly 11.4% of investment gets wasted because of poor project performance. Businesses, who often undervalue project management as a strategic competency for driving change, see their projects failing miserably. Managing a project can turn out to be a slippery slope when an organisation doesn’t have a solid grasp of all the moving pieces.

Glove with different coloured stones fixed on it to represent the infinity stones of Drupal development


When it comes to managing a website development project, with so much at stake and so much in flux, adhering to best practices becomes immensely important. Drupal development is no different. From site-building to theming to backend development, doing everything right during the Drupal development process can be a formidable task. Every stage of the Drupal website development process should be taken care of in order to get the desired result. We call these stages as the Infinity Stones of Drupal development.

In Avengers film series, Infinity Stones are said to be the group of gems that can grant an unprecedented amount of power to their owner. Marvel Cinematic Universe timeline is packed with instances where these Infinity Stones are mentioned. The Drupal world has its own set of gems that, when put together in the right manner, can lead to better project delivery. These are the essentials that have to fall in place during the development period to ensure the best yield.

Requirement gathering and analysis (Reality Stone)

A red stone on left, tasksheet icon on right, reality stone written at centre


The Reality Stone helps its owner in manipulating matter. In Drupal development, the requirement gathering and analysis phase acts as the Reality Stone.

Here, you receive inputs from all the stakeholders such as customers, salespeople, industry experts and developers. All the relevant information is gathered from the customer to build a solution that meets their expectations.

For instance, by setting up a meeting, a lot of things can come to an agreement between client and vendor. A plenitude of factors, that will majorly affect different parties involved with the project, can be figured out. Questions like what’s the budget, what will be the deadline, who will be the end-user, what’s the purpose of the building this website and other such questions could be raised and discussed. This stage helps resolve any ambiguities that might become a problem later on.

Architecture and design (Mind Stone)

a yellow stone on left, pencil icon on right, mind stone written at centre


Using Mind Stone, an artificially intelligent peace-keeping program called Ultron was built. This powerful stone allowed its owner to control the minds of others. The architecture and design stage of Drupal development is equivalent to Mind Stone. Once you have gathered the requirement from all the stakeholders, the next stage involves the process of understanding what was exactly in the mind of stakeholders and deriving a functional architecture out of it. All the stakeholders can then analyse the design specification and offer their feedback and suggestions. 

In this stage, several important questions can be pondered over like which of the core and contributed modules in Drupal can be utilised, should you go for Drupal 7 or Drupal 8 that will eventually decide the complexity of upgrade path to Drupal 9, should you go for headless approach etc. Any mistake that happens during the process of gathering stakeholders’ inputs and preparing the design and architecture plan would lead to cost overruns and project failure.

Development and implementation (Power Stone)

purple stone on left, desktop icon on right and power stone written at centre


Someone, who has acquired the Power Stone, would receive a colossal amount of energy that can even be used to destroy an entire planet. Development and implementation stage is the Power Stone of Drupal website building process. Here, developers put in all their energies into the actual development process i.e. to turn visualisation into reality.

Implementation phase begins on the basis of the design document. The design is translated into source code. A surfeit of code reviews takes place. The coding process follows the best practices of Drupal development like creating a clean content architecture by including all the fields and content types in the content structures; or choosing limited content types and fields to make things easier for content creators; or creating separate issues and patches to update the existing code and so on.

Testing (Space Stone)

blue stone on left, gear icon on right, and space stone written at centre


In Marvel films, there is a stone that is hidden inside a blue cube called the Tesseract. The Space Stone, as it is called, gives its owner the power over space. You can create a portal from one part of the universe to another. The testing phase is your Space Stone of Drupal development.

Testing phases begins once the coding gets completed. To find out every possible defect, testers have to open all the portals and do their magic. They have to keep a note of all the errors that they find during their intensive search in all of the portals. From preparing test cases to displaying the scope for more improvements in the user interface, user experience and speed, testers make a list of all the defects. These are then assigned to the developers to get them fixed. Regression testing is performed until the end product meets the client’s expectation.

Deployment (Soul Stone)

orange stone on left, rocket icon on right, and soul stone written at centre


Capturing and controlling others’ souls would call for a Soul Stone. The deployment phase is the Soul Stone of Drupal website creation process. This is the phase where you have got the final output after countless hours of hard work and are ready to see the result. You have got complete control over the resulting website.

The Drupal website, that has been built after all the requirement gathering and coding processes, is deployed in the production environment (or first UAT (User Acceptance Testing) is done based on the client’s needs).

Maintenance and improvement (Time Stone)

green stone on left, nut and bolt icon on right, time stone written at centre


Doctor Strange uses the Time Stone to trap a villain in a time loop and stop him from destroying the Earth. Whether you need to rewind or fast-forward the time, the Time Stone has got you covered.

The maintenance phase kicks in once the deployment is taken care of. This is the Time Stone of Drupal project management. In case any issue springs up during UAT tests or in the production environment, the developers can quickly rewind and check back the processes involved to find out where the error lies in. The improvement becomes easier as you go from incipient stage to the deployment stage or vice versa, find out the exact areas that are in need of enhancement or are under the threat of production downtime and act on it accordingly.

Project management (The Infinity Gauntlet)

The fancy golden glove, that Thanos wears with all the infinity stones fixed on it, is The Infinity Gauntlet. In Avengers, the Gauntlet, holding all the Infinity Stones, is the most sought-after thing. With all the stones united in the Gauntlet, its owner wields a massive amount of power. Project management is key to Drupal development and plays the role of Gauntlet. Like Thanos, with the snap of a finger, the project managers will be able to deliver the Drupal projects with ease if they ensure all the stages of Drupal development are followed accurately and effectively. Project managers are pivotal as they enable the application of knowledge, skills, tools and techniques to project activities so that the end result meets project requirements and ensures client satisfaction.

End thoughts

If Thanos, with his Gauntlet and the Infinity Stones on it, can become the most powerful being and go about destroying the universe, the Drupal project can benefit from its Infinity Stones too. The Infinity Stones of Drupal Development, starting from the requirement gathering and the designing to the deployment and the maintenance, if followed efficaciously, can make the process of creating a Drupal web property smoother and quicker.

With the presence of timely and efficient project management, everything falls in place. OpenSense Labs takes utmost care in adhering to best practices whilst developing a Drupal site. Ping us at [email protected] to know how we can bring all the Infinity Stones in its places and build an innovative Drupal website for your organisation.

Feb 27 2020
Feb 27

Schema.org metadata is one of the most important SEO optimisation issues. This is what the extensions of HTML documents that allow search engine robots to better understand the meaning of individual subpages of your website are being called. Handling the visitor's metadata in Drupal already since version 7. In this article, I will present different ways to implement them.

What do you need metadata for?

Modern search engines such as Google or Bing are no longer simple text indexing tools. They become more and more intelligent and read the page content with better and better results. They classify the content and show it in an interesting form. If you correctly tag the type of content and its basic parameters in the HTML code, it will open new SEO possibilities for you. As a professional Drupal agency that creates large websites, we attach great importance to SEO.

An example would be an event website. When you organise many events and put them on a website, Google reads the metadata contained in the list ("Event" content type, date, name, place, etc.) and presents them under the search result. In this way, you become more visible.

microdata-example-1

Metadata is also widely used in service and product reviews. Properly tagged ratings appear in the search engine in the form of stars, thanks to which they achieve a higher conversion rate:

microdata-example-2

Google currently supports a very limited set of metadata types. However, it can be expected that it will be expanded with new types of content in the future. It is a good idea then to add metadata just in case – to be one step ahead of the competition.

Metadata formats

Suppose you have the following HTML code on the page, welcoming a user named John. You would like to provide search engine robots with information about this user.

<p>Hi, I’m John.</p>

In order to do this, you will use the "Person" content-type defined by schema.org.

There are three main metadata formats, each with its own pros and cons. They are all supported by Google.

JSON-LD

This format is definitely the easiest to implement and it becomes more and more popular. It consists in adding a JSON object containing all metadata to the document (usually at the beginning) – in our example, it is the "Person" content type, which is – a person and their name, i.e. "John". This approach does not require tampering with the webpage's HTML code contained between the <p> tags, however, it is characterised by a substantial code redundancy. If you have metadata to provide, e.g. a longer description, you have to repeat it within the HTML code twice.

<script type="application/ld+json">
{
 "@context":"http://schema.org",
 "@type":"Person",
 "name":"John"
}
</script>

<p>Hi, I’m John.</p>

RDF

RDF offers a slightly different approach to content tagging. In order to avoid the redundancy characterising JSON-LD, you modify the already existing HTML code to indicate where the metadata occurs. In the example above, in accordance with the RDF specification, you find the HTML tag containing the "Person" content type and point where the person's name is located.

<p vocab="http://schema.org/" typeof="Person">
  Hi, I’m <span property="name">John</span>.
</p>

Microdata

Microdata is currently the most popular format, employing a principle similar to RDF. There is a good reason I put it at the end of this list, though. It is considered to be very limited. Despite its prevalence (it is estimated that about 75% of websites implementing metadata was using it in 2016), it is the least flexible of the specifications listed. This is why you will not find it in Drupal.

<p itemscope itemtype="http://schema.org/Person">
  Hi, I’m <span itemprop="name">John</span>.
</p>

Metadata in Drupal

Metadata implementation is possible in almost every tool used for website creation. All you need is access to templates containing the HTML tags of interest to you. In Drupal, the data is usually handled by two modules – one located in the RDF's core, and one created by the Schema.org Metatag community. I will briefly describe both of these solutions.

RDF module

The Drupal's built-in RDF module is used to map entity fields to the appropriate types of metadata. This mapping is carried out by using .yml files and is quite cumbersome – mainly due to the lack of official documentation and graphical interface. Let us assume that you have the "Event" content type, defining the name of the event (title), the location it will be held at (field_place), its date (field_date) and the ticket price (field_price). In order to tag the event page in accordance with the RDF standard, you create an rdf.mapping.node.event.yml configuration file and put it in the new foobar module in the config/install directory:

status: true
dependencies:
  config:
    - node.type.event
  module:
    - node
    - foobar
  enforced:
    module:
      - foobar
id: node.event
targetEntityType: node
bundle: event
types:
  - 'schema:Event'
fieldMappings:
  title:
    properties:
      - 'schema:name'
  field_date:
    properties:
      - 'schema:startDate'
  field_place:
    properties:
      - 'schema:location'
  field_price:
    properties:
      - 'schema:price'

Then you run the just created foobar module and look into the HTML code of the event website. There are already RDF tags within it.

<article role="article" about="/node/1" typeof="schema:Event">
  <div class="node__content clearfix">
    <div class="field__label">Place</div>
    <div property="schema:location" class="field__item">Wrocław</div>
    <div class="field__label">Date</div>
    <div class="field__item">
      <time datetime="2020-04-25T08:00:00Z" property="schema:startDate" class="datetime">Sat, 04/25/2020 - 08:00</time>
    </div>
    <div class="field__label">Price</div>
    <div property="schema:price" class="field__item">1000</div>
  </div>
</article>

Schema.org Metatag module

There is a much simpler and more straightforward method for implementing metadata, provided by the schema_metatag module, which is an extension of the popular Metatag project. It employs the JSON-LD format and allows adjusting the field mapping via a convenient admin panel. For our example concerning an event, it looks like this (after enabling the schema_event helper module):

microdata-module

Hints on the Google requirements are extremely useful here – they save a lot of time when you are optimising the website the final effect in the HTML code looks like this:

<script type="application/ld+json">{
    "@context": "https://schema.org",
    "@graph": [
        {
            "@type": "Event",
            "name": "DrupalCamp Poland",
            "startDate": "Sat, 04/25/2020 - 08:00",
            "location": {
                "@type": "Place",
                "name": "Wrocław"
            },
            "offers": {
                "@type": "Offer",
                "price": "1000"
            }
        }
    ]
}</script>

How to check the metadata correctness?

In order to ensure that your website is properly processed by search engine robots, you should check its code with Google's structured data testing tool. Errors in microdata implementation also appear in the Google Search Console. 
 

Feb 27 2020
Feb 27

How well you design the content model for your project plays an important role in your website design not just now but even in future. Consider 2-3 years down the line when you have to redesign your website, having a proper content model makes the task easier. It gives you the flexibility to redesign easily, with reusable existing components, or setting up new pages, displaying content across different channels, as and when required. 

But even with the importance it holds for website redesign, there is a common tendency to not pay enough attention to it. While we discussed its importance and challenges in the last blog, the next step is to understand how to approach documenting it. Additionally, we will look at the key solutions to content modelling with Drupal.

Building a Content Model Approach

A content model is essentially the structure of your content types that you will have for any given project. And one of the most common ways to maintain it is to start documenting in a spreadsheet. So essentially for any given content modelling documentation, you need to cover all entities like:

  • Content types
  • Taxonomies
  • Diff blocks
  • Paragraphs

For example, say you have a website for managing different music artists, and you are maintaining the profiles for several artists. So in order to start documenting your content model in a sheet, you need to define the name of the fields first. What type of fields would you have for a website that manages music artists? Name, profile details, and past compositions could be a likeable choice. So once you decide on the fields, add some description and data around why it is required. 

A content model documentation is basically supposed to be a live document that you maintain throughout your model. The fields and data you put up here is what feeds into the requirements and is also what the developers pick up. So it’s highly critical that you maintain it.

Content Modelling for a CMS Project

Now with any CMS project, how you approach content modelling also depends on the type of content. Essentially they are classified into two different categories - Structured and Unstructured content. Here’s what makes them different with respect to the content model approach:

Structured Content

This includes content like news, articles, webinars, blog, events - things essentially which editors would typically enter the content in the form of a form. The editor goes into the backend and fills out the fields in a form, they are very little bothered with what happens at the frontend. 

A structured content type follows a list of fixed templates, there might be some changes they want depending on the content but overall the structure of the content or template of the page remains same. Take for instance any news media publishing website, all of their news articles follow the same template. There might be different versions or special long form articles, certain special templates but the majority of content look the same. That is what we bucket as structured content type.

Drupal has a very mature approach to structured content, and nothing much can go wrong in it. But where we mostly face issues, where we have mostly seen issues in the past CMS in Drupal projects is with respect to unstructured content.

Unstructured Content

Unlike structured content, this has no fixed templates and are usually uniquely designed website pages like the home page, campaign page, landing page, or any special article pages. These pages are usually put together by editors who, depending on their requirements on the different components they want, stitch together these pages themselves.  

There might be some pre-defined templates, some regions, inbuilt components in place for the editors to start from. But how the page will eventually look totally depends on the editor and what they decide to do with it. 

As a result, approaching this kind of content or pages is a challenge in itself. And while there are a few solutions you could adopt, let’s first delve into what you should avoid while dealing with unstructured content pieces.

Too Many Content Types

In Drupal, one of the ways is having too many content types. For example, you want to change few things in an existing news article template, say an extra field or the font type, or the background color. You do not require to create a separate content type for this, and you shouldn’t because this is something that can go totally out of control. As more requirements or variations come up, you will keep on creating new content types when those content types are actually sharing 80-90% of the fields. 

This will result in a lot of maintenance overhead and introduce a host of issues. Plus fixing something may require a lot of regression testing, and you may also have to roll it out to different content types. So this is something you should definitely avoid.

Too Many Fields on One Content Type

Another tempting approach is to keep on adding fields to a single content type. Say you need a gray background on an article, or a font change in one, all of this can go completely out of hand. If you know what you are doing, and it's only a matter of a couple of fields then it might still be feasible. Otherwise it could cause too many issues in your next website design. 

This is because you are completely letting your content model be coupled with design and you are letting the design dictate your content model. The next time your design changes, you will have to rebuild your content model from scratch.

4 Key Solutions on Content Modelling

 

So we talked about the pitfalls, and what are the things you should avoid. Now let’s take a look at the approaches that do work well, ones that you may consider for your next project.

Drupal Core

This approach does not require any contributed module, you can do this as part of Drupal core,  and you can use Drupal’s templating and theming layer to achieve this.

This is a good approach for simpler use cases where the content structure is not really changing. Or when you want to create a separate page, where the structure is same, and you only want some minor variations, you wouldn't want developers to do this for you all the time.

However if the editors require a lot of flexibility in terms of changing the design or the page layout, then this approach will not scale.

Pros:

  • Good for simple cases
  • Same content structure, presentation variation
  • API friendly

Cons:

  • Requires development for any design change
  • Cannot handle structural changes

Paragraphs

A module in Drupal which is very popular, can be used to create LPs. Out of the 4 approaches, this is the one that can get you structured content. It is the most API friendly approach, so you can use paragraphs module to even build your LPs on a decoupled Drupal architecture where you are using a Javascript framework instead of Drupal for the frontend application. 

Another advantage is the components that you add, you can make them reusable. So there are extensions to the paragraph module that allow you to reuse the paragraph content that you create. You can reuse these components across different content types. You can also easily add any new component, or last minute design changes, it's very flexible in that sense.

The disadvantage is that it ties your content model to your frontend design. So Paragraph approach works really well for stacked content pages (one component after the other in a single column), but if you want to create multiple columns or swap things from left to right etc., you start adding those configurations to your paragraph and that means you start coupling your content model with your designs. When you have to manipulate the layout or the template in the front, that’s where you may not see as much flexibility with Paragraph approach as with others.

Entity Embed

This is the most familiar tool for editors, especially for those who have been using CMS. It allows you to build unstructured content pages using the WYSIWYG (What you see is what you get) editor. So you can write all of your content, and embed all your components within the WYSIWYG editor itself.

It is a good way to keep your HTML out of the body, and you can still maintain and build a component outside of the body feed. For example, image, slide show, a photo gallery - you could build them as separate entities, and then simply embed them into your body feed.

This approach is very powerful but also prone to abuse because there’s no fixed layout of how the page will look like. So the editors depending on their comfort and skill level with WYSIWYG, and whether they know basic HTML, it can impact their editorial experience. 

Some people may like the power this approach brings, others may find it very complex especially if you start adding many inline components into your article. It is definitely not suitable for the decoupled frontend because WYSIWYGs are meant for coupled implementation. The way you set up your components within a WYSIWYG, translating that information into a decoupled application is a different challenge altogether. So this approach is not suitable for a decoupled setup. 

Layout Builder

The most flexible approach by far, it allows editors to create regions and manipulate templates on the fly. They can create multi-column regions on their page, and pull in components. It has reusable components so there’s a lot of flexibility, easily accommodate changes, add new components to your component library and keep on expanding it. This also gives the highest level of per page control to the editors.

Some of the shortcomings of this approach are:

  • The components that you keep adding to the page, they are not explicitly connected to the page or node. So you have to do a lot of extra queries and do some leg work, for example, if you have to expose this as an API or see what components have been added to a page, you may need to go through a couple of extra hoops to get that information, unlike in paragraphs approach. 
  • This does not enforce any consistency, so depending on how much control your design team wants on the website or web pages, this approach may or may not be great. So if there’s a very consistent design that’s desirable for websites, you may not want to expose this kind of to your editor because they can change the layout as they like, and you may end up with some undesirable results.

Choosing the Right Approach

Now with these four approaches in picture, the next probable question is which one to choose. The answer is it varies depending on the type of project you are dealing with. Any page that you want to build can be done using all of these four approaches, but you also need to look at the editorial experience, how comfortable editors are using it, how much control does the design team want on the page layout- all this dictates the right approach for your project.

Most large projects use a combination of the four approaches. Homepages and other landing pages may use the Layout Builder. More structured content like case studies and products may use template switching to vary presentation as needed. A shared library of components can bring in efficiency and design consistency across different approaches for managing unstructured content pages.

In EzContent as well, we use a combination of these approaches. It is a one-stop Drupal solution which utilizes AI and machine learning algorithms to deliver an enhanced editorial experience. 

What's essential when you are going for a mix of these approaches is to ensure that your components are reusable. And that's something Drupal is great at, if you use the right modules, and create the components in a proper manner.

Thus, working on your content model, and trying to build it in a way that's decoupled with your frontend as much is feasible, are some of the things you should strive for when taking up a CMS project.

[embedded content]

Looking to enable editors with an easy publishing experience? Let’s do a little brainstorming and see how we can help. 

Feb 26 2020
Feb 26

In our current, digitally driven business climate, search engine optimization (SEO) and optimal web experiences are inherently intertwined. Each feeds off and builds upon the other. 


SEO has worked its way into our widely recognized business lexicon, and it’s generally understood that better SEO translates into better organic (unpaid) search engine rankings. A far lesser-known fact, however, is that optimal user experiences enhance SEO.

Great UX drives SEO

In the early days of SEO, initiatives were largely focused on gaming the search engines, with a goal of landing at or near the top of a SERP (Search Engine Results Page). This led to tactics such as packing key search terms into title tags and meta page descriptions.

Google and the other search engines have gotten a lot smarter. Google now detects various degrees of user engagement as a key measure for search rankings, and Google’s ever-evolving algorithm is focused on indicators that search queries result in the correct, sought-after data. In this new environment, websites that are playing by outdated rules are actually getting penalized by Google as well as the other search engines.

2-Faceted SEO Strategy

User experiences that meet expectations are at the core of great SEO, but the fact remains that information still needs to be delivered in a format that grabs the attention of search engine crawlers. As such keyword research and strategic keyword deployment remains essential.

Keyword research helps in moving beyond assumptions concerning most popular search terms relative to a particular product or service. Take the example of a search for facilities that cater to for elderly residents. A website designed to target this market absolutely needs to factor in data concerning the search volume and relative popularity of each of the following search terms:

  • Nursing homes,
  • Memory care,
  • Assisted living,
  • Assisted living facilities,
  • Retirement homes, 
  • Retirement communities,
  • Senior adult communities, and
  • Senior living facilities.

 

Keyword Research

For insight into the most popular search terms, as well as the terms that competitors are using, Google Ads (formerly Google Adwords), SEMrush, Spyfu and Moz are among the leading providers. 
 
Keep in mind that optimizing for search terms other than the highest volume search terms, is often the most effective approach to SEO. Companies that are operating in a field where the competition for the major search terms already appears to be an uphill of a battle, optimizing for the so-called “long-tail” (less frequent and more specific) search terms can be akin to a targeted, niche marketing campaign.
 
Examples of long-tail terms for senior living facilities could be “Westgate Senior Living,” or “Pet Friendly Retirement Communities.”

Keyword Placement

The main page header or the H1, is what informs Google of the subject of the page. The main header on every page is a key focus for SEO. It’s also important to be strategic about the deployment of keywords within page title tags, the page meta description and the secondary headers. 
 
Focus on a different set of keywords for each page that is crawlable by Google. The Google algorithm is looking to differentiate among pages, and anything that can be done to help clarify will serve to enhance SEO.
 
Search engine marketing is a dynamic, rapidly-evolving discipline, that too often does not receive the attention that it warrants. In a business climate where organizations are increasingly defined by their digital presence, a finely tuned and constantly refined SEO strategy is an essential success factor for organizations of every kind.
 
Looking to fine tune your site’s SEO strategy and ensure that it is aligned with current trends and best practices? Contact us today

Feb 26 2020
Feb 26
Main blog post photo_Schema.org And Metadata in Drupal Schema.org metadata is one of the most important SEO optimisation issues. This is what the extensions of HTML documents that allow search engine robots to better understand the meaning of individual subpages of your website are being called. Handling the visitor's metadata in Drupal already since version 7. In this article, I will present different ways to implement them.
Feb 26 2020
Feb 26

New days mean new rules on the web. Having social media integration buttons on your website today is one of the crucial web design tips to ensure your business success.

If you have a website on Drupal, this post will be of special interest to you. We will discuss how social media integration works in Drupal 8, what modules are available, and how to integrate social media on your website using one of them — the Easy Social Drupal module.

The importance of integrating social media

If you want to fully reap the benefits of social media marketing, you need to rely on these small website elements, which can be your huge business boosters:

  • content sharing buttons
  • buttons linking to your social accounts
  • tweetable lines in your content
  • feeds
  • counters

and more.

They help you engage more customers across multiple channels, increase your campaign visibility, improve your communication with your audience, boost your SEO, raise your brand awareness, make your site user-friendly, and much more. Social integration buttons are also indispensable elements of the contact block on every modern website.

Social media integration in Drupal 8

Any kind of third-party integration in Drupal 8 is easy to set up thanks to its API-first principle. Social integration is no exception — on the contrary, it is one of the easiest integrations to perform. This is thanks to helpful contributed modules.

Useful Drupal 8 modules for social media integration

Some of these Drupal 8 modules to integrate social media on your website are cross-network — they help you add blocks of buttons, feeds, links, counters, or social login options for multiple networks at once:

Useful Drupal 8 modules for social media integrationUseful Drupal 8 modules for social media integration

There also are Drupal 8 modules specifically tailored to the integration with particular networks (sharing content, adding feeds, and more):

Useful Drupal 8 modules for social media integrationUseful Drupal 8 modules for social media integration

Social integration via the Easy Social module in Drupal 8

The Easy Social module justifies its name — it allows you to set up your integration buttons with no fuss and no need to add external JavaScript libraries or other modules. The classic set of the most popular buttons is available both as a Drupal block or as a Views field.

Enabling the Easy Social module

When installed, the module offers an additional demonstration module — the Easy Social Example. You can choose whether to enable the latter.

Enabling the Easy Social module in Drupal 8

Enabling the social widgets

At the module’s configuration page (Configuration — Web services — Easy Social) you will see the default widgets that can be enabled:

  • Twitter
  • Facebook
  • LinkedIn
  • Pinterest
  • Google+ (included, but has reached its end-of-life)

There is also the option to load JavaScript asynchronously, which is recommended for performance purposes.

Enabling the social widgets in the Easy Social Drupal 8 module

Configuring the social widgets

Each widget has a tab where it can be configured individually. You can play with their color schemes, fonts, size, screen names, layout styles, types of actions (sharing or sending), the option to show the profile pictures of friends who liked this content, and so on. The available settings vary from widget to widget.

Configuring the social widgets in the Easy Social Drupal 8 module

Adding the social share block

Now that the widgets are selected, we will place our sharing buttons block on the website just like we would do with any other Drupal block. By going to Structure — Place block, we will choose the region to place it in. Next to the necessary region, we will click “Place block” and find the “Easy Social” block on the available list. Another click on the “Place block” and, finally, on the “Save” button is all that's left.

Adding the social share block in Drupal 8

When configuring the block, we can select the content types and pages to display it on, and user roles to display it to. The block title can be renamed to anything we would want users to see when they are supposed to share your content.

Configuring the social share block in Drupal 8

OK, that’s it! So we now see the sharing buttons below our Drupal content items:

Content node with social share buttons in Drupal 8

Let our team do the smooth integration for you!

The above example of how to integrate social media on your website was just a very simple one. Any integrations you wish are possible with the help of our Drupal development team — with any networks and featuring any settings.

If there is no contributed Drupal module that does the integration job, our team can write you a custom one. We can also apply design tweaks in accordance with your branding.

Integrate your website with social media easily — contact us!

Feb 26 2020
Feb 26

In a world filled with billions of internet-connected devices today, a lot of content is being delivered at every touchpoint in the customer journey. But sadly, most of them fail to deliver the right time customer experiences, as may be desired. The reason? Most of the content that is delivered does not pertain to a well laid out content model. There’s no design in place that utilizes the context of experiences and technology to make these content intelligent.

Not sure what that means? Think of it as a content piece that has to be responsive, adaptable, accessible, as well as machine readable to be able to reach the right audience at the right time. How do you ensure that? By focussing on making this piece contextually relevant. You need to visualize its purpose, and design it in a structure that accommodates user experiences and relevance. 

That is precisely what content modelling does. It is a formal representation of structured content as a collection of content types and their inter-relationships. And it helps you take into account any contextual experiences before framing a content model approach. One of the most common ways to maintain it is to start documenting in a spreadsheet. 

In this blog we take a look at why adopting a content model may be critical for your business, and what are the key challenges that come in the way.

Why Do You Need a Content Model

Content models have a long lasting effect on your website, especially your CMS website. Here’s what makes them so important:

Brings Flexibility

The way you model your content dictates how flexible the CMS is for editors, and for whoever is using your CMS. It also means that throughout the lifecycle of the project and even once your project goes live, how easy it is for you to accommodate changes or last minute feedback that is required by your content model.

Long Term

Your content modelling approach also has a lasting impact on how complex your content migration, or website redesign is, particularly if you are going from one CMS to the other, or choosing another technology in the future. So 2-3 yrs down the line, how easy it will be to migrate the content that all depends on how you model your content now.

Reduced Redesign Complexity

Changing the design or updating the design of your website is also very tightly coupled with your content model. If you have a content model that is decoupled with your design to whatever extent it may be possible, then redesigning your frontend in a CMS like Drupal becomes much easier.

But if your content model is really coupled with your design, then redesigning your frontend would also mean that you would need developers to change your content model, which might need to migration to content as well. So it really changes the whole complexity of your redesign exercise.

Ensures Re-usability

The way you model your content also dictates the reusability of your components, to what extent you can reuse content and design elements in the future.

Owing to these reasons, designing a content model beforehand plays quite an important role in your CMS website. Provides you the flexibility and reusability you need, along with the desired objective of creating contextual customer experiences. Now let’s look at the challenges.

Key Challenges to a Content Modelling Approach

Now that you are aware of the importance of a content model, you may be keen enough to build it. While creating a content model is quite simple physically, you may pose challenges in its conceptualization and distribution. Take a look:

Not a Single Party’s Job

Content model creation cannot be done by a single party alone. This would result in an ineffective content model that only solves the problems of that particular team. Rather a cross-functional team is required, one that contains developers, UX/UI/creative designers, content authors, as well as representatives from other areas of the business if necessary. This because everyone has some level of insight into these models – what makes sense to a developer may not make sense to a content author.

Clash of Interests

Let’s face it, having a cross-functional team work on one content modelling project is not as easy as it sounds. Certain members of a department may be too influential, or more vocal than others and might try to take the lead in mapping the content model. This could result in a clash of interests, or worse make the model inclined only to address a particular team. 

Either way this kills the effectiveness of the model, and there is also a huge chance that the team falls apart. What we need therefore is to create a solid foundation and framework that can evolve along with your project. And a team facilitator who can ensure that each team member gets the chance to have their voice heard. 

Disconnect in Terminology

When working with cross-functional teams, there is also a huge chance to have a disconnect in terminology regarding the components of content models and how certain elements are referred to. This may hamper with the content modelling process, leading to disagreements and misunderstanding between members of different departments.

To ensure this doesn’t happen, you might consider establishing a consistent content modeling vocabulary - what do you mean by pattern, assembly, content hierarchy- and similar terms in this context. This will enable all team members to understand the conversations being held and avoid misinterpretations that could delay your project delivery schedule.

Unstructured Content

Another major challenge that you may face in content modelling is with respect to building a content model for your unstructured content type. This means that for uniquely designed pages such as home page, campaign page or a landing page, there are no fixed templates that the editors use. They usually put together the layout based on their requirements and what they decide to do with it.

As a result, approaching this kind of content or pages is a challenge in itself. Coupled with that are few practices that add to this challenge, and must be avoided.

Too Many Content Types

Often editors end up having too many content types despite that most of those share 80-90% of the fields. They keep on creating content types for every new field or minor change they require in an existing template. This can go totally out of control, result in a lot of maintenance overheads as well as introduce a host of issues. Plus fixing something may require a lot of regression testing, and you may also have to roll it out to different content types. 

Too Many Fields on One Content Type

Another bad practice is to keep on adding fields to a single content type. This can again go completely out of hand, particularly if you don’t know what you are doing. It can also cause issues in your next website design, leading you to rebuild your content model from scratch.

Ultimately the art of creating a content model is supposed to be a balancing act. It should be easy for content authors to understand and use, for UX/UI designers to leverage wireframes and creative designs, and easy for developers to pull out through the API and into websites, applications and channels. In addition to this, you may consider some key solutions that will help avoid the above mentioned challenges to content modelling.

Curious to learn more? Take a look at how to build a content modelling approach with Drupal.

Looking to enable editors with an easy publishing experience? Let’s do a little brainstorming and see how we can help.

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web