Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 21 hours 39 min ago

Palantir: The Wisconsin Department of Employee Trust Funds

30 July 2019 - 3:24pm

Re-platforming the Wisconsin Department of Employee Trust Funds website from HTML templates to Drupal 8, including a complete visual and user experience redesign. An Effortless Customer Experience for Wisconsin Government Employees, Retirees, and Employers On

The Wisconsin Department of Employee Trust Funds (ETF) is responsible for managing the pension and other retirement benefits of over 630,000 state and local government employees and retirees in the state of Wisconsin. With approximately $98 billion in assets, the Wisconsin Retirement System is the 8th largest U.S. public pension fund and the 25th largest public or private pension fund in the world.

In addition to overseeing the Wisconsin Retirement System, ETF also provides benefits such as group health insurance, disability benefits, and group life insurance. Over a half-million people rely on the information ETF provides in order to make decisions that impact not only themselves, but their children, and their children’s children.

The Challenge

Given the extent of services provided by ETF, their website is large and complex with a wealth of vital information. When ETF first approached, their website (shown) hadn't been updated since the early 2000s, and it lacked a content management system. The site wasn’t accessible, it wasn’t responsive, and its overall user experience needed a drastic overhaul. 

Simply put, Wisconsin government employees could not easily navigate the crucial information they need to understand and make decisions about the benefits that they earn.

The new ETF site should lower customer effort across all touchpoints. An effortless customer experience: One stop, fewer clicks and increased satisfaction.

ETF's vision
Key Outcomes

ETF engaged Palantir to re-platform their website from HTML templates to the Drupal 8 content management system, including a complete visual and user experience redesign. After partnering with Palantir, the new user-friendly ETF site:

  • Provides ETF staff and all website visitors with a seamless experience
  • Allows Wisconsin government employees, retirees, and employers to efficiently access accurate and current information
  • Incorporates best practices for content publication for the ETF digital team
Upgrade to the Employee Benefits Explorer

One of the most notable features of the new site is ETF’s Benefits Explorer.

An important function of the ETF site is offering information regarding pension, health insurance, and other benefits. On ETF’s old site, employees were required to select cumbersome and confusing benefit options before they could find detailed information about their benefits. This task was made even more difficult by the fact that the names of benefit options are not descriptive or intuitive. ETF’s previous solution was to send physical mailers with distinctive photos on the covers, and then direct visitors to the website to select the benefit options that had the same image as their mailer.

Palantir and ETF knew that the “find my benefits” user experience needed a complete overhaul. In our initial onsite, we identified a potential solution: creating a database of employers and the benefit options they offer. With this list we built a benefits explorer tool that allows ETF’s customers to search for benefits by the one piece of information they will always definitely have: the name of their employer.

With the new explorer experience, site visitors begin by typing in the name of their employer and are immediately provided with their benefit options. We built two versions of the tool: one for the specific task of identifying health plan options, which are typically decided once a year during open enrollment, and one for identifying all benefits offered by your employer, which can be used any time of year.

The new “My Benefits” explorer is now the second most visited page on the new ETF site, which shows just how helpful this new feature is for ETF’s customers.

How We Did It

In order to transform the ETF website into an effortless experience for Wisconsin government employees, retirees, and employers, there were five critical elements to consider.

Our approach involved:

  1. Identifying “Top Tasks”
  2. Revising content
  3. User-testing the information architecture
  4. Crafting an accessible, responsive design
  5. Replatforming on a robust Content Management System: Drupal

Identifying “Top Tasks”

The biggest negative factor of the previous ETF site’s user experience was its confusing menus. The site presented too many options and pathways for people to find information such as which health insurance plan they belong to or how to apply for retirement benefits, and the pathways often led to different pages about the same topic. Frequently, people would give up or call customer support, which is only open during typical business hours.

Palantir knew the redesign would have the most impact if the site was restructured to fit the needs of ETF’s customers. In order to guarantee we were addressing customers’ most important needs, we used the Top Task Identification methodology developed by customer experience researcher and advocate Gerry McGovern.

Through the use of this method, we organized ETF’s content by the tasks site users deemed most important, with multiple paths to get to content through their homepage, site and organic search, and related content.

Revising Content

Our goal was to make content findable by both internal and external search engines. No matter what page a visitor enters the site on, the page should make sense and the visitor should be able to find their way to more information.

While the Palantir team was completing the Top Tasks analysis, the internal ETF team revised the website content by focusing on:

  • Plain language: ETF had convened a “Plain Language” initiative before engaging with Palantir, and that team was dedicated to transforming the tone of ETF’s content from stiff, formal legalese to a friendlier, more accessible tone.
  • “Bite, snack, meal” content writing strategy: The ETF team used this strategy to “chunk” their content for different levels of user engagement. A bite is a headline with a message, a snack is a short summary of the main points, and a meal is a deep dive into the details.
  • Improving metadata for accessibility and search: Palantir provided guidance on standardizing metadata, particularly for ETF’s PDF library. The ETF content team made sure that all their content had appropriate metadata.

User-tested Information Architecture (IA)

Once we had the results from our Top Tasks study, we worked toward designing a menu organized intuitively for customers. In our initial onsite, we conducted an open card sort with about 40 ETF stakeholders. Our goal was to have the ETF site content experts experiment with ways to improve the labelling, grouping, and organization of the content on their site.

We divided the stakeholders into six teams of five and gave them a set of 50 cards featuring representative content on their site. The ideas our teams generated fell largely into two groups:

  • Audience-oriented: content is organized by the role/title/person who uses it. In this approach, main menu terms might include Retiree, Member, and Employer. This approach was how ETF had content organized on their site at the time of the exercise.
  • Task-oriented: content is organized by the type of task the content relates to. In this approach, main menu terms might include Benefits, Retirement, and Member Education.

When we came back together as a group, our team of 40 stakeholders agreed that exploring a task-based information architecture would be worthwhile, but there was significant concern that switching away from an audience-based IA would confuse their customers.

Since making the site easy to use was one of our top project goals, our teams agreed to a rigorous IA testing approach. We agreed to conduct two rounds of tree tests on both an audience-oriented and task-oriented IA, and conduct three additional rounds of tests to refine the chosen approach.

Ultimately, our tests showed that the most intuitive way to organize the content for ETF’s range of customers was to organize by task, with one significant exception: Employers. ETF serves the human resources teams of all state of Wisconsin employers, and those users had completely separate content requirements from those of government employees and retirees.

Responsive Design System on Drupal

Because the former ETF site was significantly outdated, it completely lacked a content model, and the site itself was a massive hodgepodge of design elements. Palantir identified key ETF user flows, matched the content to each flow, and then abstracted out templates to serve each flow.

The overarching goal of this design system is to create intuitive, repeatable user flows through the website. These patterns enable visitors to quickly scan for the information they need, and make quick decisions about where to go next.

Accessibility and responsiveness are core requirements for ETF. Palantir used the a11y checklist from the very beginning of our design process, and continuously tested our visual designs for font size, color contrast, and general spacing of elements to ensure that accessibility was built into our design rather than retrofitted at the end.

We also conducted usability tests with real users, which helped us make accessibility improvements that accessibility checkers missed. In addition, the new design system is also fully responsive, which enables ETF’s customers to access the site from any device.

Robust Content Management

In addition to the efficiencies gained for site visitors, the new Drupal 8 site streamlines the content management process for the internal ETF site admin team. Previously, content creation happened across people and departments with minimal editorial guidelines. Once the copy was approved internally, the new content was handed to the webmaster for inclusion on the site. The process for updating content frequently took weeks.

With their new Drupal 8 platform, the ETF team has moved to a distributed authorship workflow, underpinned by the Workbench suite of modules which allows for editorial/publishing permissions. Now, ETF subject matter experts can keep their own content up to date while following established standards and best practices. The decision to publish content is still owned by a smaller group, to ensure that only approved and correct content is uploaded to the live site.

The Results

With the fully responsive design system in place, the new ETF site offers a significantly upgraded user experience for their customers:

  • Task-oriented: Our data-based top tasks approach ensured that we kept the focus on the user’s journey through the site. Everything from the menus to the page-level strategy to the visual design was geared towards making it effortless for visitors to achieve their most important tasks.
  • Structured content: Not only has the website’s content been rewritten to be more scannable for readers, but it’s also now structured for SEO. Our initial user research uncovered search as one of the most frustrating aspects of the site: “The main thing for me is really the search results: the most up to date version is never the first thing that turns up” By adding metadata to ETF’s library of PDF forms and transforming their content from freeform text to structured data, ETF’s search experience has made a complete turnaround.
  • User testing: Our strategy and design work was validated throughout the engagement with real site users, which kept us all grounded in the outcomes.
  • Accessible and responsive design: The design system isn’t just WCAG A.A compliant according to accessibility testing software - we worked with users to ensure that the site delivers a good experience with site readers. Incorporating a11y standards from the very beginning of the design process ensured that accessibility was baked into our design rather than a last-minute add on.

Palantir created a task-based navigation and content organization to support the customer journey, which is contributing to a better user experience. The new site is more personalized and engaging for customers.

Mark Lamkins

Director, Office of Communications

Categories: Drupal

Horizontal Integration: Testing Acquia Lift & Content Hub locally with ngrok

30 July 2019 - 12:34pm
Testing integrations with external systems can sometimes prove tricky. Services like Acquia Lift & Content Hub need to make connections back to your server in order to pull content. Testing this requires that your environment be publicly accessible, which often precludes testing on your local development environment. Enter ngrok As mentioned in Acquia's documentation, ngrok can be used to facilitate local development with Content Hub. Once you install ngrok on your development environment, you'll be able to use the ngrok client to connect and create an instant, secure URL to your local development environment that will allow traffic to connect…
Categories: Drupal

Gábor Hojtsy: Prepare for Drupal 9: stop using drupal_set_message()!

30 July 2019 - 8:05am

I posted my analysis of top uses of deprecated code in Drupal contributed projects in May 2019 two months ago. There are some great news since then. First of all, Matt Glaman of Centarro implemented support for deprecation messages directly in reports, so we can analyse reports much better in terms of actionability. Second, Ryan Aslett at the Drupal Association implemented running all-contrib deprecation testing on (Drupal's official CI environment). While showing that data on projects themselves is in the works, I took the data to crunch some numbers again and the top deprecated API uses are largely the same as two months ago. However, we have full analysis of all deprecation messages and their fixability which gets us two powerful conclusions.

Stop using drupal_set_message() now!

If there is one thing you do for Drupal 9 compatibility, make it getting rid of using drupal_set_message(). As the API documentation for drupal_set_message() explains you should use the messenger service and invoke the addMessage() method on it.

Of the total of 23750 deprecated API use instances found in 7561 projects, 29% of them were instances of drupal_set_message(). So statistically speaking if you stop using this single function, you are already 29% on your way to Drupal 9 compatibility (likely more for most projects).

Dezső Biczó already built automated deprecation fixers covering drupal_set_message() and more, based on rector.

72% of deprecated API use can already be resolved

On top of the 29% of drupal_set_message(), there is another 43% of various other API uses that can be fixed now. This means that those deprecated APIs were marked before Drupal 8.6.0 was released and are therefore in currently unsupported Drupal core versions. So stopping the use of them would still keep your code compatible with all currently supported Drupal core versions. In other words, as of today, project maintainers can resolve almost three quarters of the outstanding code changes for Drupal 9 compatibility. Considering we are still ten months from before Drupal 9's planned release date, this is quite good news!

Upgrade Status is a nice visual tool to explicitly list all the errors in the projects you scan. It provides instructions on how to fix them and immediately fixable issues are highlighted.

Work with project maintainers

You are not a project maintainer but want to help? Yay! Based on the above it may be tempting to run to the issue queue and submit issues for fixing all the things. Good plan! One thing to keep in mind though is to work with the maintainers of projects so your help benefits the project most effectively. project owners may specify Drupal 9 plan information that should help you engage with them the best way (use the right meta issue, know of their timeline plans, and so on). Check the project page of projects you are interested to be involved with to make sure you contribute the best way. projects can now specify Drupal 9 porting information, so *you* can direct *your* contributors to provide the most valuable help on the way to Drupal 9, fund the process or just step back (for now). Edit your project to help your contributors help you!

— The Drop is Always Moving (@DropIsMoving) May 21, 2019

More to come

I think the data is super-interesting and I plan to do more with it, for example cross-referencing with project usage. Stay tuned for more information in the future. In the meantime all the source data is available for your mining as well.

Disclaimer: The data is based on the state of contributed projects on July 29, 2019 based on Drupal core's 8.8.x development branch on July 29, 2019. As contributed module maintainers commit fixes, the data will get better. As core introduces more deprecations (until Drupal 8.8.0-alpha1), the data could get worse. There may also be phpstan Drupal integration bugs or missing features, such as not finding uses of deprecated global constants yet. This is a snapshot as the tools and state of code on all sides evolve, the resulting data will be different.

Categories: Drupal

OpenSense Labs: Harnessing AWS services with Drupal

30 July 2019 - 2:34am
Harnessing AWS services with Drupal Shankar Tue, 07/30/2019 - 15:04

Ever since the cloud computing proliferated enterprise digital transformation, new cloud platform services have started thronging the scenes. Now, the cloud ride is burgeoning even faster in 2019 and the cloud vendor innovation pace is at sky-high. The revenue is soaring. Amazon Web Services (AWS), one of the giants in this space, has witnessed a 45% rise in revenue year over year and reached $7.43 Billion for the fourth quarter of 2018.

AWS has been a force to reckon with when it comes to buying storage space for holding a colossal database, provision of bandwidth for hosting a website or processing power in order to run intricate software remotely. With AWS, the necessity of buying and running own hardware gets eliminated and organisations or individuals can pay for only what they actually use. Netflix, leading media services provider and a go-to option for streaming movies and web series, leverages AWS for almost all its backend infrastructure, storing and streaming its online content.

Netflix, from being a DVD-by-mail service to one of the most sought after media streaming services in the world, has come a long way. The number of Netflix subscribers has grown multifold (approximately 150 million in 2019). With 37% of the internet users around the globe binging movies and web series on Netflix, the power of AWS has been a massive success for them to keep up with the growing strength of customer base and scale at demand. If AWS can play such an influential role on a big enterprise like Netflix, you can hope for wondrous things to transpire when another magic pearl is added. Drupal can do miracles along with different AWS products and there are various ways to leverage products of Amazon Web Services with Drupal for your web development solution. But first, let’s take a quick look at AWS and a plentitude of products that it offers.

AWS in a nutshell

It is imperative to understand where AWS stands today in the market share before getting acquainted with its various provisions. In comparison to other big cloud service providers - Microsoft and Azure - there is a clear lead in the market maintained by AWS.

Source: Canalys

Amazon Web Services is definitely one of the most sought after cloud solutions in the market. So what is it? It is a comprehensive cloud platform by e-commerce giant Amazon that provides software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS) offerings. AWS offers cloud services from multiple data centres and availability zones that are spread across different regions of the world.

A Well-Architected Framework can be put into use that is built to assist cloud architects in the development of a safe, high-performing, resilient, and efficacious infrastructure for their applications. This framework is based on five pillars namely operational excellence, security, reliability, performance efficiency and cost optimisation.

AWS provides a huge set of cloud-based services comprising categories like analytics (Amazon CloudSearch, Amazon Athena etc.), application integration (Amazon Simple Notification Service, Amazon MQ etc.), robotics (AWS RoboMaker), compute (AWS Elastic Beanstalk, AWS Lambda etc.), database (Amazon Aurora, Amazon Redshift etc.), and satellite (AWS Ground Station) among others for helping organisations move rapidly, lessen IT costs, and be highly scalable.

Source: AWSDifferent ways to leverage AWS services with Drupal

Drupal, an open-source content management framework, is an astounding digital experience platform that helps you disseminate the right content to the right person at the right time on the right devices. Its great content authoring capabilities, provision of stupendous web performance, multilingual features, high scalability, easy integration with the best tools that are available outside of its periphery, mobile-first approach, multisite offering, and immense security make it one of the leaders in the content management system (CMS) market. No wonder its usage has continuously risen to new heights.

Drupal usage statistics | Source: BuiltWith

Whether you need to deploy a production-ready Drupal website or build innovative solutions with Drupal 8, many of the products from AWS can be of magnificent use in Drupal development. Let’s take a look:

Production grade Drupal configuration

You can deploy a highly available Drupal architecture on the AWS cloud using a quick start guide. This allows you to leverage AWS services and further improve the performance and extend the functionality of your CMS. AWS’ flexible compute, storage and database services make it a top-notch platform for running Drupal workloads.

The core AWS components that are used for this implementation involve the AWS services like EC2 (Elastic Compute Cloud), EFS (Elastic File System), RDS (Relational Database Service), VPC (Virtual Private Cloud), Auto Scaling, CloudFormation, Elastic Load Balancing, IAM (Identity and Access Management), ElastiCache, CloudFront and Route 53.

The AWS Regions assist in governing network latency and regulatory compliance. Regions are designed by taking availability into consideration and comprise at least two availability zones. Regional endpoints are supported by most AWS services thereby minimising data latency as they provide an entry point for service requests in that region. 

Source: AWS

For the deployment of production-grade Drupal configuration, AWS CloudFormation gives you an automated, simple way for creating and handling a collection of related AWS resources. The main template takes care of building the network-related resources first and then the launch of different templates for Drupal and Amazon Aurora ensues. Modularising CloudFormation code involves other templates and the creation of an Amazon Machine Image (AMI) for Drupal requires an additional template that uses AWS Lambda. For installing Drupal on all the instances in the Auto Scaling group, AMI turns out to be effective. This negates the possibility of repeated downloads.

There are optional templates that can be leveraged like deploying an ElastiCache cluster, building CloudFront web distribution and creating DNS (Domain Name System) records in Route 53 public hosted zone. If you use ElastiCache or CloudFront, the configuration of Drupal with requisite default settings is done. Optimisation of Drupal’s caching and content delivery network settings can be done once Drupal stack is deployed. And when you delete the main template, it deletes the entire stack.

This quick start’s highly available reference architecture for Drupal deployment requires an HTTP(S) load balancer, two or more Drupal servers on Apache web server, shared file storage, shared ElastiCache for Memcache cluster, CloudFront distribution, and Route 53. Deployment of Drupal can be done into a new Virtual Private Cloud (VPC) which involves building a new AWS environment comprising VPC, subnets, NAT gateways, security groups, bastion host and a lot of other infrastructure components. Or, the deployment of Drupal can also be done into an existing VPC that enables Drupal in your existing AWS infrastructure.

Alternative to deploying and hosting production-ready Drupal

For deploying a high-availability Drupal website, this AWS documentation another way round. It exhibits the process of deploying and hosting Drupal. In this, the implementation of an architecture, in order to host Drupal for a production workload, requires minimal governance responsibilities from you.

AWS Elastic Beanstalk, Amazon RDS and Amazon EFS can be leveraged. Once the uploading of Drupal files is done, Elastic Beanstalk governs the deployment process automatically that involve application health monitoring, load balancing, capacity provisioning, auto-scaling among others. RDS offers a cost-effective and resizable capacity while managing time-consuming database administration tasks for you.

Serverless implementation using Lambda@Edge Source: AWS

Drupal can also be a fantastic solution for implementing serverless architecture. The union of Amazon CloudFront, Lambda@Edge and headless Drupal can offer the lowest latency and personalised experience to the users. Deployment of CloudFront allows you to cache and accelerate your Drupal content with the assistance from a globally distributed set of CloudFront nodes. In this, every CloudFront distribution constitutes one or more origin locations. An origin is where Drupal content resides. Deployment of Drupal 8 is done running by running the supplied Amazon CloudFormation stacks. In this, AWS services like EC2, EFS, RDS and Aurora are of great use as well. It is all wrapped in a highly available design with the help of multiple Availability Zones and the configuration is done in such a manner that auto-scaling can be successfully done using EC2 Auto Scaling groups.

Creation of URL aliases for the content is done using the path module that is available in Drupal 8. Within the Drupal 8 administration, ‘Aggregate CSS Files’ and ‘Aggregate JavaScript Files’ are enabled by default. Therefore, the need for bandwidth gets reduced between the Origin AWS infrastructure and CloudFront Edge nodes. Internal Drupal caching is disabled by default that has the authority over the maximum amount a time a page could be cached by browsers and proxies. For altering file URLs and easily caching CSS, JavaScript images, audio and videos within CloudFront, it is also suggested to enable Drupal’s CDN module. Subsequently, CloudFront distribution is created with the help of CloudFront console that involves configurations on Origin, default cache behaviour settings and distribution settings.

Interactive screens using AWS IOT

Drupal is an incredible option for building a scalable digital signage solution for a variety of organisations and can reduce costs, speed up time to market, and help in creating engaging experiences for the people. Metropolitan Transportation Authority (MTA), that plays a significant role as the largest public system in the United States of America, has benefitted by leveraging Drupal and AWS IoT services.

Source: Acquia

Drupal, which powers MTA’s website, also helped them to serve content and data to thousands of digital signs in hundreds of stations in New York City. The utilisation of digital signage’s benefit in station countdown clocks has allowed MTA to offer a great customer experience.

The content can be built inside Drupal and data is pulled from external feeds so that countdown clocks can be supplied with data. The data can be pulled from transit information weather and message provider because Drupal is equipped with provider APIs and once the data is given context via Drupal content model, it is pushed to the digital signs. This is done with the assistance of a data pipeline that’s implemented for utilising IoT service from AWS. 

Cross-channel experience with Amazon Alexa

Amalgamation of Amazon Alexa and Drupal can be great for allowing content to be accessed both via web and voice assistants. Alexa Drupal module helps in the integration. For this, Drupal website must be available online and using HTTPS. To begin with, Alexa module can be installed and enabled on the Drupal site followed by the creation of a new Alexa Skills Kit. Subsequently, application ID, that is provided by Amazon in ‘Skill Information’ is to be copied and submitted to the Drupal site’s configuration. Configuration of Alexa skill in Alexa Skills Kit can then be done and a customised handler module can be built for handling custom Alexa skills.

A digital agency used this process to build a solution that leveraged both Alexa and Drupal. This they demonstrated through fictional grocery store called Freshland Market. In this, a user opts for a food recipe from Freshland Market’s Drupal site and gets all the ingredients required to cook the food. The food recipe that was asked by the user was for 8 persons but the site has that information for 4 persons. So, the Freshland Market Alexa skill adjusts the quantity of ingredients by itself for 8 persons. In the midst of an array of questions and the relevant ingredients and cooking procedures that the user involves himself with, the food preparation activity turns out to be very simple for the user and it doesn’t require the user to look at the laptop or mobile phone at any stage.

Open source photo gallery using Amazon Rekognition and Amazon S3

Amazon Rekognition’s powerful face and object recognition capabilities can be leveraged with Drupal to a great extent. Its deep learning feature assesses a plethora of images and then utilises all of that data to label objects and detect faces in separate photos. Amazon S3 can help in storing all the photos on a website in one S3 bucket.
In a bid to create an open and powerful solution for building galleries and sharing images, a digital agency integrated S3, Rekognition and AWS Lambda with Drupal 8. The main objectives behind this implementation of an open source photo gallery were that it should be ‘self-hosted’, be easily able to upload plentitude of photos, use Drupal as a content store, leverage S3 for file storage and utilise Rekognition for automatic face and object recognition. The expected outcome was to make Drupal even better for photo sharing.

Source: Acquia

They succeeded by developing an automated image processing workflow. In this, a user uploads a single picture or a set of pictures to Drupal 8 with the help of Entity Browser Drupal module. With the help of S3 File System module, Drupal, then, stores each of the pictures in an Amazon S3 bucket. For every new picture that gets copied into S3 bucket, an AWS Lambda function is triggered and the Lambda function sends the image to Rekognition. The function, then, receives back facial and object recognition data and calls a REST API  resource on the Drupal 8 site for delivering the data through JSON. Rekognition API Drupal module helped in parsing the data and storing labels and recognised faces in Drupal taxonomies and then relating the labels and faces to the Media Image entity for each of the uploaded pictures.


Drupal 8 keeps setting the bar higher when it comes to ease of use, offering limitless new ways to tailor and deploy your content to the Web, easily customise data structures, listing and pages, reaping the benefits of new capabilities for exhibiting data on mobile devices, building APIs and adapting to multilingual needs. Digital innovation is the forte of Drupal 8. And when AWS services are used along with Drupal, there is no stoppage to building exciting solutions.
We believe in open source innovation and are committed to offering great digital experiences with our expertise in Drupal development. Talk to our Drupal experts at and let us know how do you want us to be a part of your digital transformation endeavours.

blog banner blog image AWS Amazon Web Services Drupal 8 Blog Type Articles Is it a good read ? On
Categories: Drupal Blog: Interview with Maria Totova, co-founder of Drupal Girls: Paying it forward with Drupal mentorship

29 July 2019 - 11:30pm

We had an amazing talk with the super friendly Maria Totova, a driving force behind the Bulgarian Drupal community, organizer of various educational events, avid speaker and co-founder of Drupal Girls. Have a read and learn more about her numerous interesting projects and her love for Drupal. 

Categories: Drupal

OSTraining: Add a Zoom Effect to Your Images in Drupal 8

29 July 2019 - 9:27pm

The Intense Drupal 8 module provides a nice whole screen zoom of the images on your site. Keep reading if you want to learn how to install and use this module with a practical example.

Let’s start!

Categories: Drupal

OSTraining: Add a "Back to Top" Arrow to Your Drupal Site

29 July 2019 - 9:27pm

Sites with long pieces of content or with a long landing page often have a little arrow at the bottom, which helps you get back to the top of the site instead of scrolling the whole way back.

The Back To Top Drupal 8 module helps site-builders who are not yet ready to work with templates or JavaScript to place this kind of button on their sites.

Keep reading to find out how. Let’s start!

Categories: Drupal

CiviCRM Blog: (Development) Towards a clean build of CiviCRM on Drupal 8

29 July 2019 - 4:31pm

In the coming weeks, you can expect a series of changes going into the development pipeline to support the CiviCRM-Drupal 8 integration. Individually, these will seem unrelated and disjoint - they may not explicitly reference “D8”. I wanted to spend a moment to discuss the concept which ties them together: the clean install process, which will make Civi-D8 an equal member of the Civi CMS club and a good base for continued development and maintenance.

This work on D8 stabilization has been made possible by the generous funders of the Civi-D8 Official Release MIH. If you’d like to see more topics addressed, please consider contributing to the MIH.

What do you mean by "clean" install process?

A "clean" install process is a set of steps for building a site in which CiviCRM comes in a direct fashion from source-code with a bare minimum of intermediate steps.

To see this concept in action, we can compare CiviCRM's integrations with Drupal 7 and Joomla:

  • CiviCRM-D7 is amenable to a (comparatively) clean install process. There are three Github projects (“civicrm-core”, “civicrm-packages”, and “civicrm-drupal”) which correspond directly to folders in the web-site. If you copy these projects to the right locations, then you have an (almost) valid source-tree.

  • CiviCRM-Joomla is not amenable to a clean install process. You might think it's similar -- it uses a comparable list of three projects (“civicrm-core”, “civicrm-packages”, “civicrm-joomla”). The problem is that “civicrm-joomla” does not correspond to a singular folder -- the install process requires a diasporadic distribution of files. The install script which handles this is tuned to work from the “” file, and producing that file requires a tool called ”distmaker”. “distmaker” is fairly heavy - it requires more upfront configuration, is brittle about your git status, runs slower, and produces 200+mb worth of zipfiles. In short, building a CiviCRM-Joomla site from clean source is more difficult.

Why does a "clean" process matter?

It's easier to develop and maintain software when the build is clean and intuitive. Specifically:

  • It's easier to climb the ladder of engagement from user/administrator to contributor/developer.

  • It's easier to lend a hand - when someone submits a proposed patch, it's easier to try it out and leave a friendly review.

  • It's easier to setup automated QA processes for evaluating proposals and upcoming releases.

  • It's easier to setup sites for RC testing, issue triage, pre-release demos, and so on.

  • It's easier to pre-deploy a bugfix that hasn't been officially released yet.

Anecdotally, more experts with stronger collaborations have grown-up and stayed around in the Civi-D7 and Civi-WP realms than the Civi-Joomla realm. And that does not feel like a coincidence: as a developer who watches the queue, I'm generally intimidated by a Civi-Joomla patch -- even if it looks simple -- purely on account of the difficult workflow. I believe that a reasonably clean/intuitive build process is prerequisite to a healthy application and ecosystem.

Moreover, a clean build of Civi-D8 is important for Civi's future. Civi-D7 cannot be the reference platform forever - if we expect Civi-D8 to take that mantle, then it needs to be on good footing.

What kind of changes should we expect?

From a infrastructure perspective: Expect automatic setup of D8 test/demo sites - in the same fashion as D7, WordPress, and Backdrop. This means PR testing for "civicrm-drupal-8". For bug triage, it means normalized and current test builds. For release-planning and QA, the test matrices will provide test-coverage for D8 (similar to the other CMS integration tests). These services are blocked on the need for a clean process.

From a site-builder perspective: Expect the recommended template for `composer.json` to be revised. This should improve support for backports and extended security releases. Early adopters may eventually want to update their `composer.json` after this settles down; however, the details are not set in stone yet.

From a developer perspective: Expect the process for setting up `git` repos to become simpler. Instead of using the bespoke `gitify`, you'll be able to use the more common `composer install --prefer-source`.

From a code perspective: Expect changes to code/use-cases which (directly or indirectly) require auto-generated files. For example, when initializing Civi's database, the current Civi-D8 installer relies on “.mysql” files (which have been pre-generated via ”distmaker”); we can replace this with newer function calls which don't require pre-generated files -- and therefore don't depend on ”distmaker” or “”.


ArchitectureDrupalDrupal 8Make it happen
Categories: Drupal

Hook 42: The Return From GovCon 2019

29 July 2019 - 8:57am
The Return From GovCon 2019 Lindsey Gemmill Mon, 07/29/2019 - 15:57
Categories: Drupal Image optimization in Drupal 8 with built-on capabilities

29 July 2019 - 7:08am
Let’s talk about the reasons to optimize images and the ways to use the image optimization in Drupal 8 via the core features. 
Categories: Drupal

Amazee Labs: Decoupled Days Recap: Amazees from around the World

29 July 2019 - 1:57am
Decoupled Days is a conference for anyone who works with decoupled Drupal technology: developers, architects, executives, and even marketers like me. It’s been around since 2017 and focuses on sharing knowledge about back-end CMS development as a content service as well as front-end development for applications that consume that content.
Categories: Drupal

PreviousNext: Functional testing with PHP page objects and Mink

28 July 2019 - 11:30pm

Page objects are a pattern that can be used to write clearer and more resilient test suites. This blog post will explore implementing page objects in PHP with the Mink library.

by Sam Becker / 29 July 2019

There are various PHP libraries for creating and maintaining page objects. In order to create a library that was useful for the current state of PHP functional testing in Drupal, I created a library with the design goals of:

  • Working seamlessly with Drupal core test classes, traits and weitzman/drupal-test-traits.
  • Working with all of Drupal's dev dependency version constraints and not introducing additional dependencies.
  • Exclusively utilising the Mink API, to provide a fast on-ramp for moving existing tests to page objects and for developers to write new page objects using their existing knowledge of Mink.
  • Drawing inspiration from nightwatch.js to provide transferability between PHP and JS functional tests.

Taken from the project page, by implementing page objects:

  • You create tests that are easier to read and maintain.
  • You reduce coupling between test cases and markup.
  • You encourage thorough testing by making the whole process easier.

While these examples will be using sam152/mink-page-objects the principles apply to using any library or indeed plain old objects. First I'll examine a real project test case using Mink directly, written to test a search feature on a Drupal site:

/** * Test how search results appear on the site. */ public function testSearchItemDisplay() { $sample_result = $this->randomMachineName(32); $this->createNode([ 'title' => $sample_result, 'type' => 'news_item', 'body' => ['value' => 'Test news item body'], 'moderation_state' => 'published', ]); $this->searchApiIndexItems(); $this->drupalGet(''); $this->submitForm([ 'query' => $sample_result, ], 'Search'); $this->assertSession()->pageTextContains('1 results for'); $this->assertSession()->elementContains('css', 'h1', $sample_result); $this->assertSession()->elementContains('css', '.sidebar-menu__item--active', 'Show all'); $this->assertSession()->elementContains('css', '.listing', $sample_result); // A news item should not appear when filtering by basic pages. $this->clickLink('Basic page'); $this->assertSession()->pageTextContains('0 results for'); $this->assertSession()->elementContains('css', '.sidebar-menu__item--active', 'Basic page'); $this->clickLink('News item'); $this->assertSession()->elementContains('css', '.sidebar-menu__item--active', 'News item'); $this->assertSession()->elementContains('css', '.listing', $sample_result); }

And now the equivalent test refactored to use a page object:

/** * Test how search results appear on the site. */ public function testSearchItemDisplayPageObject() { $sample_result = $this->randomMachineName(32); $this->createNode([ 'title' => $sample_result, 'type' => 'news_item', 'body' => ['value' => 'Test news item body'], 'moderation_state' => 'published', ]); $this->searchApiIndexItems(); $search_page = SearchPage::create($this); $search_page->executeSearch($sample_result) ->elementContains('@title', $sample_result) ->assertResultCount(1) ->assertResultsContain($sample_result) ->assertActiveFilter('Show all'); $this->clickLink('Basic page'); $search_page->assertActiveFilter('Basic page') ->assertResultCount(0); $this->clickLink('News item'); $search_page->assertActiveFilter('News item') ->assertResultCount(1) ->assertResultsContain($sample_result); }

In the second test, there are a few advantages:

  • The code is more DRY, since selectors on the page aren't repeated. In fact, if the page object was used for all future search tests, they'd never be repeated in a test again!
  • The test uses a more natural language that is easier to parse by readers of the code and communicates the intentions of the author in a clearer fashion.
  • The search page object is type-hinted, making writing new tests fast and reducing the amount of page related knowledge developers must collect and remember.

The cost paid for these benefits is an additional layer of indirection between your test case and the test browser, so to realise the full benefit of such an approach, I'd expect a page object to be written to service at least two different test cases however I haven't experimented implementing this pattern across a large scale test suite.

An annotated version of the page object (for the purposes of demonstration) looks like:

/** * A page object for the search page. */ class SearchPage extends DrupalPageObjectBase { /** * {@inheritdoc} */ protected function getElements() { // Selectors found on the page, these can be referenced from any of the Mink // API calls within this page object. return [ 'title' => 'h1', 'results' => '.listing', 'activeFilter' => '.sidebar-menu__item--active', ]; } /** * Assert the number of results on the search page. * * @param int $count * The number of items. * * @return $this */ public function assertResultCount($count) { $this->assertSession()->pageTextContains("$count results for"); return $this; } /** * Assert a string appears on the page. * * @param string $string * The string that should appear on the page. * * @return $this */ public function assertResultsContain($string) { $this->elementContains('@results', $string); return $this; } /** * Assert a string does not appear on the page. * * @param string $string * The string that should not appear on the page. * * @return $this */ public function assertResultsNotContain($string) { $this->elementNotContains('@results', $string); return $this; } /** * Assert the active filter. * * @param string $filter * The active filter. * * @return $this */ public function assertActiveFilter($filter) { $this->elementContains('@activeFilter', $filter); return $this; } /** * Execute a search query. * * @param string $query * A search query. * * @return $this */ public function executeSearch($query) { $this->drupalGet(''); $this->submitForm([ 'query' => $query, ], 'Search'); return $this; } }

While the library itself is decoupled from Drupal, the DrupalPageObjectBase base class integrates a few additional Drupal features such as UiHelperTrait for methods like ::drupalGet and ::submitForm as well as creating a ::create factory to automatically wire dependencies from Drupal tests into the page object itself.

I would be interested in hearing thoughts on if introducing page objects may benefit Drupal core's own functional test suite and details on how that might be accomplished given the tools available. 

Tagged Testing, Functional Testing, Mink, PHP Libraries
Categories: Drupal Drupal Meetup Bangalore – July 2019

27 July 2019 - 4:40am
The meetup started at 10:30 AM with a brief introduction of every attendee. We covered some of the Drupal news such as recent and upcoming events in India and internationally. We also talked about Drupal 9 and other changes in the technology.
Categories: Drupal

Mediacurrent: Introducing the Rain Install Profile for Drupal

26 July 2019 - 12:49pm

The Mediacurrent team is excited to formally introduce Rain, an enterprise-grade Drupal install profile. Two years in the making, our team has spent countless hours developing these tools internally and deploying them to our client projects.

Our goal with this post is to share with the broader Drupal community, explain why we created Rain, and share how it can benefit your organization. We welcome feedback.

What is Rain? 

The Rain installation packages the best solutions the Drupal community has to offer so that organizations can build sites faster. We have used Rain internally for the last two years, making improvements along the way prior to its release as an open-source project.

Made by Mediacurrent

We designed the Rain install profile with the goal to capture features that overlap all verticals and projects of every size and scope. As part of the development process, we examined features and content patterns from successful client projects over the past three years. Through our research, we found many content features and module configurations did, in fact, apply to projects across the spectrum. Our focus has been to build Rain with the features that create the best admin and authoring experience we can provide for our clients and the open-source community.

Mediacurrent believes strongly in open source solutions, so we have released all of our project tooling to the community. For more information on the tools we have publicly released please visit the Mediacurrent Development Tools page for more information and links to our projects.

Who is Rain for?

It’s a full-time job to simplify processes on the backend and deliver a consistent, high-impact customer experience. Mediacurrent created the Rain Install Profile to make these jobs easier. 

Clients using Rain today include large B2B Enterprise, Higher Education, and Non-profit organizations. The Rain distribution is flexible enough to serve large and small organizations alike. For large enterprise builds, the install profile will reduce overhead and take advantage of reusable features even if the project overall is a highly-customized implementation. Smaller, more budget-conscious organizations have the opportunity to reuse even more out-of-box functionality for further savings. The end result is a fully branded, enterprise-grade Drupal solution for your organization

What makes the Rain Install profile different?

At DrupalCon this year, co-worker Justin Rent and I presented on the idea of “Content Patterns.” This presentation gives a window into the challenges we were facing and our approach to addressing those challenges. In short, we believe to have long-term success as an agency we need to pool together best practices and take advantage of repeatable patterns. While every project we work on is unique in some way, we also see many shared problems that could benefit from common-sense solutions. As an organization, we made a commitment to build tools that would address those problems and share them with the community.

We borrowed from other distributions, Acquia Lightning and Thunder CMS which are both great projects in their own right. We did, however, add our own twist. 

Our approach1. Package and configure common modules

We package popular contributed modules like Metatag and many others that focus primarily on authoring and admin experience. Our installation comes with “sensible defaults” that offer a great out of box experience while saving developer and administrative time.

2. Offer flexible content features to jump-start development

Rain offers a variety of content features, including content types and paragraphs, not found in most distributions. These features are all optional and offer the opportunity to jump-start development. 

We believe our approach to content architecture gives editors a consistent, flexible interface for managing content. At the same time, it helps developers get going faster while being fully configurable. 

3. Ship with an extendable base theme and style guide

Rain ships with an excellent starter base theme.  This offers several advantages but is not required (see our GatsbyJS + Rain webinar for a “decoupled" option).

The theme ships with a base style guide that includes the most common components you’ll find on a website. These components provide basic styling and markup that saves development time. The components are intended to be branded to match the design requirements of a given project. Additionally, all Paragraph features are pre-integrated with the base theme and style guide to once again save development time and reduce costs. The net result -- the development team gets a running start on a new project instead of constantly reinventing the wheel.

Next steps

We would love to hear feedback from you. What features are your pain points, what features would you like to see? Interested in working with Mediacurrent? Contact us for a live Rain demo or for more information about our services. 

Categories: Drupal

Hook 42: Drupal Core Initiative Meetings Recap - July 16th-24th, 2019

26 July 2019 - 12:34pm
Drupal Core Initiative Meetings Recap - July 16th-24th, 2019 Will Thurston-… Fri, 07/26/2019 - 19:34
Categories: Drupal

TEN7 Blog's Drupal Posts: August Drupal Lunch and Learn at Walker Library

26 July 2019 - 8:00am

We’re excited to be hosting the August 2019 TC Drupal monthly meeting, the first in the new "Lunch and Learn" format, which will rotate venues and feature a myriad speakers. See Allie's post about the change on the Twin Cities page. We look forward to them each month!

Categories: Drupal

Hook 42: Does a Bear Drupal in the Woods?

26 July 2019 - 7:32am
Does a Bear Drupal in the Woods? Lindsey Gemmill Fri, 07/26/2019 - 14:32
Categories: Drupal

Srijan Technologies: Run your Drupal 40% cheaper

26 July 2019 - 4:21am

The expanding data landscape is feeding the demand for higher operational agility. This calls for a more responsive, reliable IT infrastructure — that doesn’t rake up millions — minimizes delays and downtime while improving security and making infrastructure more agile.

Between capacity constraints and unpredictable pricing models, AWS offers suited workloads for growing infrastructure needs with a host of services - IaaS, PaaS, SaaS - for Drupal enterprises. 

Here’s how you can run your Drupal up to 40% cheaper.

Drupal-powered enterprises need to constantly understand and adapt to the changing landscape in order to achieve the business objective

Categories: Drupal

ThinkShout: Is My Website Accessible?

26 July 2019 - 4:00am

You know how important accessibility is, but now what? There are a lot of well intentioned sites on the internet that aren’t accessible.

Is your website accessible?

How do you find out?

Well, it’s not as hard as it seems—and we’re here to help! Here are a few quick ways to measure the accessibility of your website.

1. Automated accessibility tests

While automated tools will only catch about 30% of accessibility bugs, they will give you a general idea of your site’s accessibility and show you some ways to make improvements.

Lighthouse: Chrome’s Accessibility Reporting Tool

Lighthouse is a free tool available right in Chrome. You can use it by simply using chrome’s testing website, in your development tools when you inspect a page, or with a browser plugin. Keep in mind that manual testing is also required to get a full picture of accessibility—we’ll cover that in just a moment.

To use the tool by going to a URL: Visit and paste the URL of the page you want tested into the form field, then click “Run Audit” to see results.

To use the tool through inspect

  1. Right click on the webpage you want to test, and select “Inspect” from the dropdown or from your keyboard press command + option + I. This will open the inspect tool and bring up the last tool you used, so if the last thing you did was run an audit, it will bring you back to the audits panel.

  2. In the inspection window at the top right, click on the button with a double arrow, or expand the window until you see “Audits.” Select “Audits.”

  3. Select your device size (mobile or desktop), and select “Accessibility” from the Audit Type options.
  4. Click “Run Audits.”
  5. A report will pop up in the inspect window with your overall score with information about your score results. Scores are out of 100, and 100 does not mean that a site is completely accessible–it means that it passed all automated tests.
  6. Below the score are details about accessibility errors. Toggle open these errors to see what element is failing and how to make fixes.
WAVE: Firefox and Chrome Extension

WAVE is a browser extension that allows you to run an automated accessibility test on a page of your website. It’s very thorough and one of our favorites for testing and fixing accessibility bugs.

To use WAVE:

  1. Install the WAVE Extension
  2. Go to the webpage you want to test, and click on the WAVE icon in the tools portion of your browser window. A report will pop up and your page will be marked up with the results of the review.

  3. A Summary will show up by default listing the number of Errors, Warnings, and other details on the page.

  4. Click on the Flag icon to see more details. This will include information about what errors are on the page

  5. Clicking on the Tab at the bottom of the page that says “< code >” will show you the code marked up with the errors found.
  6. With the “< code >” tab open, you can click on the errors and warnings in the panel on the left to jump to the errors in the code. In the image below, clicking on the yellow rectangle “Redundant Link” icon in the report panel makes the code jump to the offending code.

2. Manual accessibility tests

A manual test will catch things automated tests can’t quite figure out. Robots are good for some things, but they can’t figure out human intention, so things like tab order, visual theming and good alt tags should be manually tested.

Keyboard testing makes sure that the site works for folks who are blind, who have low vision, who have limited mobility, or the person whose trackpad is broken. Conduct the following tests to see if your site is accessible to those using a keyboard to navigate:

  1. Go to the page you’d like to test. Start with your cursor in the address bar, and hit the “tab” button to navigate through the page. Each time you press tab, you should be moved to the next button, link or form input.
  2. Ideally, the first link you get to on the page is a “skip to main content” link that allows users to skip repeated navigation items.

  3. As you continue to tab through the page, you should be able to see where the focus is as it lands on each button, link and form field. Pro-tip: If you lose track of where it is because there’s not a visual indication that’s an accessibility issue.
  4. Check the order: Does pressing the tab key follow the natural flow of the page, or does it jump around? A good tab order follows the natural flow.
  5. Can you operate all menus, pop-ups, buttons, and forms?
  6. Can you press shift tab and navigate backwards?
  7. Are there items that are clickable that don’t receive focus?

Important Note: Keyboard testing needs to be done on mobile as well as desktop. Why? Some users who are blind don’t use full-sized computers or laptops because they don’t actually need a large display. Other users have low vision and magnify their screens. Which leads us to testing with zoom…

3. Testing with zoom

If you zoom a desktop screen to 400% on a responsive site you get…the mobile site! This is why testing on mobile and desktop is important.

Now that you’ve increased the screen to 400%, browse the page. As you browse ask yourself:

  1. Does text content get cut off?
  2. Do buttons get pushed off of the page?
  3. Is the functionality intact?
  4. Is there key functionality on desktop that’s no longer available on the mobile version?
4. Testing with a Screen Reader

Using a screen reader is a more advanced testing approach, and very helpful in identifying accessibility bugs on a site. If you use a mac, VoiceOver is the built in screen reader. To turn VoiceOver on or off, press command f5. Here’s a quick video tutorial on how to test your page using VoiceOver. The video description includes the full text of the captions as a quick reference.

You can also turn on VoiceOver and tab through the page again to see if icon buttons are labeled properly, if the form labels you’ve applied make sense, and if alt tags on images are useful. If you press “control option a” all at once, VoiceOver will start reading every element from where you are on the page. If you tab, it will read the buttons, links and form inputs.

To sum it up:

Learning about different testing methods can help inform and add clarity to the process of making your site accessible. This is one of the most critical steps in your journey to making a website that everyone can experience. If you want to know how to transform these errors into a site that reads and navigates smoothly for all users, ThinkShout is here to help! Contact us to learn more about how we can partner to make your website more accessible.

Categories: Drupal

JD Does Development: Quick Hit: Using Drupal and Symfony Components Without Bootstrapping Drupal

25 July 2019 - 11:47pm
Quick Hit: Using Drupal and Symfony Components Without Bootstrapping Drupal jflynn Fri, 07/26/2019 - 01:47 Sometimes we just want to see if a thing works

Recently I ran into a situation while building out the Watson/Silverpop Webform Parser where I just wanted to test and see if a few things worked without having to reload and bootstrap Drupal every time I refreshed a page. I also wanted to utilize some of the classes and methods made available from Symfony and Drupal. Can you feel my dilemma?

Let's be honest, running drush cr and refreshing a page takes time, and I'm an impatient person, so I wanted to see if there was a way to use some of these things without going through the pain of waiting for a Drupal bootstrap. Turns out, the solution wasn't that difficult and it made development on many methods of my module more pleasant than it could have been.

Here's the scenario

I wanted to test a few things that didn't require the database connection. Specifically, Drupal\Core\Serialization\Yaml to parse an array that I was building into YAML. So, what I did was stubbed out what would become my class WatsonFormEntityForm in a file in my docroot that I creatively named test.php. Now I was able to navigate to local.docksal/test.php on my local machine and see things working.

Get to the good stuff, already!

I got to a point in my development where I was able to convert the submitted HTML, in this case from a call to file_get_contents('./test.html'); into an array that I could work with. Xdebug was going great, and so was the module, but I wanted to see if I could convert it into YAML using a native Drupal method. The solution came with one single line of code.

$autoloader = require_once 'autoload.php';

This tells PHP, "Hey, we got a file here that wants to use some of the methods and classes in the Autoloader. Let's go ahead and let it!" This variable doesn't need to be called anywhere in the file. It just needs to exist. Now I was able to update the file with a few friendly use statements from within the Drupal and Symfony ecosystem without having to wait for all the database connections to happen.

The end result was:

<?php use Drupal\Core\Serialization\Yaml; $autoloader = require_once 'autoload.php'; // Do all the things here, including: $yaml = Yaml::encode($array); var_dump($yaml);

It sped up development, and it made it so I didn't have to wonder if something wasn't working because I forgot to drush cr all the things or if it was just because I made some mistakes.


Be sure that any code you're running doesn't rely on database calls or the container. For instance, if you try to run $nodes = \Drupal::entityTypeManager()->getStorage('node')->loadMultiple(); is going to throw a painful error.

Also, this is mainly for rapid prototyping or proving concepts. I don't recommend writing an entire module in procedural code and then trying to refactor later. Maybe take it one function at a time just to make sure it's doing what you want it to do.

Let me know if this helped you out or if you have better suggestions for rapidly testing some Drupal stuff without having to rely on a full bootstrap. As always, feel free to reach out to me on the Drupal Slack, where I'm always Dorf and always willing to help if I can.

Category Development Tags Drupal Drupal Planet Comments
Categories: Drupal