Drupal Planet

Subscribe to canal de noticias Drupal Planet
Drupal.org - aggregated feeds in category Planet Drupal
Actualizado: hace 17 mins 20 segs

Dries Buytaert: Acquia a leader in 2019 Gartner Magic Quadrant for Web Content Management

Jue, 08/01/2019 - 14:36

For the sixth year in a row, Acquia has been recognized as a leader in the Gartner Magic Quadrant for Web Content Management. Acquia first entered the Web Content Management Magic Quadrant back in 2012 as a Visionary, and since then we've moved further than any other vendor to cement our leadership position.

As I've written before, analyst reports like the Gartner Magic Quadrant are important because they introduce organizations to Acquia and Drupal. As I've put if before If you want to find a good coffee place, you use Yelp. If you want to find a nice hotel in New York, you use TripAdvisor. Similarly, if a CIO or CMO wants to spend $250,000 or more on enterprise software, they often consult an analyst firm like Gartner..

In 2012, Gartner didn't fully understand the benefits of Acquia being the only WCM company who embraced both Open Source and cloud. Just seven years later, our unique approach has forever changed web content management. This year, Acquia moved up again in both of the dimensions that Gartner uses to rank vendors: Completeness of Vision and Ability to Execute. You'll see in the Magic Quadrant graphic that Acquia has tied Sitecore for the first time:

Acquia recognized as a leader, next to Adobe, Sitecore and Episerver, in the 2019 Gartner Magic Quadrant for Web Content Management.

I believe we would have placed even higher had our Mautic acquisition completed a bit earlier.

In mature markets like Web Content Management, there is almost always a single proprietary leader and a single Open Source leader. There is Oracle and MongoDB. Splunk and Elastic. VMWare and Docker. Gitlab and Github. That is why I believe that next year it will be Acquia and Adobe at the very top of the WCM Magic Quadrant. Sitecore and Episerver will continue to fight for third place among companies who prefer a Microsoft-centric approach. I was not surprised to see Sitecore move down this year as they work to overcome technical product debt and cloud transition, leading to strange decisions like acquiring a services company.

You can read the complete report on Acquia.com. Thank you to everyone who contributed to this result!

Drupal Association blog: It's Time To Vote - Community Elections 2019

Jue, 08/01/2019 - 14:09

Voting is now open for the 2019 At-Large Board positions for the Drupal Association! If you haven't yet, check out the candidate’s profiles. Get to know your candidates, and then go vote.

Cast Your Vote!

Voting is open to all individuals who had a Drupal.org account by the time nominations opened and who have logged in at least once in the past year. You do not have to have a Drupal Association membership.

To vote, you will rank candidates in order of your preference (1st, 2nd, 3rd, etc.). The results will be calculated using an "instant runoff" method. For an accessible explanation of how instant runoff vote tabulation works, see videos linked in this discussion.

Election voting is from 1 August, 2019 through 16 August, 2019. During this period, you can continue to review and comment on the candidate profiles.

Have questions? Please contact me: Rachel Lawson.

Agaric Collective: Drupal migrations: Understanding the ETL process

Jue, 08/01/2019 - 11:12

The Migrate API is a very flexible and powerful system that allows you to collect data from different locations and store them in Drupal. It is in fact a full-blown extract, transform, and load (ETL) framework. For instance, it could produce CSV files. Its primarily use, thought, is to create Drupal content entities: nodes, users, files, comments, etc. The API is thoroughly documented and their maintainers are very active in the #migration slack channel for those needing assistance. The use cases for the Migrate API are numerous and vary greatly. Today we are starting a blog post series that will cover different migrate concepts so that you can apply them to your particular project.

Understanding the ETL process

Extract, transform, and load (ETL) is a procedure where data is collected from multiple sources, processed according to business needs, and its result stored for later use. This paradigm is not specific to Drupal. Books and frameworks abound on the topic. Let’s try to understand the general idea by following a real life analogy: baking bread. To make some bread you need to obtain various ingredients: wheat flour, salt, yeast, etc. (extracting). Then, you need to combine them in a process that involves mixing and baking (transforming). Finally, when the bread is ready you put it into shelves for display in the bakery (loading). In Drupal, each step is performed by a Migrate plugin:

The extract step is provided by source plugins.
The transform step is provided by process plugins.
The load step is provided by destination plugins.

As it is the case with other systems, Drupal core offers some base functionality which can be extended by contributed modules or custom code. Out of the box, Drupal can connect to SQL databases including previous versions of Drupal. There are contributed modules to read from CSV files, XML documents, JSON and SOAP feeds, WordPress sites, LibreOffice Calc and Microsoft Office Excel files, Google Sheets, and much more.

The list of core process plugins is impressive. You can concatenate strings, explode or implode arrays, format dates, encode URLs, look up already migrated data, among other transform operations. Migrate Plus offers more process plugins for DOM manipulation, string replacement, transliteration, etc.

Drupal core provides destination plugins for content and configuration entities. Most of the time targets are content entities like nodes, users, taxonomy terms, comments, files, etc. It is also possible to import configuration entities like field and content type definitions. This is often used when upgrading sites from Drupal 6 or 7 to Drupal 8. Via a combination of source, process, and destination plugins it is possible to write Commerce Product Variations, Paragraphs, and more.

Technical note: The Migrate API defines another plugin type: `id_map`. They are used to map source IDs to destination IDs. This allows the system to keep track of records that have been imported and roll them back if needed.

Drupal migrations: a two step process

Performing a Drupal migration is a two step process: writing the migration definitions and executing them. Migration definitions are written in YAML format. These files contain information about the how to fetch data from the source, how to process the data, and how to store it in the destination. It is important to note that each migration file can only specify one source and one destination. That is, you cannot read form a CSV file and a JSON feed using the same migration definition file. Similarly, you cannot write to nodes and users from the same file. However, you can use as many process plugins as needed to convert your data from the format defined in the source to the format expected in the destination.

A typical migration project consists of several migration definition files. Although not required, it is recommended to write one migration file per entity bundle. If you are migrating nodes, that means writing one migration file per content type. The reason is that different content types will have different field configurations. It is easier to write and manage migrations when the destination is homogeneous. In this case, a single content type will have the same fields for all the elements to process in a particular migration.Once all the migration definitions have been written, you need to execute the migrations. The most common way to do this is using the Migrate Tools module which provide Drush commands and a user interface (UI) to run migrations. Note that the UI for running migrations only detect those that have been defined as configuration entities using the Migrate Plus module. This is a topic we will cover in the future. For now, we are going to stick to Drupal core’s mechanisms of defining migrations. Contributed modules like Migrate Scheduler, Migrate Manifest, and Migrate Run offer alternatives for executing migrations.


This blog post series is made possible thanks to these generous sponsors. Contact Understand DRupal if your organization would like to support this documentation project, whether the migration series or other topics.

Read more and discuss at agaric.coop.

CTI Digital: CTI Digital at Drupal Camp Pannonia 2019

Jue, 08/01/2019 - 04:30

We’re thrilled to be attending Drupal Camp Pannonia from the 1st to 3rd August!

Drupal Atlanta Medium Publication: Drupal. The Next Generation. They Are Out There.

Mié, 07/31/2019 - 08:57
Approaching 20 years old, the Drupal Community must prioritize recruiting the next generation of Drupal ProfessionalsFerris Wheel in Centennial Olympic Park in Atlanta, Georgia

Time flies when you are having fun. One of those sayings I remember my parents saying that turned out to be quite true. My first Drupal experience was nearly 10 years ago and within a blink of an eye, we have seen enormous organizations adopt and commit to Drupal such as Turner, the Weather Channel, The Grammys, and Georgia.gov.

Throughout the years, I have been very fortunate to meet a lot of Drupal community members in person but one thing I have noticed lately is that nearly everyone’s usernames can be anywhere between 10–15 years old. What does that mean? As my dad would say, it means we are getting O — L — D, old.

For any thriving community, family business, organization, or your even favorite band for that matter, all of these entities must think about succession planning. Succession what, what is succession planning?

Succession planning is a process for identifying and developing new leaders who can replace old leaders when they leave, retire or die. -Wikipedia

That's right, we need to start planning a process for identifying who can take over in leadership roles that continue to push Drupal forward. If we intend to keep Drupal as a viable solution for large and small enterprises, then we should market ourselves to the talent pool as a viable career option to help in an attempt to lure talent to our community.

There are many different way’s to promote our community and develop new leaders. Mentorship. Mentorship helps ease the barrier for entry into our community by providing guidance into how our community operates. Our community does have some great efforts taking place in the form of mentoring such as Drupal Diversity & Inclusion (DDI) initiative, the core mentoring initiative and of course the code and mentoring sprints at DrupalCon and DrupalCamps. These efforts are awesome and should be recognized as part of a larger strategic initiative to recruit the next generation of Drupal professionals.

Companies spend billions of dollars a year in recruiting but as an open-source community, we don’t have billions so

… what else can we do to attract new Drupal career professionals?The Drupal Career Summit

This year’s Atlanta Drupal Users’s Group (ADUG) decided to develop the Drupal Career Summit, all in an effort to recruit more professionals into the Drupal community. Participants will explore career opportunities, career development, and how open source solutions are changing the way we buy, build, and use technology.

  • Learn about job opportunities and training.
  • Hear how local leaders progressed through their careers and the change open source creates their clients and business.
  • Connect one-on-one with professionals in the career you want and learn about their progression, opportunities, challenges, and wins.
When and Where Is it?

On Saturday, September 14 from 1pm -4:30pm. Hilton Garden Inn Atlanta-Buckhead 3342 Peachtree Rd., NE | Atlanta, GA 30326 | LEARN MORE

Who Should Attend?

Student and job seekers can attend for FREE! The Summit will allow you to meet with potential employers and industry leaders. We’ll begin the summit with a panel of marketers, developers, designers, and managers that have extensive experience in the tech industry, and more specifically, the Drupal community. You’ll get a chance to learn about career opportunities and connect with peers with similar interests.

REGISTERAre You Hiring?

We’re looking for companies that want to hire and educate. You can get involved with the summit by becoming a sponsor for DrupalCamp Atlanta. Sponsors of the event will have the opportunity to engage with potential candidates through sponsored discussion tables and branded booths. With your sponsorship, you’ll get a booth, a discussion table, and 2 passes! At your booth, you’ll get plenty of foot traffic and a fantastic chance to network with attendees.

BECOME A SPONSORWhat you can do?

If you can’t physically attend our first Career Summit, you can still donate to our fundraising goals. And if you are not in the position to donate invite your employer, friends, and colleagues to participate. Drupal Career Summit.

Drupal. The Next Generation. They Are Out There. was originally published in Drupal Atlanta on Medium, where people are continuing the conversation by highlighting and responding to this story.

Spinning Code: Bypass Pantheon Timeouts for Drupal 8

Mié, 07/31/2019 - 08:30

Pantheon is an excellent hosting service for both Drupal and WordPress sites. But to make their platform work and scale well they have set a number of limits built into the platform, these include process time limits and memory limits that are large enough for the vast majority of projects, but from time to time run you into trouble on large jobs.

For data loading and updates their official answer is typically to copy the database to another server, run your job there, and copy the database back onto their server. That’s fine if you can afford to freeze updates to your production site, setup a process to mirror changes into your temporary copy, or some other project overhead that can be limiting and challenging. But sometimes that’s not an option, or the data load takes too long for that to be practical on a regular basis.

I recently needed to do a very large import for records into a Drupal database and so started to play around with solutions that would allow me to ignore those time limits. We were looking at needing to do about 50 million data writes and the running time was initially over a week to complete the job.

Since Drupal’s batch system was created to solve this exact problem it seemed like a good place to start. For this solution you need a file you can load and parse in segments, like a CSV file, which you can read one line at a time. It does not have to represent the final state, you can use this to actually load data if the process is quick, or you can serialize each record into a table or a queue job to actually process later.

One quick note about the code samples, I wrote these based on the service-based approach outlined in my post about batch services and the batch service module I discussed there. It could be adapted to a more traditional batch job, but I like the clarity the wrapper provides for breaking this back down for discussion.

The general concept here is that we upload the file and then progressively process it from within a batch job. The code samples below provide two classes to achieve this, first is a form that provides a managed file field which create a file entity that can be reliably passed to the batch processor. From there the batch service takes over and using a bit of basic PHP file handling to load the file into a database table. If you need to do more than load the data into the database directly (say create complex entities or other tasks) you can set up a second phase to run through the values to do that heavier lifting. 

To get us started the form includes this managed file:

$form['file'] = [ '#type' => 'managed_file', '#name' => 'data_file', '#title' => $this->t('Data file'), '#description' => $this->t('CSV format for this example.'), '#upload_location' => 'private://example_pantheon_loader_data/', '#upload_validators' => [ 'file_validate_extensions' => ['csv'], ], ];

The managed file form element automagically gives you a file entity, and the value in the form state is the id of that entity. This file will be temporary and have no references once the process is complete and so depending on your site setup the file will eventually be purged. Which all means we can pass all the values straight through to our batch processor:

$batch = $this->dataLoaderBatchService->generateBatchJob($form_state->getValues());

When the data file is small enough, a few thousand rows at most, you can load them all right away without the need of a batch job. But that runs into both time and memory concerns and the whole point of this is to avoid those. With this approach we can ignore those and we’re only limited by Pantheon’s upload file size. If they file size is too large you can upload the file via sftp and read directly from there, so while this is an easy way to load the file you have other options.

As we setup the file for processing in the batch job, we really need the file path not the ID. The main reason to use the managed file is they can reliably get the file path on a Pantheon server without us really needing to know anything about where they have things stashed. Since we’re about to use generic PHP functions for file processing we need to know that path reliably:

$fid = array_pop($data['file']); $fileEntity = File::load($fid); $ops = []; if (empty($fileEntity)) { $this->logger->error('Unable to load file data for processing.'); return []; } $filePath = $this->fileSystem->realpath($fileEntity->getFileUri()); $ops = ['processData' => [$filePath]];

Now we have a file and since it’s a csv we can load a few rows at time, process them, and then start again.

Our batch processing function needs to track two things in addition to the file: the header values and the current file position. So in the first pass we initialize the position to zero and then load the first row as the header. For every pass after that we need to find point we left off. For this we use generic PHP files for loading and seeking the current location:

// Old-school file handling. $path = array_pop($data); $file = fopen($path, "r"); ... fseek($file, $filePos); // Each pass we process 100 lines, if you have to do something complex // you might want to reduce the run. for ($i = 0; $i < 100; $i++) { $row = fgetcsv($file); if (!empty($row)) { $data = array_combine($header, $row); $member['timestamp'] = time(); $rowData = [ 'col_one' => $data['field_name'], 'data' => serialize($data), 'timestamp' => time(), ]; $row_id = $this->database->insert('example_pantheon_loader_tracker') ->fields($rowData) ->execute(); // If you're setting up for a queue you include something like this. // $queue = $this->queueFactory->get(‘example_pantheon_loader_remap’); // $queue->createItem($row_id); } else { break; } } $filePos = (float) ftell($file); $context['finished'] = $filePos / filesize($path);

The example code just dumps this all into a database table. This can be useful as a raw data loader if you need to add a large data set to an existing site that’s used for reference data or something similar.  It can also be used as the base to create more complex objects. The example code includes comments about generating a queue worker that could then run over time on cron or as another batch job; the Queue UI module provides a simple interface to run those on a batch job.

I’ve run this process for several hours at a stretch.  Pantheon does have issues with systems errors if left to run a batch job for extreme runs (I ran into problems on some runs after 6-8 hours of run time), so a prep into the database followed by running on queue or something else easier to restart has been more reliable.

View the code on Gist.

OPTASY: Best of July: Top 5 Drupal Blog Posts that We Have Bookmarked this Month

Mié, 07/31/2019 - 04:45
Best of July: Top 5 Drupal Blog Posts that We Have Bookmarked this Month adriana.cacoveanu Wed, 07/31/2019 - 07:45

It's that time of the month again! The time when we express our thanks to those Drupal teams who've generously (and altruistically) shared valuable free content with us, the rest of the community. Content with an impact on our own workflow and our Drupal development process. In this respect, as usual, we've handpicked 5 Drupal blog posts, from all those that we've bookmarked this month, that we've found most “enlightening”.


Palantir: The Wisconsin Department of Employee Trust Funds

Mar, 07/30/2019 - 19:24

Re-platforming the Wisconsin Department of Employee Trust Funds website from HTML templates to Drupal 8, including a complete visual and user experience redesign.

etf.wi.gov 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 Palantir.net, 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

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

Mar, 07/30/2019 - 16:34
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…

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

Mar, 07/30/2019 - 12:05

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 drupalci.org (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, drupal.org 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 drupal.org 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. Drupal.org 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.

https://t.co/hf2ENvlZSo 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! pic.twitter.com/l1OWwOllBK

— 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.

OpenSense Labs: Harnessing AWS services with Drupal

Mar, 07/30/2019 - 06:34
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 hello@opensenselabs.com 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

Agiledrop.com Blog: Interview with Maria Totova, co-founder of Drupal Girls: Paying it forward with Drupal mentorship

Mar, 07/30/2019 - 03:30

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. 


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

Mar, 07/30/2019 - 01:27

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!

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

Mar, 07/30/2019 - 01:27

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!

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

Lun, 07/29/2019 - 20:31

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 “civicrm-X.Y.Z-joomla.zip” 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 civicrm.org 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 “setup.sh”.


ArchitectureDrupalDrupal 8Make it happen

Hook 42: The Return From GovCon 2019

Lun, 07/29/2019 - 12:57
The Return From GovCon 2019 Lindsey Gemmill Mon, 07/29/2019 - 15:57

wishdesk.com: Image optimization in Drupal 8 with built-on capabilities

Lun, 07/29/2019 - 11:08
Let’s talk about the reasons to optimize images and the ways to use the image optimization in Drupal 8 via the core features. 

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

Lun, 07/29/2019 - 05:57
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.

PreviousNext: Functional testing with PHP page objects and Mink

Lun, 07/29/2019 - 03:30

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